1. 测试代码
Instrument 中的 Display 模块：
iOS 中采用双重缓冲和三重缓冲一起使用，从 display 中就可以看出来。即：双缓冲不够用了就采用三缓冲。
先上测试代码：
2. 几种情况分析
首先看看双重缓冲：
如上，此时双缓冲很够用，每次 Vsync 来到之前,上一帧的 frame buffer(apple叫做surface + ID)，所以帧率很高，基本在 60 FPS。
其中 frame xxx 表示第几帧。例子中使用的 Layer 来画 Path，Path 不会重新生成，而是一直 addLineTo，所以内容会越来越多：
接着看随着内容的增多增加，进而使用三缓冲：
如上图，出现了 surface 3、41、5 三个缓冲区，且随着 Vsync 信号的到来，在三个 surface 之间切换，这明显是三缓冲策略。
上图可以看到，每次的绘图时间没有明显变长，仍然维持在一个 Vsync 信号间隔之间（16ms），所以 FPS 依然比较高，维持在 60FPS 左右：
这里的耗时辩证来看，有可能 commit 之后渲染的是上一次 commit 的画面；
来看看之前的双缓冲的情况：
如上图，双缓冲时，从视觉效果上看，渲染时间大概是三分之一个 Vsync 间隔，而三缓冲时，大概是二分之一个 Vsync 间隔，从这里大概可以看出三缓冲是一种补充措施，尽量维持渲染效率。另外，这里涉及到 GPU 复杂的工作原理，单纯的这么分析不一定准确，需要结合实际情况分析。
上述几种情况都是没有掉帧的情况下，接下来看看三缓冲情况下不够用了，出现掉帧的情况：
如上图，出现了多个 surface 展示两帧的情况，其原因就是因为 frame buffer 没有渲染完成。所以这种情况下，FPS 基本在 30 左右；
再来看一个严重掉帧的情况：
如上图，蓝色画面停留了 9 帧，而 commits 频率很正常，耗时也很短，所以这肯定不是 CPU 卡顿。
上图中，和之前明显不一样的地方在于，stutters 中也有了展示，这个词是口吃的意思。难道这就是”微型口吃“？
确实是微型口吃；
3. commit层级
看看之前的双缓冲的情况：
这张图片中， commits 之前就已经渲染完了？显然不是，surface5 显示的是上一帧的画面，第一个 commits 渲染完成的画面由 surface41 展示。
GPU 渲染的规则和机制可能有很多，后期需要深入研究后才能看的更清晰。比如可能 Surface5 已经渲染完成，如果双缓冲够用，那么在展示 Surface5 之前不会开始渲染 Surface41，所以很多地方需要辩证来看；
4. 微型口吃
定义：帧率不一样。某几个画面渲染时间大于显示器的 Vsync 间隔，而其他的画面渲染时间小于 Vsync。即：游戏/app 的帧率（如40FPS/25ms一次） < 显示器帧率(60FPS/16ms)
现象：
帧率表现：
原因：FPS虽然高，但是FPS不一致导致人眼视觉上看起来更卡顿。帧率不一致，不平滑是关键；因此，相对而言，此种情况下，帧率不一致比帧率低更显得卡顿。
做法，就是使用 Metal 中的 Api 来设置固定的帧率：
核心点：在自己 App/游戏的最大能力范围内，保持帧率的一致；
因此，此种方案，帧率从 40FPS 降低到了 30FPS，但是视觉效果上看上去更流畅了。
不使用 Metal 框架时的另外一种做法：
但是这种做法需要注意 CPU 的使用，每秒刷新 60 次相当于执行 60 次 commit，如果 commit 阶段占用过多 CPU，那么 CPU 可能会报表。
理想情况：
上图是静止画面时做的测试。如果不使用固定刷新频率，那么 FPS 基本上就是 0。而上图就是采用了固定 60hz 的刷新频率。
上图是理想状态下，此时，commits 阶段代码比较简单，将主要渲染流程交给了 Core Animation，进而转嫁到了 GPU，所以 CPU 占用很低。另外，由于画面没有更新，所以 GPU 基本上就是在两个或三个 frame buffer 上来回切换，基本上不占用 GPU，估计就是视频控制器和显示器比较忙活~~~
不理想的情况：
如上图，此时虽然 GPU 占比很低，但是 CPU 长期稳定在 43%，这样还不如不使用这种固定刷新频率的方法，直接不刷新可能会更好。因为不刷新时，如果画面没有发生变化，就不会有 CPU 和 GPU 的消耗。
注意：上述两个例子都是在静止画面的情况下所列举的例子，目的只是加深对固定刷新频率的理解，千万不要无脑直接使用到自己的项目上。
5. 补充
游戏类 App 比较追求帧率，因为游戏即使处于无交互的状态，因为有很多动画，画面也几乎都是在变化的，所以游戏中的帧率是实实在在的画面变化频率。
而普通的 App 在无交互时，大部分情况下只是视频显示器在重复扫描同一个 frame buffer 并将信号传递给显示器进行光学展示。这种固定帧率的方式如果用到普通 App 上，对于静止画面而言，本质上就是让视频控制器改变其 frame buffer 的指向，在两个或多个 frame buffer 之间切换扫描，而这两个 frame buffer 其实都是没有发生变化的，所以更像是一种假象或是模拟刷新的行为。
所以，固定帧率对于游戏 App 而言，是在没办法达到高帧率的情况下的一种折中方案。固定帧率对于普通 App 而言，意义并不大，甚至可能会掩盖问题或引入性能问题。因为普通 App 的渲染瓶颈一般都是在 CPU，或者说是 CPU 和 GPU 之间的负载均衡。
