上篇文章了说了UMG对于不同分辨率通过调整DPI Scale来进行缩放，使得布局正确。并且我们也看到1280X720的设计界面，设置DPI为1.5以后，在1920x1080的设备也能显示良好，But，事情到此并未结束。我们稍微细心检查一下，就会发现，1280x720是16:9,1920x1080也是16:9，宽高正好可以通过1.5进行等比缩放，那如果一个设备的宽高比不是16:9呢？1440x900是16:10，如果按照之前的思想，1280x720的按钮长这样

1920x1080的按钮长这这样

那么1440x900的按钮，横向缩放是1400/1280=1.12，竖向缩放是1200/720=1.25。就应该长这样

 

看起来明显比较奇怪，我们并不希望在1440x900的屏幕上把界面拉伸成这个模样。 我们对于缩放的要求是等比缩放，所以要么是按照1280到1440来进行放大，要么是按照720到900来进行放大。问题来了，到底该按照那个方向来进行缩放？

假如按照长边1440来放大，则整体放大1.12倍，成下面这个样子。

横向虽然充满屏幕了，但竖向上因为720*1.125=810，并没有到900，所以下面漏出了一段空白区域。

如果按照短边900放大，则整体放大1.25倍，成下面这个样子。

竖向虽然充满屏幕了，但横向上因为1280*1.25=1600，比1440要大，所以右边伸出去了一段。

这其实是一个无解的问题，因为实际屏幕大小只要和设计大小不是等比缩放的，就会遇见这种要么下面漏出，要么右边伸出的问题。所以UE4给出的方案是让开发者自己去选择缩放标准，上面截图的右下角有个设置按钮，点开后打开如下设置界面

开发者可以设置DPI Scale Rule，这是个枚举类型，有下面参数可以设置

ShortestSide：按照短边缩放（本文中按照1440x900中的900缩放，右边伸出）

LongestSide：按照长边缩放（本文中按照1440x900中的1440缩放，下面漏出）

Horizontal：按照水平缩放（本文中按照1440x900中的900缩放，右边伸出）

Vertical：按照竖直缩放（本文中按照1440x900中的900缩放，右边伸出）

ScaleToFit：自适应缩放。

Custom：自定义缩放。

我们发现ShortestSide和Vertical很像，缩放短边，LongestSide和Horizontal很像，缩放长边，但它们之间还是有区别的。Vertical和Horizon不管长边短边，进行固定方向的缩放，而ShortestSide则会判断哪边是短边，如果竖向是短边，则按照竖向进行缩放，如果横向是短边（比如手机屏幕），则按照横向进行缩放。

Horizontal如下图，可见始终是按照水平方向进行缩放的。Vertical类似。

Longest如下图，可见当水平缩短到比竖直还短的时候，竖直变成了长边，即使水平继续缩短，因为竖直作为长边没有改变，所以缩放也不再改变。

ScaleToFit：自适应缩放。这种缩放方式不再使用DPI Curve作为依据，而使用ScaleToFitRule，DesignScreenSize来作为标准参照，比如我们的界面在设计的时候标准是1280x720，则到实际设备的时候，就用实际设备的大小和1280作计算，得出DPI Scale，根据我的测试，这个缩放规则和Horitontal、Vertical、Longest、Shortest都不一样，当长宽比小于设计大小时（长度相对更短），会按照长度缩放，长宽比超过设计大小时，（长度相对更长），会按照宽度缩放。

最简单的就是选择ScaleToFit，然后设定我们的参照标准是1280x720，具体设备的缩放就让UMG自动去计算（漏出问题，可以通过全屏填充解决）。

OK，那么既然有这么多种设置，那么在实际开发中，我们到底应该采用哪种设置？

Longest和Horizontal要谨慎使用，我们知道现在手机设备有很多种分辨率，以1920x1080的16:9为标准的话，绝大多数的设备长宽比都大于16:9，这意味着如果按照长边缩放，必然会导致UMG在高度上过度放大，导致显示区域超出屏幕，想象一下一个超宽显示器玩游戏，横向缩放3倍以后，游戏中的道具背包也会被缩放3倍，从而超出竖向的显示区域，而如果按照高度缩放，则此时高度还是1080，所以不会发生任何缩放，道具背包的大小尺寸就是不变的。

以高度为缩放依据（shortest或者vertical），如何保证背包界面紧贴着屏幕右侧？这个可以通过锚点解决，只要把背包界面锚在右边即可。

下一篇，我们再对Widget的LocalSize和AbsoluteSize等函数进行简单地研究。