Part 10
一 如何提升App的稳定性
1、正确认识
稳定性是大问题，Crash是P0优先级的
稳定性可优化面很广(Crash、卡顿、耗电等)
2、稳定性纬度
Crash纬度
性能纬度(启动速度、卡顿、电量、流量、内存等)
业务的高可用纬度
3、稳定性优化概览
重在预防、监控必不可少
思考更深一层、重视隐含信息
长效保持需要科学流程
二 高Crash率的破解之道
1、Crash相关指标
UV、PV Crash率
PV访问量（Page View），即页面访问量，每打开一次页面PV计数+1，刷新页面也是。
UV访问数（Unique Visitor）指独立访客访问数，一台电脑终端为一个访客。
UV Crash率 = Crash UV(发生崩溃的用户)/DAU(日活跃用户数量)
UV方便评估用户影响范围
PV方便评估Crash的影响程度
注意：沿用一种衡量方式作为评定指标
Java、Native Crash率
Java Crash开发中最常见问题如各种的EXCEPTION
Native Crash相对来讲比较难以分析的类型
启动、重点流程Crash率
影响最严重的Crash
结合客户端容灾
增量、存量Crash率
增量->新出现的Crash->新版本的重点
存量->老版本就有Crash->继续啃的硬骨头
处理策略： 优先解决增量、持续跟进存量扫描二维码关注公众号，回复： 5820620 查看本文章
crash率评价
Java、Native的Crash务必在千分之二以下
Crash率万分位优秀
2、Crash关键问题
尽可能还原Crash现场
堆栈、设备、OS本版、进程、线程名、logcat
前后台、使用时长、App版本、小版本、升级渠道
CPU架构、内存信息、线程数、资源包信息、行为日志
APM后台聚合展示
Crash线程信息
Crash Top机型、os版本、分布版本、区域
Crash起始版本、上报趋势、是否新增、持续、量级
3、Crash治理方案
解决线上常规Crash
系统级的Crash尝试Hook绕过
疑难Crash重点突破、更换方案
三 移动端业务高可用方案
1、业务高可用重要性
高可用：性能+业务
业务高可用侧重于用户功能完整可用
业务高可用真实的影响收入
2、业务高可用方案建设
数据采集
梳理项目主流程、核心路径、关键节点
Aop自动采集、统一上报
报警策略
阈值报警(某个点击事件不可相应超过一定次数)
趋势报警(昨天异常和今日的对比)
特定指标报警、直接上报
异常监控
Catch代码块(catch导致的功能不可用)
异常逻辑(如:返回false导致的功能不可用的统计)
// 以下代码是为了演示业务不正常场景下的监控
try {
// 一些业务处理
Log.i("", "");
} catch (Exception e) {
ExceptionMonitor.monitor(Log.getStackTraceString(e));
}
// 异常逻辑场景下的监控
boolean flag = true;
if (flag) {
// 正常，继续执行流程
} else {
ExceptionMonitor.monitor("");
}
//异常控制类
public class ExceptionMonitor {
public static void monitor(String message){
// 数据缓存及后续上报逻辑
}
}
单点追查
需要针对性分析的特定问题
全量日志回捞，专项分析
兜底策略
热修复
配置中心，功能开关(服务端动态控制业务功能)
跳转分发中心(模块化开发的路由，有问题的界面不进行跳转或跳转至统一提示界面)
四 移动端容灾方案
1、移动端容灾方案必要性
灾：性能、业务异常
传统流程:用户反馈、重新打包、渠道更新
2、容灾方案建设
功能开关
配置中心，服务端下发配置控制
针对场景：功能新加或代码改动
示例代码
//配置管理类
public class ConfigManager {
public static boolean sOpenClick = true;
}
//在添加或者修改的代码中添加判断
if(ConfigManager.sOpenClick){
//新逻辑
}else{
//老逻辑
}
//通过服务端接口的返回值修改sOpenClick的状态
统跳中心
界面切换通过路由，路由决定是否重定向
eg：Native Bug不能热修复则跳转到临时的H5界面中
动态化修复
热修复能力、可监控、灰度、回滚、清除
推拉结合、多场景调用保证到达率
Weex、RN增量更新
安全模式
根据Crash信息自动恢复，多次启动失败重置App
严重Bug可阻塞性热修复(只有热修复成功才可进入app主界面)
异常熔断：多次请求失败则主动拒绝
示例代码
1.通过UncaughtExceptionHandler记录崩溃
2.在Application中
private int mCrashTimes;//崩溃次数
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
if(mCrashTimes > 3){
// 删除文件，恢复到重新安装的状态
}
if(mCrashTimes > 5){
// 清除热修信息
}
}
五 稳定性长效治理
1、全流程Crash长效治理
开发阶段
统一编码规范、增强编码功底、技术评审、CodeReview机制(用3个月左右的时间统一之后一般可达到目的)
架构优化：能力收敛、统一容错
测试环节
功能测试、自动化测试、回归测试、覆盖安装
特殊场景、机型等边界测试
云测平台(提供多种机型)
合码阶段
编译检查、静态扫描
预编译流程、主流程自动回归
发布阶段
多轮灰度(又少变多)
分布场景、纬度全面覆盖
运维阶段
灵敏监控
回滚、降级策略
热修、容灾方案