1. 性能优化工具（七）-调试GPU过度绘制 & GPU呈现模式分析
调试GPU过度绘制和GPU呈现模式分析是android手机自带的分析工具。能比较方便的帮助开发者检验是否存在overdraw和卡顿的问题，但是不能帮忙定位问题。
位置：开发者选项
2.1 调试GPU过度绘制
这个工具主要是用来检查布局中是否存在布局层次过深的问题。
从上图看到检测的结果分为四个等级，蓝色，淡绿，淡红，深红代表了4种不同程度的Overdraw情况，我们的目标就是尽量减少红色Overdraw，看到更多的蓝色区域。
2.2 GPU呈现模式分析
这个工具主要是用来反映界面的绘制情况，查看是否存在耗时问题。
具体渲染原理就不介绍了，本章只是工具介绍。
1）柱状图每一根代表一帧
2）随着界面的刷新，界面上会滚动显示垂直的柱状图来表示每帧画面所需要渲染的时间，柱状图越高表示花费的渲染时间越长。
3）中间有一根绿色的横线，代表16ms，我们需要确保每一帧花费的总时间都低于这条横线，这样才能够避免出现卡顿的问题。
4）详细分析下不同颜色的柱状图代表的意思：
在Android6.0之前，柱状图主要为黄色、红色、蓝色(Swap Buffers,Command Issue,Draw)三类。自从安卓6.0之后，玄学曲线进行了改版，增加至8条数据。新版本GPU呈现分析曲线新增加了(Sync&Upload,Measure&LayoutAnimation,Input Handling,Misc/Vsync Delay)五大步骤数据。
（1）Command Issue(红色)：表示执行任务的时间，是Android进行2D渲染显示列表的时间，为了将内容绘制到屏幕上，Android需要使用Open GL ES的API接口来绘制显示列表，红色线条越高表示需要绘制的视图更多；比如我们在遇到多张图加载的时候，红色会突然跳的很高，此时滑动页面也就不流畅了，要等几秒图片才能加载出来，并不是卡住。
（2）Swap Buffers(黄色)：表示处理任务的时间，即CPU等待GPU完成任务的时间，线条越高，表示GPU做的事情越多。若橙色部分过高，说明GPU目前过于忙碌。
（3）Draw(蓝色)：表示测量和绘制视图列表所需要的时间，蓝色线条越高表示每一帧需要更新很多视图，或者View的onDraw方法中做了耗时操作。它越长说明当前视图比较复杂或者无效需要重绘，表现为卡顿。
理想的流畅状态是三色都低于绿线以下。
（4）Sync & Upload(浅蓝色)：表示的是准备当前界面上有待绘制的图片所耗费的时间，为了减少该段区域的执行时间，我们可以减少屏幕上的图片数量或者是缩小图片的大小。
下面这几种统称为绿色，随着后面标注的数字颜色逐渐加深。
（5） Measure/Layout(绿色1)表示布局的onMeasure与onLayout所花费的时间，一旦时间过长，就需要仔细检查自己的布局是不是存在严重的性能问题；。
（6）Animation(绿色2)：表示计算执行动画所需要花费的时间，包含的动画有ObjectAnimator，ViewPropertyAnimator，Transition等等。一旦这里的执行时间过长，就需要检查是不是使用了非官方的动画工具或者是检查动画执行的过程中是不是触发了读写操作等等。
（7）Input Handling(绿色3)：表示系统处理输入事件所耗费的时间，粗略等于对事件处理方法所执行的时间。一旦执行时间过长，意味着在处理用户的输入事件的地方执行了复杂的操作。
（8） Misc Time/Vsync Delay(绿色4)：表示在主线程执行了太多的任务，导致UI渲染跟不上vSync的信号而出现掉帧的情况。
总结一下：
红色/黄色/：从布局构建角度去考虑。优化：否减少视图层级、减少无用的背景图、减轻自定义控件复杂度等。
蓝色/浅蓝/各种绿色：从耗时操作角度去考虑。
2. Android性能优化第（八）篇---App启动速度优化之耗时检测处理
应用的启动速度缓慢这是很多开发者都遇到的一个问题，比如启动缓慢导致的黑屏，白屏问题，大部分的答案都是做一个透明的主题，或者是做一个Splash界面，但是这并没有从根本上解决这个问题。那么如何从根本上解决这个问题或者做到一定程度的缓解？
1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会首先会创建一个新的进程分配给该应用，这种启动方式就是冷启动。
2、热启动：当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动。
3、温启动 ：当启动应用时，后台已有该应用的进程，但是启动的入口Activity被干掉了，比如按了back键，应用虽然退出了，但是该应用的进程是依然会保留在后台，这种启动方式叫温启动。
adb shell am start -W [PackageName]/[PackageName.MainActivity]
执行成功后将返回三个测量到的时间：
这里面涉及到三个时间，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 这个方法的调用耗时，ThisTime 是指调用过程中最后一个 Activity 启动时间到这个 Activity 的 startActivityAndWait 调用结束。TotalTime 是指调用过程中第一个 Activity 的启动时间到最后一个 Activity 的 startActivityAndWait 结束。如果过程中只有一个 Activity ，则 TotalTime 等于 ThisTime。
总结:如果只关心某个应用自身启动耗时，参考TotalTime；如果关心系统启动应用耗时，参考WaitTime；如果关心应用有界面Activity启动耗时，参考ThisTime。
从我们Application开始到首页显示出来，这个过程，我们应该注意一些什么，将这个过程细分一下，会有下面的时间点需要注意。
Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量、布局、绘制显示在界面上。
因为上面这些阶段全部都是在主线程中执行的，任何不经意的操作都可能拖慢应用的启动速度。所以我们不应在Application以及Activity的生命周期回调中做任何费时操作，具体指标大概是你在onCreate，onResume，onStart等回调中所花费的总时间最好不要超过400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。但是有些 不得以的任务 又必须在UI显示之前执行。所以我们要将 任务 划分优先级。
对于首页渲染完成后，开始加载，或者延迟加载，延迟加载的目的就是界面先显示出来，然后加载，但是你觉得要延迟多久呢？在 Android 的高端机型上,应用的启动是非常快的 , 这时候只需要 Delay 很短的时间就可以了, 但是在低端机型上,应用的启动就没有那么快了,而且现在应用为了兼容旧的机型,往往需要 Delay 较长的时间,这样带来体验上的差异是很明显的。延迟加载有一种方式。
极力推荐用第二种，在窗口完成以后进行加载，这里面的run方法是在onResume之后运行的。关于这种懒加载机制，参考 Android应用启动优化:一种DelayLoad的实现和原理(上篇) ，给出了详细的解释。
通过上面我们知道一种懒加载机制，所以我们可以将Application中和首页的onCreate中的有些耗时任务，放到首页渲染完毕后加载。如何找出这些耗时任务，TraceView就派上用场了，TraceView的用法，移步我的前面的博客 Android性能优化第（六）篇---TraceView 分析图怎么看？
比如在首页的onCreate中我们进行了用户启动上报，这个进行懒加载是不是分分钟减少139毫秒呢？
在比如在Application里面用到了GSON，将String转化成json,我将这个移动到懒加载里面，是不是又减少了100毫秒呢？
在比如，有些Application中做了支付SDK的初始化，用户又不会一打开App就要支付，放在Application中加载干嘛？
此处我们这里举得例子是优化了139毫秒和100毫秒的，其实真正耗时的任务有的有1秒多，都被我优化完了，所以trace图中看不到了，就举个了这两个例子，还有SharedPreferences也是耗时大户，经过检测保存一个boolean变量耗时120+毫秒以上。
利用TraceView可以清楚我们每一个方法的耗时时间，极大的帮助了我们做优化工作。
五、优化思路总结
1、UI渲染优化，去除重复绘制，减少UI重复绘制时间，打开设置中的GPU过度绘制开关，各界面过度绘制不应超过2.5x；也就是打开此调试开关后，界面整体呈现浅色，特别复杂的界面，红色区域也不应该超过全屏幕的四分之一；
2、根据优先级的划分，KoMobileApplication的一些初始化工作能否将任务优先级划分成3,在首页渲染完成后进行加载，比如：PaySDKManager。
3、主线程中的所有SharedPreference能否在非UI线程中进行，SharedPreferences的apply函数需要注意，因为Commit函数会阻塞IO，这个函数虽然执行很快，但是系统会有另外一个线程来负责写操作，当apply频率高的时候，该线程就会比较占用CPU资源。类似的还有统计埋点等，在主线程埋点但异步线程提交，频率高的情况也会出现这样的问题。
4、检查BaseActivity,不恰当的操作会影响所有子Activity的启动。
5、对于首次启动的黑屏问题，对于“黑屏”是否可以设计一个.9图片替换掉，间接减少用户等待时间。
6、对于网络错误界面，友好提示界面，使用ViewStub的方式，减少UI一次性绘制的压力。
7、任务优先级为2，3的，通过下面这种方式进行懒加载的方式
8、Multidex的使用，也是拖慢启动速度的元兇，必须要做优化。后面有空专门写一篇Multidex。
相关链接：
Android应用启动优化:一种DelayLoad的实现和原理(上篇)http://androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html
Android性能优化之加快应用启动速度http://www.open-open.com/lib/view/open1452821612355.html
手机淘宝性能优化全记录http://www.open-open.com/lib/view/open1452488209370.html
Android客户端性能优化（魅族资深工程师毫无保留奉献）http://blog.tingyun.com/web/article/detail/155#rd
Please accept mybest wishes for your happiness and success !
3. androidUI卡顿原理分析及Vsync信号机制
一、UI卡顿定义
1、用户角度：app操作界面刷新缓慢，响应不及时；界面滑动不够流畅；
2、系统角度：屏幕刷新帧率不稳定，掉帧严重，无法保证每秒60帧，导致屏幕画面撕裂；
二、UI卡顿常见原因分析以及处理方案
1、过度绘制：
原因：界面布局设计不合理或者过于复杂导致系统无法在16毫秒内完成渲染，view过度绘制导致CPU或者GPU负载过重，View频繁触发measure、layout操作，导致measure、layout累计耗时严重以及整个View错误的频繁重新渲染；
方案：优化界面布局，使界面布局视图扁平化，去除不必要的背景颜色，减少透明色的使用；
方案依据原理：尽量减少View在系统中measure、layout、draw的累计时间；
2、UI线程的复杂运算
原因：UI主线程运算耗时
方案：减少UI线程中数据运算，使用子线程处理耗时任务
3、频繁GC
原因：（1）、内存抖动；（2）、瞬间产生大量对象，消耗内存；
方案：尽量避免在循环逻辑或者onDraw方法中频繁创建新对象和使用局部变量；
三、android Vsync机制
1、什么是Vsync ?
Vsync 是Vertical Synchronization(垂直同步)的缩写，是一种在PC上很早就广泛使用的技术，可以简单的把它认为是一种定时中断。而在Android 4.1(JB)中已经开始引入VSync机制，用来同步渲染，让AppUI和SurfaceFlinger可以按硬件产生的VSync节奏进行工作。
2、Android屏幕刷新过程
Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，屏幕的刷新过程是每一行从左到右（行刷新，水平刷新，Horizontal Scanning），从上到下（屏幕刷新，垂直刷新，Vertical Scanning）。当整个屏幕刷新完毕，即一个垂直刷新周期完成，会有短暂的空白期，此时发出 VSync 信号。所以，VSync 中的 V 指的是垂直刷新中的垂直-Vertical。
3、没有使用Vsync的情况
可见vsync信号没有提醒CPU/GPU工作的情况下，在第一个16ms之内，一切正常。然而在第二个16ms之内，几乎是在时间段的最后CPU才计算出了数据，交给了Graphics Driver,导致GPU也是在第二段的末尾时间才进行了绘制，整个动作延后到了第三段内。从而影响了下一个画面的绘制。这时会出现Jank（闪烁，可以理解为卡顿或者停顿）。这时候CPU和GPU可能被其他操作占用了，这就是卡顿出现的原因；
4、使用Vsync同步
CPU/GPU接收vsync信号，Vsync每16ms一次，那么在每次发出Vsync命令时，CPU都会进行刷新的操作。也就是在每个16ms的第一时间，CPU就会响应Vsync的命令，来进行数据刷新的动作。CPU和GPU的刷新时间，和Display的FPS是一致的。因为只有到发出Vsync命令的时候，CPU和GPU才会进行刷新或显示的动作。CPU/GPU接收vsync信号提前准备下一帧要显示的内容，所以能够及时准备好每一帧的数据，保证画面的流畅；
5、多级缓冲
Android除了使用Vsync机制，还使用了多级缓冲的策略来优化屏幕显示，如双重缓冲（A + B），当Display buffer A 数据时，CPU/GPU就已经在buffer B 中处理下一帧要显示的数据了。
可是，当系统资源紧张性能降低时，导致GPU在处理某帧数据时太耗时，在Vsync信号到来时，buffer B的数据还没准备好，此时不得不显示buffer A的数据，这样导致后面CPU/GPU没有新的buffer准备数据，空白时间无事可做，后面Jank频出
因此采用三级缓冲来解决系统对性能不稳定导致的卡顿
当出现上面所述情况后，新增一个buffer C 可以减少CPU和GPU在Vsync同步间的空白间隙，此时CPU/GPU能够利用buffer C 继续工作，后面buffer A 和 buffer B 依次处理下一帧数据。这样仅是产生了一个Jank，可以忽略不计，以后的流程就顺畅了。
注：在多数正常情况下还是使用二级缓冲机制，三级缓冲只是在需要的时候才使用；
4. 过度绘制的解决
《Google的性能优化典范》一文是Android程序内存优化的指导，分别从渲染、电量、运算和内存几个方面阐述了优化方向。
本文关注渲染方向：
渲染其实是指GPU渲染，是App计算--绘制--渲染 过程中的最后一步。CPU负责Measure Layout，Execute GPU负责Rasterization（栅格化）。
CPU通常存在的问题是 非必需的视图组件、视图层级；GPU的问题是过度绘制。
Overdraw 过度绘制：
定义：屏幕上的某个像素在同一帧的时间内被绘制了多次
例如UI是层叠的，看不见的UI也做绘制操作，就是多余的。当设计效果上更加华丽炫酷时，堆叠视图层级是常见的情况，但这很容易产生性能问题。
怎么过度绘制打开开关和如何看，不介绍了就。
1.写合理而高效的布局
Android的布局可以通过xml来实现，这使得开发者布局时较为随意，只以实现功能为目的，忽略性能问题的累积效应。
在开发设计之初，就应该考虑布局的效率问题，以免出现后期修改的高成本。
降低Layout层级，有很多方法 不列举了。
2.移除非必须的background: Activity的DecorView有默认的背景色，可以改为透明
getWindow().getDecorView().setBackgroundColor(getResources().getColor(R.color.transparent));
这个颜色从ActivityTheme设置，被decorView所持有
screen_background_selector_dark在sdk中定义为纯黑色
所以也可以 android:windowbackground="null" 方法来修改
后续会在Theme自定义，或BaseActivity 统一优化
3.View BackGround 优化：
4.移除不必要的背景色
比如Activity中含Fragment,如果Fragment有背景色而且是全屏的，Activity就不必要。
又比如ViewPager中含fragment ViewPager的背景色是不必要的
5.ClipRect
在ViewGroup的drawChild方法中，
protected boolean drawChild(Canvas canvas, View child, long drawingTime)
在ViewGroup的Canvas上绘制子child，不同的child都在同一个canvas绘制，如果view相互遮盖，则重复绘制难免。
Canvas的clipRect方法，提供了限定绘制区域的功能，在某个child 绘制时，可以限定绘制区域为自己的显示区域，解决了这个问题。
v4包中的DrawerLayout，就专门做了ClipRect优化
pilot端的问题就在于DrawerContent没有背景，而是把背景设置在了里面的Fragment，导致DrawerLayout优化没有生效
此优化一般用于自定义view中，而且控件交互存在View之间重叠的情况
Android中每个Window对应一个Canvas，window下所有view绘制公用一个canvas，viewtree的父节点在调用child.draw之前都会根据child的layout边界对canvas进行裁剪，这也是为什么超过view边界的内容不会被显示的原因。
但是对于各child大部分重叠的控件，会产生过度绘制，就需要clipRect优化。大部分容易重叠的控件FrameLayout RelativeLayout本身没有优化，需要开发者根据实际情况对自定义控件进行优化。
优化前：[图片上传失败...(image-5fc76c-1513077609721)]
优化后：[图片上传失败...(image-87aa6e-1513077609721)]
6.善用9patch，背景图如果只显示边框，选用9patch，中间的透明会被2D渲染器优化overdraw
过度绘制的原因无外乎：复杂的Layout层级、重叠的背景、重叠的View几种。开发人员在设计之初就要充分考虑过度绘制等性能敏感地带，要知道等到功能实现之后再去改Layout层级，onDraw方法等，成本和风险都会指数型提高。