如上图是由 opensignal 统计的 2014 年 Android 设备的数据, 可以看到碎片化越来越严重, 苹果相比 Android 来说稍微好点但最近几年由于创新乏力不断在屏幕尺寸上做文章也使得苹果的适配开始面临更多的挑战.
背景
首先, App 适配问题的由来, 是因为无线智能终端和以往的 Windows/MacOs 相比, 属于软硬件高度绑定的嵌入式设备, 大多数智能终端的系统和硬件都是高度绑定的, 并不像当年的 Windows 可以兼容大多数的机器配置. 由于硬件驱动和功能的不断创新, 各个厂家会针对自己的终端在系统上做很多的定制化工作. 尤其是 Android, 由于源码开放且厂家众多, 各厂家采用的硬件种类繁多, 因此各终端系统的碎片化就越来越严重.
我们的 App 需要在如此众多的终端上运行, 而终端的系统版本, 屏幕分辨率, 所用的配件千差万别, 厂商带来的系统 API 改动非常的多. 当我们的代码调用系统的 API 产生了不一致的效果而没有很好的处理的话, 就很容易产生适配问题.
iOS 篇
由于 iOS 的厂家只有苹果比较简单, 所以我们先来谈谈 iOS.
由于 iOS 本身的封闭性, 软硬件都是用苹果自己的芯片和系统, 那我们就从硬件和软件两方面来分析一下看看有什么差异:
硬件
大家应该都知道即便是同一款 iPhone 也会区分不同的型号, 这个主要是和发行区域有关, 在有些地方 iPhone 会和当地的运营商合作推出带锁的版本, 也就是让手机只支持某一类运营商的网络, 虽然这会导致在基带芯片上有所不同, 不过由于苹果的运算芯片采用的是自研芯片, 因此对于适配同款 iPhone 的不同型号来说基本没有差异.
软件
由于 iOS 本身是封闭的, 全球所有 iPhone 都是使用苹果自己的 iOS 系统, 采用的服务和框架也都是苹果提供的, 因此不同地区的 iOS 系统本身除了本地化的一些语言差异可以说基本没有什么差异, 只有系统版本间的差异.
总体来说, 由于苹果的封闭性, 对于设备碎片化的把控都是比较好的. 因此我们重点关注影响适配是以下几个因素:
系统版本 > 屏幕尺寸 > 机型 > 语言 > 网络 > 海外版本.
因此, 我们的第一重点是放在系统版本的差别上, 因为系统版本的升级会更改一大批 API 的内部调用处理方式, 是最容易出现适配问题和 Crash 问题的原因, 这一点可以从历史问题中来证明. 第二个原因就是屏幕的尺寸, 这个基本上就和机型是强相关的, 因为 iPhone 机型少, 而尺寸基本上就是由机型不同来决定. 而屏幕尺寸的不同又很容易导致我们的控件显示尺寸在没有做好适配的情况下变形, 虽然不易产生 Crash, 但是用户会看到变形甚至不全的信息, 也会严重影响到用户功能使用, 因此也需要重点关注.
综上所述, 我们对于 iOS 的适配策略总体就是, 版本覆盖完全, 屏幕覆盖完全, 机型覆盖完全.
Android 篇
接下来就是我们的大头 Android 系统的适配问题了, 大家经常提到的 Android 碎片化, 主要体现在设备碎片化, 品牌碎片化, 系统碎片化, 屏幕碎片化等多方面. 我们在保证产品功能正常的同时, 还需要兼容碎片化可能带来的潜在问题, 以确保良好的用户体验.
碎片化情况
设备碎片化
以下是 opensignal 平台统计的当前 Android 手机设备型号碎片图, 已经有超过 18000 + 种的设备了.
品牌碎片化
以下是 opensignal 平台统计的当前 Android 手机品牌碎片图, 从图中我们可以看到各类手机品牌非常多.
系统碎片 化
以下是 opensignal 平台统计的当前 Android 操作系统碎片图. 从 2008 年发布的 Android 第 1 版到 2018 年最新的 9.0 版本, 以及期间各大版本过程中发布的小版本和 bug fix 版本, 目前都有不同的手机厂商在使用, 有的进行了深度定制, 有的推出了自己的 ROM, 这些无疑更加剧了 Android 操作系统严重的碎片化.
屏幕碎片化
以下是 opensignal 平台统计的当前 Android 手机设备屏幕的碎片图, 可见 Android 的屏幕尺寸规格众多, 在这种碎片化中, 你的 App 说不好会落到哪个坑里面, 也许是某个特殊屏幕分辨率.
项目各阶段适配策略
Android 严重的碎片化提升了适配测试的难度, 我们无法做到 100% 的适配测试, 但可以按照不断完善的适配策略通过项目中各角色相互协同, 一起努力将适配问题尽可能的减少, 以便更好的提升用户体验.
项目过程可分成以下四个阶段: 需求 / 交互 / 视觉阶段, 开发阶段, 测试阶段, 发布阶段, 每个阶段都需要各负责人对适配做出明确处理.
需求 / 交互 / 视觉阶段, 需要需求方在 PRD 中做简要说明, 需要交互设计师和视觉设计师在各自的交互稿和视觉稿中明确指出, 哪些页面需要横竖屏适配, 哪些页面需要手机和平板适配
开发阶段, 需要开发同学对需要适配的需求点做好技术设计和编码, 包括手机平板横竖屏, 第三方组件新增和升级以及新 Android SDK/API 使用
测试阶段, 需要测试分别通过白盒适配方式和机型适配方式进行有针对性的适配测试; 白盒适配主要针对于开发过程中适配的代码进行测试. 机型适配的基础需要一个适配的机器列表, 机型列表总结好后, 就可以通过手工适配, UI 自动化, 云测平台等多种手段进行适配测试
发布阶段, 通过众测及时发现 Beta 阶段的适配问题, 通过灰度及时处理真实用户遇到的适配问题
对于测试同学而言, 需要在项目的各个阶段都关注适配问题, 并给出合理的适配测试用例, 并在项目过程中通过各种适配测试手段, 尽可能多的发现适配问题, 将线上的适配问题概率降低.
适配策略详解
手机横竖屏适配
从 4.0 版本开始, Android 客户端开始适配平板和横竖屏, 实现方式主要是是新增了平板以及横竖屏的 layout 文件, 对于一个页面来说可能最多存在四种不同的 layout 样式: 手机竖屏, 手机横屏, 平板竖屏和平板横屏, 针对于不同 layout 可以采用白盒测试的方式做有针对性的适配测试:
通过代码梳理当前所有页面 layout 样式, 梳理每个页面共支持多少种 layout
通过视觉稿初步确认手机和平板适配的页面以制定适配测试方案
通过开发测试过程中 res/layout 下新增的不同 layout 文件来做有针对性的测试
第三方组件新增和升级适配
我们的 App 中一般会依赖很多的第三方组件, 主要是各种 so 文件和 jar 文件, 这些 so,jar 中有些时候进行升级后, 底层编译器对不同的 OS 或者 ROM 支持的情况不同, 导致了 App 出现 Crash/ANR 等异常情况:
对第三方依赖按照重要性进行梳理
针对每一个第三方组件梳理历史适配问题, 整理第三方组件的适配方法
熟悉每次第三方组件升级的业务逻辑和升级原理, 进行有针对性的适配方法, 比如 V4 和 V7 包的差异, 以及 V7 带来的新组件特性. 对于底层更加复杂可测性不高的第三方组件, 可以结合适配机型列表进行不同机型适配, 可以采用手工和自动化的方式进行
新 Android SDK/API 适配
在开发过程中可能会出现引用最新版的 Android SDK 中新 API 来实现功能, 而该 API 可能存在不兼容的情况引起适配问题, 可以采取下面的方式进行保障:
梳理从应用最低适配的系统版本开始以后新增 API 的详细情况
借助 Lint 对每次项目版本中 API 使用情况进行扫描和统计, 对新的 API 做针对性的适配测试
借助于 infer 等静态扫描工具, 对 Android 代码进行静态扫描, 提升代码质量
代表机型适配
Android 的碎片化导致适配的手机设备花样繁多, 主要通过手工或自动化的方式覆盖更多的机型来加以保证, 大致可以按照下面的思路来开展工作:
线上 Top 机型代表设备
线上 Top 系统版本代表设备
不同 SOC/ROM 厂商代表设备
对平时工作中的问题机型进行梳理, 并提交采购, 纳入手工适配范围
自动化平台适配
通过 UI 自动化平台, 对核心业务场景进行自动化覆盖, 在做功能回归测试的同时也可以达到适配测试的目的, 我们选了 Top 设备进行了 UI 自动化适配, 发现了在不同机型上有些页面存在兼容性问题 (例如: 某个按钮在华为机型上不显示等).
国内外云测平台适配
国内有很多测试平台提供云测的服务, 包括百度 MTC, 阿里 MQC, 腾讯 WeTest,Testin 以及 TestBird 等. 各大测试平台的移动应用兼容性测试服务所采用的方法其实大同小异, 一般都包括在大批量真机上进行安装, 启动, 运行 Monkey 脚本 (某些会带有智能算法), 卸载测试, 但是从测试效果来看, 其实差别还是蛮大的, 对比下来我们是选用的阿里 MQC, 对于有国外适配需求的团队这里推荐两个平台: AppThwack 和 Testdroid.
众测和灰度发布
开发, 测试同学进行适配测试, 碍于 Android 的严重碎片化, 手头设备是极其不完整, 在未全量上线前, 借助于真实用户手中自己的设备进行众测和灰度发布阶段的正式使用来提前暴露问题, 只要合理利用, 不失为一个发现适配问题的有效手段. 由于各公司采用的众测和灰度发布方式不尽相同在这里就不展开说了.
基于图像识别做适配
最近测试智能化的趋势和话题也非常热, 一些团队看到了图像识别在适配测试中发挥作用的可能, 于是他们基于图像识别技术去做了一套一系统来提升适配测试的效率.
关于模拟器
客户端测试的一个好处就是可以利用模拟器来代替真机进行一部分的测试工作, 比如可以利用模拟器进行手动或自动化的方式来发现一些功能性 Bug, 但对于网络模拟, 摄像头的调用, 消息推送等功能就不建议用模拟器来测试了.
总结
适配测试对于移动应用来说是一个重要的环节, 本文基于在开发, 测试过程中积累的经验总结了一套可行的适配测试策略, 并在实际工作中实施, 当然其中肯定有考虑不全的地方, 接下来还会继续深入白盒适配策略, 机型适配策略以及借助自动化, 图像识别技术等来更好的发现适配问题, 也欢迎对此感兴趣的同学多交流!
来源: https://juejin.im/entry/5c6942a0f265da2de52d7b11