Android APP 性能优化的一些思考

说到 Android 系统手机，大部分人的印象是用了一段时间就变得有点卡顿，有些程序在运行期间莫名其妙的出现崩溃，打开系统文件夹一看，发现多了很多文件，然后用手机管家 APP 不断地进行清理优化 ，才感觉运行速度稍微提高了点，就算手机在各种性能跑分软件面前分数遥遥领先，还是感觉无论有多大的内存空间都远远不够用。相信每个使用 Android 系统的用户都有过以上类似经历，确实，Android 系统在流畅性方面不如 IOS 系统，为何呢，明明在看手机硬件配置上时，Android 设备都不会输于 IOS 设备，甚至都强于它，关键是在于软件上。造成这种现象的原因是多方面的，简单罗列几点如下：

• 其实近年来，随着 Android 版本不断迭代，Google 提供的Android 系统已经越来越流畅，目前最新发布的版本是 Android 8.0 Oreo 。但是在国内大部分用户用的 Android 手机系是各大厂商定制过的版本，往往不是最新的原生系统内核，可能绝大多数还停留在 Android 5.0 系统上，甚至 Android 6.0 以上所占比例还偏小，更新存在延迟性。
• 由于 Android 系统源码是开放的，每个人只要遵从相应的协议，就可以对源码进行修改，那么国内各个厂商就把基于 Android 源码改造成自己对外发布的系统，比如我们熟悉的小米手机 Miui 系统、华为手机 EMUI 系统、Oppo 手机 ColorOS 系统等。由于每个厂商都 修改过 Android 原生系统源码，这里面就会引发一个问题，那就是著名的Android 碎片化问题，本质就是不同 Android 系统的应用兼容性不同，达不到一致性。
• 由于存在着各种 Android 碎片化和兼容性问题，导致 Android 开发者在开发应用时需要对不同系统进行适配，同时每个 Android 开发者的开发水平参差不齐，写出来的应用性能也都存在不同类型的问题，导致用户在使用过程中用户体验感受不同，那么有些问题用户就会转化为 Android 系统问题，进而影响对Android 手机的评价。

性能优化

 

今天想说的重点是Android APP 性能优化，也就是在开发应用程序时应该注意的点有哪些，如何更好地提高用户体验。一个好的应用，除了要有吸引人的功能和交互之外，在性能上也应该有高的要求，即时应用非常具有特色，在产品前期可能吸引了部分用户，但是用户体验不好的话，也会给产品带来不好的口碑。那么一个好的应用应该如何定义呢？主要有以下三方面：

• 业务/功能
• 符合逻辑的交互
• 优秀的性能

众所周知，Android 系统作为以移动设备为主的操作系统，硬件配置是有一定的限制的，虽然配置现在越来越高级，但仍然无法与 PC 相比，在 CPU 和内存上使用不合理或者耗费资源多时，就会碰到内存不足导致的稳定性问题、CPU 消耗太多导致的卡顿问题等。

面对问题时，大家想到的都是联系用户，然后查看日志，但殊不知有关性能类问题的反馈，原因也非常难找，日志大多用处不大，为何呢？因为性能问题大部分是非必现的问题，问题定位很难复现，而又没有关键的日志，当然就无法找到原因了。这些问题非常影响用户体验和功能使用，所以了解一些性能优化的一些解决方案就显得很重要了，并在实际的项目中优化我们的应用，进而提高用户体验。

四个方面

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

• 流畅
• 稳定
• 省电、省流量
• 安装包小

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

 

打造一个高质量的应用应该以4个方向为目标：快、稳、省、小。

快：使用时避免出现卡顿，响应速度快，减少用户等待的时间，满足用户期望。

稳：减低 crash 率和 ANR 率，不要在用户使用过程中崩溃和无响应。

省：节省流量和耗电，减少用户使用成本，避免使用时导致手机发烫。

小：安装包小可以降低用户的安装成本。

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

 

卡顿优化

卡顿根本原因

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

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

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

• UI 生命周期控制
• 系统事件处理
• 消息处理
• 界面布局
• 界面绘制
• 界面刷新

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

 

1.布局优化

 

布局是否合理主要影响的是页面测量时间的多少，我们知道一个页面的显示测量和绘制过程都是通过递归来完成的，多叉树遍历的时间与树的高度h有关，其时间复杂度 O(h)，如果层级太深，每增加一层则会增加更多的页面显示时间，所以布局的合理性就显得很重要。

那布局优化有哪些方法呢，主要通过减少层级、减少测量和绘制时间、提高复用性三个方面入手。总结如下：

• 减少层级。合理使用 RelativeLayout 和 LinerLayout，合理使用Merge。
• 提高显示速度。使用 ViewStub，它是一个看不见的、不占布局位置、占用资源非常小的视图对象。
• 布局复用。可以通过 标签来提高复用。
• 尽可能少用wrap_content。wrap_content 会增加布局 measure 时计算成本，在已知宽高为固定值时，不用wrap_content 。
• 删除控件中无用的属性。

 

2，避免过度绘制

过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 UI 结构中，如果不可见的 UI 也在做绘制的操作，就会导致某些像素区域被绘制了多次，从而浪费了多余的 CPU 以及 GPU 资源。

如何避免过度绘制呢，如下：

• 布局上的优化。移除 XML 中非必须的背景，移除 Window 默认的背景、按需显示占位背景图片
• 自定义View优化。使用 canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。

 

3，启动优化

通过对启动速度的监控，发现影响启动速度的问题所在，优化启动逻辑，提高应用的启动速度。启动主要完成三件事：UI 布局、绘制和数据准备。因此启动速度优化就是需要优化这三个过程：

• UI 布局。应用一般都有闪屏页，优化闪屏页的 UI 布局，可以通过 Profile GPU Rendering 检测丢帧情况。
• 启动加载逻辑优化。可以采用分布加载、异步加载、延期加载策略来提高应用启动速度。
• 数据准备。数据初始化分析，加载数据可以考虑用线程初始化等策略。

 

4，合理的刷新机制

在应用开发过程中，因为数据的变化，需要刷新页面来展示新的数据，但频繁刷新会增加资源开销，并且可能导致卡顿发生，因此，需要一个合理的刷新机制来提高整体的 UI 流畅度。合理的刷新需要注意以下几点：

• 尽量减少刷新次数。
• 尽量避免后台有高的 CPU 线程运行。
• 缩小刷新区域。

 

5，其他

在实现动画效果时，需要根据不同场景选择合适的动画框架来实现。有些情况下，可以用硬件加速方式来提供流畅度。

 

内存优化

 

一、 Android的内存机制

    Android的程序由Java语言编写，所以Android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存，所有对象在java堆内分配空间；然而对象的释放是由垃圾回收器来完成的。C／C++中的内存机制是“谁污染，谁治理”，java的就比较人性化了，给我们请了一个专门的清洁工（GC）。

 

二、Android的内存溢出

    Android的内存溢出是如何发生的?

    Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。因此我们所能利用的内存空间是有限的。如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误。

为什么会出现内存不够用的情况呢？我想原因主要有两个：

• 由于我们程序的失误，长期保持某些资源（如Context）的引用，造成内存泄露，资源造成得不到释放。
• 保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制。

常见内存泄漏场景

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

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

 

优化内存空间

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

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

稳定性优化

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

• 提高代码质量。比如开发期间的代码审核，看些代码设计逻辑，业务合理性等。
• 代码静态扫描工具。常见工具有Android Lint、Findbugs、Checkstyle、PMD等等。
• Crash监控。把一些崩溃的信息，异常信息及时地记录下来，以便后续分析解决。
• Crash上传机制。在Crash后，尽量先保存日志到本地，然后等下一次网络正常时再上传日志信息。

 

耗电优化

在移动设备中，电池的重要性不言而喻，没有电什么都干不成。对于操作系统和设备开发商来说，耗电优化一致没有停止，去追求更长的待机时间，而对于一款应用来说，并不是可以忽略电量使用问题，特别是那些被归为“电池杀手”的应用，最终的结果是被卸载。因此，应用开发者在实现需求的同时，需要尽量减少电量的消耗。

在 Android5.0 以前，在应用中测试电量消耗比较麻烦，也不准确，5.0 之后专门引入了一个获取设备上电量消耗信息的 API:Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系统电量分析工具，和Systrace 一样，是一款图形化数据分析工具，直观地展示出手机的电量消耗过程，通过输入电量分析文件，显示消耗情况，最后提供一些可供参考电量优化的方法。

除此之外，还有一些常用方案可提供：

• 计算优化，避开浮点运算等。
• 避免 WaleLock 使用不当。
• 使用 Job Scheduler。

 

小结

性能优化不是更新一两个版本就可以解决的，是持续性的需求，持续集成迭代反馈。在实际的项目中，在项目刚开始的时候，由于人力和项目完成时间限制，性能优化的优先级比较低，等进入项目投入使用阶段，就需要把优先级提高，但在项目初期，在设计架构方案时，性能优化的点也需要提早考虑进去，这就体现出一个程序员的技术功底了。

什么时候开始有性能优化的需求，往往都是从发现问题开始，然后分析问题原因及背景，进而寻找最优解决方案，最终解决问题，这也是日常工作中常会用到的处理方式。