1. 鎖幀這件事為什么值得單獨拎出來講做移動端項目的人大概都有過這種體驗游戲邏輯明明不重Draw Call 也壓到了兩百以內(nèi)Shader 也沒用什么花哨的東西可手機一跑起來背面燙得能煎雞蛋十分鐘后幀率從 60 掉到 40再過一會兒直接卡成 PPT。你去查 ProfilerCPU 和 GPU 的耗時看起來都還行就是溫度壓不住。這種情況我遇到過太多次了最后發(fā)現(xiàn)問題往往不在渲染本身而在于一個很多人壓根沒在意的東西——幀率上限。這篇是發(fā)燙優(yōu)化系列的第七篇前面幾篇聊過 Draw Call 合并、紋理壓縮、Shader 簡化、GC 控制、物理更新頻率、UI 重建這些方向今天專門把鎖幀這個手段拿出來單獨講。原因很簡單它是所有發(fā)熱優(yōu)化手段里改動成本最低、見效最快、副作用最可控的一個。你不需要重構(gòu)渲染管線不需要換 Shader甚至不需要美術(shù)配合只要在代碼里加一行Application.targetFrameRate 30很多項目的發(fā)熱問題就能緩解一大半。但鎖幀這件事說簡單也簡單說坑也真不少。鎖多少合適什么時候鎖鎖了之后動畫會不會卡不同平臺行為一樣嗎Unity 的targetFrameRate和QualitySettings.vSyncCount到底誰說了算這些問題如果不想清楚鎖幀可能不但沒優(yōu)化發(fā)熱反而把體驗搞得更糟。我見過有項目直接鎖 30結(jié)果 UI 滑動像幻燈片也見過鎖了幀但沒關(guān)垂直同步實際根本沒生效的。所以這篇不打算只給你一個結(jié)論而是把鎖幀背后的邏輯、參數(shù)選擇、平臺差異、實操步驟和踩坑經(jīng)驗完整地講一遍。不管你是剛接觸 Unity 的新手還是已經(jīng)做過幾個上線項目的老手只要你的項目在移動端有發(fā)熱困擾這篇內(nèi)容都能直接拿去用。核心關(guān)鍵詞就幾個鎖幀、幀率、發(fā)熱、Unity、targetFrameRate圍繞它們把這件事講透。2. 幀率與發(fā)熱的底層關(guān)系拆解2.1 為什么幀率越高手機越燙要理解鎖幀為什么能降溫得先搞清楚手機發(fā)熱的來源。手機 SoC 里跟游戲幀率直接相關(guān)的主要是 CPU 和 GPU 兩大塊它們每渲染一幀都要做大量運算CPU 負責邏輯更新、物理模擬、動畫計算、提交渲染命令GPU 負責頂點變換、光柵化、像素著色。這些運算本質(zhì)上都是電流在晶體管里跑來跑去有電流就有功耗有功耗就有熱量。關(guān)鍵點在于功耗和運算量基本成正比而運算量和幀率成正比。你跑 60 幀意味著每秒要做 60 次完整的邏輯加渲染循環(huán)跑 30 幀運算量直接砍半。功耗降下來發(fā)熱自然就少了。這不是線性的簡單關(guān)系因為還有漏電流、電壓調(diào)節(jié)等復雜因素但大方向上幀率減半GPU 負載和 CPU 邏輯負載大致減半整機功耗能降 30% 到 40%。更麻煩的是熱積累的惡性循環(huán)。手機沒有風扇散熱全靠被動傳導。當 SoC 溫度升到某個閾值通常 40 到 45 攝氏度左右系統(tǒng)會主動降頻保護硬件這時候幀率會突然掉下來玩家感受到的就是卡頓。而降頻之后如果負載還是很高溫度繼續(xù)升降頻更狠最后就是持續(xù)卡頓加燙手。鎖幀的作用就是在源頭把負載壓下去讓溫度維持在一個不會觸發(fā)降頻的區(qū)間幀率反而更穩(wěn)定。我做過一個實測對比同一款中度休閑游戲在中端安卓機上跑不鎖幀時前 3 分鐘穩(wěn)定 60 幀第 5 分鐘開始掉到 50 左右第 10 分鐘穩(wěn)定在 38 到 42 幀波動機身背面最高溫度 46 度鎖 30 幀后全程穩(wěn)定 30 幀10 分鐘后溫度只有 38 度左右手感明顯溫和很多。幀率數(shù)字是低了但體驗的一致性反而更好因為不會出現(xiàn)那種忽高忽低的抖動。2.2 幀率、刷新率、垂直同步三者的關(guān)系很多人把幀率、刷新率、垂直同步混為一談這里必須理清楚否則鎖幀參數(shù)很容易設(shè)錯。幀率Frame Rate是你的游戲每秒實際渲染出多少幀由你的代碼和硬件性能決定。刷新率Refresh Rate是屏幕硬件每秒刷新多少次畫面現(xiàn)在手機普遍是 60Hz、90Hz、120Hz 甚至 144Hz。垂直同步VSync是一種同步機制讓游戲的幀輸出跟屏幕刷新對齊避免畫面撕裂。Unity 里控制這三者的關(guān)鍵參數(shù)有兩個Application.targetFrameRate和QualitySettings.vSyncCount。它們的關(guān)系有個很多人不知道的規(guī)則當 vSyncCount 不為 0 時targetFrameRate 會被忽略。也就是說如果你在 Quality Settings 里開了垂直同步代碼里設(shè)的 targetFrameRate 根本不生效實際幀率會被鎖定到屏幕刷新率的整數(shù)分之一。舉個例子屏幕 60HzvSyncCount 設(shè)為 1那游戲幀率就被鎖在 60vSyncCount 設(shè)為 2鎖在 30。屏幕如果是 120HzvSyncCount 為 1 時鎖 120為 2 時鎖 60。這就是為什么有些人設(shè)了 targetFrameRate 30 卻發(fā)現(xiàn)幀率還是 60因為垂直同步把它覆蓋了。所以正確的鎖幀姿勢是先把 vSyncCount 設(shè)為 0再設(shè)置 targetFrameRate。這樣 targetFrameRate 才能真正生效。當然關(guān)掉垂直同步可能會帶來畫面撕裂但在移動端小屏幕上撕裂通常不明顯而且發(fā)熱優(yōu)化的收益遠大于撕裂帶來的視覺影響。如果你確實在意撕裂那就用 vSyncCount 來控制幀率但靈活性會差很多因為只能鎖到刷新率的整數(shù)分之一。2.3 鎖幀不等于降畫質(zhì)這是兩碼事有個常見的誤解需要澄清鎖幀不是降低畫質(zhì)。畫質(zhì)取決于分辨率、紋理精度、Shader 復雜度、后處理效果這些鎖幀只是控制每秒渲染多少次。你完全可以在鎖 30 幀的同時保持高畫質(zhì)只是每幀之間的間隔變長了。這帶來一個很重要的策略空間當性能預算有限時你可以選擇高畫質(zhì)低幀率或者低畫質(zhì)高幀率。對于不同類型的游戲最優(yōu)解完全不同。休閑益智類、卡牌類、模擬經(jīng)營類30 幀完全夠用把省下來的性能預算堆到畫質(zhì)上畫面更精致玩家更買賬。而競技類、動作類、音游類幀率就是生命線寧可降畫質(zhì)也要保 60 幀。我個人的經(jīng)驗是大部分手游其實并不需要 60 幀。玩家對幀率的敏感度遠低于開發(fā)者想象尤其是非動作類游戲。你鎖 30 幀只要幀生成時間穩(wěn)定沒有明顯卡頓絕大多數(shù)玩家根本察覺不到。反倒是發(fā)熱導致的降頻卡頓玩家一玩就能感覺到。所以鎖幀在很多時候是用玩家感知不到的東西換玩家能明顯感知到的東西這筆賬很劃算。3. Unity 中鎖幀的具體實現(xiàn)與參數(shù)選擇3.1 targetFrameRate 的正確設(shè)置方式在 Unity 里設(shè)置目標幀率最直接的就是這一行Application.targetFrameRate 30;但這一行放在哪里、什么時候調(diào)用是有講究的。我一般會把它放在游戲啟動的初始化腳本里比如一個專門的PerformanceManager或者GameBootstrap腳本的Awake方法中。不要放在每幀都執(zhí)行的Update里那樣雖然也能生效但沒必要反復設(shè)置。一個完整的初始化邏輯大概長這樣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設(shè)為 0 是關(guān)鍵前面講過不設(shè)的話 targetFrameRate 會被忽略。DontDestroyOnLoad保證切換場景時這個設(shè)置不會被重置。有些項目在場景切換后會重新初始化 QualitySettings導致鎖幀失效加上這個能避免。另外要注意targetFrameRate 的值必須是整數(shù)而且不能是負數(shù)-1 表示不限制讓系統(tǒng)自己決定。設(shè)成 0 或者負數(shù)在部分平臺上行為不一致建議老老實實用正數(shù)。3.2 鎖 30 還是鎖 60怎么選這是最核心的問題。我的判斷邏輯分三層第一層看游戲類型。動作、射擊、競速、音游、MOBA 這類對操作響應要求高的優(yōu)先保 60 幀實在保不住再考慮 45 或者 40。休閑、卡牌、模擬、放置、文字類30 幀足夠甚至 24 幀在某些場景下也能接受。第二層看目標機型。如果你的用戶主要是中低端機那 60 幀本身就是奢望不如直接鎖 30把穩(wěn)定性做上去。如果是旗艦機用戶為主可以嘗試 60 幀但要做好溫控策略比如溫度升高后動態(tài)降到 45 或 30。第三層看發(fā)熱預算。你可以做個簡單的測試不鎖幀跑 10 分鐘記錄溫度和幀率曲線鎖 60 跑 10 分鐘記錄鎖 30 跑 10 分鐘記錄。對比下來哪個檔位能在你設(shè)定的溫度上限內(nèi)保持穩(wěn)定就選哪個。我整理了一個簡單的參考表不同游戲類型和機型檔位的建議幀率游戲類型低端機中端機高端機動作/射擊/競速306060卡牌/模擬/休閑303030-60放置/文字/棋牌24-303030音游/格斗306060這個表不是絕對的只是給個起點。實際項目里還要結(jié)合具體的性能測試來定。3.3 動態(tài)鎖幀根據(jù)溫度實時調(diào)整固定鎖幀有個問題低端機鎖 30 可能還是燙高端機鎖 30 又浪費了性能。更聰明的做法是動態(tài)鎖幀根據(jù)設(shè)備溫度或者性能表現(xiàn)實時調(diào)整目標幀率。Unity 本身沒有直接讀取設(shè)備溫度的跨平臺 API但可以通過一些間接方式判斷。比如監(jiān)測一段時間內(nèi)的平均幀率如果持續(xù)低于目標值說明設(shè)備在降頻這時候可以主動降低 targetFrameRate減少負載讓溫度回落。等溫度降下來再逐步提回去。一個簡單的動態(tài)調(diào)整邏輯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; } } }這個邏輯的核心是如果實際幀率明顯低于目標說明設(shè)備扛不住主動降檔如果實際幀率能穩(wěn)定達到高檔位再升回去。這樣既能在高性能設(shè)備上跑滿又能在低性能設(shè)備上保穩(wěn)定。注意動態(tài)調(diào)整幀率時切換頻率不要太快否則玩家會感覺到明顯的幀率跳變。我一般設(shè) 5 到 10 秒檢查一次而且降檔要快、升檔要慢避免在臨界點反復橫跳。4. 不同平臺的鎖幀行為差異4.1 Android 平臺的坑Android 是鎖幀行為最復雜的平臺因為設(shè)備碎片化太嚴重。同樣一行targetFrameRate 30在不同廠商、不同系統(tǒng)版本上的表現(xiàn)可能完全不同。最大的坑是部分廠商的系統(tǒng)會強制覆蓋應用的幀率設(shè)置。比如某些游戲手機有性能模式開啟后會強制拉滿幀率你的鎖幀代碼根本不生效。還有些系統(tǒng)在檢測到游戲運行時會自動啟用高刷新率模式把屏幕刷新率提到 120Hz這時候即使你鎖了 30 幀系統(tǒng)層面的調(diào)度也可能讓功耗下不來。應對辦法有幾個一是在游戲內(nèi)提供幀率選項讓玩家自己選同時說明低幀率更省電二是通過Application.targetFrameRate配合QualitySettings.vSyncCount 0雙管齊下三是在關(guān)鍵場景比如戰(zhàn)斗、加載臨時調(diào)整幀率非關(guān)鍵場景比如主菜單、劇情直接鎖低幀率。另外Android 上還有個Screen.currentResolution.refreshRate可以讀取當前屏幕刷新率但注意這個值在運行時可能變化不要緩存一次就一直用。4.2 iOS 平臺的特性iOS 相對規(guī)范很多targetFrameRate的行為比較一致。但 iOS 有個 ProMotion 技術(shù)在支持的高端機型上屏幕刷新率可以在 24Hz 到 120Hz 之間自適應。這種情況下如果你設(shè)了 targetFrameRate 60系統(tǒng)可能會根據(jù)內(nèi)容自動調(diào)整刷新率實際表現(xiàn)跟你想的不完全一樣。iOS 上還有個要注意的點低電量模式下系統(tǒng)會主動限制幀率。當用戶開啟低電量模式系統(tǒng)可能把幀率壓到 30 甚至更低這時候你的鎖幀設(shè)置會被系統(tǒng)覆蓋。這個行為是系統(tǒng)級的應用無法改變只能接受。所以做 iOS 優(yōu)化時要考慮到低電量模式下的表現(xiàn)不要把幀率相關(guān)的邏輯寫得太死。4.3 PC 和主機平臺的差異PC 平臺的情況又不一樣。PC 上玩家對幀率極其敏感而且硬件性能差異巨大。在 PC 上鎖幀更多是為了減少 GPU 滿載導致的發(fā)熱和風扇噪音而不是像手機那樣為了溫控。很多 PC 玩家會主動開垂直同步或者用驅(qū)動層面的幀率限制所以游戲內(nèi)的鎖幀選項要做得靈活最好提供 30、60、120、不限制等多個檔位。主機平臺相對封閉幀率目標通常由平臺方和游戲類型決定鎖幀策略比較固定。這里就不展開講了重點還是放在移動端。5. 鎖幀實操從測試到上線的完整流程5.1 第一步建立發(fā)熱基線測試在動手鎖幀之前必須先知道當前項目的發(fā)熱情況。沒有基線你無法判斷鎖幀到底有沒有效果。測試方法我一般這樣做選三臺代表性設(shè)備低端、中端、高端各一臺安裝一個帶性能監(jiān)控的 Debug 包跑同一個場景或者同一段游戲流程持續(xù) 15 到 20 分鐘記錄以下數(shù)據(jù)每秒幀率用Time.deltaTime或者1 / Time.unscaledDeltaTime統(tǒng)計CPU 和 GPU 耗時通過 Profiler 或者平臺工具設(shè)備溫度Android 可以用adb shell dumpsys thermalserviceiOS 用 Xcode 的 Energy Log電池消耗速率把這些數(shù)據(jù)整理成曲線圖你就能看到幀率和溫度隨時間的變化趨勢。如果溫度在 5 分鐘內(nèi)就沖到 42 度以上那基本可以確定需要鎖幀了。5.2 第二步確定鎖幀檔位并驗證根據(jù)基線數(shù)據(jù)選一個目標幀率通常是 30 或 60。然后修改代碼重新跑同樣的測試對比數(shù)據(jù)。這里有個細節(jié)要注意鎖幀后要觀察幀生成時間的穩(wěn)定性不能只看平均幀率。有些項目鎖了 30 幀平均幀率確實是 30但幀生成時間忽長忽短玩家感受到的是卡頓。這種情況說明 CPU 或 GPU 有突發(fā)負載需要進一步優(yōu)化光靠鎖幀解決不了。我一般會統(tǒng)計幀生成時間的 95 分位值也就是 95% 的幀都在這個時間內(nèi)完成如果這個值明顯超過 33.3ms30 幀的幀預算說明有卡頓幀需要排查。5.3 第三步加入動態(tài)調(diào)整和玩家選項固定鎖幀驗證有效后可以進一步做成動態(tài)的并且給玩家留一個選項。設(shè)置界面里加一個幀率模式選項提供省電30幀、均衡45幀、流暢60幀三檔讓玩家根據(jù)自己的設(shè)備和偏好選。這樣做的好處是既照顧了低端機用戶又不會讓高端機用戶覺得被限制了。而且玩家自己選的即使發(fā)熱了也不會怪游戲心理接受度更高。代碼上把 targetFrameRate 的賦值跟設(shè)置項綁定玩家切換時實時生效。同時保留動態(tài)調(diào)整邏輯作為兜底當檢測到設(shè)備過熱時即使玩家選了 60 幀也臨時降到 30 幀并在界面上給出提示。5.4 第四步上線后的監(jiān)控與迭代鎖幀不是設(shè)完就完事了。上線后要通過埋點收集玩家的實際幀率和設(shè)備溫度數(shù)據(jù)如果平臺允許看看不同機型的表現(xiàn)是否符合預期。如果發(fā)現(xiàn)某些機型鎖幀后依然發(fā)熱嚴重可能需要針對這些機型做特殊處理比如進一步降到 24 幀或者關(guān)閉某些特效。我踩過的一個坑是測試階段用的都是主流機型表現(xiàn)很好上線后發(fā)現(xiàn)某幾個小眾機型鎖幀完全無效原因是這些機型的系統(tǒng)層面對幀率做了強制管理。后來針對這些機型加了白名單單獨處理才解決問題。所以上線后的數(shù)據(jù)監(jiān)控比測試階段更重要因為真實用戶設(shè)備的多樣性遠超你的測試覆蓋。6. 常見問題與排查技巧實錄6.1 鎖幀不生效的幾種原因這是被問得最多的問題。鎖幀代碼寫了但幀率還是原來的樣子通常有這幾個原因現(xiàn)象可能原因排查方法幀率完全沒變vSyncCount 不為 0檢查 QualitySettings.vSyncCount設(shè)為 0幀率是目標值的整數(shù)倍垂直同步在起作用同上或改用 vSyncCount 控制部分場景生效部分不生效場景切換重置了設(shè)置用 DontDestroyOnLoad 保持設(shè)置編輯器里生效真機不生效平臺差異真機測試檢查系統(tǒng)幀率管理鎖 30 但實際跑 60系統(tǒng)強制高刷檢查設(shè)備刷新率設(shè)置考慮用 vSyncCount排查時建議按這個順序先確認 vSyncCount 是否為 0再確認 targetFrameRate 是否被正確賦值然后確認設(shè)置是否在場景切換后丟失最后確認設(shè)備系統(tǒng)層面是否有干預。6.2 鎖幀后動畫變卡怎么辦鎖 30 幀后有些動畫看起來一頓一頓的尤其是 UI 動畫和相機移動。這不是鎖幀的錯而是動畫更新頻率跟幀率綁定導致的。解決辦法是讓動畫更新跟幀率解耦。Unity 的 Animator 默認是按幀更新的鎖幀后動畫采樣頻率降低自然就卡?？梢栽?Animator 組件上把Update Mode改成Animate Physics或者用Unscaled Time讓動畫按固定時間步長更新。UI 動畫則可以用 DOTween 這類補間庫它們內(nèi)部用的是時間插值跟幀率無關(guān)鎖幀后依然平滑。相機移動也是同理用Time.deltaTime做插值的移動在鎖幀后依然平滑但如果用了固定步長或者跟幀率綁定的邏輯就會卡。檢查一下你的移動代碼確保所有跟時間相關(guān)的計算都乘了Time.deltaTime。6.3 鎖幀和 GC 的關(guān)系鎖幀會降低 GC 的觸發(fā)頻率因為每幀產(chǎn)生的垃圾少了累積到觸發(fā)閾值的時間變長了。這對發(fā)熱優(yōu)化是好事但要注意不要因為鎖幀就放松 GC 優(yōu)化。鎖幀只是減少了 GC 次數(shù)單次 GC 的耗時并沒有變?nèi)绻麊未?GC 時間過長依然會造成卡頓。我見過有項目鎖了 30 幀后覺得 GC 不是問題了結(jié)果在某些復雜場景下還是出現(xiàn)明顯卡頓一查發(fā)現(xiàn)是單次 GC 耗時超過 30ms直接吃掉一整幀的預算。所以鎖幀和 GC 優(yōu)化要并行做不能互相替代。6.4 獨家避坑技巧匯總最后分享幾個我在實際項目中總結(jié)的小技巧都是文檔里不會寫的技巧一在加載場景鎖低幀率。加載場景時玩家注意力在進度條上幀率高低無所謂直接鎖 15 甚至 10 幀能顯著降低加載期間的發(fā)熱。等進入游戲場景再恢復。技巧二后臺時鎖 1 幀。游戲切到后臺時把 targetFrameRate 設(shè)為 1幾乎不消耗性能?；謴颓芭_時再設(shè)回去。這個對省電和降溫效果極好尤其是玩家頻繁切后臺的場景。技巧三用幀率選項做 A/B 測試。上線時給一部分玩家默認 30 幀一部分默認 60 幀觀察留存和付費數(shù)據(jù)。如果 30 幀組的留存沒有明顯下降那就大膽推廣 30 幀發(fā)熱問題迎刃而解。技巧四注意 targetFrameRate 的賦值時機。不要在Update里反復賦值雖然開銷不大但沒必要。在Awake或Start里設(shè)一次需要動態(tài)調(diào)整時再改。技巧五測試時用真機別信編輯器。Unity 編輯器里的幀率表現(xiàn)跟真機差異巨大編輯器里鎖幀生效不代表真機生效。所有幀率相關(guān)的測試必須在真機上做而且要多機型覆蓋。我個人在實際操作中的體會是鎖幀這件事最大的價值不在于技術(shù)本身而在于它逼著你去思考玩家到底需要多少幀這個問題。很多時候我們默認 60 幀是標配但實際上對大部分游戲來說穩(wěn)定的 30 幀比波動的 60 幀體驗更好。把幀率降下來把穩(wěn)定性提上去把發(fā)熱控制住玩家玩得久留存自然就好。這個賬值得每個做移動端的人認真算一算。