iOS的三重缓冲和微型口吃(micro stuttering)

iOS的三重缓冲和微型口吃(micro stuttering)Instrument中的Display模块:instrument-displayiOS中采用双重缓冲和三重缓冲一起使用,从display中就可以看出来。即:双缓冲不够用了就采用三缓冲。首先看看双重缓冲:双缓冲如上,此时双缓冲很够用,每次Vsync来到之前,上一帧的framebuffer(apple叫做surface+ID),所以帧率很高,基本在…

大家好,又见面了,我是你们的朋友全栈君。

Instrument 中的 Display 模块:

iOS的三重缓冲和微型口吃(micro stuttering)

instrument-display

iOS 中采用双重缓冲和三重缓冲一起使用,从 display 中就可以看出来。即:双缓冲不够用了就采用三缓冲。

首先看看双重缓冲:

iOS的三重缓冲和微型口吃(micro stuttering)

双缓冲

如上,此时双缓冲很够用,每次 Vsync 来到之前,上一帧的 frame buffer(apple叫做surface + ID),所以帧率很高,基本在 60 FPS。

其中 frame 大概就是图层上的内容吧,暂时没找到一个很专业的名词解释。例子中使用的 Layer 来话 Path,Path 不会重新生成,而是一直 addLineTo,所以内容会越来越多:

iOS的三重缓冲和微型口吃(micro stuttering)

事件代码

iOS的三重缓冲和微型口吃(micro stuttering)

绘制代码

iOS的三重缓冲和微型口吃(micro stuttering)

处理逻辑代码

接着看随着 frame 增加,进而使用三缓冲:

iOS的三重缓冲和微型口吃(micro stuttering)

三缓冲

如上图,出现了 surface 3、41、5 三个缓冲区,且随着 Vsync 信号的到来,在三个 surface 之间切换,这明显是三缓冲策略。

上图可以看到,每次的绘图时间明显的变长了(commit 之后到 queue 的间隔就是生成 bitmap 的耗时):

iOS的三重缓冲和微型口吃(micro stuttering)

image.png

这里的耗时参考意义不一定大,辩证来看。

看看之前的双缓冲的情况:

iOS的三重缓冲和微型口吃(micro stuttering)

双缓冲

上一张图片感觉有点不对,commits 之前就已经渲染完了?应该是软件的一些误差吧,不过大体也能看到,surface 大部分时间都是在排队,这也就意味着渲染在 commits 之后很快就完成了;

上图蓝色应该是上一次 commit 之后渲染完成的 bitmap。这些流程是交错的,不可能 commit 还没提交完就已经渲染完成开始排队了。

iOS的三重缓冲和微型口吃(micro stuttering)

image.png

上一张图看上去比较真实吧~~~

上述几种情况都是没有掉帧的情况下,接下来看看三缓冲情况下不够用了,出现掉帧的情况:

iOS的三重缓冲和微型口吃(micro stuttering)

三缓冲也掉帧的情况

如上图,出现了多个 surface 展示两帧的情况,其原因就是因为 frame buffer 没有渲染完成。所以这种情况下,FPS 基本在 30 左右;

再来看一个严重掉帧的情况:

iOS的三重缓冲和微型口吃(micro stuttering)

严重掉帧

如上图,蓝色画面停留了 9 帧,而 commits 频率很正常,耗时也很短,所以这肯定不是 CPU 卡顿。

上图中,和之前明显不一样的地方在于,stutters 中也有了展示,这个词是口吃的意思。难道这就是”微型口吃“?

确实是微型口吃;

定义:帧率不一样。某几个画面渲染时间大于显示器的 Vsync 间隔,而其他的画面渲染时间小于 Vsync。即:游戏/app 的帧率(如40FPS/25ms一次) < 显示器帧率(60FPS/16ms)

表现:

iOS的三重缓冲和微型口吃(micro stuttering)

image.png

原因:FPS虽然高,但是FPS不一致导致人眼视觉上看起来更卡顿。帧率不一致,不平滑是关键;因此,相对而言,此种情况下,帧率不一致比帧率低更显得卡顿。

iOS的三重缓冲和微型口吃(micro stuttering)

降低帧率之后

做法,就是使用 Metal 中的 Api 来设置固定的帧率:

iOS的三重缓冲和微型口吃(micro stuttering)

保持帧率一直

核心点:在自己 App/游戏的最大能力范围内,保持帧率的一致;

因此,此种方案,帧率从 40FPS 降低到了 30FPS,但是视觉效果上看上去更流畅了。

不使用 Metal 框架时的另外一种做法:

iOS的三重缓冲和微型口吃(micro stuttering)

CADisplayLink

但是这种做法需要注意 CPU 的使用,每秒刷新 60 次相当于执行 60 次 commit,如果 commit 阶段占用过多 CPU,那么 CPU 可能会报表。

理想情况:

iOS的三重缓冲和微型口吃(micro stuttering)

理想情况

上图是静止画面时做的测试。如果不适用固定刷新频率,那么 FPS 基本上就是 0。而上图就是采用了固定 60hz 的刷新频率。

上图是理想状态下,此时,commits 阶段代码比较简单,将主要渲染流程交给了 Core Animation,进而转嫁到了 GPU,所以 CPU 占用很低。另外,由于画面没有更新,所以 GPU 基本上就是在两个或三个 frame buffer 上来回切换,基本上不占用 GPU,估计就是视频控制器和显示器比较忙活~~~

不理想的情况:

iOS的三重缓冲和微型口吃(micro stuttering)

不理想情况

如上图,此时虽然 GPU 占比很低,但是 CPU 长期稳定在 43%,这样还不如不使用这种固定刷新频率的方法,直接不刷新可能会更好。

注意:上述两个例子都是在静止画面的情况下所列举的例子,目的只是加深对固定刷新频率的理解,千万不要无脑直接使用到自己的项目上。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/143315.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号