APP应用崩溃

一：崩溃和崩溃率
Android崩溃
是指Android应用程序出现异常退出，对一个应用来说几乎是致命的问题。
崩溃率
衡量一个应用质量高低的基本指标。一个产品的崩溃率，跟我们如何捕获、处理这些异常有比较大的关系。
很多工具提供了收集崩溃，计算崩溃率的能力，如阿里的友盟、腾讯的Bugly、网易云捕、Google的Firebase。
二：崩溃类型
Android崩溃分为以下几种：
Java Crash
java代码中出现了未捕获的异常，导致程序异常退出。
Native Crash
一般是因为Native代码中访问了非法地址或者是地址对齐问题，再或者是发生程序主动Abort,这些都会产生对应的signal信息，导致程序异常退出。
ANR
一般是系统检测到应用某些动作超时，AMS停止应用程序。
OOM
Android检测到系统内存不足，触发LowMenKiller驱动杀死进程来释放内存
二：定位崩溃问题三板斧
2.1知己知彼
尽可能收集一下信息，包括但不限于：
a.崩溃发生的进程名、线程名、是否UI线程
b.崩溃堆栈、类型、场景
c.Logcat日志，包括应用日志、系统日志
d.内存信息、资源信息如线程数
e.应用版本、机型、系统版本、CPU等等
上述日志并不是所有的崩溃都需要，比如简单的java crash可能一个堆栈信息就足以，但对于其他类型崩溃，或者偶现的崩溃，就需要从多个维度去分析本质。
2.2开门见山
大部分简单的crash,实际通过检查异常堆栈信息，就可以判断崩溃的类型、对应代码位置：
a.Java Crash:这种堆栈中打印会比较详细，有异常类型、代码行数、比如NullPointException表示空指针，什么位置的哪个变量为空指针。
b.Native Crash:需要观察堆栈中signal、code、fault addr等内容，对于signal，比较常见的是有SIGSEGV和SIGABRT,前者一般是因为空指针、非法指针，后者主要是因为ANR和调用了abort()退出异常。
2.3死缠烂打
如果堆栈中无法明显看出问题，我们就需要借助多个其他手段
a.尝试复现：当我们知道大概原因，但是无法准确定位位置，或者干脆毫无头绪时，就希望通过模拟场景，重复用户操作来复现。只要能复现的问题，就一定是个能解决的问题，相信我们开发者都有这个自信。
b.查找共性：如果我们手上有多例不同用户的相同异常，我们就可以通过分析这些问题的共同点，比如设备、系统或者都做了某个操作等等。
上面这些手段，纸上谈兵看似简单，但是实际问题操作可能艰难重重，需要我们耐住寂寞，反复的大胆推测、小心求证，总会发现一些关键的蛛丝马迹。
三：常见Android崩溃
a.Dialog生命周期异常
异常信息：android.view.Windowmanger$BadTokenExcetion:Unable to add window–token android.os.BinderProxy@61843434de for display = 0 is not valid;is your activity running?
异常原因：Dialog触发show或者dismiss时，WindowManager发现其所在的Activity已经不存在
修改方式：dialog.show()时，判断dialog是否为空且activity是否在运行中；且控制Dialog的生命周期，在Activiy销毁时，将dialog对象一起销毁。
b.StackOverFlowError
异常信息：java.lang.StackOverflowError：stack size 8MB
异常原因：JVM中有个栈，预设了一个深度，当超出这个深度时，就会抛出StackOverFlowError。
Android中一般有这几种可能：代码中出现了递归调用；界面的布局文件嵌套层次太深；应用中有多个线程，只是finish()页面无法彻底关闭这些线程，再次进入应用，可能触发上述问题，建议使用线程池来管理
c.UnstaisfiedLinkError
异常信息：java.lang.UnsatisfiedLinkError:dalvik.system.PathClassLoader[DexPathList[zip file”/data/app/com.king.reading/base.apk”],nativeLibraryDirectories=[/lib/arm64,system/lib64]]couldn’t find”libnative-lib.so”
异常原因：代码中调用了native方法，但是该方法所在的so文件不存在，需要检查包中是否包含对应的so。
四：总结
崩溃攻防是一个长期的过程，我们尽可能的提前预防崩溃的发生，将它消灭在萌芽阶段。
作为技术人员，我们不应该盲目追求崩溃率这一数字，应该以用户体验为先，如果强行去掩盖一些异常，往往会适得其反，而且对产品的整体成长是个伤害。
所以我们不应该随意只是用try catch去隐藏问题，而是要从源头入手，了解崩溃的本质原因，保证后面的运行流程。
在解决问题过程中，需要我们做到由点到面，不能只针对某个崩溃去解决，而是要考虑这一类的崩溃怎么解决和预防。