排查指南 | 两个案例学会从埋点排查 iOS 离线包

Posted 2022-01-26 mPaaS

离线包原理

以一次启动离线包的流程为例，离线包的加载流程分为两种场景，第一种是离线包下载好的场景，流程如图1所示，第二种是离线包没下载好的场景，如图2所示：

图1：离线包加载主流

图2：离线包下载流程

我们可以从埋点来跟踪离线包具体的加载流程*：

1. 检查本地是否有离线包，本地有则执行第四步解压，解压之后再进行校验，校验通过加载本地离线包，如果本地已经安装过，那就不需要解压直接走解压后的流程

2. 网络请求离线包信息，这一步和上一步是异步进行的，对应的埋点有 H5_APP_REQUEST

3. 对比请求回来的离线包信息，再决定是否下载离线包，对应的埋点有 H5_APP_DOWNLOAD

4. 解压离线包，对应的埋点有 H5_APP_UNZIP

5. 如果开启了离线包验签，校验离线包的合法性，对应的埋点有

H5_APP_VERIFY、H5_AL_SESSION_VERIFYTAR_FAIL

6. 加载本地离线包，对应的埋点有

H5_AL_SESSION_MAP_SUCCESS、H5_AL_SESSION_FALLBACK

注意：fallback走线上需要等到离线包请求这个异步请求回调回来之后返回的 fallback + mainUrl 确定 Webview 打开的URL。

*参考资料：离线包日志埋点

https://help.aliyun.com/document_detail/111420.html

案例1：首次打开离线包白屏

STEP1：按照离线包加载流程分析，首次打开离线包一定是需要走线上的fallback，因为本地没有，走线上之前一定需要先知道离线包的线上地址也就是URL，所以需要查看日志分析是否是请求离线包信息那一步出错了。

STEP2：分析日志打开线上离线包的时候URL为空，在离线包请求还没有回调回来之前就打开离线包，所以出现了白屏。

STEP3：检查代码

将创建的离线包控制器作为根视图，时机过早，所以导致了该问题。

STEP4：结合客户需求给出建议，可以使用本地预制离线包解决首次过早打开离线包出现白屏的问题。

案例2：打开预置离线包，报错（-1009）

复现demo：https://gw.alipayobjects.com/os/bmw-prod/b4eb0343-f2be-4ef5-ab3b-beebbf0b988c.zip

STEP1：断网情况下打开预制离线包失败显示网络无法连接说明打开预制包失败了，所以走了线上，由于没有网络所以显示网络无法连接，问题出在本地预制的离线包上。

STEP2：按照离线包的加载流程分析，在本地有预制包的情况下出现走线上的情况分别有两种情况，离线包验证签名失败和加载本地离线包失败。

STEP3：日志分析

观察到有验签失败的字样。

STEP4：检查代码客户端是否关闭了验签，默认是开启的，如果没有关闭，那么客户端需要设置对应的公钥，或者关闭验签。

STEP5：关闭验签再试一遍，继续分析日志：

H5_AL_SESSION_FALLBACK加载本地离线包失败，最终走的线上，观察解压离线包成功没有问题，问题出在加载离线包那一步，日志中查找到H5_APP_EXCEP离线包异常埋点，是读取数据时候失败了。

STEP6：问题有可能出现在该离线包上面，所提供一个正常的离线包给客户做成本地预制离线包，断网打开验证，没有问题，问题就出在该离线包上。

STEP7：解开预制的离线包，观察离线包是否路径字符总长度是否超过了限制导致读取数据失败。

JS文件名称过长，导致总的字符长度超过了限制，需要客户修改离线包*。

*参考资料：生成离线包

https://help.aliyun.com/document_detail/85627.html

思考和总结

通过上面两个案例的介绍，我们可以清晰的看到案例一最终出现问题的原因是请求离线包信息这个请求没有回调回来，客户就打开离线包时没有获取到URL，问题出现在了请求离线包那一步了，而案例二最终定位到加载本地包失败那一步。

了解了离线包的具体加载流程，再结合nebula容器自动化埋点日志，就可以具体定位问题到离线包加载的哪一步了。

本文作者：阿里云 mPaaS TMA 团队（杨强  荣阳）

END

---

下周二（8.24）阿里云飞天会员日开启，消息推送等资源包1折秒杀抢购，点击文末阅读原文了解更多折扣详情。

IO 异常输出排查指南

关注+星标公众号，不错过精彩内容

转自 | 鱼鹰谈单片机

在嵌入式开发过程中，IO 操作是不可避免的，很多时候 IO 操作很正常，但有些时候可能因为某些原因导致异常输出，或者说不是你想要的输出（本来应该一直输出高电平，突然出现一个低电平）。

1、时间太久，不知道在哪里操作了这个 IO
2、程序异常篡改 IO 输出。
3、维护别人的程序，代码太多，不知道哪些地方会修改这个 IO。

针对这些情况，本篇笔记鱼鹰将讨论如何快速排查异常输出问题（软件问题，非单片机本身问题）。

一、全局搜索

一般来说，IO 输出肯定有迹可查，比如我们可以全局搜索 GPIOB 和 GPIO_Pin_0 之类的。
当然，我们也可以借助 SI 之类的工具查看相关定义的使用情况。

总之，这个方法，比较笨，但对付一般的异常输出，问题不大。

二、断点神器

如果上述方法还是没法查出问题，那么只能请出我们的终极杀人王“火云邪神”，不，终极调试神器——断点出场了（关于该调试方法使用与介绍，可以查看历史笔记《打了多年的单片机调试断点到底应该怎么设置？| 颠覆认知》）

既然从源码很难分析这些问题，那就只能靠单片机本身提供的调试手段来查了。

比如，输出时，我们一般都会调用 GPIOB->BSRR 之类的寄存器设置高电平或低电平，所以我们可以使用我们的调试神器跟踪这个寄存器的写入情况，比如我们可以通过设置如下窗口跟踪 GPIOB->BSRR 写入情况：

（这里设置为 4 字节访问，是因为这里的寄存器是 32 位的）

当然，除了要查 BSRR，还有 BRR、ODR 等寄存器，还有别忘了，位绑定的地址操作。

总之，这些地址全部跟踪一遍，如果是软件问题，99% 都能查出来。

另外鱼鹰再教大家一个快速找到寄存器地址方法，比如在调试模式下，可以在命令行中输入下面这个，就能得到对应的地址，当然绑定地址只能通过变量中转一下了，或者直接看汇编代码也很快。

总之，找地址的方法很多，千万不要傻傻的自己手工算，不然怎么早点下班玩游戏啊。

而对于有些 IO 的配置莫名的改变了，比如输入变输出，输出变输入，那还要跟踪 CRL 、 CRH 寄存器。

该方法从根本上跟踪指令，基本上所有代码都将无所遁形（除了 DMA 的操作，不过一般人应该不会用 DMA 去控制 IO 吧），即使你的代码是指针或者其他骚操作，甚至是异常篡改 IO 寄存器这种情况。

如何避免？

一般来说，上面两种方法基本上就可以排查问题了，但是有些情况很复杂，就需要根据情况选择适合自己的方法了，方法二绝对是神器级别的，一般问题不大。

所以现在讨论一下怎么尽量避免这个问题。

1、每个 IO 操作尽量封装在单独一个函数中，或者使用一个枚举参数进行控制，比如一个枚举 OUT_PIN_LED，这样在全局搜索时，搜索这个函数或者枚举就可找出所有操作该 IO 的位置，这也是鱼鹰为什么要实现这个 IO 框架的原因之一（简单实用IO输入输出框架）。绝对不建议直接操作库函数或者寄存器。

2、使用 LCKR （锁定）寄存器。很多道友可能听说或者见过这个寄存器，但在实际项目中很少使用。事实上这个寄存器很有用处，特别是你不确定这个 IO 配置是否会被别人的代码修改的情况。如果很确定这个 IO 从始至终只会有一个配置（输入或输出等），那么建议大家在配置完后使用该寄存器锁定对应的引脚，这样，你就不怕别人意外修改这个 IO 的配置了（只要锁定了，就无法修改配置，除非重新上电）。之后你的关注点集中在 IO 输出即可，而不必怀疑配置被修改的可能。当然，在锁定这个 IO 之前的代码问题，可不敢保证。

------------ END ------------

●精选 | ST工具、下载编程工具

●精选 | 嵌入式软件设计与开发

●精选 | 软件工具、 编译器、 编辑器

欢迎关注我的公众号，回复“加群”按规则加入技术交流群，回复“1024”查看更多内容。

欢迎关注我的视频号：

点击“阅读原文”查看更多分享，欢迎点分享、收藏、点赞、在看。