共计 1802 个字符，预计需要花费 5 分钟才能阅读完成。
「本文选自《阿里云 SRE 技术期刊》2021 年 02 月刊」
挪动端的混合架构模式给 App 开发带来了簇新的空间，通过 H5 构建的业务模块能够实现高效疾速的版本迭代，满足多样化的业务需要。为了补救 H5 技术的局部性能有余，mPaaS 客户端框架为开发者提供了“离线”机制。
开发者在接入 mPaaS H5 容器后，配合 mPaaS 挪动公布服务，能够让客户端不便地从本地加载 H5 业务包，极大地晋升了 H5 利用的加载效率。须要留神的是，这套离线机制的接入过程必须要严格依照文档来进行，一些轻微的谬误可能导致离线机制失败，给 H5 利用的加载性能带来影响。
这篇文章将和大家分享一起由离线包重构引起的“白屏”期待景象的排查和解决案例。
1. 问题背景
咱们（阿里云金融线 SRE 团队）接到客户的反馈：开发者对所有线上离线包进行了一轮的整合和重构，发版后发现 H5 利用的加载性能呈现较大的进化：在网络好的状况下会有一个短暂的“白屏”等待时间，在网络较差的状况下，甚至齐全无奈实现页面的加载。更具体的信息包含：
1) 前一天早晨在生产环境进行离线包版本更新，发现公布白名单内的用户拜访离线包呈现性能进化
2) iOS 和 Android 双端均存在这个问题
3) 白名单内共有 20 多个外部用户，非内部用户，对外业务没有理论影响
4) 非白名单内用户拜访的还是老版本的离线包，没有呈现问题
5) 开发侧的变更内容包含：
a) 全量离线包更新，更新数量大略是 60 个左右
b) 旧离线包的架构是 1 个公共资源包 + N 个一般资源包
c) 新离线包的架构是 3 个公共资源包 + N 个一般资源包
2. 剖析与排查
依据症状“网络好的状况下会有一个短暂的“白屏”等待时间，网络较差的状况下，甚至齐全无奈实现页面的加载”，咱们首先狐疑的是离线包的“离线”机制失败了，流量 fallback 到了线上资源。揣测“白屏”等待时间是 Web 资源网络下载和加载慢导致的，如下图所示：
要验证这个揣测，咱们须要通过抓取 HTTP 层面的报文来确认这个问题，抓包办法可参考文后材料理解详情[1]。从网络包中咱们察看到，每次关上 H5 利用，均存在不同水平的资源文件拉取行为，这些 Web 资源大的有几十 MB，通过网络加载速度较慢，如下图所示：
和客户进一步沟通确认，这部分资源来自于一个新增的公共资源包。依据 mPaaS H5 容器的接入要求，公共资源包的注册须要在容器初始化的时候手动指定，而一般资源包则不须要这样的操作，可参考文后材料理解详情[2]，[3]。
联合过后的状况（仅进行了离线包的云端重构，新增 3 个全局资源包，客户端 App 并未从新发版）揣测：这部分 fallback 流量产生起因是客户端未注册新的公共资源包，因而容器不晓得这部分资源在本地的映射，只能从网络 fallback 地址获取，而这里的外围 JS 资源的加载慢导致了“白屏”期待的性能问题。
根据上述剖析进行客户端代码查看，确认客户端的确没有对新增的公共资源包进行注册。开发者依照文档从新对这个细节进行解决，打包测试后确认问题隐没：不再有 fallback 的申请，“白屏”期待的问题也失去了解决。
3. 小结
开发者在 mPaaS H5 容器在接入和应用上须要对一些细节投入特地的关注，比方离线包的验签和全局包的应用等。因为 H5 容器存在 fallback 机制，所以即便“离线”失败，容器也是能够“失常”加载业务包的内容的，开发阶段开发者往往容易疏忽掉“离线”对性能层面的影响。倡议开发者在联调和上线的过程中，对于离线机制的工作状况予以检查和确认，能够通过抓包的伎俩从内部确认没有额定的、非必要的 fallback 申请产生，最终的目标是施展离线包的性能劣势。
参考文档
[1]如何抓取 HTTP 报文（Mac OS/Charles）：https://help.aliyun.com/document_detail/159161.html
[2]Android 治理离线包：https://help.aliyun.com/document_detail/112553.html
[3]iOS 治理离线包：https://help.aliyun.com/document_detail/112928.html
《阿里云 SRE 技术期刊》
《阿里云 SRE 技术期刊》2021 年 02 月刊重磅公布啦，囊括了事件要闻、利用阐明、最佳实际、测试环境搭建、问题排查等泛滥技术干货，感兴趣的小伙伴速来围观~~
关注公众号 「mPaaS」 回复“SRE 期刊”立刻下载原文
-END-
