Android适配到底有多坑？
之前一直给大家推荐技术文章，今天换个口味，推荐一篇我司测试团队明一同学写的文章，作为开发，我也经常会关心测试方面的进展，也买过一些测试的书专门学习，毕竟高质量的产品需要开发与测试共同保障，尤其是用户规模与质量要求非常高的一些产品，单靠开发很难高效地保证最终产品质量。
今天这篇文章虽是测试同学的总结与吐槽，相信不少开发同学也会感同身受，我司测试团队有一个测试相关的公众号在运营，里面有不少测试经验总结。坦白讲，作为开发我感兴趣的内容有限，不过相信大家也有一些做测试的朋友，不妨推荐给他们关注下，文末有公众号二维码。
由于安卓系统的开放性，OEM厂商和运营商都会对Android进行定制。
于是安卓的大航海时代来了。
Android设备五花八门，各种Android手机、平板、电视、手表层出不穷，Android电冰箱电饭锅乱入… ...
随着设备、品牌、系统版本、屏幕、分辨率碎片化的不断加深，兼容性测试一直在折磨着测试人员。
据统计，我们团队中做过兼容性测试的男性有2/3在已经开始谢顶，每做6个月兼容性测试寿命就会缩短半年。
So问题来了：挖掘机技术。。。兼容性问题一般跟啥有关？
排名不分先后，不吹不黑原因多到数不过来：
Android的API版本
屏幕尺寸 & 分辨率
任性的Launcher
特殊ROM行为
系统Webview差异
手机GPU
Open GL
其他软件
存储卡
输入法
网络
语言
X86
深度定制的魅族…
…
挑几个常见的唠唠吧。
Android API Level
应用需要判断运行时设备的系统版本，不能调用高于设备本身Level的API，也要做好低版本兼容实现， API Level的兼容性处理不好经常会导致FC。
尤其新的系统版本更新、新产品和新功能都需要考虑API版本的兼容性测试。
举个例子，我们前阵子做了一个吊炸天的动画，使用了比较新的API，但开发时没有注意到API Level，然后在2.3的设备上一旦播放这个动画就FC。
Android版本和API Level对应关系，可以参考：
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
屏幕尺寸 & 分辨率
Android设备的屏幕尺寸太多了，同尺寸手机分辨率也不尽相同。
一般尽可能使用线性或相对布局；统统使用绝对布局的开发人员建议乱棍打死。
另外就是dp和px单位换算的问题，不同的设备屏幕密度可能不一样，开发人员在coding的时候，直接使用px的话在小屏和屏幕密度特别大的设备上会特别难看。
问题会更多的出现在小屏设备上，瞅瞅240*320分辨率上俄语、阿拉伯语文案那酸爽…
新产品和新功能可以在模拟器上看过效果后、扩大范围组织一下Bug Bash；模拟器有时也会不靠谱，推荐云测试平台的截图功能。
关于屏幕分辨率信息，可以猛击我查询：http://screensiz.es/phone
任性的Launcher
众多系统厂商以及第三方定制的桌面（Launcher）在适配和兼容性方面常常不一样，就拿桌面快捷方式来说我们就遇到过这些问题：
不能添加快捷方式到桌面
不能删除快捷方式
买一送一添加了两个快捷方式
无法更新快捷方式图标
快捷方式图标被拉伸
快捷方式图标被替换
创建快捷方式时应用挂了
栽赃陷害，在程序启动之后Launcher让一个大大的广告弹出来糊满屏幕…
魅族
经过深度定制的Flyme确实有很多亮点，但其深度定制也产生了比其他机型多得多的兼容性问题，比如：
安装失败
卸载失败（这你能信？）
天杀的屏幕适配
文本框/输入法闹鬼
根本不能打开推送
出现两个底部菜单让人误以为眼花
如果只买三部测试机我一定买一部魅族…
除了依靠测试人员的经验保障产品质量，还可以用一些第三方的测试服务；在产品上线后，也要对线上数据充分地理解分析，与开发一起及时发现与定位问题。
早上产品往Testin、MTC、TestCloud、易测云、Testdroid、Test bird、TA云测 blabla一堆云测试平台上一挂，晚上收货满满一筐问题（什么？还要定位提单？老板今天平安夜我要搞对象好吗）
说到数据分析， Play Store最近更新了，能够看到分数最低的机型、语言、应用版本、系统版本和地区，这对于分析线上兼容性问题也是一个挺有效的手段。