本篇只是站在大佬们的肩膀上，供给一些个人关于稳定性建设计划思路，欢迎大家探讨

界说： 这儿的Android稳定性单指Crash

指标口径： 用户可感知溃散率，以用户为纬度，即Crash设备数 / 总设备数

精细化单个bug的纬度：

  • bug频次
  • 爆炸半径
  • 影响时长

从溃散的产生处理整个链路出发： RD编码 –> 线下测验 –> 灰度发版 –> 溃散产生&数据采集聚类 –> RD修正 –> 版别发布

全体思路

Android稳定性方案浅析

1、编码阶段

制定代码规范，加强代码Review，引入静态代码检查，完善测验流程等削减问题产生

a、静态代码检查

有时会呈现某些初级过错如:divide by zero 导致的crash，运用Lint和detekt进行静态代码检查不失为一种好计划，能够放在代码合入的SA阶段

b、检查是否需求处理警告问题

在我们编码或许改动前史遗留的代码时，AS中存在一些警告⚠️，commit时要根据提示进行review，是否需求每次修正和改动还有待商榷

c、检测SQL质量

参阅Matrix SQLite Lint: 按官方最佳实践自动化检测 SQLite 句子的运用质量；(看能否拓展到其他场景)

d、依赖库的检查 (能够跟组件化相关)

选用gradle脚本编译时检查依赖库是否相同，处理不同组件或许不同APP之间SDK版别不一致可能导致的溃散，防止CI阶段打包失利或许上线后呈现异常

  • 新增or改动SDK检测，CI diff 产出依赖树 全功能提测阶段
e、review规范
  • 提交reviewer的质量把控认识；要害代码需求两个人review，+1 +2经过才能够合入
  • 跟流水线CI自动识别中心类文件要求两人review的才能结合起来

2、测验&流水线

进步稳定性的认识，不论多微小的改动都要进行自测！！！

a.单元测验
  • 重点模块的单测才能
b.自动化测验
  • 结合QA补齐自动化测验的才能，掩盖中心场景
  • 跟devops渠道才能结合，将LeakCanary等才能跟Monkey结合，自动创立卡片
  • 针对函数接口的异常数据排雷测验(参阅/post/702812…)
c.CI/CD
  • 流水线打包效率提高

3、溃散数据采集&剖析

正如RD讲的那样，给我一个溃散仓库我就能定位到问题所在，能完好的复原”事故现场”成为重中之重

a.仓库反混杂

结合各个公司APM渠道上传mapping文件以及符号表，每个溃散数据均展现混杂之前的定位

b.渠道仓库聚类
  • 接入iqiyi开源的XCrash库或许breakpad，上报java和native的溃散仓库到Server并聚类展现
  • 接入开源的Sentry库并搭建本地私有化服务，完成溃散的上报和聚类
c.渠道数据状况标识

已修正、Pending、下个版别修正等状况或许备注的标识，每次剖析成果留下文字记载

d.分模块上传要害数据

会员模块上传会员信息、支付模块上传订单信息等

4、灰度阶段

a.测验轨迹前置小版别提早暴露问题
b.三方SDK降级战略

firebase、广告库等三方SDK升级一定要调查溃散率变化，并做好降级处理

c.crash率异常熔断机制
  • 灰度进程短少中间对Crash率异常的鉴定规范，业务异常的鉴定规范
  • 全体&每个溃散数据的量级(该溃散人数/安装率)记载，设定阈值，每日将两个版别比照骤增或许骤降的数据输出并产出陈述
c.上车战略

中心思路是代码改动最小化，预留todo下迭代改，防止构成新的线上crash

5、重点问题处理

I.源码剖析

尽管 androidxref.com 和 cs.android.com 都能够在线查阅源码，但这两处的Android版别并不全；android.googlesource.com 这儿能够下载到简直一切版别的源码，本地经过 Sublime 剖析源码也非常方便（能够直接显示和跳转到方法的界说&引用方位）。

II.OOM问题
a.大图监控管理
  • 线下监控：经过插件在 mergeResources 任务后，遍历图片资源，收集超过阈值的图片资源，输出列表
  • 参阅NativeBitmap 把应用内存运用的大头（即 Bitmap 的像素占用的内存）转移到 Native 堆；但是可能会导致32位虚拟内存不足
  • 在接口层中将一切被创立出来的 Bitmap 参加一个 WeakHashMap，同时记载创立 Bitmap 的时间、仓库等信息，然后在恰当的时分检查这个 WeakHashMap 看看哪些 Bitmap 依然存活来判别是否呈现 Bitmap 乱用或走漏。 微信 Android 终端内存优化实践
b.hook pthred

选用bhook，针对pthread_create创立的子线程中产生了信号(SIGSEGV)进行兜底操作；相当于catch native crash，产生crash时重新履行之前的逻辑

c.32位虚拟内存优化
  • Patrons 经过一系列技能手段完成运转期间动态调整Region Space预分配的地址空间
  • mSponge 优化了虚拟机对 LargeObjectSpace 的内存办理战略，间接添加其它内存空间运用上限 (未开源)
  • pthread hook 对 native 线程的默许栈大小进行折半

Android稳定性方案浅析

d.监控

接入KOOM，进行线下OOM产生时的采样上报

III.native crash
  • google官网供给的native crash问题确诊思路
  • 对Native Crash进行捕获，自界说完成自己的重启逻辑，比如重启/自界说上报crash等等
  • 加载so失利，尝试用java替代的降级战略

6、防裂化&基础建设

a.版别回忆

溃散数据自动化采集，以月度或许季度为纬度爬取数据，构成总结

b.溃散维护和安全形式机制
  • 经过ASM在编译时对四大组件生命周期等要害代码加上try-catch处理
  • 经过一定的战略，针对重复重启导致的溃散问题，让用户挑选继续初始化或许清除数据
c.日志回捞
  • 全埋点用户操作路径辅佐剖析
  • 参阅Logan进行日志回捞系统的建设，方便针对某一用户产生问题后捞回日志剖析
d.移动端性能中台

自建集溃散监控、上报、剖析、归因于一体(能够参阅Matrix直接建立)，能够轻松定位各种线上疑难杂症，更有超具体性能、卡顿、打点等全流程监控处理渠道

参阅：

  • 美团外卖Android Lint代码检查实践 /post/684490…
  • 货拉拉稳定性 /post/710074…
  • 美团外卖Android Crash管理之路 /post/684490…
  • 【得物技能】得物App Android Crash管理演进 /post/700106…
  • 快手客户端稳定性系统建设_如果activity的mdestroyed值为true时(ondestroy时赋值),说明activ_快手技能团队的博客-CSDN博客