1、Android的两种崩溃
- Java崩溃 ：在 Java 代码中，出现了未捕获异常，导致程序异常退出
- Native崩溃 ：一般都是因为在Native代码中访问非法地址，也可能是地址对齐出现了问题，或者发生了程序主动abort（使中止），这些都会产生相应的signal信号，导致程序异常退出
2、Native崩溃的捕捉流程
课前准备 ----Android 平台 Native 代码的崩溃捕获机制及实现
- 现有方案
| 方案 |
优点 |
缺点 |
| Google Breakpad |
权威，跨平台 |
代码体量较大 |
| 利用Logcat日志 |
利用安卓系统 |
需要在crash时启动新进程过滤logcat日志，不靠谱 |
| coffeecatch |
实现简洁，改动容易 |
存在兼容性问题 |
- Native崩溃从捕获到解析要经历的流程
3、Native崩溃捕捉的难点
- 怎样保证客户端在各种极端情况下依然可以生成崩溃日志（Native崩溃捕捉的难点）
1、情况一：文件句柄泄漏，导致创建日志文件失败，怎么办？
应对方式：我们需要提前申请文件句柄fd预留，防止出现这种情况
2、情况二：因为栈溢出了 ，导致日志生成失败，怎么办？
应对方式：为了防止栈溢出导致进程没有空间创建调用栈执行处理函数，
通常会使用常见signalstack。在一些特殊情况下，可能还需要直接替换当前
栈，所以也需要在队中预留部分空间
3、整个堆的内存都耗尽了，导致日志生成失败，怎么办？
应对方式：这个时候无法安全的分配内存，也不敢使用stl或libc的函数，
因为它们内部实现会分配内存，这个时候如果继续分配内存，会导致出现对破坏
或者二次崩溃。Breakpad做的比较彻底，重新封装了Linux Syscall Support，来
避免直接调用libc。
4、堆破坏或二次崩溃导致日志生成失败，怎么办？
应对方式：BreakPad会从原进程fork出子进程去手机崩溃现象，此外涉及与java
相关的，一般也会用子进程去操作，这样即使出现二次崩溃，只是这部分的信息
丢失，父进程后面还可以继续获取其他的信息，在一些特殊的情况，还可能需要
从子进程fork出孙进程
4、客观的衡量崩溃
- 现存的第三方崩溃服务
1、腾讯的Bugly
2、阿里的啄木鸟平台
3、网易云捕
4、Google的Firebase
- 崩溃率的衡量
1、UV（unique visitor 独立访客）崩溃率
2、PV（page view 页面浏览量）崩溃率
3、启动崩溃率
4、重复崩溃率
- 计算方式
UV 崩溃率 = 发生崩溃的UV / 登录的UV （其他相同）
- 启动页崩溃的解决方案-----安全模式
由于启动崩溃对用户的伤害最大，应用无法启动往往通过热修复也无法拯救
故需要通过一些特殊方式来处理，微信读书、蘑菇街、淘宝、天猫使用一种
叫做安全模式的技术来保障启动流程
1、判断异常退出：
a、App启动时记录一个flag值，当满足以下条件时，将flag清除
<1> App正常启动10秒
<2>用户正常退出应用
<3>永固主动从前台切换到后台
当启动阶段发生异常，则flag值不会清空，通过flag可以判断客户端是否
异常退出，每次退出，flag值都会+1
2、安全模式的分级执行策略
a、安全模式中根据flag值的大小做了分级执行策略，目前分为两级安全
模式，连续crash 2次为一级安全模式，连续crash 3次及以上为二级安全
模式
b、业务线可以在一级安全模式中注册行为，比如某业务要清空缓存数据，
这样在进入一级安全模式时，安全模式就会自动调用注册的行为，尝试修
复客户端
c、如果一级安全模式无法修复APP，则会进入二级安全模式，二级安全模
式会将APP恢复到初次安装状态，将Document、Library、Cache三个根目
录清空
3、热修复执行策略
a、老版本热修复策略：二级安全模式中触发。
b、连续crash 3次后触发，在有问题的情况下，能打开这么多次APP的用户
太少了，则需要将热修复从具体的级别中剥离，只要发现配置中需要热修复，
APP就会同步阻塞进行热修复，保证修复的及时性
4、灰度方案
a、安全模式指定聊简单的灰度方案，灰度时，配置中会同时包含灰度、正式两
份配置，也会包含灰度的开率
b、App根据自己特定算法（业务需求）算出是否满足灰度条件，若满足，则使
用灰度配置，否则使用正式配置
- 延伸
1、动态配置---不要写死！天猫App的动态化配置中心实践
2、App A/B测试---天猫App A/B测试实践
3、解耦神器---解耦神器 —— 统跳协议和Rewrite引擎
5、客观的衡量稳定性
- 发现ANR的方法
1、使用FileObserver监听/data/anr/traces.txt的变化，不过现在高版本的
ROM没有这个权限了。国外现在使用Google Play服务，国内微信现在使
用的是Hardcoder框架（HC框架是一套独立于安卓系统实现的通信框架，
它让App和厂商ROM能够实时对话，目标就是充分调度系统资源来提升
APP的运行速度和画质，切实提高大家的手机使用体验）向厂商获取了更大
的权限。这一策略优点像IOS的机制，优先调度系统资源给最前端的app使用。
- 常见的应用退出情形
1、主动自杀：Process.killProcess()、exit()等。
2、崩溃：出现了Java和Native崩溃
3、系统重启：系统出现异常、断电、用户主动重启
4、被系统杀死
5、ANR
- 异常率
UV 异常率 = 发生异常退出或崩溃的 UV / 登录 UV
通过异常率来评估应用的稳定性
说明：文章内容摘录自Android 开发高手课程图文数据