​应用程序闪退称之为 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

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

​