Jank卡顿

最近了解到游戏流畅度：帧率FPS、卡顿次数Jank、卡顿率stutter

关于jank:

这是底层的一些介绍：

https://blog.youkuaiyun.com/xuesen_lin/article/details/8954869/

卡顿（Jank）的定义

Android团队把滞缓，不流畅的动画定义为卡顿（jank），一般是由于丢帧引起的。从Android诞生的第一天直到现在的8核CPU，Android始终未能摆脱卡顿的问题。在Android APP的性能测试中卡顿测试是非常重要的一部分。

Project Butter 黄油计划

Android4.1 Jelly Bean引入了ProjectButter

先说背景，再讲解为什么ProjectButter能提升流畅性

用户感受到流畅性在于自己的输入事件与返回结果之间的延迟，若事件延迟短，则跟手，流畅，

这只是用户的角度看问题，系统中，从事件输入到最终结果响应，过程非常复杂：

(Activity)Event->SetPropertyValue->Invalidate->Measure&Layout->PrepareDraw ->

(SF)DequeueBuffer

(Activity)UpdateDisplayList->DrwaDisplayList->SwapBuffers ->

(SF)EnqueueBuffer,

(SF)CompositeWindows->PostBuffer

Acitivity进程内，主要是接收到事件后进程控件属性的更新，然后根据新的属性重新测量和布局，

布局完成后从SF获取一个缓冲，然后将新空间树的结构更新到这个buffer中，最后交给SF合成和显示。

下节讲SF，现在只要知道，SF是系统中专门负责绘制UI的系统服务就可以。

9.3.1 FPS

FramesPerSecond，FrameRate，Hz，

平稳的60FPS就算是流畅，但ipad pro 2017的refreshRate已经达到120Hz。

平稳是指，不可以有卡帧、掉帧的情况

1000ms / 60 = 16.67ms

每一帧必须保证在这个时间内处理完

Jank的产生：

VSync Vsync

Disp 0 | 1 | 1 | 2 | 3 |

GPU 1 | |2 |3 4 |

CPU 1 | 2 | 3 | 4 |

CPU负责测试和布局的计算

GPU负责图像的合成

Display是最终的显示模块，代表用户看到的结果

所有界面的刷新都要经历这三个模块的流水线作业，

流程：

开始没画面，disp0，

CPU产出1st帧的内容，然后交给GPU，接着在Disp上显示

假设CPU忙其他事，没能连续产生2nd帧内容，则导致一系列延迟，第一帧画面停留了2个VSync

ProjectBuffer引入两个机制提升流程性：

1，VSYNC机制

2，Triple Buffer

9.3.2 VSYNC

Vertical Synchronization，垂直同步，用来防止Tearing撕裂，视频、游戏由一幅幅图像组成，称为帧；

每帧有很多像素点，显示器显示每一帧画面时，需要一行一行刷新到屏幕，（逐行扫描），

显示器通过GPU的Buffer拿到要显示的每一帧数据，假设显示器将当前帧内容刷新到一半时，来了新的一帧数据，两帧内容一起显示，Tearing。

VSYNC的目的就是避免这种情况，它告知GPU等到屏幕内容刷新完再加载下一帧画面内容，避免了Tearing

Android之前的版本已经使用VSYNC避免Tearing，jellyBean对VSYNC进行了加强，

所有显示组件都以VSYNC信号为基准来保证步调一致，

CPU收到VSYNC，产生帧数据，交给GPU处理display出来

 

二、Android的"16ms"原则

Android系统每隔16ms会发出VSYNC信号重绘我们的界面(Activity)。为什么是16ms，因为Android设定的刷新率是60FPS(Frame Per Second)，也就是每秒60帧的刷新率, 约16ms刷新一次。这就意味着,，我们需要在16ms内完成下一次要刷新的界面的相关运算,，以便界面刷新更新。举个例子，当运算需要24ms完成时，16ms时就无法正常刷新了，而需要等到32ms时刷新，这就是丢帧了。丢帧越多，给用户的感觉就越卡顿。

三、卡顿的原因分析

对于APP的每一个View，Android系统都会通过三个步骤来渲染：Measure（测量）、Layout（布局）和Draw（绘制）。measure从最顶部的节点开始，顺着layout树形结构依次往下测量每个view需要在屏幕中展示的尺寸大小。每个子节点都需要向父节点提供自己的尺寸来决定展示的位置，遇到冲突时，父节点可以强制子节点重新measure（可能导致时间消耗为原来的2-3倍）。因此扁平化的view结构会性能更好。

RelativeLayouts经常需要measure所有子节点两次才能把子节点合理的布局。如果子节点设置了weights属性，LinearLayouts也需要measure这些节点两次，才能获得精确的展示尺寸。如果LinearLayouts或者RelativeLayouts被套嵌使用，measure所费时间可能会呈指数级增长。

一旦view开始被measure，该view所有的子view都会被重新layout，再把该view传递给它的父view，如此重复一直到最顶部的根view。layout完成之后，所有的view都被渲染到屏幕上。需要特别注意到是，并不是只有用户看得见的view才会被渲染，所有的view都会。APP拥有的views越多，measure，layout，draw所花费的时间就越久。要缩短这个时间，关键是保持view的树形结构尽量扁平，而且要移除所有不需要渲染的view。移除这些view会对加速屏幕渲染产生明显的效果。理想情况下，总共的measure，layout，draw时间应该被很好的控制在16ms以内，以保证滑动屏幕时UI的流畅。

1、视觉惯性

    视觉预期帧率，用户潜意识里认为下帧也应该是当前帧率刷新比如一直60帧，用户潜意识里认为下帧也应该是60帧率。刷新一直是25帧，用户潜意识里认为下帧也应该是25帧率。但是刷新如果是60帧一下跳变为25帧，扰乱用户视觉惯性。这个时候就会出现用户体验的卡顿感。

2、电影帧

    电影帧率(18-24)，一般是24帧。电影帧单帧耗时：1000ms/24=40ms。电影帧率是一个临界点。低于这个帧率，人眼基本能感觉画面不连续性，也就是感觉到了卡顿。

第四部分：PerfDog-Jank

    PerfDog Jank 计算思路：考虑视觉惯性，假设以前三帧的平均帧耗时为参考，作为vsync时间间隔，连续两次vsync没有新渲染画面刷新，则认为是一次潜在卡顿，也就是说下一帧耗时大于前三帧平均帧耗时2倍，则认为一次潜在卡顿。同时单帧耗时满足大于两倍电影帧耗时1000ms/24*2 (由于人眼低于24帧才能辨别画面不连续性)，则认为是一次真正卡顿。同时若单帧耗时大于3倍电影帧耗时，则认为是一次严重卡顿。

注解：为什么是两次vsync？GPU一般是3重缓冲buffer，当前帧已占用一个buffer，即剩余2缓冲buffer，人眼一般可容忍2帧延迟。

    为什么是两帧电影帧耗时？低于24帧画面，人眼就能感知到画面不连续性，电影一般都是24帧。即电影帧耗时1000ms/24=41.67ms，两帧电影帧耗时也就是41.67ms*2，三帧电影帧耗时是41.67ms*3。

PerfDog Jank计算方法：

同时满足两条件，则认为是一次卡顿Jank.

①Display FrameTime>前三帧平均耗时2倍。

②Display FrameTime>两帧电影帧耗时 (1000ms/24*2=84ms)。
 

同时满足两条件，则认为是一次严重卡顿BigJank.

①Display FrameTime >前三帧平均耗时2倍。

②Display FrameTime >三帧电影帧耗时(1000ms/24*3=125ms)。

APP也需要关注FPS及Jank。只是需要区分使用场景，如：

1)     静态页面窗口

只需关注FPS，理论FPS应该为0，否则，说明有冗余刷新，容易引起手机发热及耗电。

2)     有滚动动画页面窗口

只需关注FPS，FPS处于合适值即可，无需高频刷新。

3)     快速滑动页面窗口。

需要关注FPS和Jank。手机交互灵敏度就是来源于此，Android系统才出黄油计划Jank。一般滑动状态下，帧率越高越好，Jank越小越好。

4)     播放视频页面窗口。

需要关注FPS和Jank，视频卡顿直接影响用户。视频一般帧率18-24帧，Jank=0。比如微信播放视频、视频播放器等。

————————————————
版权声明：本文为优快云博主「894508923」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/u012654756/article/details/88981304