图形显示过程

帧的渲染过程中一些关键组件的流程图

image.png

Image Stream Producers（图像生产者）

任何可以产生图形信息的组件都统称为图像的生产者，比如OpenGL ES, Canvas 2D, 和 媒体解码器等。

Image Stream Consumers（图像消费者）

SurfaceFlinger是最常见的图像消费者，Window Manager将图形信息收集起来提供给SurfaceFlinger,SurfaceFlinger接受后经过合成再把图形信息传递给显示器。同时，SurfaceFlinger也是唯一一个能够改变显示器内容的服务。SurfaceFlinger使用OpenGL和Hardware Composer来生成surface.

某些OpenGL ES 应用同样也能够充当图像消费者，比如相机可以直接使用相机的预览界面图像流，一些非GL应用也可以是消费者，比如ImageReader 类。

Window Manager

Window Manager是一个用于控制window的系统服务，包含一系列的View。每个Window都会有一个surface，Window Manager会监视window的许多信息，比如生命周期、输入和焦点事件、屏幕方向、转换、动画、位置、转换、z-order等，然后将这些信息（统称window metadata）发送给SurfaceFlinger，这样，SurfaceFlinger就能将window metadata合成为显示器上的surface。

Hardware Composer

为硬件抽象层（HAL）的子系统。SurfaceFlinger可以将某些合成工作委托给Hardware Composer，从而减轻OpenGL和GPU的工作。此时，SurfaceFlinger扮演的是另一个OpenGL ES客户端，当SurfaceFlinger将一个缓冲区或两个缓冲区合成到第三个缓冲区时，它使用的是OpenGL ES。这种方式会比GPU更为高效。

一般应用开发都要将UI数据使用Activity这个载体去展示，典型的Activity显示流程为：

1. startActivity启动Activity；
2. 为Activity创建一个window(PhoneWindow)，并在WindowManagerService中注册这个window；
3. 切换到前台显示时，WindowManagerService会要求SurfaceFlinger为这个window创建一个surface用来绘图。SurfaceFlinger创建一个”layer”（surface）。（以想象一下C/S架构，SF对应Server，对应Layer；App对应Client，对应Surface）,这个layer的核心即是一个BufferQueue，这时候app就可以在这个layer上render了；
   将所有的layer进行合成，显示到屏幕上。

一般app而言，在任何屏幕上起码有三个layer：

• 屏幕顶端的status bar
• 屏幕下面的navigation bar
• 还有就是app的UI部分。
  一些特殊情况下，app的layer可能多余或者少于3个，例如对全屏显示的app就没有status bar，而对launcher，还有个为了wallpaper显示的layer。status bar和navigation bar是由系统进行去render，因为不是普通app的组成部分嘛。而app的UI部分对应的layer当然是自己去render，所以就有了第4条中的所有layer进行“合成”。

GUI框架

gui.jpg

Hardware Composer

那么android是如何使用这两种合成机制的呢？这里就是Hardware Composer的功劳。处理流程为：

1. SurfaceFlinger给HWC提供layer list，询问如何处理这些layer；
2. HWC将每个layer标记为overlay或者GLES composition，然后回馈给SurfaceFlinger；
3. SurfaceFlinger需要去处理那些GLES的合成，而不用去管overlay的合成，最后将overlay的layer和GLES合成后的buffer发送给HWC处理。

借用google一张图说明，可以将上面讲的很多概念展现，很清晰。地址位于 https://source.android.com/devices/graphics/

hw.png

关于帧率

即 Frame Rate，单位 fps，是指 gpu 生成帧的速率，如 33 fps，60fps，越高越好。
但是对于快速变化的游戏而言，你的FPS很难一直保持同样的数值，他会随着你所看到的显示卡所要描画的画面的复杂程度而变化。

VSync

安卓系统中有 2 种 VSync 信号：

1. 屏幕产生的硬件 VSync： 硬件 VSync 是一个脉冲信号，起到开关或触发某种操作的作用。
2. 由 SurfaceFlinger 将其转成的软件 Vsync 信号：经由 Binder 传递给 Choreographer。

单层缓冲引发“画面撕裂”问题

single.png

如上图，CPU/GPU 向 Buffer 中生成图像，屏幕从 Buffer 中取图像、刷新后显示。这是一个典型的生产者——消费者模型。理想的情况是帧率和刷新频率相等，每绘制一帧，屏幕显示一帧。而实际情况是，二者之间没有必然的大小关系，如果没有锁来控制同步，很容易出现问题。

所谓”撕裂”就是一种画面分离的现象，这样得到的画像虽然相似但是上半部和下半部确实明显的不同。这种情况是由于帧绘制的频率和屏幕显示频率不同步导致的，比如显示器的刷新率是75Hz,而某个游戏的FPS是100. 这就意味着显示器每秒更新75次画面，而显示卡每秒更新100次，比你的显示器快33%。

双缓冲

double.png

两个缓存区分别为 Back Buffer 和 Frame Buffer。GPU 向 Back Buffer 中写数据，屏幕从 Frame Buffer 中读数据。VSync 信号负责调度从 Back Buffer 到 Frame Buffer 的复制操作，可认为该复制操作在瞬间完成。

双缓冲的模型下，工作流程这样的：

• 在某个时间点，一个屏幕刷新周期完成，进入短暂的刷新空白期。此时，VSync 信号产生，先完成复制操作，然后通知 CPU/GPU 绘制下一帧图像。复制操作完成后屏幕开始下一个刷新周期，即将刚复制到 Frame Buffer 的数据显示到屏幕上。

• 在这种模型下，只有当 VSync 信号产生时，CPU/GPU 才会开始绘制。这样，当帧率大于刷新频率时，帧率就会被迫跟刷新频率保持同步，从而避免“tearing”现象。

VSYNC 偏移

应用和SurfaceFlinger的渲染回路必须同步到硬件的VSYNC，在一个VSYNC事件中，显示器将显示第N帧，SurfaceFlinger合成第N+1帧，app合成第N+2帧。

使用VSYNC同步可以保证延迟的一致性，减少了app和SurfaceFlinger的错误，以及显示在各个阶段之间的偏移。然而，前提是app和SurfaceFlinger每帧时间的变化并不大。因此，从输入到显示的延迟至少有两帧。
为了解决这个问题，您可以使用VSYNC偏移量来减少输入到显示的延迟，其方法为将app和SurfaceFlinger的合成信号与硬件的VSYNC关联起来。因为通常app的合成耗时是小于两帧的（33ms左右）。
VSYNC偏移信号细分为以下3种，它们都保持相同的周期和偏移向量：

• HW_VSYNC_0：显示器开始显示下一帧。
• VSYNC：app读取输入并生成下一帧。
• SF VSYNC：SurfaceFlinger合成下一帧的。
  收到VSYNC偏移信号之后， SurfaceFlinger 才开始接收缓冲区的数据进行帧的合成，而app才处理输入并渲染帧，这些操作都将在16.7ms完成。

Jank 掉帧

注意，当 VSync 信号发出时，如果 GPU/CPU 正在生产帧数据，此时不会发生复制操作。屏幕进入下一个刷新周期时，从 Frame Buffer 中取出的是“老”数据，而非正在产生的帧数据，即两个刷新周期显示的是同一帧数据。这是我们称发生了“掉帧”（Dropped Frame，Skipped Frame，Jank）现象。

流畅性解决方案思路

1. 从dumpsys SurfaceFlinger –latency中获取127帧的数据
2. 上面的命令返回的第一行为设备本身固有的帧耗时，单位为ns，通常在16.7ms左右
3. 从第二行开始，分为3列，一共有127行，代表每一帧的几个关键时刻，单位也为ns

第一列t1： when the app started to draw （开始绘制图像的瞬时时间）
第二列t2： the vsync immediately preceding SF submitting the frame to the h/w （VSYNC信令将软件SF帧传递给硬件HW之前的垂直同步时间），也就是对应上面所说的软件Vsync
第三列t3： timestamp immediately after SF submitted that frame to the h/w （SF将帧传递给HW的瞬时时间，及完成绘制的瞬时时间）

1. 将第i行和第i-1行t2相减，即可得到第i帧的绘制耗时，提取出每一帧不断地dump出帧信息，计算出

一些计算规则

计算fps:

每dumpsys SurfaceFlinger一次计算汇总出一个fps,计算规则为：
frame的总数N：127行中的非0行数
绘制的时间T：设t=当前行t2 – 上一行的t2，求出所有行的和∑t
fps=N/T (要注意时间转化为秒)

计算中一些细节问题

一次dumpsys SurfaceFlinger会输出127帧的信息，但是这127帧可能是这个样子：

...
0               0               0
0               0               0
0               0               0
575271438588    575276081296    575275172129
575305169681    575309795514    575309142441
580245208898    580250445565    580249372231
580279290043    580284176346    580284812908
580330468482    580334851815    580333739054 
0               0               0
0               0               0
...
575271438588    575276081296    575275172129
575305169681    575309795514    575309142441
 

• 出现0的地方是由于buffer中没有数据，而非0的地方为绘制帧的时刻，因此仅计算非0的部分数据

• 观察127行数据，会发现偶尔会出现9223372036854775808这种数字，这是由于字符溢出导致的，因此这一行数据也不能加入计算

• 不能单纯的dump一次计算出一个fps，举个例子，如果A时刻操作了手机，停留3s后，B时刻再次操作手机，按照上面的计算方式，则t>3s,并且也会参与到fps的计算去，从而造成了fps不准确，因此，需要加入一个阀值判断，当t大于某个值时，就计算一次fps，并且把相关数据重新初始化，这个值一般取500ms

• 如果t<16.7ms,则直接按16.7ms算，同样的总耗时T加上的也是16.7

计算jank的次数:

如果t3-t1>16.7ms，则认为发生一次卡顿

流畅度得分计算公式

设目标fps为target_fps，目标每帧耗时为target_ftime=1000/target_fps
从以下几个维度衡量流畅度：

• fps: 越接近target_fps越好，权重分配为40%
• 掉帧数：越少越好，权重分配为40%
• 超时帧：拆分成以下两个维度
  • 超时帧的个数，越少越好，权重分配为5%
  • 最大超时帧的耗时，越接近target_ftime越好，权重分配为15%

end_time = round(last_frame_time / 1000000000, 2)
T = utils.get_current_time()
fps = round(frame_counts * 1000 / total_time, 2)

# 计算得分
g = fps / target
if g > 1:
  g = 1
if max_frame_time - kpi <= 1:
       max_frame_time = kpi
h = kpi / max_frame_time
 score = round((g * 50 + h * 10 + (1 - over_kpi_counts / frame_counts) * 40), 2)

参考文章：

• http://souly.cn/%E6%8A%80%E6%9C%AF%E5%8D%9A%E6%96%87/2015/08/22/android%E5%9E%82%E7%9B%B4%E5%90%8C%E6%AD%A5%E5%92%8C%E4%B8%89%E9%87%8D%E7%BC%93%E5%AD%98/

• http://windrunnerlihuan.com/2017/04/27/Android-SurfaceFlinger-%E5%AD%A6%E4%B9%A0%E4%B9%8B%E8%B7%AF-%E4%BA%8C-SurfaceFlinger%E6%A6%82%E8%BF%B0/

http://windrunnerlihuan.com/2017/05/21/VSync%E4%BF%A1%E5%8F%B7/