应用UI卡顿
常见原因主要在以下几个方面：
1、人为在UI线程中做轻微耗时操作，导致UI线程卡顿；
2、布局Layout过于复杂，无法在16ms内完成渲染；
3、同一时间动画执行的次数过多，导致CPU或GPU负载过重；
4、View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；
5、View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；
6、内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；
7、冗余资源及逻辑等导致加载和执行缓慢；
发现和定位问题，及解决方案：
打开GPU绘制，手指在卡片上来回滑来滑去，通过观察高线的位置判断卡顿的时机，我们发现滑动停止后再一次滑动时出现高峰，如图，按照经验ViewPager的卡顿问题在于滑动事件的回调，重点排查onPageScrolled，onPageSelected及Adapter的instantiateItem方法。
参考：
开发者选项：
Android 开发者选项能够帮助我们定位开发中遇到的问题，辅助我们了解应用的性能问题，对提升开发和优化效率大有帮助。
Stay awake (不锁定屏幕)
充电时保持屏幕唤醒，开发的时候，时不时的锁屏真是够了，开启它后只要插着USB线就不需要总去解锁屏幕啦。
Process Stats (进程统计信息)
使用场景: 查看后台进程和资源占用，以图形的方式展示了后台运行的进程，以及相应的运行时间和内存占用。
使用说明: 如图，左上角是指其统计的时间范围，而其下面的条形区域的进度颜色则显示了当前内存使用的情况，绿色表示处于正常范围，黄色则表示有些紧张，红色则是告急状态。再下面的列表区域则显示了当前运行的进程，右上方的百分比标明其在这段时间内运行的相对时间，100% 就表示其在这段时间内都在运行。点击进入，能够看到起内存占用详细信息。
在图中，分别显示了内存(RAM)占用情况，以及运行的 Services 列表。
Show layout bounds (显示布局边界)
使用场景: 查看 view 的区域，以及相应的 margin 和 padding.
使用说明: 开启后就能看到效果.
红色线：一个view的上边，下边，左边，右边 边界线
蓝色直角：一个view的角，比如长方形的四个角
粉红色块：margin系列的，比如layout_marginLeft 、layout_marginBottom
（注意：padding系列的，没有边界线，也没有颜色，不容易看出来）
观察布局边界线，有助于我们在布局的时候，不知道控件在哪里，不知道控件的具体位置的，可以明确的看到我们的控件在哪里。还有助于我们准确的布局控件
有时候出现一些空白空隙，或者控件重叠的情况，打开布局边界，一看就明白了。
Debug GPU OverDraw (调试 GPU 过度绘制)
先来看看什么是过度绘制。我们在绘制界面的时候，往往会有多个层级，例如在一块白色背景上绘制了一张图片，但图片下面遮住的白色背景是我们所看不到的，这一部分也是不需要绘制的，我们称这种现象为 过度绘制。显然，过度绘制造成了额外的工作，是我们应该尽可能地避免的问题。
使用场景: 查看开发的 APP 是否存在很严重的过度绘制问题。
使用说明: 开启后就能看到效果，选择 Debug GPU OverDraw, 并勾选 Show overdraw areas。
没有颜色： 意味着没有overdraw。像素只画了一次。
蓝色： 意味着overdraw 1倍。像素绘制了两次。大片的蓝色还是可以接受的（若整个窗口是蓝色的，可以摆脱一层）。
绿色： 意味着overdraw 2倍。像素绘制了三次。中等大小的绿色区域是可以接受的但你应该尝试优化、减少它们。
浅红： 意味着overdraw 3倍。像素绘制了四次，小范围可以接受。
暗红： 意味着overdraw 4倍。像素绘制了五次或者更多。这是错误的，要修复它们。
蓝色，淡绿，淡红，深红代表了4种不同程度的Overdraw情况，我们的目标就是尽量减少红色Overdraw，看到更多的蓝色区域。
值得提醒的是，过度绘制有时是无法避免的，Android建议是不要超过一次过度绘制，也就是可以是蓝色的，不能绿了。
Profile GPU rendering（GPU 呈现模式分析）
使用场景: 如我们所知，如果一阵的绘制时间超过了 16 ms，那么用户就能实际地感受到视觉上的差异，这也就是我们常说的卡顿。
GPU 呈现模式能使得我们以图形化的方式查看绘制每一帧花费的时间，以及其是否超过 16 ms，在这种模式下，可以比较粗略地定位在那一块操作比较卡顿。我们分析下图片，图片中有很多竖着的线，这些竖着的线表示一帧，其中竖线的每个颜色都表示着这一阵在绘制中的某个步骤，高度就是其花费的时间。上方的这个横线，表示16ms，任何一根竖着的线都可以和 16ms 进行比较，如果其超过 16ms，那么它的绘制时间就超过了建议的时间范围，会造成界面卡顿。开发者可以通过查看进行什么操作会使得竖线高度飙升，来初步定位卡顿问题。
使用说明: 点击 Profile GPU rendering, 选择 On screen as bars.
随着界面的刷新，界面上会滚动显示垂直的柱状图来表示每帧画面所需要渲染的时间，柱状图越高表示花费的渲染时间越长。
中间有一根绿色的横线，代表16ms，我们需要确保每一帧花费的总时间都低于这条横线，这样才能够避免出现卡顿的问题。
每一条柱状线都包含三部分，蓝色代表测量绘制Display List的时间，红色代表OpenGL渲染Display List所需要的时间，黄色代表CPU等待GPU处理的时间。
每列数据显示了渲染每一帧需要的时间，每一条线意味着一帧被绘制出来，而每条线中的不同颜色又代表着在绘制过程中的不同阶段：
Draw (蓝色) 代表着View.onDraw()方法。在这个环节会创建/刷新DisplayList中的对象，这些对象在后面会被转换成GPU可以明白的OpenGL命令。而这个值比较高可能是因为view比较复杂，需要更多的时间去创建他们的display list，或者是因为有太多的view在很短的时间内被创建。
Process (红色) – 执行Display list中的内容并创建OpenGL命令。如果有过多或者过于复杂的display list需要执行的话，那么这阶段会消耗较长的时间，因为这样的话会有很多的view被重绘。而重绘往往发生在界面的刷新或是被移动出了被覆盖的区域。
Execute (黄色) – 发送OpenGL命令到GPU。这个阶段是一个阻塞调用，因为CPU在这里只会发送一个含有一些OpenGL命令的缓冲区给GPU，并且等待GPU返回空的缓冲区以便再次传递下一帧的OpenGL命令。而这些缓冲区的总量是一定的，如果GPU太过于繁忙，那么CPU则会去等待下一个空缓冲区。所以，如果我们看到这一阶段耗时比较长，那可能是因为GPU过于繁忙的绘制UI，而造成这个的原因则可能是在短时间内绘制了过于复杂的view。
CPU无法直接将命令发给GPU 首先要明白，GPU要绘制什么样的视图是需要CPU发出指令的，但CPU不会直接告诉GPU怎么做，而是会先将这一命令存入一个“盒子”，在盒子中会形成一个列表，然后GPU从盒子中取出命令进行视图的渲染绘制。
明白了上面的过程，下面就该说说图中不同颜色到底代表了什么含义。
红色代表了“执行时间”，它指的是Android渲染引擎执行盒子中这些绘制命令的时间，假如当前界面的视图越多，那么红色便会“跳”得越高。实际使用中，比如我们平时刷淘宝App时遇到出现多张缩略图需要加载时，那么红色会突然跳很高，但是此时你的页面滑动其实是流畅的，虽然等了零点几秒图片才加载出来，但其实这可能并不意味着你卡住了。
黄色通常较短，它代表着CPU通知GPU“你已经完成视图渲染了”，不过在这里CPU会等待GPU的回话，当GPU说“好的知道了”，才算完事儿。假如橙色部分很高的话，说明当前GPU过于忙碌，有很多命令需要去处理，比如Android淘宝客户端，红色黄色通常会很高。
蓝色。假如想通过玄学曲线来判断流畅度的话，其实蓝色的参考意义是较大的。蓝色代表了视图绘制所花费的时间，表示视图在界面发生变化（更新）的用时情况。当它越短时，即便是体验上更接近“丝滑”，当他越长时，说明当前视图较复杂或者无效需要重绘，即我们通常说的“卡了”。
理解了玄学曲线不同颜色代表的意义，看懂玄学曲线就不难了。一般情况下，当蓝色低于绿线时都不会出现卡顿，但是想要追求真正的丝般顺滑那当然还是三色全部处于绿线以下最为理想。
绿色的横线表示每一帧渲染时间的阈值，值为16ms，这是因为Android流畅运行的帧率为60fps，如果每一帧的渲染时间超过16ms，帧率就降低到小于60fps，会出现丢帧的情况，直观的感受就是页面出现卡顿。如果发现条形图基本上低于绿色的线，说明页面的绘图效率良好，但当条形线频繁的超过绿色的线，应用的布局应该是有问题的，通常都是由于布局不合理或者是太过复杂。通过不同颜色的线所占的比重，可以确定卡顿是由哪个阶段引起的。
每种颜色代表每一帧渲染过程中需要完成的某一件事情，因为6.0之前的三种颜色不大能够清晰地帮助我们定位性能问题的具体原因，所以从6.0开始，将每一帧的渲染过程拆分成了8个步骤，每个步骤一种颜色，每种颜色的.
含义如下：
(1)Swap Buffers：表示处理任务的时间，也可以说是CPU等待GPU完成任务的时间，线条越高，表示GPU做的事情越多；
(2)Command Issue：表示执行任务的时间，这部分主要是Android进行2D渲染显示列表的时间，为了将内容绘制到屏幕上，Android需要使用Open GL ES的API接口来绘制显示列表，红色线条越高表示需要绘制的视图更多；
(3)Sync & Upload：表示的是准备当前界面上有待绘制的图片所耗费的时间，为了减少该段区域的执行时间，我们可以减少屏幕上的图片数量或者是缩小图片的大小；
(4)Draw：表示测量和绘制视图列表所需要的时间，蓝色线条越高表示每一帧需要更新很多视图，或者View的onDraw方法中做了耗时操作；
(5)Measure/Layout：表示布局的onMeasure与onLayout所花费的时间，一旦时间过长，就需要仔细检查自己的布局是不是存在严重的性能问题；
(6)Animation：表示计算执行动画所需要花费的时间，包含的动画有ObjectAnimator，ViewPropertyAnimator，Transition等等。一旦这里的执行时间过长，就需要检查是不是使用了非官方的动画工具或者是检查动画执行的过程中是不是触发了读写操作等等；
(7)Input Handling：表示系统处理输入事件所耗费的时间，粗略等于对事件处理方法所执行的时间。一旦执行时间过长，意味着在处理用户的输入事件的地方执行了复杂的操作；
(8)Misc Time/Vsync Delay：表示在主线程执行了太多的任务，导致UI渲染跟不上vSync的信号而出现掉帧的情况；
强制进行GPU渲染
这个选项的意思就是强制开启硬件加速。对于用户来讲，开启之后应用会变得流畅，但是由于有些Canvas方法不支持硬件加速，开启之后可能会引起应用crash。
Don’t keep activities : 不保留活动
开启这个选项后，当你从Activity A跳转到Activity B时，Activity A就会被立即销毁，这一般用来模拟设备内存不足时后台Activity被销毁的场景，如果你的应用能做到开启它时功能仍基本正常，说明代码设计得比较合理，不同Activity之间的耦和很低，对于复杂业务的应用来说，能做到这点真心不容易。
开启这个选项表示页面切到后台以后将会被系统销毁，一般用来模拟设备内存不足时后台Activity被销毁的场景。我们可以用它来测试页面重建的稳定性。如果你的应用在开启它时功能基本正常，说明代码设计得比较合理，代码写的足够健壮。这个具体怎么理解呢？
我们知道Activity有一个回调方法onSavedInstanceState()会在页面被切到后台时调用来保存页面的状态，如果页面重新切回前台而且已经被系统销毁的情况下，系统会帮我们重建页面，这个状态通常是很难模拟的。开启这个功能，就可以模拟这个情况，然后进行页面状态恢复的调试。也就是说，如果两个Activity A启动B，B启动后系统销毁了页面A，从B页面再切回来时将会白屏（或者黑屏）一下，这就是系统在重建我们的A页面。如果我们对页面恢复的处理不当，就有可能导致页面的重建出现异常，因为毕竟系统没有智能到帮我们保存所有必要的数据，有些还是需要我们自己手动来保存的。我们在测试中发现，如果将B页面的属性设置为透明，也就是设置主题为android:theme=”@android:style/Theme.Translucent”，这时候系统并不会销毁A页面，那是因为A页面并没有执行onStop()回调方法。
这个功能只是作为调试辅助开启比较合适，普通用户开启后将严重影响用户体验。