1. 控制臺命令的本質(zhì)一套跑在運行時的調(diào)試總線做 UE4 項目時間長了你會發(fā)現(xiàn)一個規(guī)律凡是能在編輯器里點出來的東西背后幾乎都對應著一條控制臺命令。它不是某個插件附帶的小工具而是引擎在運行時給自己留的一整套調(diào)試總線負責把外部的字符串指令翻譯成對引擎內(nèi)部狀態(tài)的讀寫。會用它的人和不會用的人排查同一個 Bug 的時間差可能是十倍。我把這套東西理解成三個層次最外面是執(zhí)行入口在哪敲中間是命令解析與分發(fā)誰來處理最里面是實際生效的變量或函數(shù)改了什么。很多同行卡在命令敲了沒反應本質(zhì)上是沒搞清楚這三層里哪一層斷掉了。比如在 Shipping 包上敲stat fps沒反應問題不在命令本身而在于控制臺這一層被裁剪掉了。這篇文章我就按這三個層次往下拆順帶把大家問得最多的兩個問題——外接設(shè)備映射怎么調(diào)、查詢和物理模擬到底差在哪——一起講透。先給個整體印象UE4 的控制臺命令大致分兩類。一類是控制臺變量業(yè)內(nèi)習慣叫 CVar本質(zhì)是引擎里注冊過的一個有名字、有類型、有默認值的全局變量r.ScreenPercentage、p.EnableAsyncScene、t.MaxFPS都屬于這一類。另一類是執(zhí)行命令它對應一次函數(shù)調(diào)用比如open切關(guān)卡、Slomo改時間膨脹、obj gc強制垃圾回收。這兩類的調(diào)用方式完全一樣但一個改狀態(tài)、一個做動作理解這個區(qū)別對后面排查問題很關(guān)鍵。1.1 從 ShowFlags 和 CVar 聊起ShowFlag系列是很多人接觸 UE4 控制臺命令的起點因為它直觀——敲ShowFlag.Collision 1屏幕上立刻出現(xiàn)綠色的碰撞體線框。但這里有個容易搞混的點ShowFlag.Collision并不等同于大家常說的Show Collision。前者是直接操作渲染層的顯示標記位ShowFlags 位掩碼后者是引擎提供的一個語法糖式的命令內(nèi)部會轉(zhuǎn)發(fā)到對應的 ShowFlag 上同時也可能會做一些額外的處理。我自己的用法是ShowFlag.前綴適合做批量、精確的控制尤其是腳本化的時候因為它的語法非常規(guī)整ShowFlag.名字 0/1寫進配置文件或者啟動參數(shù)里不會有歧義。而Show前綴適合手敲因為短、好記敲起來順手。兩者不是替代關(guān)系是場景不同。CVar 這邊要注意的是作用域和生命周期。CVar 不是永久生效的它分幾個層級代碼里IConsoleManager::Get().RegisterConsoleVariable()注冊時給的默認值是最底層的然后DefaultEngine.ini里的[SystemSettings]段會覆蓋它再往上運行時手敲的命令又覆蓋配置。所以當你發(fā)現(xiàn)我在 ini 里改了卻沒生效十有八九是別的地方又把它改回去了或者你改的那個 CVar 在運行時被游戲邏輯每幀重設(shè)。注意不要盲目相信ini 里寫了一定生效。有些 CVar 帶有ECVF_SetByCode之類的標志位代碼里的設(shè)定優(yōu)先級高于配置文件這種情況下只能從代碼層面改。再說類型。CVar 支持的有 bool、int、float、字符串還有一類特殊的可執(zhí)行型 CVar表現(xiàn)形式像變量但實際是命令助手比如stat本身就是這類。類型不對會靜默失敗——比如你給一個 bool 型的變量傳2它可能會當true處理也可能直接拒絕行為取決于版本和標志位。我踩過一次坑給某個 float 變量寫了個帶空格的表達式結(jié)果整個命令被截斷改成了另一個變量的值排查了半小時才發(fā)現(xiàn)是解析問題。1.2 三種調(diào)用入口與各自的適用場景第一個入口是運行時控制臺輸入框默認按反引號鍵 或 ~取決于鍵盤布局喚出。在 PIE編輯器內(nèi)運行和 Development 構(gòu)建里都可用最靈活可以隨時改隨時看。缺點是沒法復現(xiàn)你的操作不會留下痕跡第二天想再驗一遍得憑記憶。第二個入口是啟動參數(shù)用-ExecCmds命令1, 命令2的形式在啟動時就執(zhí)行一批命令。這個特別適合做預設(shè)調(diào)試環(huán)境比如跑性能測試時固定好 FPS 上限、固定好分辨率縮放、固定好 LOD 強制等級保證每次測量的起點一致。我一般會給一個專用的性能測試快捷方式來掛這串參數(shù)避免每次手敲導致變量不一致。第三個入口是代碼里調(diào)用C 用GEngine-Exec(GetWorld(), TEXT(命令))藍圖用Execute Console Command節(jié)點。這條路子適合做游戲內(nèi)的調(diào)試面板或者做自動化測試——把一系列命令按順序執(zhí)行然后把stat的結(jié)果抓出來比對就能做成一套回歸檢測。這三個入口走的是同一條分發(fā)鏈路但權(quán)限不同。啟動參數(shù)在最早階段執(zhí)行那時候很多東西還沒初始化所以有些命令此時執(zhí)行會無效或者被后續(xù)初始化覆蓋掉。這點在做啟動就固定畫質(zhì)的時候經(jīng)常遇到后面第 4 章會詳細說怎么處理。1.3 命令解析鏈路為什么有的命令在有的地方不響應引擎處理一條命令字符串的流程大致是控制臺輸入框把字符串交給UGameEngine或UEditorEngine的Exec逐層往下傳最后落到ULocalPlayer::Exec再轉(zhuǎn)發(fā)給當前PlayerController然后是它關(guān)聯(lián)的 Pawn 和 HUD。這個鏈路意味著兩件事。第一必須存在一個有效的 LocalPlayer 和 PlayerController命令才可能被處理到后半段。在關(guān)卡加載過程中、在無縫切換的過渡幀里敲命令很可能就沒反應。第二UFUNCTION(Exec)標記的自定義函數(shù)只有掛在鏈路會遍歷到的那幾個類上才生效。我見過同事把 Exec 函數(shù)寫在了一個普通的 Actor 上然后疑惑為什么敲了沒反應——它確實不會響應因為引擎不會遍歷世界里所有 Actor 去找這個函數(shù)。理解了鏈路排查就有了方向命令沒反應先確認有沒有 LocalPlayer再確認這個命令要求的上下文是不是滿足最后才懷疑命令拼寫。順序反過來會浪費大量時間。2. 命令命名體系拆解前綴就是一張分類地圖UE4 的命令數(shù)量在幾千條量級沒人能全背下來。但它的命名遵循一套相當一致的約定記住前綴就相當于記住了索引目錄。這套約定不是強制的所以偶爾會有漏網(wǎng)之魚用錯前綴但九成以上都遵守。2.1 常見前綴速查與含義把下面這張表記住你查命令的效率會有質(zhì)的變化。前綴歸屬領(lǐng)域典型命令什么時候用它r.渲染r.ScreenPercentage、r.ShadowQuality畫面表現(xiàn)、幀率、畫質(zhì)分級p.物理p.EnableAsyncScene、p.VisualizeMovement物理開銷、角色移動、碰撞調(diào)試a.動畫a.URO.Enable、a.URO.ForceAnimRate骨骼動畫開銷、更新頻率t.引擎/時序t.MaxFPS、t.HDR幀率上限、引擎級開關(guān)fx.特效舊版粒子系統(tǒng)相關(guān)老項目里還能見到新項目基本被 Niagara 取代ai.AI 邏輯AI 調(diào)試輸出行為樹、感知系統(tǒng)nav.導航導航網(wǎng)格相關(guān)尋路異常、導航網(wǎng)格重生成net.網(wǎng)絡網(wǎng)絡驅(qū)動配置聯(lián)機同步、帶寬與包處理gc.垃圾回收gc.CollectGarbageEveryFrame內(nèi)存抖動、卡頓定位slate.UI 框架Slate 渲染調(diào)試UMG 性能、界面重繪stat統(tǒng)計面板stat unit、stat rhi性能分析的核心入口Show/ShowFlag調(diào)試可視化Show Collision、ShowFlag.Bounds看碰撞、包圍盒、導航、骨架表格里最容易混淆的是stat和ShowFlag的關(guān)系。前者回答花了多少時間后者回答畫了什么東西。做性能排查時這兩個要配合用先用stat找到時間花在哪一階段再用對應的ShowFlag看看這一階段到底在渲染什么。還有一類命令沒有前綴是動詞型的比如open、Pause、Slomo、RestartLevel、Teleport、Fly、Ghost、Walk、Reload、Kill。這類命令的特點是依賴當前上下文比如Teleport需要一個視圖目標Fly需要一個可控的 Pawn。所以它們只有在合適的場景里才工作不像 CVar 那樣隨處可用。2.2 怎么在不查文檔的情況下找到想要的命令這是我最想分享的部分因為很多人做 UE4 好幾年了還在靠搜索引擎找命令名。第一招Help。不帶參數(shù)執(zhí)行Help引擎會嘗試打開或生成一份命令列表。帶上參數(shù)比如Help stat會給出這個命令的用法說明。要注意的是這個輸出的完整度在各版本間不一致有時候只有一行描述有時候什么都沒有。第二招DumpConsoleCommands。這是真正的大殺器。執(zhí)行后引擎會把當前注冊的所有控制臺命令導出到一個文本文件落在工程的Saved目錄下。有了這個文件你就能用本地搜索找關(guān)鍵詞了——比在網(wǎng)頁上翻文檔快得多而且導出的內(nèi)容是你當前這個版本、當前這些插件實際可用的命令不會有版本不匹配的問題。我的習慣是每建一個新項目先跑一次DumpConsoleCommands把結(jié)果存進項目的Docs目錄起個帶引擎版本號的名字。后面做畫質(zhì)分級或者性能測試時直接在里面搜效率極高。第三招查源碼里的注冊點。如果某個變量你想知道它的確切含義、默認值和取值范圍最可靠的辦法是在引擎源碼里搜RegisterConsoleVariable和變量名。CVar 的注冊代碼通常緊挨著使用它的邏輯注釋也往往比外部文檔詳細。特別是那些名字含糊的變量看一眼使用位置就明白了。第四招關(guān)鍵字聯(lián)想。知道前綴之后可以大膽猜。比如你想控制陰影距離r.Shadow試一下想調(diào)紋理流送池大小r.Streaming試一下。多數(shù)情況下引擎會有自動補全提示新版編輯器支持實在沒有就靠猜加篩選。3. 高頻命令分組實操清單下面這幾組命令是我日常用得最多的按用途分組每條都說明它解決什么問題、什么時候用、有什么坑。3.1 診斷可視化Show、ShowFlag、ShowDebug 三兄弟這三者的定位完全不同混用會很痛苦。Show是最老的接口語法是Show 名字一次只能開關(guān)一個。常用的大致有這幾個Show Collision顯示碰撞體線框Show Bounds顯示包圍盒Show Navigation顯示導航網(wǎng)格Show Splines顯示樣條還有一個特殊的Show Bounds能順便看到 Actor 的 Tick 狀態(tài)。ShowFlag是新接口語法是ShowFlag.名字 0/1名字用的是顯示標記的枚舉名。它的優(yōu)勢是可以精細控制——ShowFlag.StaticMeshes 0會把所有靜態(tài)網(wǎng)格關(guān)掉ShowFlag.SkeletalMeshes 0關(guān)掉骨骼網(wǎng)格ShowFlag.Particles 0關(guān)掉粒子。做渲染排查時逐個關(guān)掉這些顯示類別能快速定位到是哪一類物體在拖后腿。ShowDebug是完全不同的一類的它負責在屏幕上疊加一塊文本調(diào)試面板。不帶參數(shù)執(zhí)行ShowDebug會列出所有可用的調(diào)試類別ShowDebug AI顯示 AI 狀態(tài)ShowDebug Animation顯示動畫狀態(tài)ShowDebug Camera顯示相機參數(shù)ShowDebug Input顯示輸入狀態(tài)。關(guān)閉用ShowDebug None。提示ShowDebug面板的內(nèi)容是按幀刷新的如果某個字段一直是空的通常是這個類別的 Debug 數(shù)據(jù)沒有被對應的系統(tǒng)寫入而不是顯示有問題。檢查一下相關(guān)系統(tǒng)是否在那個上下文里被激活。3.2 性能統(tǒng)計stat 家族與 ProfileGPU、stat startfilestat家族是性能排查的主力它把引擎內(nèi)部的計時器數(shù)據(jù)實時貼在屏幕上。最核心的幾條stat fps只顯示幀率最輕量適合長時間掛著觀察波動。stat unit顯示四個數(shù)字——Frame整幀時間、Game游戲線程、Draw渲染線程、GPU顯卡這是判斷瓶頸在哪一端的第一條命令沒有之一。如果 Game 明顯高于其他去查游戲邏輯如果 Draw 高去查場景里的繪制調(diào)用如果 GPU 高去查像素開銷。stat unitgraph把stat unit的數(shù)值畫成曲線圖做性能回歸的時候比看數(shù)字直觀得多。它還有stat unitmax和stat unitavg兩個變體分別顯示峰值和平均值做長時間采樣特別有用——因為瞬時數(shù)值會騙人平均值和峰值才能反映真實體驗。stat scenerendering給出場景渲染的整體開銷包括各種 Pass 的時間分布和可見物體數(shù)量。stat rhi關(guān)注渲染硬件接口層能看到 DrawPrimitive 調(diào)用次數(shù)和顯存相關(guān)數(shù)據(jù)。stat game拆解游戲線程的開銷stat physics看物理stat anim看動畫stat particles看粒子stat memory看內(nèi)存stat slate看 UI。這些全開會讓屏幕很擠而且統(tǒng)計本身也有開銷測量結(jié)果會失真。我的做法是一次只開一兩個相關(guān)的測完立刻Stat None全關(guān)。ProfileGPU是一條容易被忽略但非常好用的命令。執(zhí)行后它會把 GPU 各階段的耗時輸出到日志里粒度比stat gpu更細。缺點是會打斷當前幀有輕微卡頓但抓一次性數(shù)據(jù)時很合適。做長時間性能分析就得上stat startfile和stat stopfile。這對命令會把這段時間內(nèi)的詳細統(tǒng)計寫入一個文件然后用 Session Frontend 里的 Profiler 打開能看到每個函數(shù)、每個系統(tǒng)的耗時排序。這是做深度優(yōu)化的標準流程。要注意的是文件會比較大采樣時間別拉太長一般抓個十幾秒就夠定位問題了。實操心得stat startfile期間不要做長時間的無操作停留否則會把大量空轉(zhuǎn)數(shù)據(jù)也記進去分析時反而干擾。最好讓角色在典型場景里跑一圈覆蓋主要的玩法路徑。3.3 渲染畫質(zhì)調(diào)優(yōu)r. 家族里最該記住的十幾條r.家族成員極多我按用途挑出最實用的。分辨率相關(guān)r.ScreenPercentage控制渲染分辨率縮放這是做畫質(zhì)檔位的核心參數(shù)。默認 100降到 70 能明顯提升幀率代價是畫面模糊。注意它影響的是渲染分辨率UI 通常還是按原生分辨率繪制取決于設(shè)置。r.ResolutionQuality在不同版本里語義有細微差別用之前最好確認一下當前版本的說明。抗鋸齒r.PostProcessAAQuality是主開關(guān)取值 0 到 60 是關(guān)閉1 大致對應快速近似抗鋸齒2 以上是時間性抗鋸齒的不同質(zhì)量檔。做低端機檔位時把它降到 1 或者 0收益很直接。r.DefaultFeature.AntiAliasing是項目默認值的開關(guān)影響的是新建場景的默認行為。后處理特效的開關(guān)是一組r.DefaultFeature.*比如r.DefaultFeature.MotionBlur、r.DefaultFeature.Bloom、r.DefaultFeature.AutoExposure。這些關(guān)掉能省一筆開銷而且關(guān)掉動態(tài)曝光后畫面亮度會變得穩(wěn)定可預測做美術(shù)驗收時反而更省事。陰影r.ShadowQuality是質(zhì)量總開關(guān)r.Shadow.DistanceScale控制陰影距離縮放直接影響陰影渲染的覆蓋范圍是性價比很高的一個參數(shù)r.Shadow.MaxCSMResolution控制級聯(lián)陰影貼圖的分辨率。移動端項目里這幾個參數(shù)是必調(diào)的。LOD 相關(guān)r.ForceLOD強制所有物體用某個 LOD 等級設(shè)為 -1 恢復自動。做模型檢查時常用r.ForceLOD 0強制最高精度確認模型的近景效果。r.SkeletalMeshLODBias單獨控制骨骼網(wǎng)格的 LOD 偏移。紋理流送r.TextureStreaming 0關(guān)閉流送所有紋理全量加載用來判斷卡頓是不是流送引起的。注意關(guān)掉之后顯存占用會飆升測試完記得開回來。r.Streaming.PoolSize控制流送池的大小單位是 MB移動端和低配機上這個值調(diào)小是常規(guī)操作但太小會導致紋理頻繁抖進抖出反而更卡。光源r.VolumetricFog 0關(guān)體積霧r.AmbientOcclusionLevels控制環(huán)境光遮蔽的層級數(shù)。注意r.變量里有很多是只在初始化時讀取一次的運行時改不會立刻生效。判斷方法很簡單——改完看畫面有沒有變化。沒變化的話可能需要重啟關(guān)卡甚至重啟進程。這類變量一般和著色器編譯或渲染資源分配相關(guān)。3.4 物理與查詢p. 家族以及查詢和物理模擬到底差在哪這一節(jié)回答一個被問得特別多的問題UE4 里查詢和物理模擬到底有什么區(qū)別控制臺命令上怎么體現(xiàn)。先說概念。物理模擬是剛體在力、重力、約束作用下由求解器計算位置和旋轉(zhuǎn)的變化過程它會真正改變物體的 Transform并且產(chǎn)生碰撞響應。查詢Query是向物理世界提問從這個點沿這個方向射一條線會撞到什么、這個盒子和哪些物體重疊了、這個膠囊體沿這條路徑移動會不會受阻——它只讀不寫不會推動任何物體。一個生活化的類比物理模擬像是把一堆球倒進箱子里球會互相擠壓、滾動、最終靜止查詢像是拿一根棍子伸進箱子里探一探你能知道碰到了哪個球但球不會因為你的棍子而動。控制臺層面show Collision是兩者共同的觀察窗口它會把物理世界的幾何表示畫出來。但要注意它畫的是碰撞幾何也就是物理世界真正在用的形狀而不是你在建模軟件里看到的渲染網(wǎng)格。很多看著明明碰到了卻沒觸發(fā)的問題根源就是碰撞幾何和渲染網(wǎng)格不一致——show Collision一看就明白了。p.VisualizeMovement 1是排查角色移動問題的利器它會把膠囊體的 Sweep 軌跡、地面檢測射線、落腳點都畫出來。角色在斜坡上抖動、卡在臺階上、莫名其妙掉下去這類問題用它基本都能定位。它背后用的就是查詢——每幀若干次向下的射線檢測加一次水平方向的掃掠。p.ShowInitialOverlaps用來高亮那些在生成時就和其他物體重疊的組件。這個問題會引發(fā)一堆奇怪的現(xiàn)象比如角色被卡住、物理物體突然彈飛因為物理引擎在初始化時就在處理一個本不該存在的穿模狀態(tài)。打開這個命令出問題的物體會被醒目地標出來。p.EnableAsyncScene控制異步物理場景。這個功能把一部分物理計算放到單獨的線程能減輕主線程壓力但它有明確的使用限制——異步場景里的物體不會和其他物體碰撞。用它之前一定要確認目標物體的交互需求用錯了會出現(xiàn)物體穿過地面這種詭異現(xiàn)象。至于引擎版本較新的 UE4物理后端逐步引入了新的實現(xiàn)相關(guān)參數(shù)掛在p.Chaos.前綴下。具體哪些可用、行為如何取決于你鎖定的引擎小版本用之前建議先在本地驗證一遍不要直接照搬網(wǎng)上的參數(shù)。我踩過的坑曾經(jīng)為了提幀把異步物理打開結(jié)果關(guān)卡里幾個需要堆疊的箱子全部穿模疊在了一起。異步場景適合那些不需要交互的純裝飾性物理物體凡是參與玩法交互的老老實實留在主場景里。3.5 輸入與外接設(shè)備映射的調(diào)試命令外接設(shè)備映射是實際項目里很容易出問題的一塊尤其是接手柄、方向盤、飛行搖桿這類設(shè)備的時候。癥狀通常是編輯器里模擬輸入一切正常接上真設(shè)備后要么沒反應要么軸方向反了要么數(shù)值范圍完全不對。ShowDebug Input是第一步要開的。它會把當前所有輸入動作的狀態(tài)、軸的數(shù)值實時顯示出來。設(shè)備接沒接上、按鍵有沒有映射對、軸的符號是不是反的看一眼就知道。我一般會這樣排查先確認按鍵按下去時有沒有任何數(shù)值變化有變化說明設(shè)備識別和映射鏈路是通的問題只在方向或范圍完全沒變化就往前推去看設(shè)備的識別層。關(guān)于軸的范圍有個特別容易踩的坑編輯器里配置的軸映射默認會有一個死區(qū)設(shè)置和縮放系數(shù)。外接設(shè)備尤其是模擬搖桿類原始輸出范圍往往是 -1 到 1 之外的區(qū)間或者存在零點漂移。如果死區(qū)設(shè)得太大輕微推桿就沒有響應設(shè)得太小松手后數(shù)值會一直抖動。這個只能在真設(shè)備上反復試沒有通用值。設(shè)備識別的干擾也值得說一下。同一臺機器上如果同時接了多個同類設(shè)備索引可能會串。這時候可以逐個拔插來確認或者用調(diào)試面板看設(shè)備索引和綁定關(guān)系是否對應。多設(shè)備場景下建議在游戲設(shè)置里提供一個明確的設(shè)備選擇入口而不是依賴自動識別——用戶體驗會好很多。另外輸入相關(guān)的調(diào)試還可以配合慢放來觀察。用Slomo 0.2把時間放慢輸入響應的過程會被拉長能看清一次按鍵觸發(fā)了哪些動作、軸的數(shù)值是怎么變化的。排查組合鍵、長按判定這類邏輯時特別好用。用完記得Slomo 1恢復。3.6 內(nèi)存與資產(chǎn)obj、MemReport、gc 組合拳內(nèi)存問題排查有一套固定的命令組合我把它叫三板斧。第一板斧是stat memory先看整體。它給出的是各子系統(tǒng)的內(nèi)存占用概覽能快速判斷大頭在哪——是紋理、是網(wǎng)格、還是藍圖或音頻。第二板斧是MemReport -full它會把詳細的內(nèi)存報告輸出到日志。這個報告非常全面包括按類別統(tǒng)計的資產(chǎn)數(shù)量、大小還有各種內(nèi)存池的狀態(tài)。我第一次看會覺得信息過載但它確實是定位內(nèi)存問題時信息最全的入口。常用的是MemReport -full不加參數(shù)會簡單一些。第三板斧是obj系列用來做資產(chǎn)級別的精確定位。obj list列出所有已加載的 UObject輸出的是類名和數(shù)量統(tǒng)計。更進一步可以用類名過濾比如只看紋理能發(fā)現(xiàn)哪一類資產(chǎn)加載得異常多。obj refs可以查某個對象的引用鏈用來回答這個東西為什么還沒被釋放——這是內(nèi)存泄漏排查的關(guān)鍵命令。obj gc強制觸發(fā)一次垃圾回收用來驗證這些對象是不是只是等著被回收。關(guān)于垃圾回收還有一條gc.CollectGarbageEveryFrame 1。打開它之后每幀都會做一次 GC雖然性能會明顯下降但能瞬間判斷出卡頓是不是 GC 引起的。如果打開后卡頓消失說明原本的卡頓是 GC 峰值導致的如果卡頓照舊那問題在別處。這個方法簡單粗暴但極其有效。提示MemReport的輸出默認進日志需要把日志窗口打開或者去看Saved/Logs目錄下的文件。用-log啟動參數(shù)可以直接把日志窗口拉出來省去來回切窗口的麻煩。4. 把命令固化進工程ini、代碼、打包三件事命令敲得再熟也只能解決你自己的問題。要讓團隊里所有人都能用或者讓某個設(shè)置在所有機器上保持一致就得把它固化下來。4.1 DefaultEngine.ini 里固化 [SystemSettings]最常用的方式是在工程的DefaultEngine.ini里加一段[SystemSettings]把要固定的 CVar 寫進去。引擎啟動時會讀取這個段并應用里面的設(shè)定。[SystemSettings] r.ScreenPercentage100 r.Shadow.DistanceScale0.8 r.Streaming.PoolSize1500 t.MaxFPS60 p.EnableAsyncScene0這段配置的好處是所有開發(fā)者和所有構(gòu)建都會帶上不會出現(xiàn)我這臺機器上幀率正常、你那臺就掉幀的情況。做畫質(zhì)檔位時我會準備幾份不同的配置片段打包腳本根據(jù)目標平臺選擇性地拼接。但要注意優(yōu)先級問題。前面說過CVar 有三層來源[SystemSettings]屬于中間層。如果某個變量在代碼里被以更高優(yōu)先級設(shè)置ini 里的值會被覆蓋。判斷方法是啟動后手動敲一遍同名命令看數(shù)值有沒有變化。如果變了說明之前的設(shè)定沒生效得從代碼層面找原因。還有一個常見的疑惑是[SystemSettings]和[ConsoleVariables]的區(qū)別。前者是引擎級的系統(tǒng)設(shè)定段覆蓋面更廣用法也更標準后者在部分場景下也有效但語義不太統(tǒng)一。我的建議是統(tǒng)一用[SystemSettings]除非你明確知道某個變量必須走另一個段。4.2 C 和藍圖里執(zhí)行命令做游戲內(nèi)調(diào)試面板是很多項目的剛需尤其是在做主機或者不方便開鍵盤的平臺。C 里執(zhí)行命令的核心是GEngine-Execif (GEngine GetWorld()) { GEngine-Exec(GetWorld(), TEXT(stat unit)); }這里有個細節(jié)值得說第一個參數(shù)傳 World 是有講究的有些命令需要世界上下文才能找到目標對象。傳nullptr在部分命令上能工作但另一些會靜默失敗。養(yǎng)成傳 World 的習慣能省掉很多迷惑行為。藍圖里對應的是Execute Console Command節(jié)點。它需要一個 World Context 來確認命令執(zhí)行的上下文所以通常掛在 PlayerController 或者有世界引用的藍圖里。這兩個路徑最終走的是同一套分發(fā)邏輯行為一致。做調(diào)試面板時我建議把命令做成配置驅(qū)動的而不是硬編碼。用一張 DataTable 存按鈕標題 → 命令字符串面板按表生成按鈕。這樣調(diào)整命令不用改代碼重新加載配置就行策劃和測試也能自己加。這個做法在多平臺項目里特別省事。另外要提醒的是命令的返回值不要指望。多數(shù)命令返回的是布爾值表示是否被處理具體執(zhí)行結(jié)果要從屏幕顯示或者日志里看。所以做自動化測試時通常是執(zhí)行命令后等幾幀然后去讀日志或者截圖比對而不是讀返回值。4.3 自定義 Exec 命令與 Shipping 構(gòu)建的限制當內(nèi)置命令不夠用時可以自己注冊。C 里給成員函數(shù)加UFUNCTION(Exec)標記再把這個類放在引擎會自動遍歷的那條鏈路上PlayerController、Pawn、HUD、GameMode、GameInstance 這類函數(shù)名就會變成一條控制臺命令。UFUNCTION(Exec) void SetQualityPreset(int32 Level);這樣在控制臺里敲SetQualityPreset 2就會調(diào)用到你的函數(shù)。這個能力在做工具鏈時非常好用——你可以把一堆調(diào)試開關(guān)打包成一條語義清晰的命令團隊里誰都能用不需要知道背后的 CVar 名字。關(guān)于 Cheat 類命令它依賴于當前的作弊開關(guān)狀態(tài)。在編輯器內(nèi)運行PIE時默認是允許的但在正式構(gòu)建里通常被關(guān)掉。所以凡是給策劃和測試用的調(diào)試命令建議不要做成 Cheat 類而是在 Development 構(gòu)建里直接可用。最后說 Shipping 構(gòu)建。Shipping 是發(fā)行用的最高優(yōu)化等級為了包體和安全性引擎會裁剪掉大量調(diào)試能力包括控制臺輸入框和一部分命令。所以你會遇到Development 包里能用的命令Shipping 包里敲不出來的情況。這是設(shè)計如此不是 Bug。那 Shipping 下怎么做調(diào)試我的做法有三條路一是保留一個 Development 構(gòu)建專門給測試團隊用來抓問題二是在 Shipping 里預留一套輕量的自定義調(diào)試入口通過預設(shè)的按鍵組合觸發(fā)有限的功能而不是暴露完整控制臺三是把常用的診斷信息做成常駐的性能監(jiān)控 UI只在特定條件下顯示。第三條路對線上問題定位幫助最大因為用戶遇到問題時你能直接讓他們截個圖。5. 一次完整的排查實操從 45 幀到 60 幀講理論不如講一次真實的過程。我挑一個印象比較深的案例整個排查就是靠控制臺命令完成的。5.1 現(xiàn)象與第一輪定位項目是一個中等規(guī)模的開放區(qū)域場景在目標配置的機器上跑出 45 幀左右的平均值目標是穩(wěn)定 60。場景里沒有明顯的巨型模型或者超高清貼圖美術(shù)資源看起來是合理的。第一步stat unit。結(jié)果是 Frame 約 22msGame 約 8msDraw 約 20msGPU 約 21ms。這里就能讀出信息了Game 線程不是瓶頸Draw 和 GPU 都接近 20ms說明渲染側(cè)壓力大。同時 Draw 高而 GPU 略高于 Draw說明既有提交開銷也有像素開銷兩頭都有。第二步stat scenerendering。重點看兩個數(shù)可見物體數(shù)量和各個渲染 Pass 的耗時分布。這里發(fā)現(xiàn)可見靜態(tài)網(wǎng)格數(shù)量遠超預期而且陰影相關(guān)的 Pass 占了相當大一塊。第三步ShowFlag.Shadow 0把陰影全關(guān)再看stat unit。GPU 時間從 21ms 掉到 13ms 左右。確認陰影是 GPU 側(cè)的大頭。5.2 收窄到渲染線程的過程接下來要解釋 Draw 為什么高。Draw 高通常意味著在 CPU 側(cè)提交了太多繪制調(diào)用。先用stat rhi看 DrawPrimitive 的調(diào)用次數(shù)發(fā)現(xiàn)明顯偏高。然后用ShowFlag.StaticMeshes 0關(guān)掉所有靜態(tài)網(wǎng)格Draw 時間立刻降到 6ms 左右確認是靜態(tài)網(wǎng)格的提交量問題。進一步定位用ShowFlag.Bounds 1和Show Collision輔助觀察發(fā)現(xiàn)大量小物件被渲染而且很多是在遠處根本看不清的細節(jié)。同時ShowFlag.Navigation 1時也發(fā)現(xiàn)場景里存在一些不該渲染的輔助幾何體。這里有個關(guān)鍵的判斷不是單個模型太重而是數(shù)量太多導致提交開銷累積。這類問題用合并網(wǎng)格、做 LOD、調(diào)整剔除距離都能解決但優(yōu)先級要按收益排。5.3 結(jié)論與驗證最終的調(diào)整方向有三條一是優(yōu)化陰影配置把r.Shadow.DistanceScale從默認值降到 0.8同時降低級聯(lián)陰影的分辨率并關(guān)掉不需要投影陰影的物體二是對場景里的靜態(tài)網(wǎng)格做合并減少繪制調(diào)用三是給遠處的細節(jié)物件配置更激進的 LOD 和剔除距離。改完后用t.MaxFPS 60鎖定上限再跑一遍完整路徑stat unit穩(wěn)定在 Frame 約 16msGame、Draw、GPU 三項均衡。為了確認沒有引入回歸我用stat unitgraph掛了十分鐘曲線平穩(wěn)沒有周期性的尖峰——說明也沒有引入 GC 或者流送引起的抖動。最后把這次的參數(shù)調(diào)整固化進DefaultEngine.ini的[SystemSettings]并把整個排查過程用到的命令整理成一張清單放進項目文檔。下次遇到同類問題新人照著清單走一遍就行不用重新摸索。這個案例里真正花時間的不是敲命令而是判斷哪個數(shù)值代表什么問題。命令只是把數(shù)據(jù)擺出來解讀數(shù)據(jù)的能力才是核心。我的建議是每次排查完都記錄下來慢慢會形成自己的判斷直覺。6. 常見問題速查與避坑清單最后把平時被問得最多的問題整理成一張表遇到問題按順序排查基本能覆蓋九成情況。6.1 命令敲了沒反應的排查順序現(xiàn)象最可能的原因驗證方式控制臺完全打不開Shipping 構(gòu)建裁剪了控制臺換 Development 構(gòu)建試一次命令輸入后無任何輸出命令不存在或拼寫錯誤用Help 命令名確認數(shù)值型的命令改完沒變化變量被更高優(yōu)先級覆蓋或需重啟才生效重啟關(guān)卡后再看自定義 Exec 命令不響應函數(shù)所在類不在執(zhí)行鏈路上或未標記 Exec換到 PlayerController 上試ShowFlag 類命令無效名字拼錯大小寫敏感或該版本無此標記用ShowDebug列出可用項啟動參數(shù)里的命令沒生效執(zhí)行時機太早被后續(xù)初始化覆蓋改成進游戲后再手動執(zhí)行驗證這張表里最值得展開的是第三條。CVar 不生效的原因五花八門我遇到過的情況包括變量被游戲邏輯每幀重設(shè)、變量在 ini 里寫了兩遍后者覆蓋前者、變量本身的優(yōu)先級標志位高于配置文件。排查方法是一致的——先確認命令本身有效手動執(zhí)行看有沒有變化再確認有沒有別的地方在改它在代碼里搜變量名最后確認生效時機。另外ShowFlag的名字是大小寫敏感的而且不同引擎版本的可選標記不完全一樣。寫配置文件時如果照抄了別的版本的寫法可能會靜默失效。穩(wěn)妥做法是在當前版本里先用ShowDebug或者幫助命令確認一遍。6.2 幾個容易踩的坑坑一stat全開導致數(shù)據(jù)失真。所有統(tǒng)計面板都開著的時候統(tǒng)計自身的開銷可能占到幾毫秒。做對比測試時務必保持只開必要項而且兩次測試開的項目要一致否則數(shù)據(jù)沒法比。坑二在加載過程中敲命令。無縫切換、關(guān)卡流送、資產(chǎn)異步加載這些階段LocalPlayer 和執(zhí)行上下文可能不完整命令會靜默失敗。養(yǎng)成習慣——等畫面穩(wěn)定了再敲。坑三把調(diào)整后的 CVar 忘了寫進配置。手敲的變量只對當前會話有效。我見過團隊里每個人都在自己機器上手動調(diào)結(jié)果打包出來的表現(xiàn)完全不同。凡是確定要保留的調(diào)整立刻寫進DefaultEngine.ini?？铀挠眠\行時命令去驗證只在初始化時讀取的變量。前面提過一部分渲染相關(guān)的變量只在啟動時讀取。你運行時改了看不到變化不代表這個變量沒用可能只是生效時機不對。這種情況要配合啟動參數(shù)或者 ini 來驗證?？游搴雎悦顚π阅艿母蓴_。像r.TextureStreaming 0、gc.CollectGarbageEveryFrame 1這類命令用它們做判斷是可以的但不能用來測性能數(shù)值。切換完記得恢復默認值一個干凈的基線比什么都重要?？恿绨姹菊瞻崦?。UE4 從 4.20 到 4.27 之間命令的增刪和語義變化相當多。看別人的排查記錄時先確認對方用的引擎版本和你是否接近。差距大的話先驗證一遍再用。6.3 建立自己的命令清單說了這么多最后還是落到一個習慣上建一份自己的命令清單。我的做法是按用途分幾個文件——性能排查、畫質(zhì)調(diào)優(yōu)、內(nèi)存分析、輸入調(diào)試每個文件里只放實際用過的命令附一行說明和一次真實的使用場景。這份清單的價值在于它是你驗證過的不是從網(wǎng)上抄的。用過的命令你知道它的行為、知道它的坑、知道什么版本能用。新項目啟動時把清單過一遍往往能提前避免很多重復勞動。另外清單最好帶一個注意事項欄記錄那些非直觀的行為。比如這條命令會打斷當前幀、這條改了之后必須重啟、這條只在 PIE 下有效。這些信息文檔里通常不寫但實際用起來非常關(guān)鍵。我個人在實際操作中的體會是控制臺命令的價值不在于你會背多少條而在于你能不能在出問題的時候快速想到該用哪條命令去把數(shù)據(jù)取出來。取數(shù)據(jù)的能力決定了排查效率而這份清單就是把這個能力沉淀下來的方式。