作者：友盟 + 挪动开发专家 张文
「解体」与「卡顿」、「异样 退出」等一样，是影响 App 稳定性常见的三种状况。相干数据显示，当 iOS 的解体率超过 0.8%，Android 的解体率超过 0.4% 的时候，沉闷用户有显著降落态势。它不仅会造成要害业务中断、用户留存率降落、品牌口碑变差等负面影响，而且会间接带来卸载和散失。也 同时给开发者带来不可小觑的资本损失。
那么，解体率低的 App 品质就高么？是否能够通过解体率直接判断 App 的稳定性？
首先，掂量一个 App 品质好坏时咱们须要定义一个对立的口径，即哪些指标能够作为稳定性的评估口径？以友盟 + 的 U-APM 定义的稳定率这个概念为例，评估一个 App 的稳定性和品质，个别从以下三点综合思考：
产生了解体，如 java 解体和 Native 解体，即用解体率这个指标来评估计算；
产生了 ANR，即用 ANR 率这个指标来评估计算；
异样退出，如：low memory killer、工作列表中划掉、零碎异样、断电、用户触发关机 / 重启等，即用异样率这个指标来评估计算。
解体，也就是程序出现异常，导致程序退出。包含：
Java 解体，也就是在 Java 代码中呈现了未捕捉异样，导致程序异样退出。如：空指针异样、数组越界异样等。
Native 异样，也就是在 Native 代码中，呈现谬误产生相应的 signal 信号，导致程序异样退出。如：拜访非法地址、地址对其问题等。
Java 解体的捕捉绝对会简略一些，Native 解体的捕捉可能要求咱们对系统底层常识要有肯定的把握。咱们晓得 Android 是基于 Linux 零碎的，零碎中的解体大多是因为编码谬误或硬件谬误导致的。当零碎遇到不可复原的谬误时会通过异常中断的形式触发异样解决流程，这些中断的解决被对立为了信号量。当应用程序接管到某个信号量时会依照内核默认的动作解决，如 Term、lgn、Core、Stop、Cont。同时咱们也能够通过 sigaction 注册接管信号来指定解决动作，比方捕捉解体信息等。当然捕捉过程中也会有一些艰难点，尤其在极其环境中，比方栈溢出时，因为栈空间曾经被用完，造成咱们的信号处理函数没法被调用，以至于无奈捕捉到解体信息，这时咱们须要思考应用 signalstack，使咱们的信号处理函数能够在堆外面调配到一块内存空间作为“可替换信号栈”来解决解体信息。
当然，除了稳固、平安的捕捉能力外，还须要丰盛解体现场的上下文信息，比方 Logcat 信息、调用栈信息、设施信息、环境信息等等，为咱们后续定位和解决问题提供全面的参考。
对于产生解体的状况，咱们应用解体率作为数据指标。包含：
UV 解体率，也就是产生解体谬误的去重用户 / 去重沉闷总用户；
PV 解体率，也就是产生解体谬误的次数 / 启动次数；
启动解体率，也就是利用启动过程中产生的解体，很容易被疏忽但又十分重要的解体指标，因为启动是 APP 生命周期中十分重要的一个阶段，很多广告、闪屏、流动等内容都在这个过程中透出，同时启动时又须要加载各种初始化，并且如果启动呈现谬误，往往热修复、降级融灾策略都无法弥补。
ANR，也就是 Application Not Responding，当应用程序一段时间无奈及时响应，则会弹出 ANR 对话框，让用户抉择持续期待，还是强制敞开。从用户体验的角度看，有时候 ANR 可能要比解体会带来更蹩脚的体验，所以开发者器重解体的同时也要非常重视 ANR。
ANR 捕捉的准确性始终是一直降级打怪、不断完善的过程。晚期咱们通过 FileObserver 监听 /data/anr/traces.txt 文件的变动进行捕捉和上报，但很遗憾随着版本升级，零碎和厂商开始收紧系统文件但权限，此计划的笼罩设施状况越来越低，造成 ANR 捕捉的准确性也始终升高。
随后咱们改良为监控音讯队列的运行工夫的形式捕捉 ANR，也就是向主线程 Looper 中放入一个空音讯，监听该空音讯在 5 秒后是否被执行，但该计划无奈实在的捕捉 ANR 状况（存在漏报和误报状况），并且也无奈失去残缺的 ANR 内容。后续咱们参考 Android ANR 的实现原理，实现了一套实时、精确的 ANR 捕捉计划，并且能够兼容所有零碎版本。咱们晓得零碎的 system_server 过程在检测到 APP 呈现 ANR 后，会向呈现 ANR 的过程发送 SIGQUIT (signal 3) 信号。默认状况，零碎的 libart.so 会收到该信号，并调用 Java 虚拟机的 dump 办法生成 traces。
咱们通过拦挡 SIGQUT，在呈现 ANR 时优先接管到信号，并生成 traces 和 ANR 日志，在解决完信号后，将信号持续传递给零碎让系统生成 traces 文件，生成 traces 文件时，在保障内容与零碎原生的一致性的同时还对生成 traces 文件的速度进行了显著的晋升，无效地防止了可能因生成 traces 工夫过长，而被 system_server 应用 SIGKILL (signal 9) 再次强杀，同时咱们对捕捉到的内容进行了丰盛，包含：触发 ANR 的起因、手机中 TOP 过程 CPU 使用率、ANR 过程中 TOP 线程 CPU 使用率、CPU 各外围解决工夫散布状况、磁盘 IO 操作期待时长等重要信息，对剖析、定位和解决 ANR 问题，提供了更加强有力的撑持！
同样对于产生 ANR 的状况，咱们也分为 UV ANR 率和 PV ANR 率，算法可参考如上解体率的计算。
当然，除了解体和 ANR，咱们往往疏忽了异样退出这种场景，但往往通过异样退出咱们能够发现如 low memory killer、零碎重启等无奈失常捕捉到的问题。比方兼容性问题导致的闪退、设施重启、三方库被动调用 exit 函数，导致利用闪退次数减少等难以发现的问题，所以通过异样退出率咱们能够比拟全面的理解和掂量利用的稳定性。
综上，对于文章开始的那个问题，我想大家都应该有答案了吧。当然，咱们不应该为了覆盖代码品质问题，通过手动 try catch 去躲避某些问题，这样有可能会打断用户的失常应用，并造成感知性的阻断反馈，应该从用户应用 APP 时的实在感知登程，当呈现问题时及时捕捉和解决问题。
App 的稳定性时一个长期一直迭代的过程，在这个过程中 U -APM 是一个很好的晋升效率降低成本的工具，他提供了收集、解析、聚合、剖析的能力，下一期咱们会从如何通过 U -APM 解决和解决解体、ANR 等问题进行解说，纵情期待。