前述
最近在做app性能优化，这里做一个总结，供大家了解学习，也方便自己以后查阅.
用android的同学都知道，新买的手机用过一段时间后，手机变得越来越卡了；装了一些APP后，电量用得飞快，一天基本要一充；有些APP打开半天加载不出来；有些APP进入某些页面突然闪退；还有用了一些APP,流量用得飞快，几百M的流量用了几天就没有了等等；
这是什么原因呢？
- android系统源码是开放的，可以对源码的更改，像国内的几大手机厂商，都是对系统进入定制开发，这样就会引发一系列问题，比如说著名的系统碎片化问题;
- 各大厂商定制的系统，兼容性肯定不好，开发人员要对各个系统做各种适配，还有开发人员的水平参次不齐，开发出来的APP就会出现这样那样的问题等等；
那我们又得如何处理这样的问题呢？
那就是今天我们要说的APP性能优化，开发人员开发出来的app要性能好，用户体验好，性能好的APP总结一下，有如下几点：
- APP使用起来不卡顿,要流畅；
- 要省电，省流量；
- 要稳定，不闪退(减少闪退，ANR率)；
- APP包尽量要小；
要开发性能好的app,主要要达到以上四点；但是如何达到上面几点呢，那我们得找到达不到的原因，下面我们一一来分析，并给出解决方案：
卡顿优化
Android 应用启动慢，使用时经常卡顿，是非常影响用户体验的，应该尽量避免出现。总的来说造成卡顿的原因有如下几种：
- UI的绘制。主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。
- 数据处理上。导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在主线程处理，这个是初级工程师会犯的错误，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。引起卡顿的原因很多，但不管怎么样的原因和场景，最终都是通过设备屏幕上显示来达到用户，归根到底就是显示有问题，所以，要解决卡顿，就要先了解 Android 系统的渲染机制。
- UI的过度绘制,绘制的页面有几层View，底层View都是隐藏的，这种的还绘制的话就会造成过度绘制
andriod的渲染机制
要在屏幕上显示，其实要经过一系列的过程，Android 应用程序把经过测量、布局、绘制后的 surface 缓存数据，通过 SurfaceFlinger 把数据渲染到显示屏幕上， 通过 Android 的刷新机制来刷新数据。也就是说应用层负责绘制，系统层负责渲染，通过进程间通信把应用层需要绘制的数据传递到系统层服务，系统层服务通过刷新机制把数据更新到屏幕上。
这里我们先介绍一个名词：FPS。FPS 表示每秒传递的帧数。在理想情况下，60 FPS 就感觉不到卡，这意味着每个绘制时长应该在16 ms 以内。但是 Android 系统很有可能无法及时完成那些复杂的页面渲染操作。Android 系统每隔 16ms 发出 VSYNC 信号，触发对 UI 进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需的 60FPS。如果某个操作花费的时间是 24ms ，系统在得到 VSYNC 信号时就无法正常进行正常渲染，这样就发生了丢帧现象。那么用户在 32ms 内看到的会是同一帧画面，这种现象在执行动画或滑动列表比较常见，还有可能是你的 Layout 太过复杂，层叠太多的绘制单元，无法在 16ms 完成渲染，最终引起刷新不及时。
android的View的绘制流程大家应该都知道，都是要经过三大核心步骤：Measure、Layout、Draw。具体是如何实现的建议看一下View的源码，这里我就不多说了；如果绘制的层级深，页面复杂，在Measure、Layout这二个步骤要花费大量的时间；这样也会造卡顿现象；
andriod卡顿优化方案
- 不要在主线程进行网络访问/大文件的IO操作
- 绘制UI时，尽量减少绘制UI层次；减少不必要的view嵌套，可以用Hierarchy Viewer工具来检测，后面会详细讲；
- 当我们的布局是用的FrameLayout的时候，我们可以把它改成merge,可以避免自己的帧布局和系统的ContentFrameLayout帧布局重叠造成重复计算(measure和layout)
- 提高显示速度,使用ViewStub：当加载的时候才会占用。不加载的时候就是隐藏的，仅仅占用位置。
- 在view层级相同的情况下，尽量使用 LinerLayout而不是RelativeLayout；因为RelativeLayout在测量的时候会测量二次，而LinerLayout测量一次，可以看下它们的源码；
- 删除控件中无用的属性;
- 布局复用.比如listView 布局复用
- 尽量避免过度绘制（overdraw）,比如：背景经常容易造成过度绘制。由于我们布局设置了背景，同时用到的MaterialDesign的主题会默认给一个背景。这时应该把主题添加的背景去掉；还有移除 XML 中非必须的背景
- 自定义View优化。使用 canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。也是避免过度绘制．
- 启动优化,启动速度的监控，发现影响启动速度的问题所在，优化启动逻辑，提高应用的启动速度。比如闪屏页面，合理优化布局，加载逻辑优化，数据准备，这里后面我会单独写一篇文章讲如何优化程序的启动速度及Splash页面设计，这里还会讲到热启动和冷启动．
- 合理的刷新机制，尽量减少刷新次数，尽量避免后台有高的 CPU 线程运行，缩小刷新区域。
andriod卡顿优化所用到的工具
性能问题并不容易复现，也不好定位，但是真的碰到问题就需要借助相应的的调试工具,下面介绍比较常用的调试工具。
- 1.Profile GPU Rendering
在手机开发者模式下，有一个卡顿检测工具叫做：Profile GPU Rendering,看图：
![]()
image.png
上图中的绿线代表16ms,要确保一秒内打到60fps,你需要确保这些帧的每一条线都在绿色的16ms标记线之下.任何时候你看到一个竖线超过了绿色的标记现,你就会看到你的动画有卡顿现象产生.
下面的柱状图蓝色代表测量绘制的时间,当你看到蓝色的线很高的时候,有可能是因为你的一堆视图突然变得无效了(即需要重新绘制),或者你的几个自定义视图的onDraw函数过于复杂.
柱状图红色代表执行的时间,这部分是Android进行2D渲染 Display List的时间,为了绘制到屏幕上,Android需要使用OpenGl ES的API接口来绘制Display List.这些API有效地将数据发送到GPU,最终在屏幕上显示出来.当你看到红色的线非常高的时候,这些复杂的自定义View就是罪魁祸首:
橙色部分表示的是处理时间,或者说是CPU告诉GPU渲染一帧的地方,这是一个阻塞调用,因为CPU会一直等待GPU发出接到命令的回复,如果柱状图很高,那就意味着你给GPU太多的工作,太多的负责视图需要OpenGL命令去绘制和处理.
总之，保持动画流畅的关键就在于让这些垂直的柱状条尽可能地保持在绿线下面,任何时候超过绿线,你就有可能丢失一帧的内容.
- 2.Debug GPU overDraw过度绘制检测
在手机开发者模式下，有一个过度绘制检测工具叫做：Debug GPU overDraw,看图：
![]()
image.png
![]()
image.png
原色：没有过度绘制
蓝色：1 次过度绘制
绿色：2 次过度绘制
粉色：3 次过度绘制
红色：4 次及以上过度绘制
耗电优化
在移动设备中，电池的重要性不言而喻，没有电什么都干不成。对于操作系统和设备开发商来说，耗电优化一致没有停止，去追求更长的待机时间，而对于一款应用来说，并不是可以忽略电量使用问题，特别是那些被归为“电池杀手”的应用，最终的结果是被卸载。因此，应用开发者在实现需求的同时，需要尽量减少电量的消耗。
耗电的原因其实很多，这里我就讲一下几种优化方案，优化方案的反面就是他的原因了，几种优化方案如下：
- 合理的使用wack_lock锁，wake_lock锁主要是相对系统的休眠(这里就是为了省电，才做休)而言的，意思就是我的程序给CPU加了这个锁那系统就不会休眠了，这样做的目的是为了全力配合我们程序的运行。有的情况如果不这么做就会出现一些问题，比如微信等及时通讯的心跳包会在熄屏不久后停止网络访问等问题。所以微信里面是有大量使用到了wake_lock锁。这里有一篇关于wake_lock的使用，请查阅；
- 使用jobScheduler2，集中处理一些网络请求，有些不用很及时的处理可以放在充电的时候处理，比如，图片的处理，APP下载更新等等，这里有一篇关于jobScheduler的使用，请查阅；
- 计算优化，避开浮点运算等。
- 数据在网络上传输时，尽量压缩数据后再传输，建议用FlatBuffer序列化技术，这个比json效率高很多倍，不了解FlatBuffer，建议找资料学习一下，后面有时间的话，也会专门写关于FlatBuffer的文章．
andriod耗电分析所用到的工具
在 Android5.0 以前，在应用中测试电量消耗比较麻烦，也不准确，5.0 之后专门引入了一个获取设备上电量消耗信息的 API:Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系统电量分析工具，是一款图形化数据分析工具，直观地展示出手机的电量消耗过程，通过输入电量分析文件，显示消耗情况，最后提供一些可供参考电量优化的方法。
![]()
image.png
Battery Historian耗电分析工具的开源地址;具体如何使用这里不细讲，以后单独写文章介绍；
安装包大小优化
随着功能不断增加，APP的包肯定不会断的变大，但应用的安装包越大，用户下载的门槛越高，特别是在移动网络情况下，用户在下载应用时，对安装包大小的要求更高，因此，减小安装包大小可以让更多用户愿意下载和体验产品。所以，我们还是要想办法去如何去优化，尽量减小app的安排包．
APP包优化方案
- res资源优化
（1）只使用一套图片，使用高分辨率的图片。
（2）UI设计在ps安装TinyPNG插件，对图片进行无损压缩。
（3）svg图片：一些图片的描述，牺牲CPU的计算能力的，节省空间。使用的原则：简单的图标。
（4）图片使用WebP(https://developers.google.com/speed/webp/)的格式（Facebook、腾讯、淘宝在用。）缺点：加载相比于PNG要慢很多。 但是配置比较高。工具：http://isparta.github.io/
（5）使用tintcolor(android - Change drawable color programmatically)实现按钮反选效果。
（2）Lint工具检查无用文件将无用的资源列在“UnusedResources: Unused resources”，删除。
（3）移除无用的依赖库。
（2）一些模块的插件化动态添加。
（3）so文件的剪裁和压缩。
- assets资源优化
（1）音频文件最好使用有损压缩的格式，比如采用opus、mp3等格式，但是最好不要使用无损压缩的音乐格式
（2）对ttf字体文件压缩，可以采用FontCreator工具只提取出你需要的文字。比如在做日期显示时，其实只需要数字字体，但是使用原有的字体库可能需要10MB大小，如果只是把你需要的字体提取出来生成的字体文件只有10KB
- 代码混淆。
使用proGuard 代码混淆器工具，它包括压缩、优化、混淆等功能。
- 7z极限压缩
具体请参考微信的安接包压缩,实现实现原理，有时间再分析；
内存优化
在 Android 系统中有个垃圾内存回收机制，在虚拟机层自动分配和释放内存，因此不需要在代码中分配和释放某一块内存，从应用层面上不容易出现内存泄漏和内存溢出等问题，但是需要内存管理。Android 系统在内存管理上有一个 Generational Heap Memory 模型，内存回收的大部分压力不需要应用层关心， Generational Heap Memory 有自己一套管理机制，当内存达到一个阈值时，系统会根据不同的规则自动释放系统认为可以释放的内存，也正是因为 Android 程序把内存控制的权力交给了 Generational Heap Memory，一旦出现内存泄漏和溢出方面的问题，排查错误将会成为一项异常艰难的工作。除此之外，部分 Android 应用开发人员在开发过程中并没有特别关注内存的合理使用，也没有在内存方面做太多的优化，当应用程序同时运行越来越多的任务，加上越来越复杂的业务需求时，完全依赖 Android 的内存管理机制就会导致一系列性能问题逐渐呈现，对应用的稳定性和性能带来不可忽视的影响，因此，解决内存问题和合理优化内存是非常有必要的。
在开发的过程，如果方法不当的话，很容易造成内存泄漏，接下来，来说一下哪些情景容易出现内存泄漏。
内存泄漏出现的情景
- 单例中引用的上下文Context，引用了Activity中的Context, 这样会造成内存泄漏，要引用Application中的Context;
- 资源性对象未关闭。比如Cursor、File文件等，往往都用了一些缓冲，在不使用时，应该及时关闭它们。
- 注册对象未注销。比如事件注册后未注销，会导致观察者列表中维持着对象的引用。
类的静态变量持有大数据对象。
- 非静态内部类的静态实例。
- Handler临时性内存泄漏。如果Handler是非静态的，容易导致 Activity 或 Service 不会被回收。
- 容器中的对象没清理造成的内存泄漏。
- WebView。WebView 存在着内存泄漏的问题，在应用中只要使用一次 WebView，内存就不会被释放掉。
内存优化的方案
- 对象引用。强引用、软引用、弱引用、虚引用四种引用类型，根据业务需求合理使用不同，选择不同的引用类型。
- 减少不必要的内存开销。注意自动装箱，增加内存复用，比如有效利用系统自带的资源、视图复用、对象池、Bitmap对象的复用。
- 使用最优的数据类型。比如针对数据类容器结构，可以使用ArrayMap数据结构，避免使用枚举类型，使用缓存Lrucache等等。
- 图片内存优化。可以设置位图规格，根据采样因子做压缩，用一些图片缓存方式对图片进行管理等等。图片的压缩几种方案;
内存分析工具
做内存优化前，需要了解当前应用的内存使用现状，通过现状去分析哪些数据类型有问题，各种类型的分布情况如何，以及在发现问题后如何发现是哪些具体对象导致的，这就需要相关工具来帮助我们。以下介绍几种内存分析工具
- Memory Monitor
Memory Monitor 是一款使用非常简单的图形化工具，可以很好地监控系统或应用的内存使用情况．
主要有以下功能：
(1).显示可用和已用内存，并且以时间为维度实时反应内存分配和回收情况。
(2).快速判断应用程序的运行缓慢是否由于过度的内存回收导致。
(3).快速判断应用是否由于内存不足导致程序崩溃。
Heap Viewer 的主要功能是查看不同数据类型在内存中的使用情况，可以看到当前进程中的 Heap Size 的情况，分别有哪些类型的数据，以及各种类型数据占比情况。通过分析这些数据来找到大的内存对象，再进一步分析这些大对象，进而通过优化减少内存开销，也可以通过数据的变化发现内存泄漏。
主要有以下功能：
(1)实时查看App分配的内存大小和空闲内存大小
(2)发现Memory Leaks
Heap Viewer不光可以用来检测是否有内存泄漏，对于内存抖动，我们也可以用该工具检测，因为内存抖动的时候，会频繁发生GC，这个时候我们只需要开启Heap Viewer,观察数据的变化，如果发生内存抖动，会观察到数据在段时间内频繁更新。
Memory Monitor 和 Heap Viewer 都可以很直观且实时地监控内存使用情况，还能发现内存问题，但发现内存问题后不能再进一步找到原因，或者发现一块异常内存，但不能区别是否正常，同时在发现问题后，也不能定位到具体的类和方法。这时就需要使用另一个内存分析工具 Allocation Tracker，进行更详细的分析， Allocation Tracker 可以分配跟踪记录应用程序的内存分配，并列出了它们的调用堆栈，可以查看所有对象内存分配的周期。
- Memory Analyzer Tool(MAT)
MAT 是一个快速，功能丰富的 Java Heap 分析工具，通过分析 Java 进程的内存快照 HPROF 分析，从众多的对象中分析，快速计算出在内存中对象占用的大小，查看哪些对象不能被垃圾收集器回收，并可以通过视图直观地查看可能造成这种结果的对象。
稳定性优化
Android 应用的稳定性定义很宽泛，影响稳定性的原因很多，比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等，都会对应用的稳定性造成影响。其中最常见的两个场景是：Crash 和 ANR，这两个错误将会使得程序无法使用，比较常用的解决方式如下：
- 提高代码质量。比如开发期间的代码审核，看些代码设计逻辑，业务合理性等。
- 代码静态扫描工具。常见工具有Android Lint、Findbugs、Checkstyle、PMD等等。
- Crash监控。把一些崩溃的信息，异常信息及时地记录下来，以便后续分析解决。
- Crash上传机制。在Crash后，尽量先保存日志到本地，然后等下一次网络正常时再上传日志信息。
总结
其实app性能优化，不是一二天可以完成的，主要是要开发的过程，不断的提前代码的质量，开发人员提高自己的开发水平，发现了问题，就要及时的解决，好了，这个就写到这里，有时间再做补充．
