大家好,又见面了,我是你们的朋友全栈君。
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 的耗时):
这里的耗时参考意义不一定大,辩证来看。
看看之前的双缓冲的情况:
上一张图片感觉有点不对,commits 之前就已经渲染完了?应该是软件的一些误差吧,不过大体也能看到,surface 大部分时间都是在排队,这也就意味着渲染在 commits 之后很快就完成了;
上图蓝色应该是上一次 commit 之后渲染完成的 bitmap。这些流程是交错的,不可能 commit 还没提交完就已经渲染完成开始排队了。
上一张图看上去比较真实吧~~~
上述几种情况都是没有掉帧的情况下,接下来看看三缓冲情况下不够用了,出现掉帧的情况:
如上图,出现了多个 surface 展示两帧的情况,其原因就是因为 frame buffer 没有渲染完成。所以这种情况下,FPS 基本在 30 左右;
再来看一个严重掉帧的情况:
如上图,蓝色画面停留了 9 帧,而 commits 频率很正常,耗时也很短,所以这肯定不是 CPU 卡顿。
上图中,和之前明显不一样的地方在于,stutters 中也有了展示,这个词是口吃的意思。难道这就是”微型口吃“?
确实是微型口吃;
定义:帧率不一样。某几个画面渲染时间大于显示器的 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%,这样还不如不使用这种固定刷新频率的方法,直接不刷新可能会更好。
注意:上述两个例子都是在静止画面的情况下所列举的例子,目的只是加深对固定刷新频率的理解,千万不要无脑直接使用到自己的项目上。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/143315.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...