iOS的三重缓冲和微型口吃（micro stuttering）
iOS的三重缓冲和微型口吃（micro stuttering）
大家好，又见面了，我是你们的朋友全栈君。
Instrument 中的 Display 模块：
instrument-display
iOS 中采用双重缓冲和三重缓冲一起使用，从 display 中就可以看出来。即：双缓冲不够用了就采用三缓冲。
首先看看双重缓冲：
双缓冲
如上，此时双缓冲很够用，每次 Vsync 来到之前,上一帧的 frame buffer(apple叫做surface + ID)，所以帧率很高，基本在 60 FPS。
其中 frame 大概就是图层上的内容吧，暂时没找到一个很专业的名词解释。例子中使用的 Layer 来话 Path，Path 不会重新生成，而是一直 addLineTo，所以内容会越来越多：
事件代码
绘制代码
处理逻辑代码
接着看随着 frame 增加，进而使用三缓冲：
三缓冲
如上图，出现了 surface 3、41、5 三个缓冲区，且随着 Vsync 信号的到来，在三个 surface 之间切换，这明显是三缓冲策略。
上图可以看到，每次的绘图时间明显的变长了(commit 之后到 queue 的间隔就是生成 bitmap 的耗时)：
image.png
这里的耗时参考意义不一定大，辩证来看。
看看之前的双缓冲的情况：
双缓冲
上一张图片感觉有点不对，commits 之前就已经渲染完了？应该是软件的一些误差吧，不过大体也能看到，surface 大部分时间都是在排队，这也就意味着渲染在 commits 之后很快就完成了；
上图蓝色应该是上一次 commit 之后渲染完成的 bitmap。这些流程是交错的，不可能 commit 还没提交完就已经渲染完成开始排队了。
image.png
上一张图看上去比较真实吧~~~
上述几种情况都是没有掉帧的情况下，接下来看看三缓冲情况下不够用了，出现掉帧的情况：
三缓冲也掉帧的情况
如上图，出现了多个 surface 展示两帧的情况，其原因就是因为 frame buffer 没有渲染完成。所以这种情况下，FPS 基本在 30 左右；
再来看一个严重掉帧的情况：
严重掉帧
如上图，蓝色画面停留了 9 帧，而 commits 频率很正常，耗时也很短，所以这肯定不是 CPU 卡顿。
上图中，和之前明显不一样的地方在于，stutters 中也有了展示，这个词是口吃的意思。难道这就是”微型口吃“？
确实是微型口吃；
定义：帧率不一样。某几个画面渲染时间大于显示器的 Vsync 间隔，而其他的画面渲染时间小于 Vsync。即：游戏/app 的帧率(如40FPS/25ms一次) < 显示器帧率(60FPS/16ms)
表现：
image.png
原因：FPS虽然高，但是FPS不一致导致人眼视觉上看起来更卡顿。帧率不一致，不平滑是关键；因此，相对而言，此种情况下，帧率不一致比帧率低更显得卡顿。
降低帧率之后
做法，就是使用 Metal 中的 Api 来设置固定的帧率：
保持帧率一直
核心点：在自己 App/游戏的最大能力范围内，保持帧率的一致；
因此，此种方案，帧率从 40FPS 降低到了 30FPS，但是视觉效果上看上去更流畅了。
不使用 Metal 框架时的另外一种做法：
CADisplayLink
但是这种做法需要注意 CPU 的使用，每秒刷新 60 次相当于执行 60 次 commit，如果 commit 阶段占用过多 CPU，那么 CPU 可能会报表。
理想情况：
理想情况
上图是静止画面时做的测试。如果不适用固定刷新频率，那么 FPS 基本上就是 0。而上图就是采用了固定 60hz 的刷新频率。
上图是理想状态下，此时，commits 阶段代码比较简单，将主要渲染流程交给了 Core Animation，进而转嫁到了 GPU，所以 CPU 占用很低。另外，由于画面没有更新，所以 GPU 基本上就是在两个或三个 frame buffer 上来回切换，基本上不占用 GPU，估计就是视频控制器和显示器比较忙活~~~
不理想的情况：
不理想情况
如上图，此时虽然 GPU 占比很低，但是 CPU 长期稳定在 43%，这样还不如不使用这种固定刷新频率的方法，直接不刷新可能会更好。
注意：上述两个例子都是在静止画面的情况下所列举的例子，目的只是加深对固定刷新频率的理解，千万不要无脑直接使用到自己的项目上。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/143315.html原文链接：https://javaforall.cn
腾讯云开发者
