技术干货 | mPaaS 框架下如何使用 Crash SDK 对闪退进行分析？

目前 mPaaS Android 是使用的是 Crash SDK 对闪退进行的处理，Crash SDK 是 Android 平台上一款功能强大的崩溃日志收集 SDK，有着极高的崩溃收集率和完整、全面的崩溃日志信息，生成的日志内容很是利于问题的跟进和解决。

在咱们的平常运维中，常常遇到一些闪退，没法直接从闪退堆栈看到缘由，尤为是一些非 Java 的 Native 的闪退，这里分享下在 mPaaS 框架下怎么使用 Crash SDK 对闪退进行分析。

 

 

闪退报文分析工具介绍

对于 mPaaS 的用户，从 MAS 上闪退分析平台导出的通常是原始的闪退信息，闪退信息比较多，若是直接阅读会比较困难，使用者能够经过下载 Chrome 的插件 LogAnalyzer。

LogAnalyzer 会将 Crash SDK 生成的日志文本内容转化成可视效果较强的 HTML 页面展示，功能仍是很强大的，主要包含：

1. 高亮显示日志中重点信息，并使用不一样颜色区分；
2. 支持日志内容总体结构预览，快速定位重点内容；
3. 常见崩溃缘由提醒；

安装好 Chrome 插件后，还须要作如下配置

1. 修改闪退文件后缀为 .txt

因为 MAS 上默认下载的文件后缀是.dat，须要改成.txt，不然 LogAnalyzer 会不识别。

2. 修改插件配置

因为 Chrome 默认权限限制，任何 Chrome 插件默认都不能访问文件网址，须要在 Chrome 插件中进行以下操做。

1.打开 Chrome 插件管理页面 chrome://extensions/

2.找到 LogAnalyzer 插件，点击 “详细信息" 进入设置：

3.找到容许访问文件网址选项，并勾选；
4.打开或者刷新日志页面，LogAnalyzer 就生效了。

3. 生效效果

把日志文件直接拖到 Chrome 后，能够看到右边插件生效后，能够经过不一样颜色显示闪退信息的各个字段。

首次打开后的使用说明以下：

正常查看闪退截图以下：

 

 

闪退分析举例

咱们常常在平常运维中遇到一些非 Java 的 Native 模块闪退，好比 UC。这种时候不少时候只能去联系 UC 团队进行支撑，其实不少场景下，闪退的根因并非 UC，只是最后的闪退点在 UC。

以最近平常运维中比较常遇到的 UC 内核的闪退为例，对一些案例的处理分享以下。

1. Java 空指针致使 UC 闪退

咱们在闪退点上能够看到如下闪退（已经隐藏客户 apk 相关信息)，若是只是从这看咱们暂时没有任何线索，咱们继续往下看日志：

当看到 logcat 节点信息的时候，咱们发现了线索，首先咱们看到关键字：begin to generate native report，表示当前是闪退日志上报的日志，咱们再往前看，logcat 节点里打印了异常堆栈信息。

从堆栈信息能够看到，是因为 precreate 操做触发了底层的空指针，从而致使初始化异常，最后触发了闪退。解决方案就是临时关闭预建立，从而规避了闪退。

从上面的案例咱们能够看出：

1. Native 的闪退不必定是 Native 模块的缘由致使的，有多是因为 Java 致使的异常，从而致使 Native 闪退；
2. begin to generate native report 附近能够看闪退相关的 logcat 信息，协助定位闪退的一些上下文日志。

2. 上层 OOM 致使 UC 闪退

首先咱们看上报的闪退点的日志以下图所示，闪退在了 RenderThread 里，也是毫无头绪。

咱们继续硬着头皮往下看，在 logcat 节点里查找 begin to generate native report 上报节点，咱们看到了大量的底层 OOM 的异常日志，基本大几率肯定是 OOM 的缘由了。

剩下的就是查找 OOM 是哪里触发的。

点击闪退里的内存节点，基本缘由就比较清晰了，当前手机的 Vmsize 基本已经到最大了，咱们知道对于 32 位的进程，APP 可以使用的 VmSize 最大为 3GB，不过当运行在 64 位 CPU 上时，VmSize 最大可超过 3GB，接近 4GB。

可是因为内核须要占据一部分，以及不一样的 ROM 版本的差异，咱们发现有如下规律：Android 8.1.0 及以后的系统，大部分 native oom crash 发生时 VmSize 分布在 3.5 - 3.9 G 的位置，相对较为集中。因此下面的案例的解决思路就变成了怎么解决 OOM 了。

3. FD 误关致使 UC 闪退

上报的日志以下图所示，咱们大概只能看出 SIGILL 有多是主动崩溃，崩溃 ILL_ILLOPC 表示非法操做。

而后咱们继续看 logcat 节点的 begin to generate native report, 基本确认缘由是由于 UC 使用的 FD 对象被其余程序关闭。

随后 UC 提供了带 FDscan 的工具包，经过咱们复现后发现，是因为 UC 调用 shouldIntercept 回调的输入流对象被其余模块 close 掉了，致使 UC 使用的时候发现 FD 对象已经被关闭，从而作了崩溃处理。最后的处理方案就变成了用户解决其余模块的误关 FD 的问题。

 

 

总结

综合以上的 Case 分析，在遇到 Native 模块闪退的时候，通常若是从直接的闪退堆栈看不出缘由的时候，不要心急，能够搜索 begin to generate native report 找到崩溃上下文，多看看 logcat 闪退上下文的日志，会有一些收获，同时对于 oom 类型的问题，能够结合当前内存统计来看。

 

 

关于 mPaaS MAS

MAS 移动分析服务：经过多端埋点数据的采集与分析，实现产品核心指标监控。

支持应用稳定性分析，包括闪退监控、异常监控、性能监控及用户诊断功能，帮助开发人员及时发现、定位问题。

帮助企业更好的完成业务监控、用户洞察与行为分析，指导产品迭代，精细化产品运营，辅助营销决策，加速业务商业化。

点击了解MAS更多资讯

 

- END -