如何提升App的稳定性
正确认识
大型、运营期才重视
Crash是P0优先级
稳定性可优化的面很广
稳定性维度
Crash维度
性能维度
业务高可用
稳定性概览
重在预防，监控必不可少
思考更深一层、重视隐含信息
长效保持需要的科学流程
高Crash率的破解之道
Crash相关指标
1UV、PV Crash率
UV Crash率： 一段时间内所有用户中崩溃的用户占比
PV Crash率： 一段时间内所有用户启动次数中崩溃的使用占比
注意：沿用同一种衡量方式
2Java、Native Crash率
3启动、重点流程 Crash率
启动10S内，影响最严重的Crash
结合客户端容灾
4增量、存量 Crash率
新增的Crash
存量=老版本Crash
增量Crash是新版本重点
存量Crash是持续啃得硬骨头
优先解决增量，持续追查存量
Crash率评价：
务必在千分之二
Crash万分位优秀
Crash关键问题
尽可能还原Crash现场
.堆栈、设备、OS版本、进程、线程、log
.前后台、使用时长、app版本、小版本、渠道
.CPU架构、内存信息、线程数、资源包信息、行为日志
APM后台聚合展示：
.Crash现场信息
.Crash Top机型、OS版本、分布版本、区域
.Crash骑士版本、上报趋势、是否新增、持续、量级
整体架构
Crash关键问题
责任归属
.专项小组轮值
.自动匹配分配
.处理流程全纪录
单个Crash处理方案：
.根据堆栈及现场信息找答案
.找共性:机型、OS、式样开关、资源包
.线下复现、远程调试
Crash率治理方案：
.解决线上常规Crash
.系统级Crash尝试Hook绕过
.疑难Crash重点突破、更换方案
移动端业务高可用方案建设
业务高可用重要性
高可用：性能+业务
业务高可用侧重于用户功能完整可用
业务高可用真实的影响收入
业务高可用具体建设
数据采集
.梳理项目主流程、核心路径、关键节点
.可用Aop自动采集、统一上报
报警策略
.阈值报警
.趋势报警
.特定指标报警、直接上报
异常监控
.Crash代码块
.异常逻辑
单点追查
.需要针对性分析的特定问题
.全量日志回捞，专项分析
兜底策略
.配置中心，功能开关
.跳转分发中心
总结
移动端容灾方案
必要性
灾：性能、业务异常
传统流程：用户反馈、重新打包、渠道更新，不可接受
建设
功能开关
.配置中心，服务端下发配置控制
.针对场景：功能新加或代码改动
统跳中心
.界面切换通过路由，路由决定是否重定向
.eg 跳到H5
动态化修复
.热修复能力，可监控，灰度，回滚，清除
.推拉结合，多场景调用保证到达率
.Weex、RN增量更新
安全模式
.根据Crash信息自动回复，多次启动失败重置App
.严重Bug壳阻塞性热修
.异常熔断：多次启动失败则主动拒绝
稳定性长效治理
全流程Crash长效治理
开发阶段
.统一编码规范、增强编码工地、技术评审、CodeReview机制
.架构优化：能力收敛、统一容错
测试阶段
.功能测试、自动化测试、回归测试、覆盖安装
.特殊场景、机型等便捷测试
.云测平台
合码阶段
.编译检测，静态扫描
.预编译流程，主流程自动回归
发布阶段
.多轮灰度
.分场景、维度全面覆盖
运维阶段
.灵敏监控
.回滚、降级策略
.热修、容灾方案
稳定性优化模拟面试
做了哪些稳定性方面的优化
随着项目成熟，Crash专项优化，性能稳定性优化，业务稳定性优化。
性能稳定性方面怎么做的
线下返现问题、优化为主
线上监控为主
Crash专项优化
业务稳定性如何保障
数据采集+报警
异常监控+单点追查
兜底策略
返现异常情况，怎么快速止损
能力：功能开关、统跳中心
动态修复：热修、资源包更新
自主修复：安全模式
