Android APP 性能优化的一些思考

转自：https://www.cnblogs.com/cr330326/p/8011523.html

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

卡顿优化

内存优化

耗电优化

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

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

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

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

（1）计算优化。算法、for循环优化、Switch..case替代if..else、避开浮点运算。

浮点运算：计算机里整数和小数形式就是按普通格式进行存储，例如1024、3.1415926等等，这个没什么特点，但是这样的数精度不高，表达也不够全面，为了能够有一种数的通用表示法，就发明了浮点数。浮点数的表示形式有点像科学计数法（.*****×10），它的表示形式是0.*****×10，在计算机中的形式为 .***** e ±**），其中前面的星号代表定点小数，也就是整数部分为0的纯小数，后面的指数部分是定点整数。利用这样的形式就能表示出任意一个整数和小数，例如1024就能表示成0.1024×10^4，也就是 .1024e+004，3.1415926就能表示成0.31415926×10^1，也就是 .31415926e+001，这就是浮点数。浮点数进行的运算就是浮点运算。浮点运算比常规运算更复杂，因而计算机进行浮点运算速度要比进行常规运算慢得多。

（2）避免 Wake Lock 使用不当。

Wake Lock是一种锁的机制，主要是相对系统的休眠而言的，,只需有人拿着这个锁，系统就无法进入休眠意思就是我的程序给CPU加了这个锁那系统就不会休眠了，这样做的目的是为了全力配合我们程序的运行。有的情况假如不这么做就会出现少量问题，比方微信等及时通讯的心跳包会在熄屏不久后中止网络访问等问题。所以微信里面是有大量使用到了Wake_Lock锁。系统为了节省电量，CPU在没有任务忙的时候就会自动进入休眠。有任务需要唤醒CPU高效执行的时候，就会给CPU加Wake_Lock锁。大家经常犯的错误，我们很容易去唤醒CPU来工作，但是很容易不记得释放Wake_Lock。

（3）使用 Job Scheduler 管理后端任务。

在Android 5.0 API 21 中，google提供了一个叫做JobScheduler API的组件，来解决当某个时间点或者者当满足某个特定的条件时执行一个任务的场景，例如当客户在夜间休息时或者设施接通电源适配器连接WiFi启动下载升级的任务。这样可以在减少资源消耗的同时提升应用的效率。

安装包大小优化

应用安装包大小对应用使用没有影响，但应用的安装包越大，用户下载的门槛越高，特别是在移动网络情况下，用户在下载应用时，对安装包大小的要求更高，因此，减小安装包大小可以让更多用户愿意下载和体验产品。

常用应用安装包的构成，如图所示：

从图中我们可以看到：

• assets文件夹。存放一些配置文件、资源文件，assets不会自动生成对应的 ID，而是通过 AssetManager 类的接口获取。
• res。res 是 resource 的缩写，这个目录存放资源文件，会自动生成对应的 ID 并映射到 .R 文件中，访问直接使用资源 ID。
• META-INF。保存应用的签名信息，签名信息可以验证 APK 文件的完整性。
• AndroidManifest.xml。这个文件用来描述 Android 应用的配置信息，一些组件的注册信息、可使用权限等。
• classes.dex。Dalvik 字节码程序，让 Dalvik 虚拟机可执行，一般情况下，Android 应用在打包时通过 Android SDK 中的 dx 工具将 Java 字节码转换为 Dalvik 字节码。
• resources.arsc。记录着资源文件和资源 ID 之间的映射关系，用来根据资源 ID 寻找资源。

减少安装包大小的常用方案

• 代码混淆。使用proGuard 代码混淆器工具，它包括压缩、优化、混淆等功能。
• 资源优化。比如使用 Android Lint 删除冗余资源，资源文件最少化等。
• 图片优化。比如利用 AAPT 工具对 PNG 格式的图片做压缩处理，降低图片色彩位数等。
• 避免重复功能的库，使用 WebP图片格式等。
• 插件化。比如功能模块放在服务器上，按需下载，可以减少安装包大小。

小结

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

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