App性能优化之稳定性优化；十分钟带你了解Crash治理

最新推荐文章于 2024-07-03 16:40:03 发布

Web学习笔记

最新推荐文章于 2024-07-03 16:40:03 发布

阅读量887

点赞数 12

分类专栏： 2024年程序员学习文章标签：性能优化

本文链接：https://blog.csdn.net/qq194582923/article/details/137199546

版权

2024年程序员学习专栏收录该内容

243 篇文章 1 订阅

订阅专栏

1、其实近年来，随着Android版本不断迭代，Google提供的Android系统已经越来越流畅，但是在国内大部分用户用的Android手机系是各大厂商定制过的版本，往往不是最新的原生系统内核，可能绝大多数还停留在较老的Android版本，更新存在延迟性。

2、由于Android系统源码是开放的，每个人只要遵从相应的协议，就可以对源码进行修改，那么国内各个厂商就把基于Android源码改造成自己对外发布的系统，比如我们熟悉的小米MIUI系统、华为EMUI系统、oppo的ColorOS系统等。由于每个厂商都修改过Android原生系统源码，这里面就会引发一个问题，那就是著名的Android碎片化问题，本质就是不同Android系统的应用兼容性不同，达不到一致性。

3、由于存在着各种Android碎片化和兼容性问题，导致Android开发者在开发应用时需要对不同系统进行适配，同时每个Android开发者的开发水平参差不齐，写出来的应用性能也都存在不同类型的问题，导致用户在使用过程中用户体验感受不同，那么有些问题用户就会转化为Android系统问题，进而影响对Android手机的评价。

二、App稳定性

Android 应用的稳定性定义很宽泛，影响稳定性的原因很多，比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等，都会对应用的稳定性造成影响。其中最常见的两个场景是：Crash 和 ANR，这两个错误将会使得程序无法使用，比较常用的解决方式如下：

提高代码质量。比如开发期间的代码审核，看些代码设计逻辑，业务合理性等。

代码静态扫描工具。常见工具有Android Lint、Findbugs、Checkstyle、PMD等等。

Crash监控和上传。把一些崩溃的信息，异常信息及时地记录下来，以便后续分析解决。在Crash后，尽量先保存日志到本地，然后等下一次网络正常时再上传日志信息。

本文重点说说Crash相关的东西，包括Crash对App的影响、造成Crash的因素和优化/降低Crash率的方法论。

三、什么是Crash

Crash崩溃也叫闪退，指用户在操作手机App时，突然退出App的现象，伴随着可能会弹出停止运行的对话框或者自动重启App。

四、Crash的原理

JavaWeb程序在运行的过程中，只要还有其他线程运行，JVM虚拟机就不会关闭，进程就不会结束。但是在Android App的运行过程中，不论是主线程还是子线程，或是三方库的子线程，只要发生异常，就会引起应用崩溃。原因是JavaWeb程序中没有设置默认的线程异常处理器，而Android系统为每一个Android App进程都设置了默认的线程异常处理器。

五、Crash的影响

Crash率是衡量一个App口碑好坏的重要指标之一。如果忽略了它的存在，它就会得寸进尺，愈演愈烈，最后造成大量用户的流失，进而会带来无法估量的损失。

六、Crash治理原则

对于Crash的治理，我们尽量遵守以下三点原则：

1、由点到面。一个Crash发生了，我们不能只针对这个Crash的去解决，而要去考虑这一类Crash怎么去解决和预防。只有这样才能使得这一类Crash真正被解决。

2、异常不能随便吃掉。随意的使用try-catch，只会增加业务的分支和隐蔽真正的问题，要了解Crash的本质原因，根据本质原因去解决。catch的分支，更要根据业务场景去兜底，保证后续的流程正常。

3、预防胜于治理。当Crash发生的时候，损失已经造成了，我们再怎么治理也只是减少损失。尽可能的提前预防Crash的发生，可以将Crash消灭在萌芽阶段。

七、Crash治理分类

##(一) 常规的Crash治理

常规Crash发生的原因主要是由于开发人员编写代码不小心导致的。解决这类Crash需要由点到面，根据Crash引发的原因和业务本身，统一集中解决。常见的Crash类型包括：空节点、角标越界、类型转换异常、实体对象没有序列化、数字转换异常、Activity或Service找不到等。这类Crash是App中最为常见的Crash，也是最容易反复出现的。在获取Crash堆栈信息后，解决这类Crash一般比较简单，更多考虑的应该是如何避免。下面介绍两个我们治理的量比较大的Crash。

NullPointerException空指针异常

1、NullPointerException是我们遇到最频繁的，造成这种Crash一般有两种情况：

对象本身没有进行初始化就进行操作。
对象已经初始化过，但是被回收或者手动置为null，然后对其进行操作。

2、两种情况对应的解决方法：

针对第一种情况导致的原因有很多，可能是开发人员的失误、API返回数据解析异常、进程被杀死后静态变量没初始化导致，我们可以做的有：

（1）对可能为空的对象做判空处理。
（2）养成使用@NonNull和@Nullable注解的习惯。
（3）尽量不使用静态变量，万不得已使用SharedPreferences来存储。
（4）考虑使用Kotlin语言。

针对第二种情况大部分是由于Activity/Fragment销毁或被移除后，在Message、Runnable、网络等回调中执行了一些代码导致的，我们可以做的有：

（1）Message、Runnable回调时，判断Activity/Fragment是否销毁或被移除；加try-catch保护；Activity/Fragment销毁时移除所有已发送的Runnable。
（2）封装LifecycleMessage/Runnable基础组件，并自定义Lint检查，提示使用封装好的基础组件。
（3）在BaseActivity、BaseFragment的onDestory()里把当前Activity所发的所有请求取消掉。

IndexOutOfBoundsException角标越界异常

这类Crash常见于对ListView的操作和多线程下对容器的操作。

1、针对ListView中造成的IndexOutOfBoundsException，经常是因为外部也持有了Adapter里数据的引用（如在Adapter的构造函数里直接赋值），这时如果外部引用对数据更改了，但没有及时调用notifyDataSetChanged()，则有可能造成Crash，对此我们封装了一个BaseAdapter，数据统一由Adapter自己维护通知，同时也极大的避免了The content of the adapter has changed but ListView did not receive a notification，这两类Crash目前得到了统一的解决。

2、很多容器是线程不安全的，所以如果在多线程下对其操作就容易引发IndexOutOfBoundsException。常用的如JDK里的ArrayList和Android里的SparseArray、ArrayMap，同时也要注意有一些类的内部实现也是用的线程不安全的容器，如Bundle里用的就是ArrayMap。