移动端游戏兼容性适配经验兼容性适配顾名思义，是让游戏能在更多的设备上可玩，保证功能、显示效果不出问题。 主要包含一下几种

兼容性适配顾名思义，是让游戏能在更多的设备上可玩，保证功能、显示效果不出问题。

主要包含一下几种类型：

由于IOS的手机种类比较少，它的兼容性适配非常简单，所以这篇文章还是只介绍Android的适配。

机型市场占比

Android中类繁多，主要区别有厂商、显示屏分辨率、CPU、GPU、OpenGL ES版本、内存等。各个游戏发行商会有玩家机型的统计信息，比如腾讯《2020移动游戏质量白皮书》里就展示了一部分。

做事要分清主次，做兼容性适配也是一样，在精力有限的条件下需要知道哪些机型是我们重点支持哪些设备，要舍弃哪些设备。在兼容性适配开始前，我们会根据市场占有率和付费率等数据将机型排序，对市场占有率高和付费率高的机器优先做适配。如果随便找一些机器适配，可能会将大量时间花在个例问题上，比如某个市场占比很小GPU的机器+某openglES版本+某种shader用法导致的显示异常。

根据运营提供的各机型的付费率和市场占比，确定需要支持的机型下限。比如内存小于1G，OpenGL ES2.0版本，Android系统4.0的机器市场占比已经接近0，因为这些机器可能是8年前的主流机器，现在一款游戏既要支持最新的设备又想要支持8年前的设备能够流畅游玩，那么美术资源制作、引擎底层设计、性能优化都会很痛苦。考虑到我们的成本，果断放弃了1.5G以下/OpenGL ES2.0/Android 4.x的设备。

工具

市场上的Android手机品类繁多，作为一个游戏开发商，尤其是中小厂，不可能为了兼容性买非常多的设备，我们的设备也就几十台。所以想要做更完备的兼容性测试，需要借助一些平台帮我们进行兼容性测试平台。我们经常使用的有TestIn和TestBird，这些平台除了进行兼容性测试外，还能够远程真机调试，让我们在有限的条件下完成对更多机型的适配。

安装

笔者碰到的无法安装的原因一般是是由于机型太老或存储不足导致的。

游戏引擎或三方SDK都会设置Android minVersion，系统版本小于minVersion的设备无法安装。我们支持的最小系统版本是Android 5.0。

当包体太大，机器本身的存储不足时，也有可能发生安装失败。如果这个机器本身存储就非常小，比如只有4G、8G，并且机器已经非常老旧了，就算拼命优化包体也无法彻底弥补硬件本身的缺陷，笔者建议直接放弃这种设备，不必浪费时间。

拉起

无法正常拉起的问题通常比较好解决，从LogCat中找线索一般就可以了，如果找不到有用的线索，那么加打印逐步缩小范围也可以逐步定位到。

笔者遇到的拉起崩溃有：

申请在Android Manifest中配置的权限，被系统杀掉了。一般发行都都会有权限的申请要求，按照发行的要求配置权限，不要越界申请未经允许的权限。 在拉起过程中启动游戏系统的负荷过大，比如加载大量的配置、代码、资源文件，导致游戏长期无响应被系统主动杀死。使用分帧技术将这些任务分散到多帧中执行就可以极大降低这种事情发生的概率。 一部分机型硬件特性导致的适配差异触发了漏洞导致了崩溃，一般android GPU对extensions、异步Context、二进制Shader、纹理格式等相关。优先查看崩溃栈，如果没有崩溃栈，那就用加打印缩小范围。

显示异常

显示问题是Android机型适配上出现的最重要的问题。

笔者遇到的主要是两种：UI显示和GPU适配。

UI显示

跟机型种类有关的UI显示问题主要由两类：异形屏适配和UI的制作有问题。

其中UI制作问题，一般是UI美术在制作时没有正确设置UI对齐方式和拉伸方式，在不同分辨率的手机上显示错位了。

异形屏包括刘海屏、挖孔屏、水滴屏。在Android P之前，几乎每个厂商都设计了自己的异形屏适配解决方案（异形屏适配方案）。在Android P之后，Google提供了统一的适配方案（Display Cutout）。我们第一版方案是对能获取异性屏信息的设备做异性屏适配，将UI和文字在异形屏的安全区域内绘制。但Android P之前的设备有很多机器是无法获取异形屏相关的信息的，我们做了一个白名单，将这些设备加到白名单中做异形屏适配。但是经过长期的迭代，仍然会有漏网之鱼。

最后我们采取的方案是对所有屏幕都做异形屏适配，即顶部的那块可能存在异形的矩形区域不绘制任何文字和UI。

GPU适配

GPU的发展实在太快了，八年前刚上市的Adreno 405，去年上市的旗舰是Adreno 888。它们除了性能上的差别，还有支持功能的差别。

对各种类型的GPU的兼容性，笔者处理过OpenGL ES 2.0与OpenGL ES 3.x的兼容，不同GPU Extensions的兼容，以及特定GPU的兼容。

在游戏中大量运用的需要区分OpenGL ES2.0 与 OpenGL ES3.0的地方主要是，Bloom效果需要的float问题格式，支持ETC2的压缩格式，在ES 3.0上是支持的，而在ES 2.0的GPU上是通过Extension支持的，兼容ES 2.0会非常麻烦，最后考虑到ES 2.0设备的市场占有率极低，直接放弃了对ES2.0的维护。

笔者项目对OpenGL Extensions的部分识破诶如下：

功能Extension扩展D24的深度格式GL_OES_depth24VertexArrayObjectGL_OES_vertex_array_objectVolumeTextureGL_OES_texture_3D

有些GPU不支持支持在异步线程创建Context，导致子线程无法编译Shader只能在主线程编译造成卡顿，需要对这种GPU支持分帧编译shader。

有些GPU的extension里有某种扩展，但实际并不支持。如PowerVR Rogue GE8320、PowerVR Rogue GT7400、Adreno (TM) 510，extentions里有GL_EXT_texture_border_clamp，但会有显示问题。另外VAO、Depth24也碰到了这种情况。

性能

兼容性测试的需要关注的主要指标有帧间隔、卡顿（Jank）、内存，这部分的优化方法在移动端游戏性能优化--ARPG项目的优化经验 - 掘金已经介绍过了。

崩溃

对于一个引擎开发者来说，崩溃是非常严重的问题，我们要对崩溃保持高度的警惕，出现了崩溃要立即分析它的影响，根据影响制定解决策略。之前也总结过崩溃的解决经验移动游戏崩溃优化知识点总结 - 掘金。

ANR

游戏移动的设备最高端的设备与最低端的设备的性能差距可能差了10倍以上，但是游戏在不同的机器上CPU做的任务却很难有10倍的差距。这就会造成会经常出现一些低端机器的CPU处理任务时会长时间未响应，系统提示出现ANR。碰到的问题和方案也在上面的两个优化经验里介绍过了。在这里再简述一遍。

将需要花费较多CPU时间处理的任务移动到子线程处理：

资源加载 编译Shader 下载、上传 网络请求

无法放在异步线程的任务以分帧方法处理：

加载游戏的配置表 生成大量怪物 打开具有大量道具的背包

进程退出

表现为闪退，进程日志里有am_proc_died或am_killed，但没有崩溃栈。这种问题出现的频率不高，一般会在云测中被筛查出来，笔者通常会从分析LogCat和尝试复现两种方式入手，但是所获不多。猜测是云测平台的任务系统或机器由于任务调度把游戏杀死了。

引用

2020移动游戏质量白皮书——腾讯

相关知识

游戏测试之兼容性性测试标准（适配兼容）
游戏兼容性测试（通用方案）
【游戏测试】游戏兼容性测试（通用方案）
gta5怎么兼容性运行 gta5怎么兼容性运行游戏
游戏测试是一个怎样的行业？
win11系统玩英雄联盟游戏的兼容性分析及优化建议
Unity2D游戏场景镜头适配全解析
网页游戏的测试流程
更新！！！Unity移动端游戏性能优化简谱
手游和移动游戏的区别有哪些？

网址: 移动端游戏兼容性适配经验兼容性适配顾名思义，是让游戏能在更多的设备上可玩，保证功能、显示效果不出问题。 主要包含一下几种 http://www.hyxgl.com/newsview355762.html