共计 1542 个字符，预计需要花费 4 分钟才能阅读完成。
简介：首次关上离线包白屏以及报错“-1009”等该如何解决呢？
离线包原理
以一次启动离线包的流程为例，离线包的加载流程分为两种场景，第一种是离线包下载好的场景，流程如图 1 所示，第二种是离线包没下载好的场景，如图 2 所示：
图 1：离线包加载支流
图 2：离线包下载流程
咱们能够从埋点来跟踪离线包具体的加载流程 *：
- 查看本地是否有离线包，本地有则执行第四步解压，解压之后再进行校验，校验通过加载本地离线包，如果本地曾经装置过，那就不须要解压间接走解压后的流程
- 网络申请离线包信息，这一步和上一步是异步进行的，对应的埋点有 H5_APP_REQUEST
- 比照申请回来的离线包信息，再决定是否下载离线包，对应的埋点有 H5_APP_DOWNLOAD
- 解压离线包，对应的埋点有 H5_APP_UNZIP
- 如果开启了离线包验签，校验离线包的合法性，对应的埋点有 H5_APP_VERIFY、H5_AL_SESSION_VERIFYTAR_FAIL
- 加载本地离线包，对应的埋点有 H5_AL_SESSION_MAP_SUCCESS、H5_AL_SESSION_FALLBACK
留神：fallback 走线上须要等到离线包申请这个异步申请回调回来之后返回的 fallback + mainUrl 确定 Webview 关上的 URL。
* 参考资料：离线包日志埋点
案例 1：首次关上离线包白屏
STEP1：依照离线包加载流程剖析，首次关上离线包肯定是须要走线上的 fallback，因为本地没有，走线上之前肯定须要先晓得离线包的线上地址也就是 URL，所以须要查看日志剖析是否是申请离线包信息那一步出错了。
STEP2：剖析日志关上线上离线包的时候 URL 为空，在离线包申请还没有回调回来之前就关上离线包，所以呈现了白屏。
STEP3：查看代码
将创立的离线包控制器作为根视图，机会过早，所以导致了该问题。
STEP4：联合客户需要给出倡议，能够应用本地预制离线包解决首次过早关上离线包呈现白屏的问题。
案例 2：关上预置离线包，报错（-1009）
复现 demo
STEP1：断网状况下关上预制离线包失败显示网络无奈连贯阐明关上预制包失败了，所以走了线上，因为没有网络所以显示网络无奈连贯，问题出在本地预制的离线包上。
STEP2：依照离线包的加载流程剖析，在本地有预制包的状况下呈现走线上的状况别离有两种状况，离线包验证签名失败和加载本地离线包失败。
STEP3：日志剖析
察看到有验签失败的字样。
STEP4：查看代码客户端是否敞开了验签，默认是开启的，如果没有敞开，那么客户端须要设置对应的公钥，或者敞开验签。
STEP5：敞开验签再试一遍，持续剖析日志：
H5_AL_SESSION_FALLBACK 加载本地离线包失败，最终走的线上，察看解压离线包胜利没有问题，问题出在加载离线包那一步，日志中查找到 H5_APP_EXCEP 离线包异样埋点，是读取数据时候失败了。
STEP6：问题有可能呈现在该离线包下面，所提供一个失常的离线包给客户做成本地预制离线包，断网关上验证，没有问题，问题就出在该离线包上。
STEP7：解开预制的离线包，察看离线包是否门路字符总长度是否超过了限度导致读取数据失败。
JS 文件名称过长，导致总的字符长度超过了限度，须要客户批改离线包 *。
思考和总结
通过下面两个案例的介绍，咱们能够清晰的看到案例一最终呈现问题的起因是申请离线包信息这个申请没有回调回来，客户就关上离线包时没有获取到 URL，问题呈现在了申请离线包那一步了，而案例二最终定位到加载本地包失败那一步。
理解了离线包的具体加载流程，再联合 nebula 容器自动化埋点日志，就能够具体定位问题到离线包加载的哪一步了。
本文作者：阿里云 mPaaS TMA 团队（杨强 荣阳）
原文链接
本文为阿里云原创内容，未经容许不得转载。
