[Android]APP性能优化的一些思考

四个方面

可以把用户体验的性能问题主要总结为4个类别：

1.     流畅
2.     稳定
3.     省电、省流量
4.     安装包小

性能问题的主要原因是什么，原因有相同的，也有不同的，但归根到底，不外乎内存使用、代码效率、合适的策略逻辑、代码质量、安装包体积这一类问题，整理归类如下：

从图中可以看到，打造一个高质量的应用应该以4个方向为目标：快、稳、省、小。

1. 快：使用时避免出现卡顿，响应速度快，减少用户等待的时间，满足用户期望。
2. 稳：减低 crash 率和 ANR 率，不要在用户使用过程中崩溃和无响应。
3. 省：节省流量和耗电，减少用户使用成本，避免使用时导致手机发烫。
4. 小：安装包小可以降低用户的安装成本。

要想达到这4个目标，具体实现是在右边框里的问题：卡顿、内存使用不合理、代码质量差、代码逻辑乱、安装包过大，这些问题也是在开发过程中碰到最多的问题，在实现业务需求同时，也需要考虑到这点，多花时间去思考，如何避免功能完成后再来做优化，不然的话等功能实现后带来的维护成本会增加。

卡顿优化

Android 应用启动慢，使用时经常卡顿，是非常影响用户体验的，应该尽量避免出现。卡顿的场景有很多，按场景可以分为4类：UI 绘制、应用启动、页面跳转、事件响应，如图：

    
这4种卡顿场景的根本原因可以分为两大类：

1. 界面绘制。主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。
2. 数据处理。导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。

引起卡顿的原因很多，但不管怎么样的原因和场景，最终都是通过设备屏幕上显示来达到用户，归根到底就是显示有问题，所以，要解决卡顿，就要先了解 Android 系统的显示原理。

卡顿根本原因

根据Android 系统显示原理可以看到，影响绘制的根本原因有以下两个方面：

1. 绘制任务太重，绘制一帧内容耗时太长。
2. 主线程太忙，根据系统传递过来的 VSYNC 信号来时还没准备好数据导致丢帧。

绘制耗时太长，有一些工具可以帮助我们定位问题。主线程太忙则需要注意了，主线程关键职责是处理用户交互，在屏幕上绘制像素，并进行加载显示相关的数据，所以特别需要避免任何主线程的事情，这样应用程序才能保持对用户操作的即时响应。总结起来，主线程主要做以下几个方面工作：

1. UI 生命周期控制
2. 系统事件处理
3. 消息处理
4. 界面布局
5. 界面绘制
6. 界面刷新

除此之外，应该尽量避免将其他处理放在主线程中，特别复杂的数据计算和网络请求等。

内存分析工具

做内存优化前，需要了解当前应用的内存使用现状，通过现状去分析哪些数据类型有问题，各种类型的分布情况如何，以及在发现问题后如何发现是哪些具体对象导致的，这就需要相关工具来帮助我们。

1，Memory Monitor
Memory Monitor 是一款使用非常简单的图形化工具，可以很好地监控系统或应用的内存使用情况，主要有以下功能：

• 显示可用和已用内存，并且以时间为维度实时反应内存分配和回收情况。
• 快速判断应用程序的运行缓慢是否由于过度的内存回收导致。
• 快速判断应用是否由于内存不足导致程序崩溃。

2，Heap Viewer
Heap Viewer 的主要功能是查看不同数据类型在内存中的使用情况，可以看到当前进程中的 Heap Size 的情况，分别有哪些类型的数据，以及各种类型数据占比情况。通过分析这些数据来找到大的内存对象，再进一步分析这些大对象，进而通过优化减少内存开销，也可以通过数据的变化发现内存泄漏。

3，Allocation Tracker

Memory Monitor 和 Heap Viewer 都可以很直观且实时地监控内存使用情况，还能发现内存问题，但发现内存问题后不能再进一步找到原因，或者发现一块异常内存，但不能区别是否正常，同时在发现问题后，也不能定位到具体的类和方法。这时就需要使用另一个内存分析工具 Allocation Tracker，进行更详细的分析， Allocation Tracker 可以分配跟踪记录应用程序的内存分配，并列出了它们的调用堆栈，可以查看所有对象内存分配的周期。

4，Memory Analyzer Tool(MAT)

MAT 是一个快速，功能丰富的 Java Heap 分析工具，通过分析 Java 进程的内存快照 HPROF 分析，从众多的对象中分析，快速计算出在内存中对象占用的大小，查看哪些对象不能被垃圾收集器回收，并可以通过视图直观地查看可能造成这种结果的对象。
常见内存泄漏场景

如果在内存泄漏发生后再去找原因并修复会增加开发的成本，最好在编写代码时就能够很好地考虑内存问题，写出更高质量的代码，这里列出一些常见的内存泄漏场景，在以后的开发过程中需要避免这类问题。

• 资源性对象未关闭。比如Cursor、File文件等，往往都用了一些缓冲，在不使用时，应该及时关闭它们。
• 注册对象未注销。比如事件注册后未注销，会导致观察者列表中维持着对象的引用。
• 类的静态变量持有大数据对象。
• 非静态内部类的静态实例。
• Handler临时性内存泄漏。如果Handler是非静态的，容易导致 Activity 或 Service 不会被回收。
• 容器中的对象没清理造成的内存泄漏。
• WebView。WebView 存在着内存泄漏的问题，在应用中只要使用一次 WebView，内存就不会被释放掉。

除此之外，内存泄漏可监控，常见的就是用LeakCanary 第三方库，这是一个检测内存泄漏的开源库，使用非常简单，可以在发生内存泄漏时告警，并且生成 leak tarce 分析泄漏位置，同时可以提供 Dump 文件进行分析。

优化内存空间

没有内存泄漏，并不意味着内存就不需要优化，在移动设备上，由于物理设备的存储空间有限，Android 系统对每个应用进程也都分配了有限的堆内存，因此使用最小内存对象或者资源可以减小内存开销，同时让GC 能更高效地回收不再需要使用的对象，让应用堆内存保持充足的可用内存，使应用更稳定高效地运行。常见做法如下：

• 对象引用。强引用、软引用、弱引用、虚引用四种引用类型，根据业务需求合理使用不同，选择不同的引用类型。
• 减少不必要的内存开销。注意自动装箱，增加内存复用，比如有效利用系统自带的资源、视图复用、对象池、Bitmap对象的复用。
• 使用最优的数据类型。比如针对数据类容器结构，可以使用ArrayMap数据结构，避免使用枚举类型，使用缓存Lrucache等等。
• 图片内存优化。可以设置位图规格，根据采样因子做压缩，用一些图片缓存方式对图片进行管理等等。