说到 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。
小结
性能优化不是更新一两个版本就可以解决的，是持续性的需求，持续集成迭代反馈。在实际的项目中，在项目刚开始的时候，由于人力和项目完成时间限制，性能优化的优先级比较低，等进入项目投入使用阶段，就需要把优先级提高，但在项目初期，在设计架构方案时，性能优化的点也需要提早考虑进去，这就体现出一个程序员的技术功底了。
什么时候开始有性能优化的需求，往往都是从发现问题开始，然后分析问题原因及背景，进而寻找最优解决方案，最终解决问题，这也是日常工作中常会用到的处理方式。
喜欢 就关注吧，欢迎投稿！
如有任何疑问可在文章底部留言。为了防止恶意评论，本博客现已开启留言审核功能。但是博主会在后台第一时间看到您的留言，并会在第一时间对您的留言进行回复！欢迎交流！
本文链接: https://leetcode.jp/android-app-性能优化的一些思考-2/