1. 如何提升App的稳定性
Crash维度
性能维度
业务高可用维度
重在预防、监控必不可少。
思考更深一层、重视隐含信息
长效保持需要科学流程
2. 高Crash率的破解之道
Crash相关指标（Crash率）
UV、PV
天访问。 次访问。
Java native
启动、重点流程
影响最严重的Crash
结合客户端容灾
增量、存量
增量Crash是新版本重点
存量Crash是持续啃的硬骨头。
优先解决增量、持续跟进存量Crash
Crash率评价
千分之二以下。
Crash率万分位 优秀
Crash关键问题
尽可能还原Crash现场
堆栈、设备、OS版本、进程、线程名、Logcat
前后台、使用时长、App版本、小版本、渠道
CPU架构、内存信息、线程数、渠道包信息、行为日志
APM后台聚合展示
Crash现场信息
Crash Top机型、OS版本、分布版本、区域
Crash 起始版本、上报趋势、是否新增、持续、量级
采集层：错误堆栈、设备信息、行为日志、其它信息
处理层：数据清洗、数据聚合、维度分类、趋势对比
展示层：数据还原、维度信息、起始版本、其它信息
报警层：环比、同比、邮件、IM、电话
责任归属
专项小组轮值
自动匹配分配
处理流程全记录
Crash治理方案
单个Crash处理方案
根据堆栈及现场信息找答案
找共性：机型、OS、实验开关、资源包
线下复现、远程调试
Crash率治理方案
解决线上常规Crash
系统级Crash尝试Hook绕过
疑难Crash重点突破、更换方案
3. 移动端业务高可用方案建设
业务高可用重要性
高可用：性能 + 业务
业务高可用侧重于用户功能完整可用
业务高可用真实地影响收入
业务高可用方案建设
数据采集
梳理项目主流程、核心路径、关键节点
Aop自动采集、统一上报
业务高可用总结
报警策略
阈值报警
趋势报警
特定指标报警、直接上报
异常监控
Catch代码块
异常逻辑
单点追查
需要针对性分析的特定问题
全量日志回捞，专项分析
兜底策略
配置中心，功能开关
跳转分发中心（路由统一处理 跳到异常页面）
4. 移动端容灾方案
容灾方案
灾：性能、业务异常
传统流程：用户反馈、重新打包、渠道更新，不可接受
容灾方案建设
功能开关
配置中心，服务端下发配置控制
针对场景：功能新加或代码改动
统跳中心
界面切换通过路由，路由决定是否重定向
eg：Native Bug 不能热修则跳转到临时H5
动态化修复
热修复能力。可监控、灰度、回滚、清除
推拉结合、多场景调用保证到达率
Weex、RN增量更新
安全模式
根据Crash信息自动恢复，多次启动失败重置App
严重Bug可阻塞性热修
异常熔断：多次请求失败则主动拒绝
5. 稳定性长效治理
开发阶段：
统一编码规范、增强编码功底、技术评审、CodeReview机制
架构优化：能力收敛、统一容错
测试阶段：
功能测试、自动化测试、回归测试、覆盖安装
特殊场景、机型等边界测试
云测平台
合码阶段：
编译监测、静态扫描
预编译流程、主流程自动回归
发布阶段：
多轮灰度
分场景、纬度全面覆盖
运维阶段：
灵敏监控
回滚、降级策略
热修、容灾方案
6. 稳定性优化模拟面试
1）你们做了哪些稳定性方面的优化？
用户基数逐渐升高。卡顿 功能不可用。
Crash优化
性能稳定性优化
业务稳定性优化
2）性能稳定性是怎么做的？
线下发现问题、优化为主
线上监控为主
Crash专项
3）业务稳定性如何保障？
数据采集 + 报警。 每一步流程 和监控成功率 转化率。
异常监控 + 单点追查。
兜底策略
4）如果发生了异常情况，怎么快速止损？
能力：功能开关（紧急关闭功能开关）、统跳中心
动态修复：热修、资源包更新。 RN、Weex
自主修复：安全模式。
清除所有缓存，级别最高的时候 阻塞主线程，一定要让它达成热修复之后再继续。##### 1. 如何提升App的稳定性
网友评论