unity 使用Ngui 屏幕适配问题

原文地址：http://blog.csdn.net/onerain88/article/details/11713299/

一、当下移动设备的主流分辨率(数据来自“ 腾讯分析移动设备屏幕分辨率分析报告 ”)

1.1 iOS设备的分辨率主要有：

 

宽	高	宽高比
960	640	1.5
1136	640	1.775
1024	768	1.3333
2048	1536	1.3333

 

Android设备的分辨率则相对纷杂，主流的分辨率有：

宽	高	宽高比
800	480	1.6667
854	480	1.7792
1280	720	1.7778
960	540	1.7778
1280	800	1.6
960	640	1.5
1184	720	1.6444
1920	1080	1.7778

二、NGUI默认的多分辨率适配原则

NGUI本身按照“高度适配”的原则进行多分辨率下的UI适配，其默认的高度通过 UIRoot.manualHeight 设置。再配合使用 UIAnchor 便可实现一定程度的多分辨率适配。

 

其中，在Unity Editor下按照 UIRoot.manualHeight 设定的高度，编辑UI页面。这样，当UI页面在目标设备上显示时，NGUI按照目标设备的高度(targetHeight)来调整UIRoot节点的scale，以使整个UI页面适应目标设备的高度。比如manualHeight=400，而targetHeight=800，那么UIRoot的scale将被乘以2。所以，当 目标设备的宽高比与所 编辑页面的宽高比一致时，整个UI将完美显示；当目标设备宽高比小于所编辑的宽高比时，页面宽度将大于设备宽度，使得多出的部分无法显示；而当目标设备宽高比大于所编辑宽高比时，页面宽度小于设备宽度，设备两边将出现黑边。

 

而UIAnchor则是将整个页面分为TopLeft/Top/TopRight/Left/Center/Right/BottomLeft/Bottom/BottomRight九个区域，挂载了UIAnchor组件的节点都将按照设置自动停靠到相应的区域中。有了UIAnchor，上面的两个问题将被一定程度的解决：当目标设备宽高比小于编辑的宽高比时，由于UIAnchor的自动停靠功能，UI不会被裁切掉，但UI之间的左右间距将相应变小，便有可能出现UI重叠的问题；当目标设备宽高比大于所编辑宽高比时，UI之间的左右间距将变大，好在这样起码不会有UI被裁切或重叠。

 

看似我们只需要解决UI重叠的问题就搞定了。不过让我们再仔细想一下，一张铺满整个屏幕的UISprite不管是否使用UIAnchor，在目标设备宽高比更小时，sprite都会在横向上被裁切，而将目标设备宽高比更大时，sprite都不能铺满整个屏幕。

 

问题出来了：

1. 当目标设备宽高比更小时的UI重叠问题

2. 当目标设备宽高比更小时，全屏sprite被裁切问题

3. 当目标设备宽高比更大时，全屏sprite不能铺满整个屏幕的问题

 

 

三、解决问题

首先定义几个变量：

standard_width　　编辑页面的原始宽度

standard_height　　编辑页面的原始高度

device_width　　　　目标设备的宽度

device_height　　　　目标设备的高度

standard_aspect　　编辑页面的宽高比

device_aspect　　　　目标设备的宽高比

 

1. 目标设备宽高比更小时的UI重叠问题

　　当device_aspect小于standard_aspect时，UIRoot根据device_height调整其scale大小，因而使得设备宽度不足以显示整个页面。我们调整Camera.orthographicSize(仅适用2D GUI)，以足够显示页面的宽度。令

　　Camera.orthographicSize = standard_aspect / device_aspect;

即，改变了NGUI原有的“高度适配”原则，转为“宽度适配”，使得整个页面都得以显示，而由于UIAnchor的存在，UI的左右间距保持不变，但上下间距会变大。

该方法可以实现为一个MonoBehaviour脚本( UICameraAdjustor.cs)，挂载到UICamera同一个节点上，代码如下：

 

 1 using UnityEngine;
 2 using System.Collections;
 3 
 4 /// <summary>
 5 /// 根据设备的宽高比，调整camera.orthographicSize. 以保证UI在不同分辨率(宽高比)下的自适应
 6 /// 须与UIAnchor配合使用
 7 /// 将该脚本添加到UICamera同一节点上
 8 /// </summary>
 9 
10 [RequireComponent(typeof(UICamera))]
11 public class UICameraAdjustor : MonoBehaviour
12 {
13     float standard_width = 1024f;
14     float standard_height = 600f;
15     float device_width = 0f;
16     float device_height = 0f;
17 
18     void Awake()
19     {
20         device_width = Screen.width;
21         device_height = Screen.height;
22 
23         SetCameraSize();
24     }
25 
26     private void SetCameraSize()
27     {
28         float adjustor = 0f;
29         float standard_aspect = standard_width / standard_height;
30         float device_aspect = device_width / device_height;
31 
32         if (device_aspect < standard_aspect)
33         {
34             adjustor = standard_aspect / device_aspect;
35             camera.orthographicSize = adjustor;
36         }
37     }
38 }

 

总之，在使用该方法后，当device_aspect大于standard_aspect时，UI按照高度适配原则，UI的上下间距不变，左右间距变大；当device_aspect小于standard_aspect时，UI按照宽度适配原则，UI的左右间距不变，上下间距变大。

 

2. 目标设备宽高比更小时，全屏sprite被裁切问题

　　全屏背景的sprite被裁切可能在很多情况下不会成为什么问题，但在我们使用了解决问题1中的方法后，这里的“被裁切问题”就变为了同问题3类似的“不能铺满整个屏幕问题”。解决方法是放大sprite scale:

　　sprite.transform.localScale *= ( standard_aspect / device_aspect );

这样会使得sprite在横向上被裁切，宽高比不同必然的结果... 当然也可以选择只调整高度或宽度，只要能接受变形...

 

3. 目标设备宽高比更大时，全屏sprite不能铺满整个屏幕的问题

 　　同问题2，解决方法同样是放大sprite scale:

　　sprite.transform.localScale *= ( device_aspect / standard_aspect );

这样会使得sprite在纵向上被裁切。

 

问题2和3的解决方法相应脚本( UIBackgroundAjustor.cs)会在文章后面给出。

该脚本须挂载到sprite同一节点上，配合UIAnchor使用，可以选择是裁切方向。如UIAnchor停靠方式使用center，则sprite会被左右两边或上下裁切，若使用Top，则会左右裁切或下边裁切。

总之，全屏sprite会始终铺满整个屏幕，不会出现黑边。当device_aspect大于standard_aspect时，全屏sprite按照宽度适配，纵向裁切；当device_aspect小于standard_aspect时，按照高度适配，横向裁切。

 

四、优化

1. UI页面的制作尺寸按 1024 X 600

　　前面讲到主流分辨率的情况，其平均宽高比(除ipad2/3/4以外)大概为1.7，与主流的宽高比都不会偏差很大。即，在使用上面的多分辨率解决方法时，UI不会在纵向或横向上的间距过大，显得特别离谱。按照此宽高比，我们选择1024x600的尺寸来制作UI，并严格要求UI制作时，页面分为TopLeft/Top/TopRight/Left/Center/Right/BottomLeft/Bottom/BottomRight九个区域，以便挂载UIAnchor。

 

2. 全屏背景的制作按 1024 X 768

　　如果全屏背景图也按1024 x 600制作，在ipad2/3/4上就会有较大程度的放大。同时考虑到NGUI的打包atlas，使用2的幂次尺寸，高度600和768都将占用1024x1024的atlas。所以全屏背景在制作时，高度上做出一定的冗余尺寸，以使宽高比小于1.7时，高度上放大系数不会太大，避免图片严重失真。

　　加入冗余尺寸后的脚本( UIBackgroundAjustor.cs)如下：

 1 using UnityEngine;
 2 using System.Collections;
 3 
 4 /// <summary>
 5 /// 根据设备的宽高比，调整UISprite scale, 以保证全屏的背景图在不同分辨率(宽高比)下的自适应
 6 /// 将该脚本添加到UISprite同一节点上
 7 /// 须与UICameraAdjustor脚本配合使用
 8 /// </summary>
 9 
10 [RequireComponent(typeof(UISprite))]
11 public class UIBackgroundAdjustor : MonoBehaviour
12 {
13     float standard_width = 1024f;
14     float standard_height = 600f;
15     float device_width = 0f;
16     float device_height = 0f;
17 
18     void Awake()
19     {
20         device_width = Screen.width;
21         device_height = Screen.height;
22 
23         SetBackgroundSize();
24     }
25 
26     private void SetBackgroundSize()
27     {
28         UISprite m_back_sprite = GetComponent<UISprite>();
29 
30         if (m_back_sprite != null && UISprite.Type.Simple == m_back_sprite.type)
31         {
32             m_back_sprite.MakePixelPerfect();
33             float back_width = m_back_sprite.transform.localScale.x;
34             float back_height = m_back_sprite.transform.localScale.y;
35 
36             float standard_aspect = standard_width / standard_height;
37             float device_aspect = device_width / device_height;
38             float extend_aspect = 0f;
39             float scale = 0f;
40 
41             if (device_aspect > standard_aspect) //按宽度适配
42             {
43                 scale = device_aspect / standard_aspect;
44 
45                 extend_aspect = back_width / standard_width;
46             }
47             else //按高度适配
48             {
49                 scale = standard_aspect / device_aspect;
50 
51                 extend_aspect = back_height / standard_height;
52             }
53 
54             if (extend_aspect >= scale) //冗余尺寸足以适配，无须放大
55             {
56             }
57             else //冗余尺寸不足以适配，在此基础上放大
58             {
59                 scale /= extend_aspect;
60                 m_back_sprite.transform.localScale *= scale;
61             }
62         }
63     }
64 }

另外一个说法

NGUI在Unity3D游戏开发中非常常用，而NGUI对于每一个UI场景，都是以一个UIRoot为UI游戏对象树的根的，那么这个UIRoot是起什么作用的呢？

先简单看一下UIRoot中的基本属性

UIRoot游戏对象的属性只有4个，分别是缩放规则，手动高度，最小高度和最大高度

而正是这4个属性，将影响整个UI场景中整体的缩放比例，当设置好这4个属性之后，UIRoot游戏对象的相对缩放值(LocalScale)将会生成并且不能被直接修改（NGUI中很多属性都是不能直接被修改的，这种控制是在UIRoot脚本中，通过设置[ExecuteInEditMode]做到的，其相对缩放值是根据UIRoot的4个属性计算出来的），那么这4个属性分别是什么含义呢？

（吐槽一下，也许这里的用户体验并不足够友好，因为Manual Height和Minimum Height, Maximum Height并不会同时起作用，如果能做到在选择Scaling Style时动态的切换，使用者也许能更清楚它们之间的关系）

1.Scaling Style (缩放类型)

这是一个简单的枚举变量，包括三个枚举值

 public enum Scaling
     {
         PixelPerfect,
         FixedSize,
         FixedSizeOnMobiles,
     }

（FixedSize和FixedSizeOnMobiles类似，并且后者只添加了对ios和android平台的判断，所以前者可以替代后者使用）

这里只讨论PixelPerfect和FixedSize的区别，两者都是针对于所有在此UIRoot之下的UI组件而言的，也可以认为是在此UIRoot下，整个游戏屏幕的尺寸的缩放类型！

2.Manual Height和Minimum Height, Maximum Height (手动高度和最小高度，最大高度)

Manual Height和Minimum Height, Maximum Height不会同时对此UIRoot起作用，当选择Scaling Style为PixelPerfect时，我们需要设置Minimum Height, Maximum Height；而当Scaling Style为FixedSize或FixedSizeOnMobiles时，我们需要设置Manual Height。（这就是我前面吐槽的原因）

3.使用

（1）PexelPerfect和Minimum Height, Maximum Height

这个组合主要用于我们期望所有的UI纹理都“尽量”不进行缩放，所谓“尽量”的程度，则是取决于Minimum Height和Maximum Height，Minimum Height表示当设备分别率小于此设置值时，根据此设置值对UIRoot进行缩放；Maximum Height表示当设备分辨率大于此设置值时，根据此设置值对UIRoot进行缩放（UIRoot是UI游戏对象树的根，修改UIRoot的缩放，则会影响整棵UI树的缩放）

（2）FixedSize和Manul Height

这个组合主要用于我们期望所有的UI纹理都进行“合适”的缩放，所谓“合适”缩放的原则，则是根据Manual Height设置值，当设备分辨率的高度值不同于此设置值时，则根据其比例（即Manual Height / Screen Height）对整棵UI树的进行“等比”缩放（宽度的缩放比也是此比例值），这样，我们就可以做一套资源，在不同尺寸的分辨率最好的“不变形”的适配了

（3）交集

前面两组在什么情况下等同呢？

Manual Height == Minimum Height == Maximum Height 

推导过程，呵呵~~

具体可参考UIRoot中activeHeight属性和GetPixelSizeAdjustment的计算过程

4.这也许并不够

基于以上推到，当我们以1024x768为标准分辨率做一套UI资源（也就是选择FixedSize并且Manual Height=768），似乎可以满足百分之90以上的机型了，而为什么是1024x768呢？

既然我们已经容忍在除1024x768之外的其他设备上进行等比缩放了，那为什么不是960x640呢？

计算一下1024x768的宽高比=1.33，960x640的宽高比=1.5，这就是移动设备的分辨率比例的全部了吗？

当然不是，iphone5的比例就要大于1.5，还有各种奇葩的android设备呢，比如夏新的n828就是960x540，宽高比=1.78

那为什么以1024x768为标准呢？

因为1.33的宽高比，当我们的1024x768的资源到960x640的设备上时会有什么现象？

根据Manual Height / Screen Height的比例可知，我们需要缩放768 / 640 = 1.2倍，假设是一张1024x768的纹理，高度缩放1.2倍变为了640，宽度也要相应缩放1.2倍变为853（保证等比缩放不变形），也就是说1024x768的资源放到960x640上反而两边有了黑边，这是我们可以容忍的，我们可以做一个很大的背景或者拉伸，保证UI组件不变形即可，很多游戏都是这么做的，比如植物大战僵尸在iphone5和ipad上看到的背景视野并不一样大！

当放到夏新的机器上呢？

我们需要缩放768 / 540 = 1.4倍，宽度1024 / 1.4 = 731，这是可以的，只是看起来更怪一些，因为两边的黑边相对比例更大了（960 - 731=229的黑边区域）

而我表示android机器的分辨率奇葩到只有想不到，没有做不到的程度，也许宽高比1.7并不是终点，当遇到1.8之后，黑边的相对比例会更大。。。

5.问题又来了

假设我们的游戏类型更适合iphone手机玩，不太适合ipad，所以我希望能以960x640为标准做一套资源，可以吗？

我只能说不太可以，因为你要在设计UI组件的大小做限制了，为什么需要做限制？

假设我有一张纹理是960x640大小的，在iphone上铺满整屏，根据我们的设置（FixedSize和Manual Height=640），拿到1024x768的分辨率上，高度640 / 768 = 0.83，为了保证等比缩放，宽度960 / 0.83 = 1156，不幸的事情发生了，1156 > 1024，这个UI组件宽度超过了屏幕的宽度，被裁剪了。。。这是我们不能容忍的，或许你可以说我们尽量不做这种尺寸的UI，OK，你可以对UI尺寸加限制，但是当面对android那些奇葩的分辨率的时候，你会发现限制越来越大，这也许会让美术和策划疯掉！

6.解决方案

当我们花上一些时间去观察现在移动设备的分辨率时，虽然奇葩很多，但是还是有一些规律的，规律的在于宽高比而不在于具体尺寸，大体上划分一下宽高比在1.3,1.5,1.7的范围上的居多（基本是全部吧！）即便是再有1.2,1.8的比例也无妨。。。

NGUI为我们提供的方案只有以各种高度为衡量标准是不够的，我们应该加上一种以宽度为衡量标准的缩放类型

而对于UI资源的标准，我们选取960x640，宽高比为1.5

这样，当我们在兼容大于1.5的尺寸的时候，使用NGUI的现有方案；当我们在兼容小于1.5的尺寸的时候，使用以宽度为衡量标准

也就是说有一个类似Manual Width的属性，当小于1.5时，我们使用Manual Width / Screen Width得出整棵UI树的缩放比例！

这样做的好处是“黑边”区域不会太大，并且不需要对UI组件的大小做限制！