优酷客户端打包构建阶段的质量评估解决方案——PreMTL

一、PreMTL 的由来

阿里巴巴各 BU 的客户端打包构建通常是基于摩天轮（MTL）平台来完成的，它可以满足大部分的通用性需求，但对部分个性化需求难以及时响应。因此，优酷技术质量团队建设了 PreMTL 体系——意在摩天轮（MTL）打包之前的检查，快速服务优酷在打包构建环节的验证需求。

二、PreMTL 核心能力简介

在 PreMTL 体系中，我们重点建设了三个能力：静态代码扫描、包大小健康度检查、苹果审核预查。

1. 静态代码扫描

如果 Code Review 做的足够到位可以解决大部分编码问题的。但考虑到效率和覆盖范围，需要引入高自动化程度的静态代码扫描。优酷线上有相当一部分问题是由空指针引起的，如果通过客户端整包验证来发掘这类问题，好比大海捞针，即使是出现频度较高的 NPE 问题也难以发掘。静态扫描可以发挥巨大的功效，但也存在挑战：

第一是直接应用服务端扫描的工具和模式，未必适合客户端的情况；

第二是如何长效化的落地静态扫描的能力，避免短期的战役形式的推进。

为有效的应对上述挑战，我们明确了静态扫描方案的具体要求：

1. 准确度高，保证扫描结果和效率的最基本的要求；

2. 执行效率高，以满足高执行频度下快速获取结果的需求；

3. 配置简单、灵活，支持自定义规则，以满足不同业务个性化的需求；

4. 持续集成友好度高，与测试平台和流程集成成本低；

5. 最好提供双端（Android/IOS）一致的体验和方案。

基于这几个维度的筛选，我们最终选定了 Facebook 开源的静扫工具 Infer 作为主力工具进行接入。同时利用客户端测试平台的服务化能力，将用户的上手成本降到最低。

经过平台化建设的静态扫描的配置界面如上图所示，需要用户输入和选择的信息非常少，需要的内容也非常明确，上手成本比较低。一旦用户实际触发了静态扫描，平台会有机整合结果以及附加的操作，方便用户对结果进行筛选和处理。客户端测试平台静态扫描的综述结果页和详情结果页如下图所示：

[染画 1]客户端测试平台除了提供非常详尽的结果指示、查询和操作能力，还提供了对比扫描、自定义规则录入等能力，大大降低了使用成本并方便用户实现个性化测试需求。基于平台服务化，静态扫描具备了被其他平台和系统调用的能力，可以很好的集成到任何业务或团队的平台或流程中，快速发挥作用。

经优酷技术质量团队牵头，优酷在 2019 年对历史存留的空指针问题进行了集中治理，达到了 Android 端核心模块 90%+零存量 NPE，iPhone 端核心模块 80%+ 零存量 NPE 的成果，极大的解除了版本质量隐患。同时，通过多平台有效对接和联动，静态扫描已经变成了优酷客户端版本发布过程中的必经环节，实现了版本质量的常态化保障。

2. 包大小健康度检查

包大小健康度是一项比较重要但是可能被忽略的质量指标。臃肿繁杂的应用安装包不光存在更高的质量和稳定性隐患，使得问题排查的复杂度相对更大、成本更大；另一方面，安装包大小直接影响着用户的下载或保留应用的意愿。

单纯的关注整包大小并不能解决实际问题。很多版本发布流程或平台对应用整包大小都会有一些限制，从实际情况看发挥的效果非常有限，即便超过阈值也常常会因为业务需求开绿灯。如果没有一个有效的方案对应用包中存留以及新增的代码和资源的合理性进行检查和评估，并给出准确的判断结果指导业务方进行优化，应用包体积控制就会变成一个痛苦的反复讨论、对比的过程，甚至会常态化的挣扎在包体积大小的阈值线上面。为此优酷技术质量部推出了包大小检查能力，取得了不错的效果。

所谓包大小检查，是根据影响包体积大小的现实问题分别列出对应的指标，例如资源文件的大小和引用情况，PNG 图片的使用情况，代码混淆情况，或者各个模块在线上被访问的热度等等。优酷通过这种检查方式避免了对应用体积简单粗暴的一刀切式管理方法，转为数据驱动、以事实说话的方式，让新的需求可以合理的集成进来，同时又最大限度的保持了应用体积处在一个健康的状态。下图展示了客户端测试平台进行一次包大小健康度检查的结果界面，读者可以参考。

通过以上多维度的数据展示，开发团队可以有效的对存在问题的部分进行优化，决策方可以快速的判断体积增加的合理性。经过一段时间的集中推广，包大小健康度检查也已经成为了优酷客户端版本发布过程中的一个必须的检查项目，安装包的体积大小得到了较大的优化并有效控制在了一定的浮动范围内，整体效果符合项目建设的预期。优酷多个版本的包体积大小走势示意（安卓端）如下图所示。

3. 苹果审核预检查

苹果对于在应用商店发布的应用都有详细的上线前审核，优酷在应对苹果审核的检查保障手段上积累了一些经验并沉淀了一些方法：

1. 苹果的审核分为自动审核和人工审核两部分，人工审核阶段更多是关注基础功能、展示和内容方面的合规情况，对应的保障工作主要在整包验证阶段进行；

2. 自动审核部分更多的是关注应用本身的合规情况，主要是在构建打包阶段通过自动化能力来保障的。例如，如果应用代码中，诸如类名、方法名或者全局变量等关键位置有类似于“Alipay”这样的敏感字眼，苹果是非常容易怀疑提审的应用中支付方式没有符合苹果的要求，从而大概率会造成拒审。所以对于某些敏感关键字在符号级别、甚至是字符串级别的扫描是非常必要的。通过客户端测试平台的 IOS 审核检查能力，进行关键符号检查的一个结果 DEMO 如下图所示。

检查逻辑的实现机制并不复杂，但是执行的效果比较理想，配合类别同名查找等扫描能力，利用平台化的支持，优酷在 2019 年的苹果审核过程中整体顺利，一次通过率相比 2018 年上升了 50%+。

三、构建打包阶段验证能力的拓展和规划

在构建打包阶段，通过合理的能力调整和部署、针对性的解决执行环节和实现常态化的痛点，可以实现质量控制能力的有效落实。

基于已经完成的能力，我们正在开展更进一步的建设，例如：

1. 依赖关系检查，优化多模块集成效果；

2. 拓展静态扫描能力，覆盖跨模块检查；

3. 强化包大小健康度检查，发掘影响包体积大小的更多因素。

PreMTL 的建设对提升优酷客户端版本质量起到了很大的作用，希望对读者有所启发。

作者简介：

翀宸，阿里文娱技术专家。

相关阅读：

优酷播放测试体系构建及平台化整合方案

优酷如何构建覆盖全网的播放白盒测试体系

优酷大剧全链路技术保障探索和实践