Android稳定性优化深入解析

作者：程序员江同学

前言

Android的稳定性是Android性能的一个重要指标，它也是App质量构建体系中最基本和最关键的一环。如果应用经常崩溃率，或者关键功能不可用，那显然会对我们的留存产生重大影响。
为了保障应用的稳定性，我们首先应该树立对稳定性的正确认识，本文主要包括以下内容：

1. 稳定性优化的正确认识
2. Crash处理的一般步骤
3. Crash长效治理
4. 业务高可用方案建设
5. 稳定性优化常见面试题

稳定性优化的正确认识

稳定性优化的关键指标

要做稳定性优化，首先一个问题就是，要做成什么效果？Crash率多少算优秀呢?在明确了目标之后，我们才能正确认识我们的工作到底有什么作用

要计算Crash率，我们首先应该明白稳定性优化的一些关键指标

UV Crash率与PV Crash率

PV（Page View）即访问量， UV（Unique Visitor）即独立访客，0 - 24小时内的同一终端只计算一次

• UV Crash率：针对用户使用量的统计，统计一段时间内所有用户发生崩溃的占比，用于评估Crash率的影响范围。
• PV Crash率：针对用户使用次数的统计，评估相关Crash影响的严重程度。

大家可以根据自己的需要选择合适的指标，需要注意的是，需要确保一直使用同一种衡量方式。

Crash率评价

那么，我们App的Crash率降低多少才能算是一个正常水平或优秀的水平呢？

• Java与Native的总崩溃率必须在千分之二以下。
• Crash率万分位为优秀

注意，以上说的都是UV崩溃率

稳定性优化的维度

很多人都会认为稳定性优化就是降低Crash率，但如果你的APP没有崩溃，但是关键功能却不可用，这又怎么算是稳定的呢?
因此应用的稳定性可以分为三个纬度，如下所示：

• 1、Crash纬度：最重要的指标就是应用的Crash率。
• 2、性能纬度：包括启动速度、内存、绘制等等优化方向，相对于Crash来说是次要的，但也是应用稳定性的一部分。
• 3、业务高可用纬度：它是非常关键的一步，我们需要采用多种手段来保证我们App的主流程以及核心路径的稳定性。

Crash处理的一般步骤

下面我们来看下应该如何处理Crash,即如果应用崩溃了，你应该如何去分析？
主要从崩溃现场和崩溃分析两个角度来分析

崩溃现场

崩溃现场是我们的“第一案发现场”，它保留着很多有价值的线索。在这里我们挖掘到的信息越多，下一步分析的方向就越清晰，而不是去靠盲目猜测。
接下来我们具体来看看在崩溃现场应该采集哪些信息。

崩溃信息

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

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

系统信息

除了崩溃的信息之外，系统的信息有时候会带有一些关键的线索，对我们解决问题有非常大的帮助。

• Logcat输出。这里包括应用、系统的运行日志。有时从堆栈中看不出什么信息，反而可以从Logcat中获得意外收获
• 机型、系统、厂商、CPU、ABI、Linux 版本等。我们会采集多达几十个维度，这对后面讲到寻找共性问题会很有帮助。
• 设备状态：是否 root、是否是模拟器。一些问题是由 Xposed 或多开软件造成，对这部分问题我们要区别对待。

内存信息

OOM、ANR、虚拟内存耗尽等，很多崩溃都跟内存有直接关系。如果我们把用户的手机内存分为“2GB 以下”和“2GB 以上”两个桶，会发现“2GB 以下”用户的崩溃率是“2GB 以上”用户的几倍。

• 系统剩余