简介
本文是主要是记录作者调优app的过程记录，旨在记录，不在文采
调试界面是否存在过度绘制？
过度绘制就是一个像素点重复绘制的次数太多，比如你的App登录视图有View1、View2、View3…，并且这三个组件的宽高属性都是match_parent，相当于都重叠在一起了，而我们只能看到最上面的那一个view，这就是过度绘制
使用系统的GPU调试功能
打开设置->开发者选项->调试GPU过度绘制，打开后App呈现这种状态：
tips:
- 没有颜色 - 表示一个像素点只绘制了一次，显示自己本来的颜色
- 蓝色 - 1倍过度绘制，即一个像素点绘制了 2 次；
- 绿色 - 2倍过度绘制，即一个像素点绘制了 3 次；
- 浅红色 - 3倍过度绘制，即一个像素点绘制了 4 次；
- 深红色 - 4倍过度绘制及以上，即一个像素点绘制了 5 次及以上；
判断一个页面是否过度绘制，有两个准侧：
应用所有界面以及分支界面均不存在超过4X过度绘制（深红色区域）；
应用所有界面以及分支界面下，3X过度绘制总面积（浅红色区域）不超过屏幕可视区域的1/4；
解决过度绘制：
方法一 — 利用工具解析：
使用Android sdk提供的Hierarchy View工具分享布局的层级视图，查看是否有多个界面重叠在一起；由于商业版本的手机出于安全考虑，Android系统底层屏蔽了Hierarchy调试功能导致Hierarchy无法连接手机；可以root修改源码解决，楼主觉得麻烦就没去做了，如对此办法感兴趣可以自行百度
方法二 — 自行分析视图结构
自己分析自己的代码逻辑、视图结构，找出其中过度绘制的地方；楼主就是用的这种笨方法，经过我的查看，发现我的代码里面有用到一个侧滑的开源组件，而这个侧滑组件根视图如下：
<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android" >
<ImageView
android:id="@+id/iv_background"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:adjustViewBounds="true"
android:scaleType="centerCrop"/>
<ImageView
android:id="@+id/iv_shadow"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@drawable/shadow"
android:scaleType="fitXY"/>
<RelativeLayout
android:id="@+id/sv_menu_holder"
android:layout_width="match_parent"
android:layout_height="match_parent" >
</RelativeLayout>
</merge>
上面就是三个组件全是match_parent，这就是元凶，三个重叠一起大致过度绘制了；由于前两个组件涉及其他的逻辑代码，为了减少不必要的麻烦，直接将前两个属性
android:visibility="gone"
即可解决过度绘制，效果如下：
总结
- 不要让多个视图重叠进行布局
- Activity选择主题时，主题会默认屏幕绘制一次，如果你的布局xml根视图又添加了一个background熟悉，可以去把主题里面的windowbackground设置为null，如下：
<style name="noBgStyle" parent="AppTheme.NoActionBar">
<item name="android:windowBackground">@null</item>
</style>
- 一定要注意background这个属性，加一个就表示要绘制一层，不仅仅影响过度绘制，也会影响下面讲的渲染
调试界面的渲染
Android系统绘制一帧数据画面尽可能在16ms内完成，如果超过16ms，就有可能出现掉帧、卡顿的情况，所以Android系统提供了一个追踪渲染性能查案功能
打开渲染调试：
设置->开发者模式->GPU显示配置文件->以条的形式显示于屏幕
打开后效果会像这样：
图片底部的柱状图表示最近128帧的图像所消耗的时间，每一个柱子代表一帧数据，每个柱子三种颜色：
- 蓝色：更新视图花费了多少时间，类似于onDraw方法
- 红色：OpenGL 渲染 Display List 所需要的时间。通俗来说，就是记录了执行视图绘制的耗时。用代码语言来说，就是 Android 用 OpenGL ES 的 API 接口进行 2D 渲染 Display List 的时间
- 黄色：黄色代表的是这一帧 CPU 等待 GPU 处理的时间。通俗来说，就是 CPU 等待 GPU 发出接到命令的回复的等待时间。用代码语言来说，就是这是一个阻塞调用。
水平还有一根绿色的线，这根线代表16ms，每一帧所消耗的时间尽量不超过这条绿线；
在Android 6.0中，有更多的颜色被加了进来，如下图所示：
- Swap Buffers：表示处理的时间，和上面讲到的橙色一样。
- Command Issue：表示执行的时间，和上面讲到的红色一样。
- Sync & Upload：表示的是准备当前界面上有待绘制的图片所耗费的时间，为了减少该段区域的执行时间，我们可以减少屏幕上的图片数量或者是缩小图片的大小。
- Draw：表示测量和绘制视图列表所需要的时间，和上面讲到的蓝色一样。
- Measure/Layout：表示布局的onMeasure与onLayout所花费的时间，一旦时间过长，就需要仔细检查自己的布局是不是存在严重的性能问题。
- Animation：表示计算执行动画所需要花费的时间，包含的动画有ObjectAnimator，ViewPropertyAnimator，Transition等。一旦这里的执行时间过长，就需要检查是不是使用了非官方的动画工具或者是检查动画执行的过程中是不是触发了读写操作等等。
- Input Handling：表示系统处理输入事件所耗费的时间，粗略等于对事件处理方法所执行的时间。一旦执行时间过长，意味着在处理用户的输入事件的地方执行了复杂的操作。
- Misc Time/Vsync Delay：表示在主线程执行了太多的任务，导致UI渲染跟不上VSYNC的信号而出现掉帧的情况。
tips:
一般情况下，一个页面的柱子显示了128个就应该停止了，但是楼主在App打开登录页面的时候，这个柱子一直在刷新，就表示这个界面不停的在绘制，就觉得奇怪了，为什么会重新绘制，检查代码也没有发现自己有重复绘制的代码，最后才发现：
像EditText这类可以自动获取焦点的组件，打开后是默认获取焦点的，获取焦点后，可能是系统为了显示输入文字，就不停的刷新页面；解决办法就是默认进来不给EditText焦点，给一些根视图焦点就不会出现上面不停刷新问题
android:focusableInTouchMode="true" <!--强制让组件获取焦点-->
当出现了上面的过渡绘制的处理办法？
- 根据过渡绘制颜色优化层次布局减少层叠关系
使用include标签来进行布局的复用
使用merge标签去除多余层级
使用ViewStub提高加载速度（延迟加载）
移除控件中不需要的背景（主题和跟布局同事有background属性）
将layout层级扁平化，推荐使用ConstraintLayout
推荐使用头条的布局方案进行适配，使用RelativeLayout一层布局
使用嵌套少的布局，合理运用LinearLayout和RelativeLayout - 优化自定义组件代码逻辑
onMeasure/onLayout/onDraw尽量不要做复杂耗时操作
onDraw()中不要创建新的局部变量
自定义布局中经常会用到bitmap，现在有一个复用bitmap属性，在加载图片到布局BitmapFactory.Options属性inMutable设置为true，默认下次用到时直接复用，但是需要配合软引用使用，因为缓存的bitmap也有可能被回收
自定义View/ViewGroup优化
该部分优化和上面的优化很相关，自定义View一般涉及就是以下三个方法：
- onMeasure 测量view本身尺寸
- onLayout 按放组件的相对位置
- onDraw渲染绘制view到屏幕
无论是View和ViewGroup，其测量、布局和绘制默认的都是从整颗视图树tree，从根节点工作到字节点，所以尽可能减少视图层叠布局；而且系统默认在绘制一帧画面时默认在16ms内完成，如果onDraw中绘制比较复杂，而且分配了许多内存，有可能造成卡顿和频繁GC；还要注意另外两个View的函数：
requestLayout和invalidate，前者会重新调用onMesure和onLayout，如果发现view的相对位置变了，还会调用onDraw；后者会重新调用onDraw渲染整个view，如果只是一部分变化可以调用那个invalidate(l,r,t,b)这个函数，只会渲染部分view;
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
