专注IOS平台 C++语言 cocos2d-x引擎 lua脚本
unity3D学习笔记之七 RectTransform与屏幕适配
市面上的移动游戏UI布局分为两种：
1.全屏铺满
2.小屏居中
两种布局引出两种布局方式
相对布局和绝对布局
Image相对Panel顶部距离20 即Image尺寸跟随Panel尺寸改变 唯一固定的是距离顶部的距离20不变
此种对应全屏铺满的UI，比如返回按钮始终在右上角20像素出。
Image位置不随Panel变化
此种布局对应小屏居中 在不同的分辨率上 屏幕变宽变高之后小屏始终居中，到四周边界会随分辨率变化。
Unity3D-UGUI框架是开源的，但是布局组件RectTransform的实现却是不可见的。。只有官方寥寥数言的文档可参考，又到了考验灵感和耐心的时候了。
void SetSizeWithCurrentAnchors(RectTransform.Axis axis, float size);按照的当前的anchor信息来设置尺寸。实际测试发现他根据的是pviot，设置的结果与anchors反而无关。
Image height = 640
SetSizeWithCurrentAnchors(RectTransform.Axis.Vertical,610);
运行后更改对象的高度为610
至于是从上 中 下 哪部份减少30取决于pivot
pivot.y = 0 从上减少30
pivot.y = 1 从下减少30
pivot.y = 0.5 从两端各减少15
void SetInsetAndSizeFromParentEdge(RectTransform.Edge edge, float inset, float size);这个函数可以简单的理解为设置图元相对父图元边的距离以及图元的尺寸，其强大之处在于其完全不管你当前的pviot设置的啥，你的anchor设置的又是啥。
SetInsetAndSizeFromParentEdge (RectTransform.Edge.Left, 40, 960);
距离父节点左侧40 宽度960
sizeDelta：这个属性表示的就是offsetMax-offsetMin得到的向量，即图元从左下角指向右上角得到的向量。绝对布局下很好用，相对布局时不如所愿，猜测内部重新赋值了。
没有更多推荐了，unity 做打飞机游戏 背景怎么做分辨率适配_百度知道
unity 做打飞机游戏 背景怎么做分辨率适配
我有更好的答案
HTML页面可采用自适应布局或者响应式布局。自适应布局，使用百分比宽度来自适应屏幕大小。响应式布局，使用CSS的@media规则，根据不用屏幕大小范围，编写多个CSS样式，来适应多种屏幕大小。
采纳率：84%
来自团队：
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。unity 使用Ngui 屏幕适配问题
一、当下移动设备的主流分辨率(数据来自“”)
1.1 iOS设备的分辨率主要有：
Android设备的分辨率则相对纷杂，主流的分辨率有：
二、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_
即，改变了NGUI原有的“高度适配”原则，转为“宽度适配”，使得整个页面都得以显示，而由于UIAnchor的存在，UI的左右间距保持不变，但上下间距会变大。
该方法可以实现为一个MonoBehaviour脚本(UICameraAdjustor.cs)，挂载到UICamera同一个节点上，代码如下：
1 using UnityE
2 using System.C
4 /// &summary&
5 /// 根据设备的宽高比，调整camera.orthographicSize. 以保证UI在不同分辨率(宽高比)下的自适应
6 /// 须与UIAnchor配合使用
7 /// 将该脚本添加到UICamera同一节点上
8 /// &/summary&
10 [RequireComponent(typeof(UICamera))]
11 public class UICameraAdjustor : MonoBehaviour
float standard_width = 1024f;
float standard_height = 600f;
float device_width = 0f;
float device_height = 0f;
void Awake()
device_width = Screen.
device_height = Screen.
SetCameraSize();
private void SetCameraSize()
float adjustor = 0f;
float standard_aspect = standard_width / standard_
float device_aspect = device_width / device_
if (device_aspect & standard_aspect)
adjustor = standard_aspect / device_
camera.orthographicSize =
总之，在使用该方法后，当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不会在纵向或横向上的间距过大，显得特别离谱。按照此宽高比，我们选择的尺寸来制作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都将占用的atlas。所以全屏背景在制作时，高度上做出一定的冗余尺寸，以使宽高比小于1.7时，高度上放大系数不会太大，避免图片严重失真。
　　加入冗余尺寸后的脚本(UIBackgroundAjustor.cs)如下：
1 using UnityE
2 using System.C
4 /// &summary&
5 /// 根据设备的宽高比，调整UISprite scale, 以保证全屏的背景图在不同分辨率(宽高比)下的自适应
6 /// 将该脚本添加到UISprite同一节点上
7 /// 须与UICameraAdjustor脚本配合使用
8 /// &/summary&
10 [RequireComponent(typeof(UISprite))]
11 public class UIBackgroundAdjustor : MonoBehaviour
float standard_width = 1024f;
float standard_height = 600f;
float device_width = 0f;
float device_height = 0f;
void Awake()
device_width = Screen.
device_height = Screen.
SetBackgroundSize();
private void SetBackgroundSize()
UISprite m_back_sprite = GetComponent&UISprite&();
if (m_back_sprite != null && UISprite.Type.Simple == m_back_sprite.type)
m_back_sprite.MakePixelPerfect();
float back_width = m_back_sprite.transform.localScale.x;
float back_height = m_back_sprite.transform.localScale.y;
float standard_aspect = standard_width / standard_
float device_aspect = device_width / device_
float extend_aspect = 0f;
float scale = 0f;
if (device_aspect & standard_aspect) //按宽度适配
scale = device_aspect / standard_
extend_aspect = back_width / standard_
else //按高度适配
scale = standard_aspect / device_
extend_aspect = back_height / standard_
if (extend_aspect &= scale) //冗余尺寸足以适配，无须放大
else //冗余尺寸不足以适配，在此基础上放大
scale /= extend_
m_back_sprite.transform.localScale *=
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 (缩放类型)
这是一个简单的枚举变量，包括三个枚举值
（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。（这就是我前面吐槽的原因）
（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树的进行“等比”缩放（宽度的缩放比也是此比例值），这样，我们就可以做一套资源，在不同尺寸的分辨率最好的“不变形”的适配了
前面两组在什么情况下等同呢？
Manual Height == Minimum Height == Maximum Height
推导过程，呵呵~~
具体可参考UIRoot中activeHeight属性和GetPixelSizeAdjustment的计算过程
4.这也许并不够
基于以上推到，当我们以为标准分辨率做一套UI资源（也就是选择FixedSize并且Manual Height=768），似乎可以满足百分之90以上的机型了，而为什么是呢？
既然我们已经容忍在除之外的其他设备上进行等比缩放了，那为什么不是960x640呢？
计算一下的宽高比=1.33，960x640的宽高比=1.5，这就是移动设备的分辨率比例的全部了吗？
当然不是，iphone5的比例就要大于1.5，还有各种奇葩的android设备呢，比如夏新的n828就是960x540，宽高比=1.78
那为什么以为标准呢？
因为1.33的宽高比，当我们的的资源到960x640的设备上时会有什么现象？
根据Manual Height / Screen Height的比例可知，我们需要缩放768 / 640 = 1.2倍，假设是一张的纹理，高度缩放1.2倍变为了640，宽度也要相应缩放1.2倍变为853（保证等比缩放不变形），也就是说的资源放到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），拿到的分辨率上，高度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组件的大小做限制！
没有更多推荐了，[Unity3d]谈谈UI分辨率适配
多种分辨率的UI适配一直以来都是游戏开发的一个麻烦点，开发当中都是在美术和程序里的工作量寻求一个平衡点。
目前主流的UI适配设计还是以锚点定位为主，锚点定位的话，开发确实非常方便。设计人员定好每个UI要挂在哪个锚点上，刷刷刷啥也不管哪个分辨率怎么下UI会怎么显示了。不过锚点是会有它的局限性，首先设计上需要针对每种分辨率进行显示规避，要在局限的条件下设计良好的UI交互确实是对UI设计师的一个挑战。锚点定位就几乎不能做占满横条或竖条的设计了。
还有一种就是我所在上个项目佳佳做的UI配置文件适配，原理大概就是针对每个比例的分辨率记录每个UI的大小和位置（摆好每个比例的UI，然后点击按钮生成配置），然后在游戏运行时读取相应分辨率的UI配置文件来还原适配好的UI。这个做法就是不需要规避设计，但是这个方案修改操作比较麻烦。如果你要修改一个UI的交互，你需要在调节每一种比例的配置文件。人工操作的成本有点高。
以上两种都是比例适配较多，高清（例如NEW
IPAD）适配可能就比较麻烦了。如果确实有这样不能拉伸的需求（需要UI非常精致那种），只能做两套UI了。然后用NGUI的retina适配插件做相应适配。
事实上，一般游戏都不需要做到那么精致，直接用960或1024的UI拉伸到2048的程度，虽然有一些毛边，但是还是能够接受的，市面上的NEW
IPAD大部分UI都是这样搞的。
另，需要注意的是，如果你不希望UI被拉伸，又不想在高清分辨率手机上显示图标过小，可以考虑下修改手机的显示分辨率。
在U3D的Screen类下，有个Screen.SetResolution()函数，可以设置相应的渲染分辨率。IOS导出XCODE之前的build
setting的other settings下的target
device设置也可以修改IOS相应的分辨率。具体我也不多说了，大家查手册吧。
修改显示分辨率好处：
1.达到你的UI适配效果。
2.假设你觉得你们游戏在高清分辨率的手机跑起来慢的话，修改了这个，相应的像素渲染便少了很多。从而大大提高游戏的运行帧率。
1.事实上它还是拉伸了UI。
2.因为分辨率低了，显示屏确实有那个精度的视网格，所以场景中的3D模型边缘显示锯齿很明显。可以通过在quality
setting下的效果开抗锯齿选项来解决问题。（当然开抗锯齿是挺耗性能的）。
这个适配方式也不错：
最近还是比较忙，邮件若几天没回复都属于正常，但有空我也一定会抽时间回下的，后面也会花点时间整理下这些问题发出来大家参考相互学习。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。