天天系列移动游戏开发之适配篇

手机游戏的适配一直都是个难题，从多年前的J2ME时代起就是。iOS和Android的出现曾经让大家以为Apple和Google会意识到这个问题，移动开发者梦想着不需要再为设备碎片化的问题而苦恼了。

伟大的水果公司在这一点上坚持的很不错，到目前为止也只有5个不同的分辨率（480*320/960*640/1024*768/2048*1536/1136*640），而且480*320与960*640、1024*768与2048*1536属于一脉相承；而可能更加伟大Google的就完全让人失望了，众多分辨率带来的问题还是一如既往的让人头痛，而且还不仅是分辨率，加上各种手机性能的巨大差异和一些定制的ROM，让开发者望而却步。

    既然问题主要在Android平台上，那么下面的内容也都主要基于Android平台。

一、从什么维度来做机型覆盖

    有同学提出按以下几个维度来做海量机型的覆盖：

1）屏幕尺寸；

2）OS版本；

3）品牌；

4）典型机型。

同时依托公司的平台优势，根据微信、手Q、手机管家，拿到Top10、Top50等机型数据，再根据实际的项目和目标用户的情况来选取覆盖的机型。

这些是无数项目积累来的经验，当然没有问题。但这个更多的是从测试的角度来看，而这里想讨论的是从开发的角度来看，如何能够让游戏在尽可能多的设备上正常的运行。

这个实际上要可以分为两个问题：

1）屏幕适配：就是如何让游戏能够正常的显示在不同分辨率的设备上；

2）运行适配：也就是通常说的兼容性适配，要让游戏在尽可能多设备上run起来。

二、屏幕适配

Android平台上应用开发的屏幕适配，是通过编辑布局文件Layout.xml来完成。操作系统的GUI库根据Layout.xml来生成对应的GUI控件，并完成整个界面的显示。

游戏则不一样。iOS和Android平台上的游戏大部分都是使用OpenGl渲染的，所有的显示适配需要游戏自己来做。通常的做法有几种：

1）根据不同的分辨率，不等比拉伸画面至完全充满屏幕。简单粗暴，在屏幕宽高比差异很大的时候，效果很差。

2）根据不同分辨率，等比拉伸画面，如果有空余部分就刷黑边。由于使用等比拉伸，视觉效果上略好于第一种，但在大多数屏幕上都会显示黑边，或者在上下部分，或者在左右部分，无法充分利用屏幕。

3）支持锚点、dock等相对位置机制，相对复杂一些，效果也会好很多。

  如果详细的划分，这个部分也能分为两块：

1）UI适配；

2）游戏内画面适配。

1、UI适配

主要是菜单控件的排布，可以参考Scaleform、NGUI等工具。我们在平时的开发中，也积累了自己的比较完整的UI适配解决方案，尤其合适移动游戏使用。

    下面简单介绍一下我们的思路：

1）首先我们会确定一个基准分辨率，所有的资源都会以这个基准分辨率来制作。

目前大致需要支持的屏幕最小从480*320到最大的1080P，跨度非常大。我们通常选取iPhone4的屏幕大小960*640作为主分辨率。因为800*480~1280*720之间是目前最主流的分辨率，而960*640正好在这两者之间。如果游戏内存压力较大，可以考虑使用800*480作为主分辨率来制作资源。

2）构建控件树

每个UI都由一个UI控件树组成，所有的控件的显示大小和位置都是根据这棵数从根到叶子计算得来。

3）设置每个控件相对于父控件的大小和位置

我们对控件的位置和大小存储的都不是直接存储的像素值（x，y）和（w，h），而是把每个值分解成两个部分，比如w，我们使用（wk，wb）来描述，wk是相对于父控件大小的比例，wb相当于一个偏移或者校正值。还有一些额外的描述信息，如是否接受不等比拉伸（长和宽方向的不等比拉伸）等。

计算公式如下：         w = Base * wk + wb

Base是一个与父控件大小相关的值：

A）当控件接受不等比拉伸时，Base就是父控件当前的宽度

B）当控件只接受等比拉伸时，Base是根据父控件宽高中相对短的一边和基准分辨率计算得到的一个值。

根据这个公式，可以描述任意大小和位置要求的控件，并且可以根据基准分辨率的大小来计算在不同分辨率下最佳的显示效果。

对于控件高度、位置都使用类似的计算方法。

    分辨率854*480图
 

    分辨率1024*768图

2、游戏内画面适配

这个与游戏本身特点相关，没有什么通用的做法根据不同的游戏特点采取合适的做法即可。

比如天天爱消除，不论屏幕分辨率如何，需要优先保证正方形的游戏区域。在大多数手机上，为了保证手感，使这个区域尽可能的大一些，方便玩家操作。

再比如天天酷跑，需要考虑任务角色大小、滚屏速度、玩家前方的可视区域大小，如果这些配合的不好，会导致游戏在不同分辨率的屏幕上玩起来难度不一致，进而影响玩家表现，引起玩家不满。
 

    总而言之，是需要游戏根据自身特点来考虑合适的显示适配方案。

二、运行适配

1、iOS平台

先简单说一下iOS的情况。iOS平台比较封闭，封闭的好处就是兼容性好，覆盖遇到的问题很少。并且不论是OS的版本，还是硬件版本，都不是很多，比较容就全覆盖了。

1）OS版本：目前需要考虑支持4.x/5.x/6.x/7.x，更早一些的版本目前基本很少有人使用了；

2）硬件版本：iPod Touch 4/5, iPhone 4/4S/5/5S/5C, iPad 2/3/4，其他的可以忽略了。

3）苹果规范：有时App Store会提出一些新的规范和要求，比如不许使用MAC地址，生成文件不要存放在Document目录，等等。

总的来说iOS平台的一致性非常高，随便找一台iOS设备调试通过后，基本上在其他iOS设备上都能够运行。

2、Android平台

开放系统，大小坑无数。各种定制ROM加性能差异巨大的硬件，就像是被打开的潘多拉魔盒。

1）OS版本：建议支持Android 2.2及以上，从这个版本开始支持OpenGL ES 2.0规范。

2）硬件版本：各种厂商，各种山寨硬件，各种性能，无法一一列举。不推荐简单按照厂商（同一厂商的不同系列设备问题不尽相同）、设备市场占有率（市场占有率Top50的设备加起来，也不一定能占到超过一半的市场容量）等来做兼容。

总的来说，Android的兼容性适配不好做。要涉足这一块的同学请做好被反复折磨的心理准备。这里也只能给一些小的建议：

1）众所周知的，Top20、Top50的机型尽可能的覆盖测试到；

2）内存显存使用要尽可能的少，用的越少出问题的可能越小。尤其是在中断（来电、切换App等）的情况下，出bug和被系统杀死的可能要小很多。

设计可以根据设备性能来动态调整内存显存使用量的程序策略。例如监测CPU、总内存大小、当前可用内存大小等性能指标，动态选择使用较少内存的方案；对于小屏幕的手机（往往内存也比较小）使用较小的贴图尺寸，可以大量减少内存显存开销。

3）注意多线程的使用，很多设备上线程切换会带来意想不到的问题。

4）多看Android API文档，尽可能使用它推荐的做法。