Android开发高性能之 (崩溃优化)

1. Android 的两种崩溃

Android 分为 Java 崩溃和 Native 崩溃。

• java 崩溃：在 java 代码中，出现了未捕获异常，导致程序异常退出；

• Native 崩溃：在 Native 代码中访问非法地址，也可能是地址对齐出现问题，或者发生了程序主动 abort，这些都会产生相应的 signal 信号，导致程序异常退出；

1.1 Native 崩溃的捕获流程

Android 平台 Native 代码的崩溃捕获机制及实现

• 编译端。编译 C/C++ 代码时，需要将带符号信息的文件保留下来。
• 客户端。捕获到崩溃的时候，将收集到尽可能多的有用信息写入日志文件，然后选择合适的时机上传到服务器。
• 服务端。读取客户端上报的日志文件，寻找合适的符号文件，生成可读的 C/C++ 调用栈。
  带尺寸的图片:

2. 如何客观地衡量崩溃

UV 崩溃率

 UV 崩溃率 = 发生崩溃的 UV / 登录 UV

注：UV(Unique visitor):指通过互联网访问、浏览这个网页的自然人。访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。一天内同个访客多次访问仅计算一个UV。

如何清楚易懂的解释“UV和PV＂的定义？

只要用户出现过一次崩溃就会被计算到，所以 UV 崩溃率的高低会跟应用的使用时长有比较大的关系。我们还可以去看应用 PV 崩溃率、启动崩溃率、重复崩溃率这些指标。

3.如何客观地衡量稳定性

崩溃率不能完全地等价于应用的稳定性，因为我们还经常会遇到 ANR (Application Not Responding) 这个问题。

ANR 收集：

1.使用 FileObserver 监听 /data/anr/traces.txt 的变化。（很多高版本的 ROM 已经没有读这个文件的权限）
2.监控消息队列的运行时间。这个方案无法准确地判断是否真正出现了 ANR 异常，也无法得到完整的 ANR 日志，更应该放到卡顿的性能范畴。

除了常见的崩溃，还有一些会导致应用异常退出：

• 主动自杀。 Process.killProcess()、 exit() 等；
• 崩溃。出现了 Java 或 Native 崩溃；
• 系统重启。系统异常、断电、用户主动重启等，可以通过比较应用开机运行时间是否比之前记录的值更小；
• 被系统杀死。 被 low memory killer 杀掉、从系统任务管理器中划掉等；
• ANR

我们可以在应用启动的时候设置一个标志，在主动自杀或者崩溃之后更新标志，这样下次启动的时候通过检测这个标志就能确认运行期间是否发生过异常退出。

上面五种退出场景，我们排除掉主动自杀和崩溃（崩溃会单独统计）这两种场景，希望通过剩下的三种异常退出，理论上可以覆盖100%的异常捕获。

可以得到一个新的指标来衡量应用的稳定性，及异常率

 UV 异常率 = 发生异常退出或者崩溃的 UV / 登录 UV

可以把异常退出分为前台异常退出和后台异常退出。“被系统杀死”是后台异常退出的主要原因，前台退出异常我们会更加关注，比如 ANR、OOM 等。

4.应用崩溃了，你应该如何去分析？

4.1 崩溃信息

从崩溃的基本信息，可以对崩溃有初步的判断。

• 进程名、线程名。崩溃的进程是前台进程还是后台进程，崩溃是不是发生在 UI 线程。
• 崩溃堆栈和类型。崩溃是属于 Java 崩溃、Native 崩溃，还是 ANR。特别需要看崩溃堆栈的栈顶，看具体崩溃在系统代码，还是我们自己的代码里面。

    AndroidRuntime: FATAL EXCEPTION: MyThread
    Process: com.simple.carsh, PID: 6825
    java.lang.ArithmeticException: divide by zero
        at com.simple.crash.TouchActivity$1.run(TouchActivity.java:33)

4.2 系统信息

• Logcat。包括应用、系统运行日志。其中系统的 event logcat 会记录 App 运行的一些基本情况，记录在文件 /system/etc/event-log-tags 中

• 机型、系统、厂商、CPU、ABI、Linux 版本等；

• 设备状态：是否 root、是否模拟器；

4.3 内存信息

• OOM 、 ANR、虚拟内存耗尽等，很多崩溃都跟内存有直接关系。

• 系统剩余内存。关于系统内存状态，可以直接读取文件 /proc/meminfo 当系统可用内存很小（低于 MemTotal 的 10%）时，OOM、大量 GC、系统频繁自杀拉起等问题都非常容易出现。

// /proc/meminfo

MemTotal:        1550948 kB
MemFree:          465832 kB
Buffers:           25008 kB
Cached:           764404 kB
SwapCached:            0 kB
Active:           480312 kB
Inactive:         550552 kB
Active(anon):     241468 kB
Inactive(anon):    12292 kB
Active(file):     238844 kB
Inactive(file):   538260 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:        663432 kB
HighFree:          13024 kB
LowTotal:         887516 kB
LowFree:          452808 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:        241436 kB
Mapped:           188572 kB
Shmem:             12324 kB
Slab:              21936 kB
SReclaimable:      10864 kB
SUnreclaim:        11072 kB
KernelStack:        4056 kB
PageTables:         6132 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      775472 kB
Committed_AS:   18331812 kB
VmallocTotal:     122880 kB
VmallocUsed:       26120 kB
VmallocChunk:      31652 kB
HugePages_Total:       0 kB
HugePages_Free:        0 kB
HugePages_Rsvd:        0 kB
HugePages_Surp:        0 kB
Hugepagesize:       4096 kB
DirectMap4k:       16376 kB
DirectMap4M:      892928 kB

• 应用使用内存。包括 Java 内存、RSS（Resident Set Size）、PSS(Proportional Set Size), 我们可以得出应用本身内存的占用大小和分布。PSS 和 RSS 通过 /proc/self/smap 计算，可以进一步得到例如 apk、dex、so 等详细的分类统计。
• 虚拟内存。虚拟内存可以通过 /proc/self/status 得到，通过 /proc/self/maps 文件可以得到具体的分布情况，很多类似 OOM、tgkill 等问题都是虚拟内存不足导致的。

//  /proc/self/status 

Name:     com.sample.name   // 进程名
FDSize:   800               // 当前进程申请的文件句柄个数
VmPeak:   3004628 kB        // 当前进程的虚拟内存峰值大小
VmSize:   2997032 kB        // 当前进程的虚拟内存大小
Threads:  600               // 当前进程包含的线程个数

4.4 资源信息

• 文件句柄 fd 。文件句柄的限制可以通过 /proc/self/limits 获得，一般单个进程允许打开的最大文件句柄个数为 1024。但是如果文件句柄超过 800 个就比较危险，需要将所有的 fd 以及对应的文件名输出到日志中，进一步排查是否出现了有文件或者线程的泄漏。

• 线程数。当前线程数大小可以通过上面 status 文件得到，一个线程可能占 2MB 的虚拟内存，过多的线程会对虚拟内存和文件句柄带来压力。

• JNI。使用 JNI 时，如果不注意很容易出现引用失效，引用爆表等一些崩溃。

4.5 应用信息

• 崩溃场景。崩溃发生在哪个 Activity 或 Fragment，发生在哪个业务中。
• 关键操作路径。

5崩溃分析

第一步：确认重点

1.确认严重程度。优先解决 Top 崩溃或者对业务有重大影响的崩溃。
2.崩溃的基本信息。确定崩溃的类型已经异常描述，对崩溃有大致的判断。

• Java 崩溃。Java 崩溃比较明显，比如 NullPointerException 是空指针；

• Native 崩溃。需要观察 signal、code、fault addr 等内容，已经崩溃时 Java 的堆栈。崩溃信号介绍

• ANR。先看看主线程的堆栈，是否是因为锁等待导致。接着看看 ANR 日志中 iowait、CUP、GC、system server 等信息，进一步确认是 I/O 问题，或者是 CPU 竞争问题，还是由于大量 GC 导致卡死。

3.LogCat。从 LogCat 中我们可以看到当时系统的一些行为跟手机状态，例如出现 ANR 时，会有 “am_arn”; App 被杀时，会有“am_kill” 。

4.各个资源情况。结合崩溃信息，看看是不是跟“内存信息”有关，是不是跟“资源信息”有关，比如物理内存不足，虚拟内存不足，还是文件句柄 fb 泄漏了。

内存与线程相关的信息都需要特别注意，很多崩溃都是它们使用不当造成的。

第二步：查找共性

共性问题例如是不是因为安装了 Xposed，是不是只出现在 x86 的手机等

第三步：尝试复现

1.查找功能的原因。通过上面的共性归类，先看看是某个系统版本的问题，还是某个厂商特定 ROM 的问题。

2.尝试规避。查看可疑代码调用，是否使用了不恰当的 API，是否可以切换其他的实现方式规避。

3.Hook 解决。