除了常见的崩溃，还有一些会导致应用异常退出的情况，例如：
主动自杀。Process.killProcess()、exit() 等
崩溃。出现了 Java 或 Native 崩溃
系统重启。系统出现异常、断电、用户主动重启等，我们可以通过比较应用开机运行时间是否比之前记录的值更小
被系统杀死。被 low memory killer 杀掉、从系统的任务管理器中划掉等
ANR
我们可以在应用启动的时候设定一个标志，在主动自杀或崩溃后更新标志，这样下次启动时通过检测这个标志就能确认运行期间是否发生过异常退出。对应上面的五种退出场景，我们排除掉主动自杀和崩溃（崩溃会单独的统计）这两种场景，希望可以监控到剩下三种的异常退出，理论上这个异常捕获机制是可以达到 100% 覆盖的。通过这个异常退出的检测，可以反映如 ANR、low memory killer、系统强杀、死机、断电等其他无法正常捕获到的问题。当然异常率会存在一些误报，比如用户从系统的任务管理器中划掉应用。对于线上的大数据来说，还是可以帮助我们发现代码中的一些隐藏问题。根据应用的前后台状态，我们可以把异常退出分为前台异常退出和后台异常退出。“被系统杀死” 是后台异常退出的主要原因，当然我们会更关注前台的异常退出的情况，这会跟 ANR、OOM 等异常情况有更大的关联。
二、崩溃处理
我们每天工作也会遇到各种各样的疑难问题，“崩溃”就是其中比较常见的一种问题。解决问题跟破案一样需要经验，我们分析的问题越多越熟练，定位问题就会越快越准。当然这里也有很多套路，比如对于 “案发现场” 我们应该留意哪些信息？怎样找到更多的 “证人” 和 “线索” ？“侦查案件” 的一般流程是什么？对不同类型的 “案件” 分别应该使用什么样的调查方式？要相信 “真相永远只有一个”，崩溃也并不可怕。
2.1 崩溃现场
崩溃现场是我们的“第一案发现场”，它保留着很多有价值的线索。现在可以挖掘到的信息越多，下一步分析的方向就越清晰，而不是去靠盲目猜测。崩溃信息从崩溃的基本信息，我们可以对崩溃有初步的判断。进程名、线程名。崩溃的进程是前台进程还是后台进程，崩溃是不是发生在 UI 线程。崩溃堆栈和类型。崩溃是属于 Java 崩溃、Native 崩溃，还是 ANR，对于不同类型的崩溃关注的点也不太一样。特别需要看崩溃堆栈的栈顶，看具体崩溃在系统的代码，还是 APP 代码里面。关键字：FATAL
FATAL EXCEPTION: main
Process: hip.csmart, PID: 27456
java.lang.NullPointerException: Attempt to invoke virtual method ‘void android.widget.TextView.setText(int)’ on a null object reference
hip.alicsmart.activity.SplashActivitMethodAndArgsCaller.run(ZygoteInit.java:784)atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:674)
系统信息系统的信息有时候会带有一些关键的线索，对我们解决问题有非常大的帮助。Logcat。这里包括应用、系统的运行日志。由于系统权限问题，获取到的 Logcat 可能只包含与当前 APP 相关的。其中系统的 event logcat 会记录 APP 运行的一些基本情况，记录在文件 /system/etc/event-log-tags 中。
//system logcat:
10-25 17:13:47.788 21430 21430 D dalvikvm: Trying to load lib …
//event logcat:
10-25 17:13:47.788 21430
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》浏览器打开：.hn/FTe 免费领取
21430 I am_on_resume_called: 生命周期
10-25 17:13:47.788 21430 21430 I am_low_memory: 系统内存不足
10-25 17:13:47.788 21430 21430 I am_destroy_activity: 销毁 Activty
10-25 17:13:47.888 21430 21430 I am_anr: ANR 以及原因
10-25 17:13:47.888 21430 21430 I am_kill: APP 被杀以及原因
机型、系统、厂商、CPU、ABI、Linux 版本等。通过采集多达几十个维度，这对寻找共性问题会很有帮助。内存信息OOM、ANR、虚拟内存耗尽等，很多崩溃都跟内存有直接关系。如果把用户的手机内存分为“2GB 以下”和“2GB 以上”两个区，就会发现“2GB 以下”用户的崩溃率是“2GB 以上”用户的几倍。系统剩余内存。关于系统内存状态，可以直接读取文件 /proc/meminfo。当系统可用内存很小（低于 MemTotal 的 10%）时，OOM、大量 GC、系统频繁自杀拉起等问题都非常容易出现。应用使用内存。包括 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 等问题都是虚拟内存不足导致的。
Name: com.xmamiga.name // 进程名
FDSize: 800 // 当前进程申请的文件句柄个数
VmPeak: 3004628 kB // 当前进程的虚拟内存峰值大小
VmSize: 2997032 kB // 当前进程的虚拟内存大小
Threads: 600 // 当前进程包含的线程个数
一般来说，对于 32 位进程，如果是 32 位的 CPU，虚拟内存达到 3GB 就可能会引起内存申请失败的问题。如果是 64 位的 CPU，虚拟内存一般在 3～4GB 之间。当然如果我们支持 64 位进程，虚拟内存就不会成为问题。Google Play 要求 年 8 月一定要支持 64 位，在国内虽然支持 64 位的设备已经在 90% 以上了，但是商店都不支持区分 CPU 架构类型发布，普及起来需要更长的时间。资源信息有的时候会发现应用堆内存和设备内存都非常充足，还是会出现内存分配失败的情况，这跟资源泄漏可能有比较大的关系。文件句柄 fd。文件句柄的限制可以通过 /proc/self/limits 获得，一般单个进程允许打开的最大文件句柄个数为 1024。但是如果文件句柄超过 800 个就比较危险，需要将所有的 fd 以及对应的文件名输出到日志中，进一步排查是否出现了有文件或者线程的泄漏。
opened files count 812:
0 -> /dev/null
1 -> /dev/log/main4
2 -> /dev/binder
3 -> /data/data/com.xmamiga.sample/files/test.config
线程数。当前线程数大小可以通过上面的 status 文件得到，一个线程可能就占 2MB 的虚拟内存，过多的线程会对虚拟内存和文件句柄带来压力。根据我的经验来说，如果线程数超过 400 个就比较危险。需要将所有的线程 id 以及对应的线程名输出到日志中，进一步排查是否出现了线程相关的问题。
threads count 412:
1820 com.xmamiga.crashsdk
1844 ReferenceQueueD
1869 FinalizerDaemon
…
JNI。使用 JNI 时，如果不注意很容易出现引用失效、引用爆表等一些崩溃。应用信息除了系统，其实我们的应用更懂自己，可以留下很多相关的信息。崩溃场景。崩溃发生在哪个 Activity 或 Fragment，发生在哪个业务中; 关键操作路径，不同于开发过程详细的打点日志，我们可以记录关键的用户操作路径，这对我们复现崩溃会有比较大的帮助。其他自定义信息。不同的应用关心的重点可能不太一样。
2.2 崩溃分析
有了这么多现场信息之后，就可以开始真正的“破案”之旅了。绝大部分的 “案件” 只要肯花功夫，最后都能真相大白。不要畏惧问题，经过耐心和细心地分析，总能敏锐地发现一些异常或关键点，并且还要敢于怀疑和验证。第一步：确定重点确认和分析重点，关键在于终过日志中找到重要的信息，对问题有一个大致判断。一般来说，我建议在确定重点这一步可以关注以下几点。
确认严重程度。解决崩溃也要看性价比，我们优先解决 Top 崩溃或者对业务有重大影响，例如主要功能的崩溃。不要花几天去解决了一个边角的崩溃，有可能下个版本就把功能删除了。
崩溃基本信息。确定崩溃的类型以及异常描述，对崩溃有大致的判断。
一般来说，大部分的简单崩溃经过这一步已经可以得到结论。
