稳定性优化

Crash 相关指标

• UV Crash、PV Crash 率
  • UV Crash 率：一段时间内所有用户崩溃的占比
  • PV Crash 率：一段时间内所有启动次数崩溃的占比
• Java、Native Crash 率
• 启动、重点流程 Crash 率【最影响用户的 Crash】
• 增量、存量 Crash 率

Crash 率评价

• 必须在千分之二以下
• 万分位为优秀

Crash 关键问题

• 尽可能还原 Crash 现场
  • 堆栈、设备、OS版本、进程、线程名、Logcat
  • 前后台、使用时长、App版本、小版本、渠道
  • CPU 架构、内存信息、线程数、资源包信息、行为日志
• APM 后台聚合展示
  • Crash 现场信息
  • Crash Top 机型、OS 版本、分布版本、区域
  • Crash 起始版本、上报趋势、是否新增、持续、量级

Crash 率治理方案

• 解决线上常规 Crash
• 系统级 Crash 尝试 Hook 绕过
• 疑难 Crash 重点突破、更换方案

业务高可用

• 异常业务流程监控
  • Catch 代码块：确实不会崩溃，但是业务不能正常执行，同样需要上传该 Catch 到的信息
  • 异常逻辑：本该正常流程的逻辑但是走到了另一条（else）分支，同样需要上传该异常逻辑的信息
• 单点问题
  • 需要针对性分析的特定问题，全量日志回捞，专项分析
• 业务不可用兜底策略
  • 功能支持配置，不可用时通过配置中心调整功能开关
  • 组件化路由分发中心进行拦截，不可用时不跳转或者跳转到统一的异常界面，如果网页H5有相同功能且支持手机端还可跳转到该H5

移动端容灾方案

移动端出现异常处理方案

• 传统流程：用户反馈 -> 重新打包 -> 渠道更新 【这是不可接受的】
• 动态热修复
  • 要做到热修复能力可监控、灰度、回滚、清除的能力
  • 要做到推拉结合、多场景调用，保证下发率
• 安全模式
  • 根据 Crash 信息自动修复，多次启动失败重置 App
  • 严重 Bug 可以考虑使用阻塞性热修复，确保修复包正常下发了，才允许进入主界面

容灾方案实现：功能开关 -> 统跳中心 -> 动态修复 -> 安全模式

全流程 Crash 长效治理

• 开发阶段
  • 统一编码规范、增强编码功底、技术评审、CodeReview 机制
  • 架构优化：能力收敛、统一容错，采取统一的路由跳转、统一网络库等基础功能，做到基础功能统一监控和容错
• 测试阶段
  • 功能测试、自动化测试、回归测试、覆盖安装等
  • 特殊场景机型等边界测试
• 合码阶段
  • 编译检测、静态扫描、CI门禁
  • 预编译流程、主流程自动回归，通过了才允许合入
• 发布阶段
  • 多轮灰度、由小变多，争取以最小代价暴露最多问题
  • 分场景、维度全面覆盖，如针对某个地域或某个机型等更有可能出现问题的用户进行下发
• 运维阶段【正式发版】
  • 依靠 APM 的灵敏监控
  • 针对异常情况考虑回滚、降级处理
  • 也可热修或使用预留的容灾方案