Android 的两种崩溃
- Java 崩溃就是在 Java 代码中，出现了未捕获的异常，导致程序异常退出
- Native 崩溃一般都是因为在 Native 代码中访问非法地址，也可能是地址对齐出了问题，或者发生了程序主动 abort，这些都会产生响应的 singal 信号，导致程序异常退出
1.Native 崩溃的捕获流程
参考资料： Android 平台 Native 代码的崩溃捕获机制及实现
- 编译端编译时保留带符号信息的文件；
- 客户端将崩溃日志和尽可能多的有用信息写入日志文件，并上传到服务器；
- 服务端读取日志文件，找到适合的符号文件，生成可读的 C 调用栈。
2.Native 崩溃捕获的难点
最核心的是怎么样保证客户端在各种极端情况下一日可以生成崩溃日志。
Chromium 的 Breakpad 是目前 Native 崩溃捕获中最成熟的方案。
3.选择合适的崩溃服务
- 腾讯 Bugly
- 阿里 啄木鸟平台
- 网易云捕
- Google Firebase
如何客观地衡量崩溃
如果想评估崩溃造成的用户影响范围，先去看 UV 崩溃率。
UV 崩溃率 = 发生崩溃的 UV / 登录的 UV常用指标还有 PV 崩溃率、启动崩溃率、重复崩溃率。
启动崩溃对用户伤害最大，应用无法启动往往通过热修复也无法拯救。
重运营的应用汇使用”安全模式“来保证客户端的启动流程。
参考资料：
PV 即 Page View，网站浏览量，指页面的浏览次数，用以衡量网站用户访问的网页数量。用户没打开一个页面便记录1次PV，多次打开同一页面则浏览量累计；
UV 即Unique Vistor，独立访客数，指1天内访问某站点的人数，以cookie为依据。1天内同一访客的多次访问只计为1个访客；
淘宝团队是如何进行稳定性测试的
安全模式：天猫App启动保护实践
如何客观地衡量稳定性
如何发现应用中的ANR
使用 FileObserver 监听 /data/anr/traces.txt 的变化
高版本没有这个文件读取权限了，海外可以使用 Google Play 服务，国内微信利用 HardCoder 框架监控消息队列的运行时间
缺点是无法准确判断，也无法得到完整日志
异常率
应用退出的情景
- 主动自杀
- 崩溃
- 系统重启
- 被系统杀死
- ANR
通过设置标志位，主动自杀或崩溃后更新标志位，在启动应用时检查标志位，可以统计到异常退出情况。
UV 异常率 = 发生异常退出或崩溃的 UV / 登录 UV通过异常率我们可以比较全面的评估应用的稳定性。
课后作业
题目：使用 Breakpad 来捕获一个 Native 崩溃。
步骤如下：
- clone 项目到本地，导入 AS
- 由于早就配置过 ndk 环境，因此这一步跳过，直接可以跑起来
- 点击 APP 上的 CRASH 按钮，应用闪退，获得 crash 日志 714cda98-1316-41cc-c1da0ca0-03b243a0.dmp，在 /sdcard/crashDump/ 目录下
- 将其 pull 到本地
- 尝试使用项目中提供的 minidump_stackwalk 工具分析 dmp 文件，运行报错
- 根据提示这个 minidump_stackwalk 文件需要自己重新编译，找到breakpad的主页，按照步骤操作，编译成功
- 使用编译好的 minidump_stackwalk 工具分析 dmp 文件，运行成功，获得关键信息: Thread 0 (crashed) 0 libcrash-lib.so + 0x77e
- 找到 libcrash-lib.so 拷到当前目录，运行 arm-linux-androideabi-addr2line 命令，定位到报错方法
➜ chapter01 /Users/daniel/Library/Android/sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line -f -C -e libcrash-lib.so 0x77e
Crash()
/Users/daniel/Workspace/Chapter01/sample/src/main/cpp/crash.cpp:10