关于前端:技术干货-mPaaS-框架下如何使用-Crash-SDK-对闪退进行分析

简介： Android Native Crash 解决案例分享

目前 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 会不辨认。

1. 批改插件配置

因为 Chrome 默认权限限度，任何 Chrome 插件默认都不能拜访文件网址，须要在 Chrome 插件中进行如下操作。

1. 关上 Chrome 插件治理页面 chrome://extensions/

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

3. 找到容许拜访文件网址选项，并勾选；
4. 关上或者刷新日志页面，LogAnalyzer 就失效了。

1. 失效成果

把日志文件间接拖到 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 信息，帮助定位闪退的一些上下文日志。
3. 下层 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 了。

1. 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 类型的问题，能够联合以后内存统计来看。

原文链接
本文为阿里云原创内容，未经容许不得转载。