Android VSYNC与图形体系中的扯破、双缓冲、三缓冲浅析

程序员 2024-10-6 12:39:22 59 0 来自 中国
VSYNC与画面扯破

VSYNC即vertical sync,也称为垂直同步,是一种图形技能,重要就是逼迫将帧速率与表现器的革新率同步,最初由 GPU 制造商提出,重要用来处置惩罚屏幕扯破。起宰衡识下两个名词:FPS与屏幕革新频率

  • 帧率[Frame Rate,单元FPS]-显卡天生帧的速率,也可以以为是数据处置惩罚的速率
  • 屏幕革新频率 [Refresh Rate单元赫兹/HZ]:是指硬件装备革新屏幕的频率,值一样寻常是固定的,以优劣电视的电子扫描枪类比,好比60Hz的表现屏,每16ms电子枪从上到下从左到右一行一行渐渐把图片绘制出来。
两者要同步共同好才气高效的表现图像,可以人为帧率对应的是图像数据的输出,革新率对应的是图像数据的屏幕展示,如果帧率同装备的革新率不同等,而又没有采取合适的同步技能,会出现什么题目呢?大概会出现上述的屏幕扯破[多帧的局部数据共同构成了一个完备帧],表示如下:
理论上来讲,只要没做到读/写线性同步就有几率发生扯破, 只有帧数据完备更新+表现装备完备渲染才气克制扯破,相对应的扯破的复现场景有两种:

  • 1:表现装备未完备渲染: 假设表现装备只有一块显存存放表现数据,在没有同步加锁的情况下,帧数据由CPU/GPU处置惩罚完可随时写入到显存,如果恰幸亏上一帧A还没100%在屏幕表现完的时间,B帧到达,而且覆盖了A,那么在继续革新下半部门时,绘制的就是B帧数据,此时就会出现上半部门是A下半部门是B,即发生屏幕扯破:如下


  • 2 帧数据未完备更新 :仍然假设表现装备只有一块显存存放表现数据,如果在GPU覆盖旧帧的间隙,也就是显存数据没有100%革新的时间,关照渲染到屏幕,这个时间同样会发生上述事变,纵然用了半成品的帧:扯破帧。
以是同步锁的机制是扯破的关键,必须有这么一个机制告诉GPU显卡,要期待当前帧绘完备,才气更换当前帧,即VSYNC,VSYNC逼迫帧率和表现器革新频率同步,如果当前帧没绘制完,纵然下一帧准备好了,也克制使用下一帧,直到表现器绘制完当前帧,即:60HZ表现器,开了垂直同步后,表现帧率就会限定最高60,纵然显卡输出高达90FPS也没用,以致可以以为他是一种妥协性优化,肯定程度上还会低落性能。以上都是针对一块表现存储的情况,理论上只要加锁就能解决,读的时间克制写,但这么做无疑会大大低落服从,以是不能简单依赖单纯加锁解决题目。
双缓冲+垂直同步

怎样解决单缓冲+同步的性能题目呢?多增加一块表现存储区能解决吗?假定表现装备有两块显存,BackBuffer与FrontBuffer,可以简单的以为CPU/GPU占据一个缓冲、当前出现的数据占据一个缓冲,GPU/CPU 绘制更新BackBuffer,不须要关心正在展示的FrontBuffer,这就是双缓冲,相比于单缓存,双缓冲可让写与读分离,进步服从。但紧靠双缓冲理论上解决不了扯破的题目,BackBuffer毕竟也是要展示的,也要”拷贝“到FrontBuffer,如果不对拷贝利用添加干预,也大概出现扯破,VSYNC机制必须兼具克制在革新的过程中更新FrontBuffer的功能,全部的COPY大概说是Page flipping利用都要期待上一帧完全渲染完才可以,渲染完成之后,表现装备就按节奏可以发出下一个VSYNC信号,关照BackBuffer与FrontBuffer间举行拷贝,拷贝竣事后,接着举行下一帧屏幕渲染,如许就能克制屏幕扯破,固然,如果BackBuffer还未来得及完成帧更新也是须要阻断拷贝过程,否则就是渲染了半成品的帧,以是个各人为,Vsync解决扯破、双缓冲来解决性能。
It does this by preventing the GPU from doing anything to the display memory until the monitor has concluded its current refresh cycle — effectively not feeding it any more information until it’s ready for it. Through a combination of double buffering and page flipping, VSync synchronizes the drawing of frames onto the display only when it has finished a refresh cycle, so you shouldn’t ever see tears when VSync is enabled.
对Android体系而言,VSYNC除了逼迫帧率和表现器革新频率同步外,还有其他许多作用,在Android Jelly Bean之前VSYNC使用的场景比力少,只用在最后缓冲区切换,体系的其他环节没用,这种做法大概会让CPU浪费在其他低优先级的业务上,如下图:
如此情况就是一次jank
Jelly Bean之前VSYNC仅用在最后的图像表现阶段,防止屏幕扯破,但是并未调和UI的绘制,CPU对于表现帧的处置惩罚是缭乱的,VSYNC到达后,如果CPU被其他使命占据,UI绘制的执行就会耽误,等到它开始处置惩罚UI天生帧的时间,大概已经处于16ms的中心,如许就很轻易跨两个VYSNC信号,导致掉帧。在Jelly Bean中,下一帧的处置惩罚被限定在VSync信号到达时,而且依赖Android的消息屏蔽机制,将UI重绘消息的优先级是进步,其他的同步消息均不会执行,由于是在每个VSYNC信号到达时就处置惩罚帧,可以让UI绘制充实使用16ms耗时,可以只管克制跨越两帧的情况出现
这种做法包管了UI绘制的执行时间,固然不能完全解决jank【好比本身绘制就凌驾16ms】,但是对于原来就小于16ms的使命是能包管的,从而低落jank的概率,因此VSYNC+双缓冲可以或许很好低落单缓冲的性能题目,低落延时。
双缓冲的进阶:三缓冲

之前的VSYNC+双缓冲流程图示都是用1、2、3代表第帧来表现更新流程,接线来用缓冲区代表,看一下双缓冲的数据流向,抱负情况下,16ms内CPU处置惩罚完数据,将缓冲区A交给GPU,GPU接着处置惩罚A,竣事后,等下个VSYNC与前面展示缓冲区B交换,A举行屏幕渲染,B回收用来继续天生下一帧,如下图所示:
7.png 在这种模子下,CPU与GPU实在是一种串行处置惩罚的利用,存在资源的浪费,由于两者其一必空闲,毕竟没有多余的缓冲区让其处置惩罚数据,抱负情况下实在双缓冲并未有什么不妥,但是一旦CPU大概GPU处置惩罚超时,jank就很轻易发生。
VSYNC+双缓冲包管低延时,三缓冲包管稳固性:让闲置的资源动起来
双缓冲模子中表现、CPU、GPU处置惩罚都会用到Buffer,VSYNC+双缓冲在抱负情况下是没有题目的,但如果某个环节出现题目,那就不一样了,好比某些帧耗时是[CPU 8ms +GPU 12ms],凌驾了16ms,如下:
8.png 可以看到在第二个阶段,存在CPU资源浪费,双缓冲只会提供两个Buffer,B被GPU处置惩罚占用,A正在用表现,那么在第二个16ms内里,CPU就无法获取到Buffer处置惩罚UI更新,在Jank的阶段空空期待。而且,一样寻常出现这种场景都是连续的:好比复杂视觉结果,那么GPU大概会不绝超负荷,CPU不绝跟GPU抢Buffer,如许带来的题目就是滚雪球似的掉帧,不绝浪费,完全没有使用CPU与GPU并行处置惩罚的服从,成了串行处置惩罚,如下所示
如那边理呢?多增加一个Buffer给CPU用,让它提前忙起来,如许就能做到三方都有Buffer可用,CPU不用跟GPU争一个Buffer,真正实现并行处置惩罚。如下:
10.png 如上图所示,固然纵然每帧须要20ms【CPU 8ms +GPU 12ms】,但是由于多加了一个Buffer,实现了CPU跟GPU并行,便可以做到了只在开始掉一帧,后续却不掉帧,双缓冲充实使用16ms做到低延时,三缓冲保障了其稳固性,为什么4缓冲没须要呢?由于三个既可包管并行,四个徒增资源浪费。 在Android体系中,双缓冲不但仅是两份存储,它是一个概念,双缓冲是一条链路,不是某一个环节,是整个体系采取的一个机制,须要各个环节的支持,从APP到SurfaceFlinger、到图像表现都要加入协作。对于APP端而言,每个Window都是一个双缓冲的模子,一个Window对应一个Surface,而每个Surface里至少映射两个存储区,一个给图层合成表现用,一个给APP端图形处置惩罚,这便是应于上层的双缓冲。
总结


  • 同步是防止画面扯破的关键,VSYNC同步能防止画面扯破
  • VSYNC+双缓冲在Android中能有序规划渲染流程,低落延时
  • Android已经采取了双缓冲,双缓冲不但仅是两份存储,它是一个概念,双缓冲是一条链路,不是某一个环节,是整个体系采取的一个机制,须要各个环节的支持,从APP到SurfaceFlinger、到图像表现都要加入协作
  • 三缓冲在UI复杂情况下能包管画面的连续性,进步柔韧性
作者:看书的小蜗牛
链接:https://juejin.cn/post/7125675253707046926
泉源:稀土掘金  如有侵权,请接洽删除!
您需要登录后才可以回帖 登录 | 立即注册

Powered by CangBaoKu v1.0 小黑屋藏宝库It社区( 冀ICP备14008649号 )

GMT+8, 2024-11-21 21:05, Processed in 0.171044 second(s), 36 queries.© 2003-2025 cbk Team.

快速回复 返回顶部 返回列表