卡顿是如何造成的：卡主线程了
如果是子线程卡顿，是不会对应用操作卡顿
1.内部引起的：自定义View代码
2.外部引起的：如直接在主线程进行网络访问/大文件IO操作
有可能是内存造成的，内存抖动，如上一篇文章提到过一点。那就在这里具体的介绍下：
比如在我们view画一段动画的时候，每一帧的间隔时间都在16ms。这样来说的话，我们每画一帧画面的时候都对内存做一次回收。而一旦回收时间过长，就很容易造成画面卡顿
（大多数Android显示系统是以每秒钟60帧的频率工作的（专业点说，叫60Hz）也就是我们所说的60fps。为获得更平滑的动画，就必须具有每秒钟处理60帧的能力——意味着每帧只能花费16毫秒的时间。如果这个过程超过16毫秒，动画显示就会有停滞感，我们期待的如丝般顺滑的体验也就消失无踪了，在60fps内，系统会得到发送的VSYNC（垂直刷新/渲染）信号进行渲染，就会正常绘制。）
VSYNC：
1）Refresh Rate：屏幕在一秒时间内刷新屏幕的次数 有硬件的参数决定，比如60HZ
2）Frame Rate :GPU在一秒内绘制操作的帧数，比如：60fps。
GPU刷新:GPU就是帮助我们将UI等组件计算成纹理Texture和三维图形Polygons，同时会使用OpenGL，OpenGL会将纹理和三维图
形数据存储在GPU memory中
小提示:在ViewGroup中如果没有设置背景，它则不会去调用onDraw绘制方法 这个就涉及到View Tree。
优化：
1.渲染性能上的优化
2.防止过度绘制
工具Android Device Monitor,点击 start method profiling就会出现两个选项
选项一：基于样本分析，选项二：基于跟踪分析我们先来看基于样本分析，我们可以点击确定就开始跟踪了。再次点击就会生产.trace的样本文件，
我点击鼠标拖动选取了这一块区域，就可以放大观看了，如果想回到原来的，就双击上方的刻度
上图是个方法块，这个左边代表开始，右边代表结束
在我们移动鼠标的时候，上方的msec时间也会跟着动，然后下面是excl cpu mesc 的执行时间，真实的时间，左边那块是线程面板，引用队列，堆任务进程，
incl cpu time 包含其子方法调用的时间
excl cpu time 不包含其子方法调用的时间
incl real time 包含子方法真实的时间
excl real time 不包含子方法真实的时间
这样，如果出现cpu大量消耗，可以去看下
我们可以看堆和cpu的执行情况 excl cpu time，如果这个数值异常的高，就可以知道是在这一步消耗了大量的内存，同样可以找到左边的方法。
我们可以看我箭头指向的这个参数，点击他然后查看这个数值，当然这张图是没有问题的，如果这个数值一场的大，就是以为着消耗了大量的cpu。对应的该方法也需要优化。
-------------------------------------------分割线-----------------------------------------------
我们下面来说说渲染的主要问题：
1.过度绘制（OverDraw）：指的是在屏幕的某个像素点在同一帧的时间内被绘制了多次。就像是我添加一张纸盖在另一张纸上，但我们需要看的是最上面那一层，但是两张纸上都被画上了图案，而我们需要看的就只有最上面那种纸上画的图案，这样，我们就叫他为过度绘制。
在我们的绘制渲染机制里面是比较耗时的
1.CPU计算时间
CPU的优化，从减轻加工View对象成Polygons和Texture来下手
View Hierarchy中包涵了太多的没有用的view，这些view根本就不会显示在屏幕上面（出于安全考虑，Hierarchy Viewer只能连接Android开发版手机或是模拟器注意：准确地说，只有ro.secure参数等于0且ro.debuggable等于1的android系统)。
Hierarchy Viewer在连接手机时，手机上必须启动一个叫View Server的客户端与其进行socket通信。而在商业手机上，是无法开启View Server的，故Hierarchy Viewer是无法连接到普通的商业手机。
Android源码实现这一限制的地方在:
ANDROID源码根目录\frameworks\base\services\java\com\android\server\wm\WindowManageService.java
中的一段：
public boolean startViewServer(int port) {
if (isSystemSecure()) {
return false;
}
if (!checkCallingPermission(Manifest.permission.DUMP, "startViewServer")) {
return false;
}
检验一台手机是否开启了View Server的办法为：
adb shell service call window 3
若返回值是：Result: Parcel(00000000 00000000 ‘……..’)” 说明View Server处于关闭状态
若返回值是：Result: Parcel(00000000 00000001 ‘……..’)” 说明View Server处于开启状态
若是一台可以打开View Server的手机（Android开发版手机 、模拟器or 按照本帖步骤给系统打补丁的手机），我们可以使用以下命令打开View Server：
adb shell service call window 1 i32 4939
使用以下命令关闭View Server：
adb shell service call window 2 i32 4939）
一旦触发测量和布局操作，就会拖累应用的性能表现。
1.如何找出里面没用的view呢？或者减少不必要的view嵌套。
工具：Hierarchy Viewer检测
这里，我们可以看下Tree View，就可以看到所有布局的具体结构，然后在左边可以看到对应的属性参数。
还有就可以选择具体的布局，可以看到父布局中包含了多少子布局，也可以看到这个布局具体measure，layout,draw对应的时间。
优化：
1）当我们的布局是用的FrameLayout的时候，我们可以把它改成merge
可以避免自己的帧布局和系统的ContentFrameLayout帧布局重叠造成重复计算(measure和layout)
ViewStub：当加载的时候才会占用。不加载的时候就是隐藏的，仅仅占用位置。
[hierarchyviewer]Unable to capture data for node android.widget.LinearLayout@e6fdb11 in window com.example.android.mobileperf.render/com.example.android.mobileperf.render.ChatumLatinumActivity on device 192.168.56.101:5555
在去看上边有个三个小圆点的图标
三个圆点分别代表：测量、布局、绘制三个阶段的性能表现。
1）绿色：渲染的管道阶段，这个视图的渲染速度快于至少一半的其他的视图。
2）黄色：渲染速度比较慢的50%。
3）红色：渲染速度非常慢。
优化思想:查看自己的布局，层次是否很深以及渲染比较耗时，然后想办法能否减少层级以及优化每一个View的渲染时间。
2.CPU将计算好的Polygons和Texture传递到GPU的时候也需要时间
OpenGL ES API 允许数据上传到GPU后可以对数据进行保存，做了缓存。
3.GPU进行栅格化
GPU如何优化：
1.背景经常容易造成过度绘制
说多这个的话，我们就可以想到我们的xml文件中，我们经常会对ViewGroup背景进行设置背景颜色，然后再在这个控件上放到这个ViewGroup控件上，这样的话，我们就在这个控件上画上图案，而这部分则是绘制了两次。而如果绘制了超过4次，则代表是比较危险的，这一部分就需要优化。而在调试过程中，我们可以打开手机的开发者选项中的Debug Option overdraw.这样我们就可以看到对应渲染次数的颜色标识。如下：
蓝色代表绘制了1次
绿色代表绘制了2次
粉色代表绘制了3次
红色代表绘制了4次及以上
所以，看到这里就赶紧去看android：background属性咯
