为什么满帧运行的游戏,玩起来反而觉得卡顿?

大家好,我是老刘

前两天打开抖音,很多人都在聊某系统游戏插帧的事情。

具体是啥系统咱也不敢说,咱也不敢问。

不过我发现有很多博主对插帧这个问题的理解不太准确。所以今天老刘想站在开发者的角度,以Flutter为例,用大白话带大家彻底搞懂游戏或者应用中的每一帧是怎么生成的,以及市面上所谓的插帧技术到底是个啥。

再强调一下哈,本文讨论的是Flutter技术,并不指向特定的手机品牌。


手机如何生成一帧画面

为了让非开发者也能大体搞懂这个过程,我们可以结合上图,把手机内部想象成一个极其高效的流水线工厂。一帧画面的诞生,大概要经历这么一场接力赛:

第一步:屏幕打节拍(发出 Vsync 信号) 最下面的硬件层中,显示器就像是一个有着固定节奏的验收员。比如大家常说的60Hz屏幕,意味着它一秒钟要展示60次画面。每次它刚展示完一张画面,就会立刻发出一个信号:下一张准备好了吗? 这声呼唤,在技术上就被称为垂直同步信号(Vsync)

第二步:信号层层上报(硬件 -> 操作系统 -> UI框架) 这声呼唤,首先会被底层的GPU(显卡)接收到。GPU听到后,会立刻顺着箭头把信号往上汇报给操作系统(也就是图中的中间层,比如Android或iOS的底层服务)。 操作系统接到通知,马上精准地去敲最上层、当前正在运行的App的门:喂,你的UI框架(比如用Flutter开发的App就是Flutter框架,游戏就是Unity引擎),该准备下一张图了!

第三步:UI框架画线稿(计算描述内容) 处于最上层的UI框架收到这个信号后,就会迅速根据开发者写的代码逻辑,计算当前页面应该长什么样(比如按钮被按下去没,游戏人物移动到哪了)。 UI框架其实并不会亲自去给画面上色。它产出的更像是一张施工蓝图,里面描述了这里要画个红色的方块,那里要画个圆。

第四步:显卡上色并交卷(GPU -> 帧缓冲区 -> 显示器) 这份施工蓝图会再次穿过操作系统(借助图里的OpenGL、Metal等图形API),最终被派发回底层的显卡手里。 GPU才是真正的涂装大师,它会根据蓝图,飞速地计算并填满屏幕上几百万个像素点的颜色。画完之后,GPU会把这幅完整的画作存放在一个叫帧缓冲区的地方(就像是交卷处的桌子)。 最后,显示器按时过来,从帧缓冲区把这幅画拿走,展示在你的眼前。

整个接力过程,在60Hz的屏幕上,被压缩在短短的16.6毫秒内完成。是不是很神奇?

我们客户端开发时经常碰到的卡顿,有很大一部分原因就是你写的页面代码在指定时间内没有完成这一帧的计算,导致画面没有按时显示出来。


游戏和普通应用的差异

游戏和普通应用最大的差异在于:普通应用是差量更新,就是说生成新的一帧图像时,只更新其中和上一帧有差异的地方。

比如用户在商品页面点击了加购物车按钮,则下一帧购物车按钮的颜色、文字等会产生变化,但是页面的其它部分并没有变化,所以就不会重新计算。

所以在大多数的App运行时,显卡的工作量不是很大,主要的工作都是cpu完成的。

但是游戏不一样,游戏中即使视角的一个微小改变,都会造成屏幕上每个像素都产生变化。因此游戏中的帧是全量变化的,而非普通App的计算差异。

这就造成了游戏中的GPU也就是显卡工作量极高,因为每一帧都需要重新计算并涂装出一个完整的全新画面来。


到底什么是插帧技术

既然游戏每一帧都要显卡全力以赴去画,那如果玩家想玩120帧的高刷游戏,手机显卡就容易发热降频、电量尿崩。这时候插帧技术就派上用场了。

目前市面上的"插帧"在底层技术上其实分为两个核心流派:

  1. 帧插值 (Frame Interpolation - 补中间帧) 最传统的插帧方式。显卡先画出第1帧和第2帧,独立显示芯片通过对比这两张真实画面的差异,算出物体的运动轨迹,然后凭空捏造出一张"第1.5帧"塞在它们中间。

    • 优点:画面相对准确,因为是根据已知的前后结果倒推的。
    • 缺点 :会带来明显的输入延迟 (Input Lag)。因为系统必须等第2帧渲染完成,才能倒推出中间的第1.5帧,这中间存在一个时间差。
  2. 帧预测 (Frame Extrapolation - 预测未来帧) 为了解决延迟问题,更高级的技术走向了"预测"。它不需要等后续真实的画面渲染完,而是直接根据当前帧的画面、历史数据以及游戏引擎底层的运动矢量 (Motion Vectors),直接"预测"出下一帧长什么样并提前显示。

    • 优点:极大地降低了操作延迟,让触控更跟手。
    • 缺点:如果画面发生不可预测的突变(比如玩家突然转身、UI弹窗突然出现),预测就会失败,导致画面出现严重的伪影 (Artifacts) 或撕裂。

通过这两种技术的结合或取舍,一方面可以通过提升总体的帧率来让游戏更流畅,另一方面则是通过帧预测来减少实际每一帧生成的延迟,从而提升游戏的响应速度。


真假插帧技术怎么分

现在很多厂商都在宣传插帧,但体验千差万别,这里面其实是有真假之分的。

所谓真插帧,通常是指带有运动补偿(MEMC)的高级插帧技术。它会去分析画面里物体的运动矢量。比如游戏人物从左跑到右,独立芯片算出了运动轨迹,在中间准确画出过渡动作。这需要极强的算力,往往依赖手机里的独显芯片硬件支持(比如高通骁龙8系和联发科天玑旗舰芯片已内置运动估计硬件模块),画面流畅且自然。

而一些体验很差的假插帧,可能只是简单地把上一帧复制一遍(纯粹凑数),或者用非常基础的画面融合算法。一旦遇到游戏里快速转动视角的复杂场景,画面就会撕裂或者出现严重的拖影。

更关键的是,插帧本质上会带来不可避免的触控延迟。因为芯片需要等下一张真实画面出来后,才能对比算出中间那张图,这中间就有时间差。所以真正顶级的插帧技术,不光是补全画面,还会配合系统底层的触控响应优化来抵消这种延迟感。


总结一下

说到底,不管手机厂商把"插帧"技术吹得多么天花乱坠,本质上它都是一种用算力换流畅度的"障眼法"。真插帧能通过独立芯片预测运动轨迹,让画面更顺滑;而假插帧只是在凑数复制,反而会带来画面撕裂和严重的触控延迟。

作为开发者,你不仅要知道一帧画面是怎么通过流水线渲染出来的,还要明白为什么你的代码会导致掉帧。

这些渲染机制在各个端侧框架里其实都是相通的。只有把这些底层原理吃透了,你写出来的应用或者游戏,才能在不依赖任何"外挂"的情况下,给用户带来最丝滑的体验。

你在玩游戏或者做性能优化时,遇到过哪些让你抓狂的卡顿问题?又是怎么解决的?欢迎在评论区留言,咱们一起交流。


🤝 如果看到这里的同学对客户端或者Flutter开发感兴趣,欢迎联系老刘,我们互相学习。

🎁 私信免费领老刘整理的《Flutter开发手册》,覆盖90%应用开发场景。可以作为Flutter学习的知识地图。

💬 : laoliu_dev
📂 老刘也把自己历史文章整理在GitHub仓库里,方便大家查阅。

🔗 github.com/lzt-code/bl...

相关推荐
猫山月2 小时前
Flutter路由演进路线(2026)
前端·flutter
悟空瞎说5 小时前
Flutter热更新 Shorebird CodePush 原理、实现细节及费用说明
前端·flutter
Lanren的编程日记7 小时前
Flutter 鸿蒙应用AR功能集成实战:多平台AR框架+模拟模式,打造增强现实体验
flutter·ar·harmonyos
zhangjikuan898 小时前
Flutter备忘
flutter
Lanren的编程日记9 小时前
Flutter 鸿蒙应用权限管理功能实战:标准化权限申请与状态管控,提升用户信任度
flutter·华为·harmonyos
Lanren的编程日记10 小时前
Flutter 鸿蒙应用语音识别功能集成实战:多平台框架+模拟模式,实现便捷语音输入
flutter·语音识别·harmonyos
拉拉尼亚10 小时前
Flutter Widget 完全指南
flutter
Lanren的编程日记10 小时前
Flutter 鸿蒙应用数据验证功能实战:完善表单验证体系,全方位提升数据质量
flutter·华为·harmonyos
jump_jump20 小时前
GetX — Flutter 的瑞士军刀,还是过度封装的陷阱?
flutter·设计模式·前端框架