崩溃优化（上）

1. Android 的两种崩溃

Android 分为 Java 崩溃和 Native 崩溃。

• java 崩溃：在 java 代码中，出现了未捕获异常，导致程序异常退出；
• Native 崩溃：在 Native 代码中访问非法地址，也可能是地址对齐出现问题，或者发生了程序主动 abort，这些都会产生相应的 signal 信号，导致程序异常退出；

1.1 Native 崩溃的捕获流程

Android 平台 Native 代码的崩溃捕获机制及实现

• 编译端。编译 C/C++ 代码时，需要将带符号信息的文件保留下来。
• 客户端。捕获到崩溃的时候，将收集到尽可能多的有用信息写入日志文件，然后选择合适的时机上传到服务器。
• 服务端。读取客户端上报的日志文件，寻找合适的符号文件，生成可读的 C/C++ 调用栈。

image

2. 如何客观地衡量崩溃

UV 崩溃率

UV 崩溃率 = 发生崩溃的 UV / 登录 UV

注：UV(Unique visitor):指通过互联网访问、浏览这个网页的自然人。访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。一天内同个访客多次访问仅计算一个UV。

如何清楚易懂的解释“UV和PV＂的定义？

只要用户出现过一次崩溃就会被计算到，所以 UV 崩溃率的高低会跟应用的使用时长有比较大的关系。我们还可以去看应用 PV 崩溃率、启动崩溃率、重复崩溃率这些指标。

3. 如何客观地衡量稳定性

崩溃率不能完全地等价于应用的稳定性，因为我们还经常会遇到 ANR (Application Not Responding) 这个问题。

ANR 收集：

1. 使用 FileObserver 监听 /data/anr/traces.txt 的变化。（很多高版本的 ROM 已经没有读这个文件的权限）
2. 监控消息队列的运行时间。这个方案无法准确地判断是否真正出现了 ANR 异常，也无法得到完整的 ANR 日志，更应该放到卡顿的性能范畴。

除了常见的崩溃，还有一些会导致应用异常退出：

• 主动自杀。 Process.killProcess()、 exit() 等；
• 崩溃。出现了 Java 或 Native 崩溃；
• 系统重启。系统异常、断电、用户主动重启等，可以通过比较应用开机运行时间是否比之前记录的值更小；
• 被系统杀死。 被 low memory killer 杀掉、从系统任务管理器中划掉等；
• ANR

我们可以在应用启动的时候设置一个标志，在主动自杀或者崩溃之后更新标志，这样下次启动的时候通过检测这个标志就能确认运行期间是否发生过异常退出。

上面五种退出场景，我们排除掉主动自杀和崩溃（崩溃会单独统计）这两种场景，希望通过剩下的三种异常退出，理论上可以覆盖100%的异常捕获。

可以得到一个新的指标来衡量应用的稳定性，及异常率

UV 异常率 = 发生异常退出或者崩溃的 UV / 登录 UV

可以把异常退出分为前台异常退出和后台异常退出。“被系统杀死”是后台异常退出的主要原因，前台退出异常我们会更加关注，比如 ANR、OOM 等。