1故事的起因

程序猿自古以来和产品汪就是一段悲惨的孽缘，经历了千百年的风吹雨打，他们还是坚强的“在一起”，也许这就是“爱”，由恨生爱的“爱”，简单爱的“爱”，罗密欧对朱丽叶的“爱”...

话说，那是一个沉闷而太阳高照的下午，产品汪坐在一个程序猿的旁边，只见台面上摆着各种道具，水果刀、砍柴刀...不对，是Macbook、键盘、鼠标，还有那台27寸的显示器...

程序猿抖着脚，深情的望着坐在旁边的产品汪，而产品汪则手指着桌面上的一部残破并且古老的Android手机。

故事，就这么发生了...

2故事的开始

“不是，你到底想怎样啊？需求和UI都按你说的做完了啊，现在还在叽叽歪歪的干哈啊？！”程序猿飙出一段质问产品汪的话，产品汪沉稳的指着手机，“没错，是做完了，但是你看下这个界面，滑动一下，你不觉得顿卡顿卡的吗？还有这个、那个...”，“这不挺好的吗？你的需求完美的实现了啊，就要付出这样的代价啦，还想怎样啊？”程序猿抱怨着，“不行！一定要解决这个低端机卡顿的问题，不然这个用户体验太差了！”产品汪非常果断而坚决的说。

程序猿心里瞬间千万只草泥马飞奔而过，手握着桌面上的水果刀，额，不对，是鼠标...戴上耳机，噼里啪啦啦的敲着键盘，开启了改就改谁怕谁模式...但是心里默念着：小样，小心有一天掉坑里去了...

3故事的经过

注：以下都是程序猿的个人秀和心理变化历程，可能会引起某些人不适，但是还是坚持下去吧，sorry。

只见他打开最熟悉的开发工具Android Studio，把手机插上，“噔”，连接成功，打开亲生孕育的APP，滑了两下，确实是有点卡啊，怎么刚开始就虚了啊。让我好好瞧瞧。

打开对应的界面xml文件和代码文件，一看，这是哪个傻*写的代码啊，ListView的convertView都没复用，每次都重新绘制了一次，也没用ViewHolder，这图片加载也没异步处理，而且还全加载了大图，让我再滑一下，滑动过程还继续加载图片啊，你当Android手机是超级计算器啊？！

不对，这好像是我自己写的啊，当时因为快下班了，急急忙忙就写了，忘记优化了啊，被这该死的产品汪抓到把柄了！以后不管项目时间多赶都不能把代码写得那么烂才行，来吧，赶紧优化一下吧...

嗯，这样看起来就舒服多了嘛（图片异步加载可使用第三方图片加载库如Glide，这里就忽略了哈）。

来，跑上去看下。嗯...确实好了挺多了，咦，不对啊，怎么感觉还是有点卡顿，该优化的我也优化了啊，还有哪呢？

是不是布局层级太深了啊？让我打开手机开发者设置里的GPU过度绘制看下，我了个天，打开之后一片深红深红的...

注：

1、原色 – 没有被过度绘制– 绘制了两次。
2、蓝色 – 1次过度绘制 – 绘制了两次。
3、绿色 – 2次过度绘制 – 绘制了三次。
4、粉色 – 3次过度绘制 – 绘制了四次。
5、红色 – 4次过度绘制 – 绘制了四次以上。

深呼吸...继续吧，革命尚未成功，让我想想有哪些可以优化的点呢？

布局优化呢，要减少层级、减少测量和绘制时间，并且提高View的复用性。

要达到这几点，可以通过如下方法：

合理使用RelativeLayout和LinerLayout，怎么个合理使用呢？

RelativeLayout比LinearLayout慢，是因为它会让子View调用2次measure过程，而LinearLayout只需一次，但是有weight属性存在时，LinearLayout也需要两次measure；

RelativeLayout的子View如果高度和RelativeLayout不同，会导致RelativeLayout在onMeasure()方法中做横向测量时，纵向的测量结果尚未完成，只好暂时使用自己的高度传入子View系统。而父View给子View传入的值也没有变化就不会做无谓的测量的优化会失效，可以使用padding代替margin以优化；

在不响应层级深度的情况下，使用Linearlayout而不是RelativeLayout。

学会使用Merge，可以删减多余的层级，merge多用于替换FrameLayout或者当一个布局包含另一个时，merge标签消除视图层次结构中多余的视图组。例如你的主布局文件是垂直布局，引入了一个垂直布局的include，这是如果include布局使用的LinearLayout就没意义了，使用的话反而减慢你的UI表现。

使用 ViewStub，它是一个看不见的、不占布局位置、占用资源非常小的视图对象，提高显示的速度。

ViewStub最大的优点是当你需要时才会加载，使用他并不会影响UI初始化时的性能。各种不常用的布局想进度条、显示错误消息等可以使用ViewStub，以减少内存使用量，加快渲染速度。ViewStub是一个不可见的，大小为0的View。

使用include标签来提高View布局的复用性。

尽可能少用wrap_content。wrap_content 会增加布局 measure 时计算成本，在已知宽高为固定值时，不用wrap_content 。

删除控件中无用的属性。

还有就是界面的避免过度绘制。

移除 XML 中非必须的背景，移除 Window 默认的背景、按需显示占位背景图片。

使用自定义View，使用 canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。

对了，还有要保持合理的一个刷界面的机制，避免频繁的刷新，还应该尽量避免将其他处理放在主线程中，比如特别复杂的数据计算和网络请求等。

想都想好了，是时候展示一波了啊！

不对，好像还差点啥的。

用什么工具来分析呢？

NO.1 Profile GPU Rendering

在手机开发者模式下，有一个卡顿检测工具叫做：Profile GPU Rendering，如图：

它的功能特点如下：

一个图形监测工具，能实时反应当前绘制的耗时；

横轴表示时间，纵轴表示每一帧的耗时；

随着时间推移，从左到右的刷新呈现；

提供一个标准的耗时，如果高于标准耗时，就表示当前这一帧丢失。

NO.2 TraceView

TraceView 是 Android SDK 自带的工具，用来分析函数调用过程，可以对 Android 的应用程序以及 Framework 层的代码进行性能分析。它是一个图形化的工具，最终会产生一个图表，用于对性能分析进行说明，可以分析到每一个方法的执行时间，其中可以统计出该方法调用次数和递归次数，实际时长等参数维度。

NO.3 Systrace UI 性能分析

Systrace 是 Android 4.1及以上版本提供的性能数据采样和分析工具，它是通过系统的角度来返回一些信息。它可以帮助开发者收集 Android 关键子系统，如 surfaceflinger、WindowManagerService 等 Framework 部分关键模块、服务、View系统等运行信息，从而帮助开发者更直观地分析系统瓶颈，改进性能。Systrace 的功能包括跟踪系统的 I/O 操作、内核工作队列、CPU 负载等，在 UI 显示性能分析上提供很好的数据，特别是在动画播放不流畅、渲染卡等问题上。

NO.4 HierarchyViewer

HierarchyViewer工具可以查看当前界面的View的层级关系，使用它可以清晰明了的查看到当前界面有哪些View是多余的，当然也要结合布局XML文件来分析啦。

OJBK了，开始展现实力的时候到了！！！

优化过程会导致观看的不适，所以忽略了啊，敬请原谅，不原谅也没啥，就这么着了，哈哈！

4故事的尾声

“我就说你可以嘛，你看，这不就流畅多了啊，之前还那么多抱怨啊...”产品汪露出了他那锋利的钢牙，程序猿貌似感觉到了接下来肯定又没啥好事发生了。

“来来来，咱们过来看看这个需求...”

To Be Continue...