2024年1月20日发(作者：行月怡)
移动设备分辨率众多，为了让你的游戏在多数手机分辨率下都保持良好的效果和体验，需要做一些专门的适配策略。适配方案有很多，不同的游戏根据自身的特点，适用不同的方案。
本文以天天德州为例，列举一些我们探索过的方案，并进行效果比较。希望能够给在这方面摸索的同学一些参考。
手机常用分辨率：
IOS屏幕分辨率
960*640 iPhone4, iPhone4s
1136*640 iPhone5 (包括5/5C/5S)
480*320 iPhone3,3gs
1024*768 iPad1, iPad2, iPad mini
2048*1536 iPad Air
Android屏幕分辨率
800*480 华为中兴等许多国产手机
480*320 老一代Android手机中使用
1280*720 三星i9300、三星Galaxy Note II、n7100、索尼lt26i、小米二代
1920*1080 小米3、OPPO Find 5、HTC Butterfly、努比亚Z5S
分辨率占比
(图1)
这个占比数据是来源于腾讯云分析《移动行业2014年第一季度数据报告》/mta/bigdata/?p=441
为了得到一个更直观的数据，我们可以把众多分辨率的高度归一化，比较它们的宽高比。
（图2）
主流分辨率的宽高比范围在1.33~1.77
若游戏采取用系统原生的开发方法编写游戏逻辑，不跨平台。比如博雅德州扑克，在安卓和ios平台下，他们是两个独立的项目组在开发。安卓用Eclipse+java开发，ios用xcode + object c开发。这样UI的设计当然可以用各自平台提供的相对完善的UI布局机制，适配方案就按官方文档指导的方案做就可以了。
若游戏使用OpenGL来渲染，要自己实现UI的布局机制和逻辑。在不同的分辨率下就要考虑分辨率的转换和UI元素位置、大小的相应调整。
资源分辨率：
我们美术制作时，会先在一个特定的分辨率下制作场景，设置场景大小，按钮位置等。这个分辨率叫资源分辨率。
(图3)
设计分辨率：
美术资源制作完成后，要在手机上显示前，需要先做一个缩放，缩放后的分辨率叫设计分辨率。
(图4)
适配的过程大概就是上图的两个步骤。
假设资源分辨率是RH*RW，设计分辨率是DH*DW。
以横屏游戏举例，屏幕分辨率是568*355，资源分辨率是1136*640
我们有若干方案可以实现上面的过程。
方案一：等比拉伸，UI元素全部显示，留黑边
设置缩放值scale = SW/RW=568/1136=0.5, DW=SW=568，DH =
640*0.5=320，资源分辨率和屏幕分辨率宽高比有差异时，就会留出黑边。如图：
(图5)
要解决黑边问题，可以在纵向强行拉伸到全屏，这样横向和纵向的缩放比例不一样，会产生视觉偏差。如下图，设计分辨率从568*320拉成了568*355，宽高比从1.6变到1.77，头像变的有点椭圆。
(图6)
为了控制宽高比变动的过多，避免过分拉伸图像，这种方案需要继续做一些措施。
回顾我们一开始的一些常用分辨率的统计，宽高比范围基本在1.33-1.77，在这个区间我们可以选取几个分辨率，分别做对应的资源。适配时选取和屏幕宽高比最相近的分辨率进行拉伸。大概原理如图：
(图7)
宽高非等比拉伸对比：
(图8)
(图9)
方案优点：
美术设计布局场景时，不用引入相对布局，元素动态拉伸等概念和机制，逻辑上简化了布局过程，美术逻辑上的工作量减轻了。
方案缺点：
需要维护多套资源，比较繁琐。
分辨率不完全匹配时，元素还是会出现拉伸。
一旦常用分辨率宽高比出现明显变化，资源的制作也要跟着走，比较被动。
比如未来某一天流行了这样宽高比1:1的分辨，就要多搞一套资源：
(图10)
所以此种方案逻辑制作简单，适合逻辑思维不强的美术团队。或引入相对布局，动态拉伸等机制，底层改动成本较大。
方案二：竖向为准，等比拉伸，UI元素超出，不留黑边
设置缩放值scale=SH/RH=355/640=0.55, DW=RW*0.55=630，DH=SH=355，资源分辨率和屏幕分辨率有差异时，两边的UI元素可能就会超出可视范围。
(图11)
例子：1136*640的资源等比缩小到640/355，放在568*355的分辨率下显示，两边元素超出显示区域。因为DW=630>568。
若采用此方案，不考虑相对布局，不考虑多套资源。以横屏游戏为例，美术设计时，就需要把元素尽量往中间放，调整到以1.33的宽高比，两边的UI元素都能显示完整。背景尽量做宽，调整到以1.77的宽高比都能盖满。
方案优点：
一旦游戏确定是横屏或竖屏，代码改动很少就能适配，只要考虑左右两边的元素做靠边处理即可，UI的布局逻辑和动画的逻辑基本不用修改。
方案缺点：
设计不太灵活，以横屏游戏为例，元素布局要考虑1.33宽高比，背景覆盖要考虑到1.77宽高比，这样的假设在某些游戏不一定能接受。
方案三：设计分辨率等比拉伸，背景全屏拉伸
(和方案一的设置一样)设置缩放值scale =
SW/RW=568/1136=0.5, DW=SW=568，DH = 640*0.5=320，资源分辨率和屏幕分辨率宽高比有差异时，就会留出黑边。但此时，我们不是把所有元素纵向强制拉伸，只是全屏拉伸背景层。按钮，头像等UI元素保持着等比拉伸，视觉上不会有偏差。
(图12)
背景的拉伸有两种方式：
(图13)
(图14)
背景等比拉伸要考虑的问题：超出的背景被剪裁了是否能接受。
背景非等比拉伸要考虑的问题：背景非等比变形了是否有影响视觉效果。
如图12所示，采用这种方案，背景拉伸了后，需要处理元素靠边的问题，这里就要引入相对布局的机制，支持贴边布局等。相对布局等机制实现方式很多，可以做的很完备复杂，也可以做的简单够用。这里就不做详术。（以下是参考android的layout布局来做的）
(图15)
(图16)
（图17）
方案的优点：
自动适配到所有分辨率，按钮等UI元素保留比例，不会出现视觉偏差。一旦掌握了相对布局的技巧，界面制作也是相对高效，免去了多套资源。
方案的缺点：
引入了相对布局等概念，美术设计人员需要重新适应学习，重现布置场景
若界面布局逻辑上比较复杂，就需要比较完备的布局机制(相对布局，弹性拉伸，等比拉伸，动态计算，设置百分比，margin/padding，dock等一系列的实现，开发成本高)
结语：
本文以天天德州这个横屏游戏为例，列举了一些我们尝试的适配方案。并分析了各自的优缺点。适配方案可以做的很复杂完备，也可以做的简单够用即可。这需要结合具体的游戏设计、开发成本、实现难度、资源编辑器的支持做出选择。方案没有绝对的好坏，只有适不适用。
2024年1月20日发(作者：行月怡)
移动设备分辨率众多，为了让你的游戏在多数手机分辨率下都保持良好的效果和体验，需要做一些专门的适配策略。适配方案有很多，不同的游戏根据自身的特点，适用不同的方案。
本文以天天德州为例，列举一些我们探索过的方案，并进行效果比较。希望能够给在这方面摸索的同学一些参考。
手机常用分辨率：
IOS屏幕分辨率
960*640 iPhone4, iPhone4s
1136*640 iPhone5 (包括5/5C/5S)
480*320 iPhone3,3gs
1024*768 iPad1, iPad2, iPad mini
2048*1536 iPad Air
Android屏幕分辨率
800*480 华为中兴等许多国产手机
480*320 老一代Android手机中使用
1280*720 三星i9300、三星Galaxy Note II、n7100、索尼lt26i、小米二代
1920*1080 小米3、OPPO Find 5、HTC Butterfly、努比亚Z5S
分辨率占比
(图1)
这个占比数据是来源于腾讯云分析《移动行业2014年第一季度数据报告》/mta/bigdata/?p=441
为了得到一个更直观的数据，我们可以把众多分辨率的高度归一化，比较它们的宽高比。
（图2）
主流分辨率的宽高比范围在1.33~1.77
若游戏采取用系统原生的开发方法编写游戏逻辑，不跨平台。比如博雅德州扑克，在安卓和ios平台下，他们是两个独立的项目组在开发。安卓用Eclipse+java开发，ios用xcode + object c开发。这样UI的设计当然可以用各自平台提供的相对完善的UI布局机制，适配方案就按官方文档指导的方案做就可以了。
若游戏使用OpenGL来渲染，要自己实现UI的布局机制和逻辑。在不同的分辨率下就要考虑分辨率的转换和UI元素位置、大小的相应调整。
资源分辨率：
我们美术制作时，会先在一个特定的分辨率下制作场景，设置场景大小，按钮位置等。这个分辨率叫资源分辨率。
(图3)
设计分辨率：
美术资源制作完成后，要在手机上显示前，需要先做一个缩放，缩放后的分辨率叫设计分辨率。
(图4)
适配的过程大概就是上图的两个步骤。
假设资源分辨率是RH*RW，设计分辨率是DH*DW。
以横屏游戏举例，屏幕分辨率是568*355，资源分辨率是1136*640
我们有若干方案可以实现上面的过程。
方案一：等比拉伸，UI元素全部显示，留黑边
设置缩放值scale = SW/RW=568/1136=0.5, DW=SW=568，DH =
640*0.5=320，资源分辨率和屏幕分辨率宽高比有差异时，就会留出黑边。如图：
(图5)
要解决黑边问题，可以在纵向强行拉伸到全屏，这样横向和纵向的缩放比例不一样，会产生视觉偏差。如下图，设计分辨率从568*320拉成了568*355，宽高比从1.6变到1.77，头像变的有点椭圆。
(图6)
为了控制宽高比变动的过多，避免过分拉伸图像，这种方案需要继续做一些措施。
回顾我们一开始的一些常用分辨率的统计，宽高比范围基本在1.33-1.77，在这个区间我们可以选取几个分辨率，分别做对应的资源。适配时选取和屏幕宽高比最相近的分辨率进行拉伸。大概原理如图：
(图7)
宽高非等比拉伸对比：
(图8)
(图9)
方案优点：
美术设计布局场景时，不用引入相对布局，元素动态拉伸等概念和机制，逻辑上简化了布局过程，美术逻辑上的工作量减轻了。
方案缺点：
需要维护多套资源，比较繁琐。
分辨率不完全匹配时，元素还是会出现拉伸。
一旦常用分辨率宽高比出现明显变化，资源的制作也要跟着走，比较被动。
比如未来某一天流行了这样宽高比1:1的分辨，就要多搞一套资源：
(图10)
所以此种方案逻辑制作简单，适合逻辑思维不强的美术团队。或引入相对布局，动态拉伸等机制，底层改动成本较大。
方案二：竖向为准，等比拉伸，UI元素超出，不留黑边
设置缩放值scale=SH/RH=355/640=0.55, DW=RW*0.55=630，DH=SH=355，资源分辨率和屏幕分辨率有差异时，两边的UI元素可能就会超出可视范围。
(图11)
例子：1136*640的资源等比缩小到640/355，放在568*355的分辨率下显示，两边元素超出显示区域。因为DW=630>568。
若采用此方案，不考虑相对布局，不考虑多套资源。以横屏游戏为例，美术设计时，就需要把元素尽量往中间放，调整到以1.33的宽高比，两边的UI元素都能显示完整。背景尽量做宽，调整到以1.77的宽高比都能盖满。
方案优点：
一旦游戏确定是横屏或竖屏，代码改动很少就能适配，只要考虑左右两边的元素做靠边处理即可，UI的布局逻辑和动画的逻辑基本不用修改。
方案缺点：
设计不太灵活，以横屏游戏为例，元素布局要考虑1.33宽高比，背景覆盖要考虑到1.77宽高比，这样的假设在某些游戏不一定能接受。
方案三：设计分辨率等比拉伸，背景全屏拉伸
(和方案一的设置一样)设置缩放值scale =
SW/RW=568/1136=0.5, DW=SW=568，DH = 640*0.5=320，资源分辨率和屏幕分辨率宽高比有差异时，就会留出黑边。但此时，我们不是把所有元素纵向强制拉伸，只是全屏拉伸背景层。按钮，头像等UI元素保持着等比拉伸，视觉上不会有偏差。
(图12)
背景的拉伸有两种方式：
(图13)
(图14)
背景等比拉伸要考虑的问题：超出的背景被剪裁了是否能接受。
背景非等比拉伸要考虑的问题：背景非等比变形了是否有影响视觉效果。
如图12所示，采用这种方案，背景拉伸了后，需要处理元素靠边的问题，这里就要引入相对布局的机制，支持贴边布局等。相对布局等机制实现方式很多，可以做的很完备复杂，也可以做的简单够用。这里就不做详术。（以下是参考android的layout布局来做的）
(图15)
(图16)
（图17）
方案的优点：
自动适配到所有分辨率，按钮等UI元素保留比例，不会出现视觉偏差。一旦掌握了相对布局的技巧，界面制作也是相对高效，免去了多套资源。
方案的缺点：
引入了相对布局等概念，美术设计人员需要重新适应学习，重现布置场景
若界面布局逻辑上比较复杂，就需要比较完备的布局机制(相对布局，弹性拉伸，等比拉伸，动态计算，设置百分比，margin/padding，dock等一系列的实现，开发成本高)
结语：
本文以天天德州这个横屏游戏为例，列举了一些我们尝试的适配方案。并分析了各自的优缺点。适配方案可以做的很复杂完备，也可以做的简单够用即可。这需要结合具体的游戏设计、开发成本、实现难度、资源编辑器的支持做出选择。方案没有绝对的好坏，只有适不适用。