一、背景和现状
安装包的重要性无需多提，针对安装包质量控制越来越严格和规范，包括证书、文件大小、安装成功率等，APP的证书及混淆是影响APP的安装成功率及代码安全性的很大因素，随着功能迭代，安装包也会随之增大，那么用户下载和app激活转化率就会越低，同时在提交及发布渠道时的错误率也会提升，所以成熟的app会不定期进行安装包瘦身实践，通过对于代码、资源文件等梳理将安装包大小控制在一个合理的值。（比如有app，iOS安装包大小控制在55M，Android安装包大小控制在28M等）。
目前组内针对这一块已经形成了APP的安装包的常规检测，并将其加入到整个研发流程中，参与人员会包含产品、设计、开发和测试同学。
二、安装包质量目标确立
1、包大小控制
2、资源重复及大小文件检测及新增控制
3、重复、废弃及无用代码检测
4、基本项检查
三、检测技术及度量指标
1、 针对APK的总体大小
1.1 获取方式：
针对IOS端：开发者证书、企业证书和发布证书打出来的包可能大小不同，并且debug和release也会影响包大小，从第一版本开始，建议选择发布证书+release版本作为被测包。
安卓端：不存在IOS端的证书问题，建议选择release版本打出的包作为被测包
1.2 控制方式：
研发工作开始之前，研发负责人给出APP的预估大小值
（1）开发人员在需求评审完成就给出本版本安装包大小的预估值，产品和测试人员会针对研发负责人给出的预估值和实际值作出比较，并针对实际值与预估值有较大差距的情况，由开发人员给出问题原因。
（2）在整体研发过程中，设计人员给出的UI设计图根据需要优先做一次无损压缩，之后研发人员可根据项目情况，再做一次无损压缩，两次压缩之后能够降低一定量的资源文件的大小。目前安卓端一般会采用.9图片，能够有效减少图片等资源文件的大小。
2、针对资源文件的检测——避免过大和重复
重复文件的检测方式：首先根据文件头判断文件类型，确认文件类型是资源文件的，会通过大小和md5值进行资源文件是否重复的判断，之后将重复文件的列表输出，并且输出重复文件的占用大小。
对重复文件及大小的约定规则如下：
（1）重复文件的总占用大小超过0.1M时会发出告警；
（2）重复文件的项数不能有增加，历史重复需要在接下来的版本中进行不断删减。
（3）针对资源文件的大小的监控，需要与设计同学一起确定指标，将资源文件分成大中小三种级别，当出现大文件时，需要给出预警。
3、针对引入的第三方sdk的功能判断——避免sdk本身功能模块与非sdk有重复
在开发过程中需要对引入的第三方sdk的功能接口熟悉，并且需要了解sdk及非sdk模块是否存在功能的重复实现情况，是则需要在APP的非sdk的代码中做删除。
4、对代码的检查及优化：
（1）包括对重复功能的代码的检查：有可能在历史版本迭代积累的过程中，在整个研发过程中导致出现多份重复功能的代码，或者相似功能代码
（2）对废弃功能的代码检查：这里可以和测试及产品同学一起，确认版本功能以及case走查，以此来达到对历史代码的清理。建议检查方式：可以通过代码覆盖率的方式，在执行case的过程中统计代码覆盖率，对未覆盖到的代码进行分析及进一步的处理。
5、对证书、log以及混淆的校验：
（1）针对打包的证书的校验：安卓端可通过证书的md5值进行验证；
（2）混淆可通过smali工具进行解压后生成的代码，优先对资源文件做校验，之后可以获取LaunchActivity的代码，对代码做规则判定以验证是否混淆；
（3）log的验证有些apk是通过一个文件记录开关，则可解压文件读取内容得到开关即可，若不满足此要求，则可通过自动运行app获取日志信息做校验。
6、持续优化：
以上几个指标需要加入到研发管理流程中，坚持N个版本下来，一定能够有比较好的效果。
安装包检查结果输出模板可见下方：
最后作为一位过来人也是希望大家少走一些弯路，在这里我给大家分享一些软件测试的学习资料和我花了3个月整理的软件测试自学全栈，这些资料希望能给你前进的路上带来帮助。
视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。
