jank(卡顿)
android团队把滞缓，不流畅的动画定义为jank，一般是由于丢帧引起的。安卓设备的屏幕刷新率一般是60帧每秒（1/60fps＝16.6ms每帧），所以你想要渲染的内容能在16ms内完成十分关键。每丢一帧，用户就会感觉的动画在跳动，会出现违和感。
Android UI Performace Deadlines
通过上图我们可以了解到，UI从解析到绘制的大体流程：通过UI线程完成前期的处理后，然后由Render线程完成UI的绘制。上图演示的是一个展示流畅的绘制流程的UI Performance Deadlines。下图则是一个展示有卡顿的UI绘制流程,在下图我们可以看到用红色圈出来的部分，在UI线程处理时，有一部分耗时较多，导致在绘制时Render线程在绘制时超过了16.6s的分隔线，故在UI上的表现则是在那个时间点APP的UI展示存在卡顿的现象。下面我们来看看UI在解析到绘制会大体经历那些过程。
UI绘制流程
在下图中我们可以了解到UI绘制的工程中，在UI线程处理时大致会经历:Input->Animation->Layout->Record draw->Render,根据展示的内容及业务逻辑的不同，故在各个流程的耗时也不尽相同。在上诉的各个部分都可能存在消耗大量时间的情况，从而导致在绘制时时间超过Android的FPS的刷新时间，甚至在其中某个过程中阻塞导致页面Response的情况发生。我们下面就以上情况进行分析，以防止或减少jank的发生，使app的体验更友好更流畅。
减少jank的发生，我们可以通过以下的一些建议来进行优化
step 1 run release(ish) build
确保你的debug选项为false状态，因为在处于debug状态是有很多附加的调试代表将被启用，这样在处理这些调试代码时也会消耗UI线程处理代码所需要的时间
step 2 Inspect your app visually
"profile GPU Randering" can help，在开发者选项页面将此选项打开（GPU呈现模式分析）打开此选项后我们就可以通过条形图中展示的信息来判断我们的app在某一操作过程中是否出现了jank问题
step 3 Systrace
在测试app性能时，如果返现在某个地方存在绘制上的异常，或者耗时很长，那么我们就可以通过下面的命令来获取系统中缓存的trace信息
通过上图中的命令，我们可以获取到trace信息，我们在chrome中打开生成的HTML文件。在此HTML中我们可以追踪。我们要追踪jank，则需要关注UI Thread那一栏对应右边的图像展示情况，下图是一个正常的绘制过程，故UI Thread的图像都非常的整齐，我们判断出现jank的情况则是往往出现在这个地方，流畅情况下的平整图像，出现了某一事件点出现了突出点，如下图中的情况，则说明在此时间段里有jank的发生。
我们也可以在将上述图像中的突出部分图像放大，这样就可以看到我们系统在这个时间段里大致做了什么操作，耗时情况，这样有助于我们分析jank发生的具体原因。通过原因的分析我们可以一定程度上在代码中去规避这样的事件发生。
Available
保持我们的support lib 是最新的在一定程度上也能减少jank的发生，因为Android performance team一致致力于持续优化performance UI。在对于自定义UI方面最好在重写LayoutManager.collectAdjacentPerfectPosition()(RecycelrView)
source of jank - Platform
performace 团队已经或将要对下面这些可能导致jank的问题进行优化
Binder in onBind
当我们需要进程间通信时，在Android系统机制中，我们往往通过Binder机制实现进程间的通信，但是进程间通信往往是一个开销很大的活动，下图为binder机制通讯是的trace
Maintaining App Performace
- Gather User Stats
- Add tracing
- Add Jank Tests
-
Use The Tool
我们可以在关键的位置添加添加trace，并将trace上传用以分析我们APP卡顿的原因，只需要实现Window.OnFrameMetricsAvailableListener，就可以活动app的trace，我们可以将其保存并上传以供我们分析
image
