原标题：Android Native crash 处理案例分享
简介： Android Native crash 处理案例分享
1. 背景
目前 mPaas[1] Android使用Crash SDK对闪退进行的处理，CrashSDK 是 Android 平台上一款功能强大的崩溃日志收集 SDK，有着极高的崩溃收集率和完整、全面的崩溃日志信息，生成的日志内容非常利于问题的跟进和解决。在日常运维中，经常遇到一些闪退，无法直接从闪退堆栈找到原因，尤其是一些非Java的Native的闪退，这里分享下在mPaas框架下怎么使用Crash SDK分析闪退。
2. 闪退报文分析工具介绍
对于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后，可以看到右边插件生效后，可以通过不同颜色显示闪退信息的各个字段
首次打开后的使用说明如下：
正常查看闪退截图如下：
3. 闪退分析举例
我们经常在日常运维中遇到一些非Java的Native模块闪退，比如UC。其实很多场景下，闪退的根因并不是UC，只是最后的闪退点在UC。以日常运维高频的UC内核的闪退为例，对一些案例的处理分享如下。
1. java空指针导致UC闪退
在闪退点上可以看到以下闪退信息（已经隐藏客户apk相关信息)，暂无任何线索，继续查看日志。
查看logcat节点信息时，首先看到关键字：begin to generate native report, 表示当前是闪退日志上报的日志，在往前看，logcat节点里打印了异常堆栈信息，从堆栈信息可以看到，由于precreate操作触发了底层的空指针，从而导致初始化异常，触发了闪退。解决方案为临时关闭预创建，从而规避闪退。
从上面的案例可以看出，
1) Native的闪退原因不一定是Native模块，有可能是java异常导致的。
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的问题。
4. 总结
综合以上的case分析，在遇到Native模块闪退的时候，一般如果从直接的闪退堆栈看不出原因的时候，不要心急，可以搜索begin to generate native report 找到崩溃上下文，多看看logcat闪退上下文的日志，会有一些收获，同时对于oom类型的问题，可以结合当前内存统计来看。
作者：荣阳