得物App Android Crash治理演进

应用程序闪退称之为Crash,Crash率是衡量APP好坏的一个重要指标，有效的治理可以减少应用程序Crash带来用户体验问题，甚至用户流失。本文讲述得物App Android客户端的Crash率从千分之八做到万分之三过程中所做的工作,按时间阶段分别介绍在以下几个方向上的演进。

• crash预防
• crash监控告警
• crash降级保护
• crash排查定位
• crash修复

第一阶段(石器时代)

Crash信息采集，指标建立，简易的Crash分发流程

1. 基于第三方平台 bugly 采集crash信息 ，建立crash指标。
2. 每天定时以及版本发布后观察bugly crash问题 根据堆栈查找到代码作者
3. crash表格手动整理发送到群及邮件。 大致的处理流程如下图。

​

通过上述方式我们有了crash信息和crash指标参考。

不过印象深刻的是当时每次灰度发版本加班处理crash是常态，而且很多crash由于信息缺少无法排查。每周日还得挨个去查看crash整理表格数据。线上灰度版本质量和crash数据统计的准确性都在经受考验。

第二阶段(青铜时代)

灰度熔断机制(crash告警)

为了保证灰度版本的质量加入了灰度熔断机制。

1. app升级sdk
2. 基于crash sdk 监控的hook 上报同样一份数据到sls,crash达到阀值自动停止灰度。

日志文件SDK&规范(crash 排查)

为了获取crash时更多的信息 加入了本地文件信息记录。

1. 新增日志sdk
2. 用户反馈,crash等场景主动上报日志信息
3. 规范日志打印

• VERBOSE,DEBUG日志仅打印到控制台(方便调式打点）
• INFO，WARN，ERROR日志打印同时会被记录到文本日志(关键操作,线上问题定位)
• BUG日记记录同时会提交到bugly及阿里云(重要错误及时上报，测试环境抛出异常暴露问题)

自动解析统计(crash统计)

建立了基于bugly的crash处理机制

1. 新同学加入时 加入buglyId 映射表
2. 每个灰度版本发布完成后，需要对bugly 的crash问题进行追踪，找到top的问题记录相关数据并分发给相关责任人进行处理，相关同学处理完问题后对问题的处理进行一个简单的描述及标记
3. 分发这部分无法自动化，需要这边查看原因确认代码是谁提交的，才能将crash 状态变更到处理中并将其指派给相关同学，或者小伙伴主动上bugly认领一下crash问题。
4. 分发完bug后 会去跑一个脚本，生成crash信息统计表格填在文档上。

第三阶段(铁器时代)

应用评论crash通知(crash告警)

我们发现了一种Crash 场景,发生Crash时 Crash sdk还没初始化，Crash平台上没展示，但是应用市场有了Crash评论。所以去做了实时监控四大应用市场crash评论用于及时发现Crash问题

配置中心(crash 兜底)

为了减少线上问题，上线一个新功能时我们需要一个配置用于新功能的逐渐放量或者功能回退。

简易流程

​

埋点上报SDK(crash排查)

本地日志上报有实时性不高，捞取成功率不高，无法支持多维度问题数据统计的的功能。埋点上报模块与其进行了互补，及时发现线上问题和统计问题指标。

​

异常数据补充上报(crash 排查)

BPM SDK

在埋点SDK基础上封装了业务异常打点SDK 增加了业务模块,流量控制的流程。

堆栈缺少主要日志

1. 比如第一种堆栈我们更想知道具体报错的url
2. 第二种需要知道具体跳转到哪个activity 携带了什么参数导致崩溃。

​

​

这些问题能通过使用aspectj,ASM等字节码修改框架很方便的hook到我们想要的内容。

​

​

ART OOM 信息补充上报

1. 采集了当前进程内存状态

proc/self/smaps 的解析

2. 线程问题

采集了最大限制线程数，使用Thread.getAllStackTraces()获取当前线程堆栈信息 分别按照线程名和线程堆栈进行聚合 app打包时使用了字节码查桩对线程进行了重命名。

3. FD问题

fd信息聚合输出

4. 图片问题

hook获取当前加载图片的source url 尺寸。dump BitmapPool中的内存信息。dump当前屏幕上图片的url地址以及尺寸大小

5. 灰度内存超过阀值的部分wifi设备hprof文件的上送问题分析。

三方库问题处理(Crash 保护)

提供了du_aspect模块把一些第三方库的Crash通过字节码插桩方案try catch 降级为异常上报。

升级64位so(Crash 治理)

oom信息补充上报后，我们发现vmsize触顶的场景占比特别大。升级64位后占比大幅下降

第四阶段(蒸汽时代)

异常埋点平台(crash 排查)

异常埋点平台化,规范异常埋点流程,异常埋点管理。

平台建立埋点->生成代码->代码内手动埋点->发布后命中的设备上报异常埋点。

​

文件回捞(crash 排查)

文件回捞SDK,支持APP内任意文件路径下发回捞，使用场景。

1. 作为异常文件tombstone的补充回捞
2. 直播,音视频等业务线独立日志的回捞需求。

Crash安全中心(crash数据支持,crash降级兜底)

​

Crash降级兜底

​

分析工具(crash 排查)

堆栈反混淆工具

1. 堆栈反混淆
2. 查看每一行堆栈对应组件版本号,组件负责人,代码修改认等信息用来提高问题定位速度。

​

多维度日志分析

• 通过设备id,用户id快速查看异常日志
• 开发同学可以点击查看详细日志排查问题
• 测试同学可以查看问题上下文 问题堆栈负责人快速分享给开发负责人

​

关联OSS文件

1. crash后本地日志文件的查看
2. art oom场景hprof文件查看

自建Crash平台(crash告警, crash分发,crash统计,crash 处理流程优化)

​

异常Crash处理流程优化

​

文/zjy

关注得物技术，携手走向技术的云端