我们做客户端包括并不限于Android/iOS/Windows/嵌入式程序等，核心指标之首均Crash率，我们通过Crash率来衡量咱们工程的可用性高低。目前业界Crash率的定义的定义有两种：

- Crash次数/启动次数，这样能测算出每次启动后到底有多少概率是正常离开的，多少概率是闪退的，非常理论化的一个数字。
- Crash次数/用户数，比如每日Crash次数除以日活即今日Crash率，这样可以准确评估出用户感知到的可用性闪退率到底是多少。

但是如果我们要非常理论的衡量不同/所有的客户端之间的可用性，并且可进行比较，以上两种度量方式足够么？还需要补充什么参数么？

我们遇到的问题

我们一个业务有多个客户端，如果按特点来描述，有三种：

a. 第一种就是我们常见的偏C端的电商客户端，用户特点是买完即走，没啥逛的需求，平均客户端启动时间不到十分钟，每天平均用户使用一次即日活数和订单数接近。因此它的Crash率采用上面两种方式看起来都还行也都能统计准确。

b. 另一个客户端是内部人员工作用的，类似于钉钉的客户端，它的特点是用户使用时间超长，并且由于一直在使用/一直在不断被打开，好一点的手机这个应用就常驻了，而差一点的手机会变成app在不断被重启。当然，用户使用时间长，也意味着假如每分钟遇到crash的概率是相等的，那么使用时长更长的app用户遇到crash的数量就越多。因此这个app的数字用/启动次数去计算，Crash率就很离谱了，而通过日活去看crash率，就简直不能看。

c. 还有一个windows上的客户端，它的作用是在本地建立一个常驻服务去承接一些打印/硬件相关的请求转驱动。当然这个客户端有附带watchdog做crash后拉取，但是实际上它的Crash率确实无论怎么衡量，都很低。

当我们把这个三个app放在一起比较的时候，就炸了。内部人员app表示有自己的苦衷，windows客户端则无法解释为啥自己crash率这么低。如果大家都说自己有自己的特点，crash无法横向比较，衡量的可用性就没法拉出绝对性了。因此显然，目前的Crash率建模是不够用的。

为何可用性差

要找到Crash率异常率怎么度量更合适，即可用性怎么度量更合适，需要找到引起可用性降低，发生异常的根因。

- 总使用时长：直观的第一层判断是，使用时长肯定和异常率正相关。因为传统Crash率建模的核心就是假设程序单位时间可用性是一致的。也就是说，如果我们简单解决上面这个问题的话，Crash率定义为单位使用时长Crash率即可，即Crash次数/使用时长分钟数or秒速。

当然，实际上并没有这么简单。如果去review除了代码真的写坏了，其余的长尾异常，明显那些奇怪的Crash可以分为：a. 内存相关，内存不够了野指针。b. io/跨进程通信相关，和别人交互发生异常了。 c. 高阶组件相关，比如webview，相机相关的crash。d. 极端异步操作相关，快速或高强度ui操作导致的偶发异步问题。

- 内存积累：因此使用时长对应着内存积累，会逐渐导致Crash率上升。主要体现在内外两层，在内部，内存占用变高虽然不完全代表内存泄漏，但是对应的各种单例，监听器，轮训变多，也就是说常驻执行的代码覆盖率变高，对应着crash率变高。在外部，系统可用内存降低可能导致整体内存接近阈值，触发各种内存分配异常野指针，oom类型的可用性问题。
- 设备性能：有一个特征是在很多移动设备上，如果设备处于高内存压力的状态，客户端非常容易出现异常。根因是各种系统跨进程通信部分直接失败or超时，包括程序加载不完全这样的错误。不过这样的异常有可能不会进行上报。
- 操作密度：如果用户进行高操作密度的行为，对应着一个同时执行的代码量大，这是crash率上升的主因。同时也有异步逻辑风险高的因素。

这里还可以解释为什么那个windows客户端crash率低：那个客户端的特点是常驻但是实际交互不多，并且作为一个中转server本身代码量也不大，对应着：

- 每单位时钟热代码量：作为常驻客户端，如果单位时钟的热代码越少，当然crash率也就越低。这是对上面三条的二次解析。
- 应用总代码量：作为上面这一条的补充，应用的总代码量决定了热代码的上限和绝对值。

可用性变量抽象与建模

结合以上讨论的信息，我们显然可以知道，最小Crash率抽象单位为：

- 单位时钟/单位代码量/异常率

其中“单位代码量/异常率”看起来其实就是类似于千行bug率一样，只是作为统计线上可用性的话，加上了线上的时间限定即“单位时钟”与所谓热代码。但是很显然，如上这个信息，即单位时钟里到底有多少热代码是正在运行的这一点，是不可统计的。因此只能按特点进行转化。

根据上面的讨论，最简单的转化是，将crash率转化为：

- 程序基准Crash率：程序单位时钟最低的Crash，以衡量程序的基础可用性。
- 程序单位时间增长Crash率：对应着程序持续运行的可用性表现。

对应着程序运行抽线为：每次启动Launch的Crash率为初始值，然后在前台阶段，随着固定数率上升。到重启后恢复。如下图：

- 这样抽象的好处主要是简单，如果从大数据上看，只需要采集用户的每日平均启动次数/单次启动时长，就可以对这个数字进行计算了，并且这个模型可以涵盖绝大部分问题。只有基准热代码量问题无法解决（即这张图运行情况完全一致的两个应用，代码逻辑简单的那个应用Crash率低）。
- 同时，这个数字计算的结果可以对应用优化方向带来参考意义。

但是如何解决代码复杂度即热代码带来的问题呢？根据上文讨论，只能从性能结果上表现，即将当前是否有大量的hot代码的问题转换为当前程序的运行状态是否hot的问题。因此我们可以把程序运行时定义为三个状态：

- Wait态：程序无交互，looper几乎空转。实际可以用程序cpu占用测量，这个状态cpu占用应该<=0.5%才对。
- Hot态：程序处于高密度逻辑运行状态，假设是cpu占用应该>=15%。
- Normal态：即正常使用的状态。

结合第一个抽象即程序的异常率会以某个恒定速率上升，那么如果假设hot态的异常率会上升一个台阶的话，单个启动流程的曲线可以理解为：

整个时段即WHN三个状态。HN均以另一个恒定速率异常概率上升，启动H会整体高一段。而W状态假设和处于后台一致，异常率保持不变。

- 因此这里需要采集更细致的时间，即单位时间内平均W时长，H时长，N时长，通过性能采集工具进行。
- 同时也重新定义出新的应用基准Crash率和增长Crash率，与另一个热状态Crash率diff。这些数字应根据上一个模型有对应关系，假设热状态Crash率diff始终=基准Crash率 x 20%的话，这个等式就有唯一解了，可以直接换算。

因此结合以上讨论，会得到换算公式：


总的来说，对于单个客户端回话时间来说，他们的积分即总的Crash率应该是恒定的，只是我们对这个数据依据不同模型做了更细致的拆分与拟合。

设计转化与落地

因此，我们的Crash率建模重新拆分为三层：

- 基础Crash率法：单位时间Crash率。
- 运行时Crash率法：基准Crash率+单位时间增长Crash率。
- 运行时Crash率法（状态优化版）：基准Crash率2+单位时间增长Crash率2。

着三层都有查看的意义并且可以对咱们各个App进行可用性比较与衡量了。在代码上的todo，包括：

- 同一定义：目前所有采集单位均以天为单位计算。
- 应用用户行为采集：主要包括用户前后台切换，用户主动离开应用（Android返回到无Activity，PC关闭到无窗口）。
- 应用运行状态采集：建议包括并不限于CPU占用/内存占用，并且同时根据实时状态按天上报应用WHN状态时长结论与占比。
- 正常的Crash采集。

这样，我们就可以离线的计算出应用重新建模的可用性指标，并进行横向对比了。