1. 锁帧这件事为什么值得单独拎出来讲做移动端项目的人大概都有过这种体验游戏逻辑明明不重Draw Call 也压到了两百以内Shader 也没用什么花哨的东西可手机一跑起来背面烫得能煎鸡蛋十分钟后帧率从 60 掉到 40再过一会儿直接卡成 PPT。你去查 ProfilerCPU 和 GPU 的耗时看起来都还行就是温度压不住。这种情况我遇到过太多次了最后发现问题往往不在渲染本身而在于一个很多人压根没在意的东西——帧率上限。这篇是发烫优化系列的第七篇前面几篇聊过 Draw Call 合并、纹理压缩、Shader 简化、GC 控制、物理更新频率、UI 重建这些方向今天专门把锁帧这个手段拿出来单独讲。原因很简单它是所有发热优化手段里改动成本最低、见效最快、副作用最可控的一个。你不需要重构渲染管线不需要换 Shader甚至不需要美术配合只要在代码里加一行Application.targetFrameRate 30很多项目的发热问题就能缓解一大半。但锁帧这件事说简单也简单说坑也真不少。锁多少合适什么时候锁锁了之后动画会不会卡不同平台行为一样吗Unity 的targetFrameRate和QualitySettings.vSyncCount到底谁说了算这些问题如果不想清楚锁帧可能不但没优化发热反而把体验搞得更糟。我见过有项目直接锁 30结果 UI 滑动像幻灯片也见过锁了帧但没关垂直同步实际根本没生效的。所以这篇不打算只给你一个结论而是把锁帧背后的逻辑、参数选择、平台差异、实操步骤和踩坑经验完整地讲一遍。不管你是刚接触 Unity 的新手还是已经做过几个上线项目的老手只要你的项目在移动端有发热困扰这篇内容都能直接拿去用。核心关键词就几个锁帧、帧率、发热、Unity、targetFrameRate围绕它们把这件事讲透。2. 帧率与发热的底层关系拆解2.1 为什么帧率越高手机越烫要理解锁帧为什么能降温得先搞清楚手机发热的来源。手机 SoC 里跟游戏帧率直接相关的主要是 CPU 和 GPU 两大块它们每渲染一帧都要做大量运算CPU 负责逻辑更新、物理模拟、动画计算、提交渲染命令GPU 负责顶点变换、光栅化、像素着色。这些运算本质上都是电流在晶体管里跑来跑去有电流就有功耗有功耗就有热量。关键点在于功耗和运算量基本成正比而运算量和帧率成正比。你跑 60 帧意味着每秒要做 60 次完整的逻辑加渲染循环跑 30 帧运算量直接砍半。功耗降下来发热自然就少了。这不是线性的简单关系因为还有漏电流、电压调节等复杂因素但大方向上帧率减半GPU 负载和 CPU 逻辑负载大致减半整机功耗能降 30% 到 40%。更麻烦的是热积累的恶性循环。手机没有风扇散热全靠被动传导。当 SoC 温度升到某个阈值通常 40 到 45 摄氏度左右系统会主动降频保护硬件这时候帧率会突然掉下来玩家感受到的就是卡顿。而降频之后如果负载还是很高温度继续升降频更狠最后就是持续卡顿加烫手。锁帧的作用就是在源头把负载压下去让温度维持在一个不会触发降频的区间帧率反而更稳定。我做过一个实测对比同一款中度休闲游戏在中端安卓机上跑不锁帧时前 3 分钟稳定 60 帧第 5 分钟开始掉到 50 左右第 10 分钟稳定在 38 到 42 帧波动机身背面最高温度 46 度锁 30 帧后全程稳定 30 帧10 分钟后温度只有 38 度左右手感明显温和很多。帧率数字是低了但体验的一致性反而更好因为不会出现那种忽高忽低的抖动。2.2 帧率、刷新率、垂直同步三者的关系很多人把帧率、刷新率、垂直同步混为一谈这里必须理清楚否则锁帧参数很容易设错。帧率Frame Rate是你的游戏每秒实际渲染出多少帧由你的代码和硬件性能决定。刷新率Refresh Rate是屏幕硬件每秒刷新多少次画面现在手机普遍是 60Hz、90Hz、120Hz 甚至 144Hz。垂直同步VSync是一种同步机制让游戏的帧输出跟屏幕刷新对齐避免画面撕裂。Unity 里控制这三者的关键参数有两个Application.targetFrameRate和QualitySettings.vSyncCount。它们的关系有个很多人不知道的规则当 vSyncCount 不为 0 时targetFrameRate 会被忽略。也就是说如果你在 Quality Settings 里开了垂直同步代码里设的 targetFrameRate 根本不生效实际帧率会被锁定到屏幕刷新率的整数分之一。举个例子屏幕 60HzvSyncCount 设为 1那游戏帧率就被锁在 60vSyncCount 设为 2锁在 30。屏幕如果是 120HzvSyncCount 为 1 时锁 120为 2 时锁 60。这就是为什么有些人设了 targetFrameRate 30 却发现帧率还是 60因为垂直同步把它覆盖了。所以正确的锁帧姿势是先把 vSyncCount 设为 0再设置 targetFrameRate。这样 targetFrameRate 才能真正生效。当然关掉垂直同步可能会带来画面撕裂但在移动端小屏幕上撕裂通常不明显而且发热优化的收益远大于撕裂带来的视觉影响。如果你确实在意撕裂那就用 vSyncCount 来控制帧率但灵活性会差很多因为只能锁到刷新率的整数分之一。2.3 锁帧不等于降画质这是两码事有个常见的误解需要澄清锁帧不是降低画质。画质取决于分辨率、纹理精度、Shader 复杂度、后处理效果这些锁帧只是控制每秒渲染多少次。你完全可以在锁 30 帧的同时保持高画质只是每帧之间的间隔变长了。这带来一个很重要的策略空间当性能预算有限时你可以选择高画质低帧率或者低画质高帧率。对于不同类型的游戏最优解完全不同。休闲益智类、卡牌类、模拟经营类30 帧完全够用把省下来的性能预算堆到画质上画面更精致玩家更买账。而竞技类、动作类、音游类帧率就是生命线宁可降画质也要保 60 帧。我个人的经验是大部分手游其实并不需要 60 帧。玩家对帧率的敏感度远低于开发者想象尤其是非动作类游戏。你锁 30 帧只要帧生成时间稳定没有明显卡顿绝大多数玩家根本察觉不到。反倒是发热导致的降频卡顿玩家一玩就能感觉到。所以锁帧在很多时候是用玩家感知不到的东西换玩家能明显感知到的东西这笔账很划算。3. Unity 中锁帧的具体实现与参数选择3.1 targetFrameRate 的正确设置方式在 Unity 里设置目标帧率最直接的就是这一行Application.targetFrameRate 30;但这一行放在哪里、什么时候调用是有讲究的。我一般会把它放在游戏启动的初始化脚本里比如一个专门的PerformanceManager或者GameBootstrap脚本的Awake方法中。不要放在每帧都执行的Update里那样虽然也能生效但没必要反复设置。一个完整的初始化逻辑大概长这样using UnityEngine; public class PerformanceManager : MonoBehaviour { [SerializeField] private int targetFrameRate 30; [SerializeField] private bool disableVSync true; void Awake() { if (disableVSync) { QualitySettings.vSyncCount 0; } Application.targetFrameRate targetFrameRate; DontDestroyOnLoad(gameObject); } }这里把vSyncCount设为 0 是关键前面讲过不设的话 targetFrameRate 会被忽略。DontDestroyOnLoad保证切换场景时这个设置不会被重置。有些项目在场景切换后会重新初始化 QualitySettings导致锁帧失效加上这个能避免。另外要注意targetFrameRate 的值必须是整数而且不能是负数-1 表示不限制让系统自己决定。设成 0 或者负数在部分平台上行为不一致建议老老实实用正数。3.2 锁 30 还是锁 60怎么选这是最核心的问题。我的判断逻辑分三层第一层看游戏类型。动作、射击、竞速、音游、MOBA 这类对操作响应要求高的优先保 60 帧实在保不住再考虑 45 或者 40。休闲、卡牌、模拟、放置、文字类30 帧足够甚至 24 帧在某些场景下也能接受。第二层看目标机型。如果你的用户主要是中低端机那 60 帧本身就是奢望不如直接锁 30把稳定性做上去。如果是旗舰机用户为主可以尝试 60 帧但要做好温控策略比如温度升高后动态降到 45 或 30。第三层看发热预算。你可以做个简单的测试不锁帧跑 10 分钟记录温度和帧率曲线锁 60 跑 10 分钟记录锁 30 跑 10 分钟记录。对比下来哪个档位能在你设定的温度上限内保持稳定就选哪个。我整理了一个简单的参考表不同游戏类型和机型档位的建议帧率游戏类型低端机中端机高端机动作/射击/竞速306060卡牌/模拟/休闲303030-60放置/文字/棋牌24-303030音游/格斗306060这个表不是绝对的只是给个起点。实际项目里还要结合具体的性能测试来定。3.3 动态锁帧根据温度实时调整固定锁帧有个问题低端机锁 30 可能还是烫高端机锁 30 又浪费了性能。更聪明的做法是动态锁帧根据设备温度或者性能表现实时调整目标帧率。Unity 本身没有直接读取设备温度的跨平台 API但可以通过一些间接方式判断。比如监测一段时间内的平均帧率如果持续低于目标值说明设备在降频这时候可以主动降低 targetFrameRate减少负载让温度回落。等温度降下来再逐步提回去。一个简单的动态调整逻辑using UnityEngine; public class DynamicFrameRate : MonoBehaviour { [SerializeField] private int highFrameRate 60; [SerializeField] private int lowFrameRate 30; [SerializeField] private float checkInterval 5f; [SerializeField] private float lowFpsThreshold 0.85f; private float timer; private int frameCount; private float elapsed; void Start() { QualitySettings.vSyncCount 0; Application.targetFrameRate highFrameRate; } void Update() { frameCount; elapsed Time.unscaledDeltaTime; timer Time.unscaledDeltaTime; if (timer checkInterval) { float avgFps frameCount / elapsed; if (avgFps Application.targetFrameRate * lowFpsThreshold) { Application.targetFrameRate lowFrameRate; } else if (avgFps highFrameRate * 0.95f Application.targetFrameRate ! highFrameRate) { Application.targetFrameRate highFrameRate; } timer 0f; frameCount 0; elapsed 0f; } } }这个逻辑的核心是如果实际帧率明显低于目标说明设备扛不住主动降档如果实际帧率能稳定达到高档位再升回去。这样既能在高性能设备上跑满又能在低性能设备上保稳定。注意动态调整帧率时切换频率不要太快否则玩家会感觉到明显的帧率跳变。我一般设 5 到 10 秒检查一次而且降档要快、升档要慢避免在临界点反复横跳。4. 不同平台的锁帧行为差异4.1 Android 平台的坑Android 是锁帧行为最复杂的平台因为设备碎片化太严重。同样一行targetFrameRate 30在不同厂商、不同系统版本上的表现可能完全不同。最大的坑是部分厂商的系统会强制覆盖应用的帧率设置。比如某些游戏手机有性能模式开启后会强制拉满帧率你的锁帧代码根本不生效。还有些系统在检测到游戏运行时会自动启用高刷新率模式把屏幕刷新率提到 120Hz这时候即使你锁了 30 帧系统层面的调度也可能让功耗下不来。应对办法有几个一是在游戏内提供帧率选项让玩家自己选同时说明低帧率更省电二是通过Application.targetFrameRate配合QualitySettings.vSyncCount 0双管齐下三是在关键场景比如战斗、加载临时调整帧率非关键场景比如主菜单、剧情直接锁低帧率。另外Android 上还有个Screen.currentResolution.refreshRate可以读取当前屏幕刷新率但注意这个值在运行时可能变化不要缓存一次就一直用。4.2 iOS 平台的特性iOS 相对规范很多targetFrameRate的行为比较一致。但 iOS 有个 ProMotion 技术在支持的高端机型上屏幕刷新率可以在 24Hz 到 120Hz 之间自适应。这种情况下如果你设了 targetFrameRate 60系统可能会根据内容自动调整刷新率实际表现跟你想的不完全一样。iOS 上还有个要注意的点低电量模式下系统会主动限制帧率。当用户开启低电量模式系统可能把帧率压到 30 甚至更低这时候你的锁帧设置会被系统覆盖。这个行为是系统级的应用无法改变只能接受。所以做 iOS 优化时要考虑到低电量模式下的表现不要把帧率相关的逻辑写得太死。4.3 PC 和主机平台的差异PC 平台的情况又不一样。PC 上玩家对帧率极其敏感而且硬件性能差异巨大。在 PC 上锁帧更多是为了减少 GPU 满载导致的发热和风扇噪音而不是像手机那样为了温控。很多 PC 玩家会主动开垂直同步或者用驱动层面的帧率限制所以游戏内的锁帧选项要做得灵活最好提供 30、60、120、不限制等多个档位。主机平台相对封闭帧率目标通常由平台方和游戏类型决定锁帧策略比较固定。这里就不展开讲了重点还是放在移动端。5. 锁帧实操从测试到上线的完整流程5.1 第一步建立发热基线测试在动手锁帧之前必须先知道当前项目的发热情况。没有基线你无法判断锁帧到底有没有效果。测试方法我一般这样做选三台代表性设备低端、中端、高端各一台安装一个带性能监控的 Debug 包跑同一个场景或者同一段游戏流程持续 15 到 20 分钟记录以下数据每秒帧率用Time.deltaTime或者1 / Time.unscaledDeltaTime统计CPU 和 GPU 耗时通过 Profiler 或者平台工具设备温度Android 可以用adb shell dumpsys thermalserviceiOS 用 Xcode 的 Energy Log电池消耗速率把这些数据整理成曲线图你就能看到帧率和温度随时间的变化趋势。如果温度在 5 分钟内就冲到 42 度以上那基本可以确定需要锁帧了。5.2 第二步确定锁帧档位并验证根据基线数据选一个目标帧率通常是 30 或 60。然后修改代码重新跑同样的测试对比数据。这里有个细节要注意锁帧后要观察帧生成时间的稳定性不能只看平均帧率。有些项目锁了 30 帧平均帧率确实是 30但帧生成时间忽长忽短玩家感受到的是卡顿。这种情况说明 CPU 或 GPU 有突发负载需要进一步优化光靠锁帧解决不了。我一般会统计帧生成时间的 95 分位值也就是 95% 的帧都在这个时间内完成如果这个值明显超过 33.3ms30 帧的帧预算说明有卡顿帧需要排查。5.3 第三步加入动态调整和玩家选项固定锁帧验证有效后可以进一步做成动态的并且给玩家留一个选项。设置界面里加一个帧率模式选项提供省电30帧、均衡45帧、流畅60帧三档让玩家根据自己的设备和偏好选。这样做的好处是既照顾了低端机用户又不会让高端机用户觉得被限制了。而且玩家自己选的即使发热了也不会怪游戏心理接受度更高。代码上把 targetFrameRate 的赋值跟设置项绑定玩家切换时实时生效。同时保留动态调整逻辑作为兜底当检测到设备过热时即使玩家选了 60 帧也临时降到 30 帧并在界面上给出提示。5.4 第四步上线后的监控与迭代锁帧不是设完就完事了。上线后要通过埋点收集玩家的实际帧率和设备温度数据如果平台允许看看不同机型的表现是否符合预期。如果发现某些机型锁帧后依然发热严重可能需要针对这些机型做特殊处理比如进一步降到 24 帧或者关闭某些特效。我踩过的一个坑是测试阶段用的都是主流机型表现很好上线后发现某几个小众机型锁帧完全无效原因是这些机型的系统层面对帧率做了强制管理。后来针对这些机型加了白名单单独处理才解决问题。所以上线后的数据监控比测试阶段更重要因为真实用户设备的多样性远超你的测试覆盖。6. 常见问题与排查技巧实录6.1 锁帧不生效的几种原因这是被问得最多的问题。锁帧代码写了但帧率还是原来的样子通常有这几个原因现象可能原因排查方法帧率完全没变vSyncCount 不为 0检查 QualitySettings.vSyncCount设为 0帧率是目标值的整数倍垂直同步在起作用同上或改用 vSyncCount 控制部分场景生效部分不生效场景切换重置了设置用 DontDestroyOnLoad 保持设置编辑器里生效真机不生效平台差异真机测试检查系统帧率管理锁 30 但实际跑 60系统强制高刷检查设备刷新率设置考虑用 vSyncCount排查时建议按这个顺序先确认 vSyncCount 是否为 0再确认 targetFrameRate 是否被正确赋值然后确认设置是否在场景切换后丢失最后确认设备系统层面是否有干预。6.2 锁帧后动画变卡怎么办锁 30 帧后有些动画看起来一顿一顿的尤其是 UI 动画和相机移动。这不是锁帧的错而是动画更新频率跟帧率绑定导致的。解决办法是让动画更新跟帧率解耦。Unity 的 Animator 默认是按帧更新的锁帧后动画采样频率降低自然就卡。可以在 Animator 组件上把Update Mode改成Animate Physics或者用Unscaled Time让动画按固定时间步长更新。UI 动画则可以用 DOTween 这类补间库它们内部用的是时间插值跟帧率无关锁帧后依然平滑。相机移动也是同理用Time.deltaTime做插值的移动在锁帧后依然平滑但如果用了固定步长或者跟帧率绑定的逻辑就会卡。检查一下你的移动代码确保所有跟时间相关的计算都乘了Time.deltaTime。6.3 锁帧和 GC 的关系锁帧会降低 GC 的触发频率因为每帧产生的垃圾少了累积到触发阈值的时间变长了。这对发热优化是好事但要注意不要因为锁帧就放松 GC 优化。锁帧只是减少了 GC 次数单次 GC 的耗时并没有变如果单次 GC 时间过长依然会造成卡顿。我见过有项目锁了 30 帧后觉得 GC 不是问题了结果在某些复杂场景下还是出现明显卡顿一查发现是单次 GC 耗时超过 30ms直接吃掉一整帧的预算。所以锁帧和 GC 优化要并行做不能互相替代。6.4 独家避坑技巧汇总最后分享几个我在实际项目中总结的小技巧都是文档里不会写的技巧一在加载场景锁低帧率。加载场景时玩家注意力在进度条上帧率高低无所谓直接锁 15 甚至 10 帧能显著降低加载期间的发热。等进入游戏场景再恢复。技巧二后台时锁 1 帧。游戏切到后台时把 targetFrameRate 设为 1几乎不消耗性能。恢复前台时再设回去。这个对省电和降温效果极好尤其是玩家频繁切后台的场景。技巧三用帧率选项做 A/B 测试。上线时给一部分玩家默认 30 帧一部分默认 60 帧观察留存和付费数据。如果 30 帧组的留存没有明显下降那就大胆推广 30 帧发热问题迎刃而解。技巧四注意 targetFrameRate 的赋值时机。不要在Update里反复赋值虽然开销不大但没必要。在Awake或Start里设一次需要动态调整时再改。技巧五测试时用真机别信编辑器。Unity 编辑器里的帧率表现跟真机差异巨大编辑器里锁帧生效不代表真机生效。所有帧率相关的测试必须在真机上做而且要多机型覆盖。我个人在实际操作中的体会是锁帧这件事最大的价值不在于技术本身而在于它逼着你去思考玩家到底需要多少帧这个问题。很多时候我们默认 60 帧是标配但实际上对大部分游戏来说稳定的 30 帧比波动的 60 帧体验更好。把帧率降下来把稳定性提上去把发热控制住玩家玩得久留存自然就好。这个账值得每个做移动端的人认真算一算。
Unity移动端锁帧优化：降低发热、稳定帧率的实操指南
1. 锁帧这件事为什么值得单独拎出来讲做移动端项目的人大概都有过这种体验游戏逻辑明明不重Draw Call 也压到了两百以内Shader 也没用什么花哨的东西可手机一跑起来背面烫得能煎鸡蛋十分钟后帧率从 60 掉到 40再过一会儿直接卡成 PPT。你去查 ProfilerCPU 和 GPU 的耗时看起来都还行就是温度压不住。这种情况我遇到过太多次了最后发现问题往往不在渲染本身而在于一个很多人压根没在意的东西——帧率上限。这篇是发烫优化系列的第七篇前面几篇聊过 Draw Call 合并、纹理压缩、Shader 简化、GC 控制、物理更新频率、UI 重建这些方向今天专门把锁帧这个手段拿出来单独讲。原因很简单它是所有发热优化手段里改动成本最低、见效最快、副作用最可控的一个。你不需要重构渲染管线不需要换 Shader甚至不需要美术配合只要在代码里加一行Application.targetFrameRate 30很多项目的发热问题就能缓解一大半。但锁帧这件事说简单也简单说坑也真不少。锁多少合适什么时候锁锁了之后动画会不会卡不同平台行为一样吗Unity 的targetFrameRate和QualitySettings.vSyncCount到底谁说了算这些问题如果不想清楚锁帧可能不但没优化发热反而把体验搞得更糟。我见过有项目直接锁 30结果 UI 滑动像幻灯片也见过锁了帧但没关垂直同步实际根本没生效的。所以这篇不打算只给你一个结论而是把锁帧背后的逻辑、参数选择、平台差异、实操步骤和踩坑经验完整地讲一遍。不管你是刚接触 Unity 的新手还是已经做过几个上线项目的老手只要你的项目在移动端有发热困扰这篇内容都能直接拿去用。核心关键词就几个锁帧、帧率、发热、Unity、targetFrameRate围绕它们把这件事讲透。2. 帧率与发热的底层关系拆解2.1 为什么帧率越高手机越烫要理解锁帧为什么能降温得先搞清楚手机发热的来源。手机 SoC 里跟游戏帧率直接相关的主要是 CPU 和 GPU 两大块它们每渲染一帧都要做大量运算CPU 负责逻辑更新、物理模拟、动画计算、提交渲染命令GPU 负责顶点变换、光栅化、像素着色。这些运算本质上都是电流在晶体管里跑来跑去有电流就有功耗有功耗就有热量。关键点在于功耗和运算量基本成正比而运算量和帧率成正比。你跑 60 帧意味着每秒要做 60 次完整的逻辑加渲染循环跑 30 帧运算量直接砍半。功耗降下来发热自然就少了。这不是线性的简单关系因为还有漏电流、电压调节等复杂因素但大方向上帧率减半GPU 负载和 CPU 逻辑负载大致减半整机功耗能降 30% 到 40%。更麻烦的是热积累的恶性循环。手机没有风扇散热全靠被动传导。当 SoC 温度升到某个阈值通常 40 到 45 摄氏度左右系统会主动降频保护硬件这时候帧率会突然掉下来玩家感受到的就是卡顿。而降频之后如果负载还是很高温度继续升降频更狠最后就是持续卡顿加烫手。锁帧的作用就是在源头把负载压下去让温度维持在一个不会触发降频的区间帧率反而更稳定。我做过一个实测对比同一款中度休闲游戏在中端安卓机上跑不锁帧时前 3 分钟稳定 60 帧第 5 分钟开始掉到 50 左右第 10 分钟稳定在 38 到 42 帧波动机身背面最高温度 46 度锁 30 帧后全程稳定 30 帧10 分钟后温度只有 38 度左右手感明显温和很多。帧率数字是低了但体验的一致性反而更好因为不会出现那种忽高忽低的抖动。2.2 帧率、刷新率、垂直同步三者的关系很多人把帧率、刷新率、垂直同步混为一谈这里必须理清楚否则锁帧参数很容易设错。帧率Frame Rate是你的游戏每秒实际渲染出多少帧由你的代码和硬件性能决定。刷新率Refresh Rate是屏幕硬件每秒刷新多少次画面现在手机普遍是 60Hz、90Hz、120Hz 甚至 144Hz。垂直同步VSync是一种同步机制让游戏的帧输出跟屏幕刷新对齐避免画面撕裂。Unity 里控制这三者的关键参数有两个Application.targetFrameRate和QualitySettings.vSyncCount。它们的关系有个很多人不知道的规则当 vSyncCount 不为 0 时targetFrameRate 会被忽略。也就是说如果你在 Quality Settings 里开了垂直同步代码里设的 targetFrameRate 根本不生效实际帧率会被锁定到屏幕刷新率的整数分之一。举个例子屏幕 60HzvSyncCount 设为 1那游戏帧率就被锁在 60vSyncCount 设为 2锁在 30。屏幕如果是 120HzvSyncCount 为 1 时锁 120为 2 时锁 60。这就是为什么有些人设了 targetFrameRate 30 却发现帧率还是 60因为垂直同步把它覆盖了。所以正确的锁帧姿势是先把 vSyncCount 设为 0再设置 targetFrameRate。这样 targetFrameRate 才能真正生效。当然关掉垂直同步可能会带来画面撕裂但在移动端小屏幕上撕裂通常不明显而且发热优化的收益远大于撕裂带来的视觉影响。如果你确实在意撕裂那就用 vSyncCount 来控制帧率但灵活性会差很多因为只能锁到刷新率的整数分之一。2.3 锁帧不等于降画质这是两码事有个常见的误解需要澄清锁帧不是降低画质。画质取决于分辨率、纹理精度、Shader 复杂度、后处理效果这些锁帧只是控制每秒渲染多少次。你完全可以在锁 30 帧的同时保持高画质只是每帧之间的间隔变长了。这带来一个很重要的策略空间当性能预算有限时你可以选择高画质低帧率或者低画质高帧率。对于不同类型的游戏最优解完全不同。休闲益智类、卡牌类、模拟经营类30 帧完全够用把省下来的性能预算堆到画质上画面更精致玩家更买账。而竞技类、动作类、音游类帧率就是生命线宁可降画质也要保 60 帧。我个人的经验是大部分手游其实并不需要 60 帧。玩家对帧率的敏感度远低于开发者想象尤其是非动作类游戏。你锁 30 帧只要帧生成时间稳定没有明显卡顿绝大多数玩家根本察觉不到。反倒是发热导致的降频卡顿玩家一玩就能感觉到。所以锁帧在很多时候是用玩家感知不到的东西换玩家能明显感知到的东西这笔账很划算。3. Unity 中锁帧的具体实现与参数选择3.1 targetFrameRate 的正确设置方式在 Unity 里设置目标帧率最直接的就是这一行Application.targetFrameRate 30;但这一行放在哪里、什么时候调用是有讲究的。我一般会把它放在游戏启动的初始化脚本里比如一个专门的PerformanceManager或者GameBootstrap脚本的Awake方法中。不要放在每帧都执行的Update里那样虽然也能生效但没必要反复设置。一个完整的初始化逻辑大概长这样using UnityEngine; public class PerformanceManager : MonoBehaviour { [SerializeField] private int targetFrameRate 30; [SerializeField] private bool disableVSync true; void Awake() { if (disableVSync) { QualitySettings.vSyncCount 0; } Application.targetFrameRate targetFrameRate; DontDestroyOnLoad(gameObject); } }这里把vSyncCount设为 0 是关键前面讲过不设的话 targetFrameRate 会被忽略。DontDestroyOnLoad保证切换场景时这个设置不会被重置。有些项目在场景切换后会重新初始化 QualitySettings导致锁帧失效加上这个能避免。另外要注意targetFrameRate 的值必须是整数而且不能是负数-1 表示不限制让系统自己决定。设成 0 或者负数在部分平台上行为不一致建议老老实实用正数。3.2 锁 30 还是锁 60怎么选这是最核心的问题。我的判断逻辑分三层第一层看游戏类型。动作、射击、竞速、音游、MOBA 这类对操作响应要求高的优先保 60 帧实在保不住再考虑 45 或者 40。休闲、卡牌、模拟、放置、文字类30 帧足够甚至 24 帧在某些场景下也能接受。第二层看目标机型。如果你的用户主要是中低端机那 60 帧本身就是奢望不如直接锁 30把稳定性做上去。如果是旗舰机用户为主可以尝试 60 帧但要做好温控策略比如温度升高后动态降到 45 或 30。第三层看发热预算。你可以做个简单的测试不锁帧跑 10 分钟记录温度和帧率曲线锁 60 跑 10 分钟记录锁 30 跑 10 分钟记录。对比下来哪个档位能在你设定的温度上限内保持稳定就选哪个。我整理了一个简单的参考表不同游戏类型和机型档位的建议帧率游戏类型低端机中端机高端机动作/射击/竞速306060卡牌/模拟/休闲303030-60放置/文字/棋牌24-303030音游/格斗306060这个表不是绝对的只是给个起点。实际项目里还要结合具体的性能测试来定。3.3 动态锁帧根据温度实时调整固定锁帧有个问题低端机锁 30 可能还是烫高端机锁 30 又浪费了性能。更聪明的做法是动态锁帧根据设备温度或者性能表现实时调整目标帧率。Unity 本身没有直接读取设备温度的跨平台 API但可以通过一些间接方式判断。比如监测一段时间内的平均帧率如果持续低于目标值说明设备在降频这时候可以主动降低 targetFrameRate减少负载让温度回落。等温度降下来再逐步提回去。一个简单的动态调整逻辑using UnityEngine; public class DynamicFrameRate : MonoBehaviour { [SerializeField] private int highFrameRate 60; [SerializeField] private int lowFrameRate 30; [SerializeField] private float checkInterval 5f; [SerializeField] private float lowFpsThreshold 0.85f; private float timer; private int frameCount; private float elapsed; void Start() { QualitySettings.vSyncCount 0; Application.targetFrameRate highFrameRate; } void Update() { frameCount; elapsed Time.unscaledDeltaTime; timer Time.unscaledDeltaTime; if (timer checkInterval) { float avgFps frameCount / elapsed; if (avgFps Application.targetFrameRate * lowFpsThreshold) { Application.targetFrameRate lowFrameRate; } else if (avgFps highFrameRate * 0.95f Application.targetFrameRate ! highFrameRate) { Application.targetFrameRate highFrameRate; } timer 0f; frameCount 0; elapsed 0f; } } }这个逻辑的核心是如果实际帧率明显低于目标说明设备扛不住主动降档如果实际帧率能稳定达到高档位再升回去。这样既能在高性能设备上跑满又能在低性能设备上保稳定。注意动态调整帧率时切换频率不要太快否则玩家会感觉到明显的帧率跳变。我一般设 5 到 10 秒检查一次而且降档要快、升档要慢避免在临界点反复横跳。4. 不同平台的锁帧行为差异4.1 Android 平台的坑Android 是锁帧行为最复杂的平台因为设备碎片化太严重。同样一行targetFrameRate 30在不同厂商、不同系统版本上的表现可能完全不同。最大的坑是部分厂商的系统会强制覆盖应用的帧率设置。比如某些游戏手机有性能模式开启后会强制拉满帧率你的锁帧代码根本不生效。还有些系统在检测到游戏运行时会自动启用高刷新率模式把屏幕刷新率提到 120Hz这时候即使你锁了 30 帧系统层面的调度也可能让功耗下不来。应对办法有几个一是在游戏内提供帧率选项让玩家自己选同时说明低帧率更省电二是通过Application.targetFrameRate配合QualitySettings.vSyncCount 0双管齐下三是在关键场景比如战斗、加载临时调整帧率非关键场景比如主菜单、剧情直接锁低帧率。另外Android 上还有个Screen.currentResolution.refreshRate可以读取当前屏幕刷新率但注意这个值在运行时可能变化不要缓存一次就一直用。4.2 iOS 平台的特性iOS 相对规范很多targetFrameRate的行为比较一致。但 iOS 有个 ProMotion 技术在支持的高端机型上屏幕刷新率可以在 24Hz 到 120Hz 之间自适应。这种情况下如果你设了 targetFrameRate 60系统可能会根据内容自动调整刷新率实际表现跟你想的不完全一样。iOS 上还有个要注意的点低电量模式下系统会主动限制帧率。当用户开启低电量模式系统可能把帧率压到 30 甚至更低这时候你的锁帧设置会被系统覆盖。这个行为是系统级的应用无法改变只能接受。所以做 iOS 优化时要考虑到低电量模式下的表现不要把帧率相关的逻辑写得太死。4.3 PC 和主机平台的差异PC 平台的情况又不一样。PC 上玩家对帧率极其敏感而且硬件性能差异巨大。在 PC 上锁帧更多是为了减少 GPU 满载导致的发热和风扇噪音而不是像手机那样为了温控。很多 PC 玩家会主动开垂直同步或者用驱动层面的帧率限制所以游戏内的锁帧选项要做得灵活最好提供 30、60、120、不限制等多个档位。主机平台相对封闭帧率目标通常由平台方和游戏类型决定锁帧策略比较固定。这里就不展开讲了重点还是放在移动端。5. 锁帧实操从测试到上线的完整流程5.1 第一步建立发热基线测试在动手锁帧之前必须先知道当前项目的发热情况。没有基线你无法判断锁帧到底有没有效果。测试方法我一般这样做选三台代表性设备低端、中端、高端各一台安装一个带性能监控的 Debug 包跑同一个场景或者同一段游戏流程持续 15 到 20 分钟记录以下数据每秒帧率用Time.deltaTime或者1 / Time.unscaledDeltaTime统计CPU 和 GPU 耗时通过 Profiler 或者平台工具设备温度Android 可以用adb shell dumpsys thermalserviceiOS 用 Xcode 的 Energy Log电池消耗速率把这些数据整理成曲线图你就能看到帧率和温度随时间的变化趋势。如果温度在 5 分钟内就冲到 42 度以上那基本可以确定需要锁帧了。5.2 第二步确定锁帧档位并验证根据基线数据选一个目标帧率通常是 30 或 60。然后修改代码重新跑同样的测试对比数据。这里有个细节要注意锁帧后要观察帧生成时间的稳定性不能只看平均帧率。有些项目锁了 30 帧平均帧率确实是 30但帧生成时间忽长忽短玩家感受到的是卡顿。这种情况说明 CPU 或 GPU 有突发负载需要进一步优化光靠锁帧解决不了。我一般会统计帧生成时间的 95 分位值也就是 95% 的帧都在这个时间内完成如果这个值明显超过 33.3ms30 帧的帧预算说明有卡顿帧需要排查。5.3 第三步加入动态调整和玩家选项固定锁帧验证有效后可以进一步做成动态的并且给玩家留一个选项。设置界面里加一个帧率模式选项提供省电30帧、均衡45帧、流畅60帧三档让玩家根据自己的设备和偏好选。这样做的好处是既照顾了低端机用户又不会让高端机用户觉得被限制了。而且玩家自己选的即使发热了也不会怪游戏心理接受度更高。代码上把 targetFrameRate 的赋值跟设置项绑定玩家切换时实时生效。同时保留动态调整逻辑作为兜底当检测到设备过热时即使玩家选了 60 帧也临时降到 30 帧并在界面上给出提示。5.4 第四步上线后的监控与迭代锁帧不是设完就完事了。上线后要通过埋点收集玩家的实际帧率和设备温度数据如果平台允许看看不同机型的表现是否符合预期。如果发现某些机型锁帧后依然发热严重可能需要针对这些机型做特殊处理比如进一步降到 24 帧或者关闭某些特效。我踩过的一个坑是测试阶段用的都是主流机型表现很好上线后发现某几个小众机型锁帧完全无效原因是这些机型的系统层面对帧率做了强制管理。后来针对这些机型加了白名单单独处理才解决问题。所以上线后的数据监控比测试阶段更重要因为真实用户设备的多样性远超你的测试覆盖。6. 常见问题与排查技巧实录6.1 锁帧不生效的几种原因这是被问得最多的问题。锁帧代码写了但帧率还是原来的样子通常有这几个原因现象可能原因排查方法帧率完全没变vSyncCount 不为 0检查 QualitySettings.vSyncCount设为 0帧率是目标值的整数倍垂直同步在起作用同上或改用 vSyncCount 控制部分场景生效部分不生效场景切换重置了设置用 DontDestroyOnLoad 保持设置编辑器里生效真机不生效平台差异真机测试检查系统帧率管理锁 30 但实际跑 60系统强制高刷检查设备刷新率设置考虑用 vSyncCount排查时建议按这个顺序先确认 vSyncCount 是否为 0再确认 targetFrameRate 是否被正确赋值然后确认设置是否在场景切换后丢失最后确认设备系统层面是否有干预。6.2 锁帧后动画变卡怎么办锁 30 帧后有些动画看起来一顿一顿的尤其是 UI 动画和相机移动。这不是锁帧的错而是动画更新频率跟帧率绑定导致的。解决办法是让动画更新跟帧率解耦。Unity 的 Animator 默认是按帧更新的锁帧后动画采样频率降低自然就卡。可以在 Animator 组件上把Update Mode改成Animate Physics或者用Unscaled Time让动画按固定时间步长更新。UI 动画则可以用 DOTween 这类补间库它们内部用的是时间插值跟帧率无关锁帧后依然平滑。相机移动也是同理用Time.deltaTime做插值的移动在锁帧后依然平滑但如果用了固定步长或者跟帧率绑定的逻辑就会卡。检查一下你的移动代码确保所有跟时间相关的计算都乘了Time.deltaTime。6.3 锁帧和 GC 的关系锁帧会降低 GC 的触发频率因为每帧产生的垃圾少了累积到触发阈值的时间变长了。这对发热优化是好事但要注意不要因为锁帧就放松 GC 优化。锁帧只是减少了 GC 次数单次 GC 的耗时并没有变如果单次 GC 时间过长依然会造成卡顿。我见过有项目锁了 30 帧后觉得 GC 不是问题了结果在某些复杂场景下还是出现明显卡顿一查发现是单次 GC 耗时超过 30ms直接吃掉一整帧的预算。所以锁帧和 GC 优化要并行做不能互相替代。6.4 独家避坑技巧汇总最后分享几个我在实际项目中总结的小技巧都是文档里不会写的技巧一在加载场景锁低帧率。加载场景时玩家注意力在进度条上帧率高低无所谓直接锁 15 甚至 10 帧能显著降低加载期间的发热。等进入游戏场景再恢复。技巧二后台时锁 1 帧。游戏切到后台时把 targetFrameRate 设为 1几乎不消耗性能。恢复前台时再设回去。这个对省电和降温效果极好尤其是玩家频繁切后台的场景。技巧三用帧率选项做 A/B 测试。上线时给一部分玩家默认 30 帧一部分默认 60 帧观察留存和付费数据。如果 30 帧组的留存没有明显下降那就大胆推广 30 帧发热问题迎刃而解。技巧四注意 targetFrameRate 的赋值时机。不要在Update里反复赋值虽然开销不大但没必要。在Awake或Start里设一次需要动态调整时再改。技巧五测试时用真机别信编辑器。Unity 编辑器里的帧率表现跟真机差异巨大编辑器里锁帧生效不代表真机生效。所有帧率相关的测试必须在真机上做而且要多机型覆盖。我个人在实际操作中的体会是锁帧这件事最大的价值不在于技术本身而在于它逼着你去思考玩家到底需要多少帧这个问题。很多时候我们默认 60 帧是标配但实际上对大部分游戏来说稳定的 30 帧比波动的 60 帧体验更好。把帧率降下来把稳定性提上去把发热控制住玩家玩得久留存自然就好。这个账值得每个做移动端的人认真算一算。