做UE項目這些年我最大的感觸是很多團隊不是不重視性能而是把性能優(yōu)化當成項目后期的一個補救環(huán)節(jié)等場景堆到一定程度、幀率掉到?jīng)]法看了才開始找原因結果要么大規(guī)模刪資產要么靠降低分辨率硬撐。Unreal Engine開發(fā)與性能優(yōu)化這件事本質上是兩條腿走路開發(fā)階段就要給性能留余地優(yōu)化階段才能用數(shù)據(jù)說話而不是靠感覺拍腦袋。這篇文章我會從瓶頸定位、工具鏈使用、渲染層優(yōu)化、CPU邏輯優(yōu)化、內存與加載優(yōu)化這幾個維度結合我實際跑過的項目案例把UE性能優(yōu)化的完整套路梳理一遍。不管是剛接觸UE的新手還是已經(jīng)做了幾個版本但總覺得優(yōu)化無從下手的朋友都可以對照著排查自己的項目。1. 性能優(yōu)化前先搞清楚瓶頸到底在哪1.1 性能瓶頸的三種來源UE項目的性能問題表面上看都是卡頓掉幀但根源往往完全不同。我把它們粗暴分成三類CPU瓶頸、GPU瓶頸、加載/內存瓶頸。CPU瓶頸最常見的表現(xiàn)是場景里Actor數(shù)量巨大、藍圖邏輯復雜、每幀執(zhí)行大量Tick或者碰撞查詢導致GameThread游戲線程跑不完。這時候你會發(fā)現(xiàn)GPU其實很閑GPU占用率不高但幀率就是上不去。GPU瓶頸則相反顯卡忙不過來常見于場景里堆了太多高精度模型、復雜的實時陰影、多層半透明疊加或者后處理效果開得太猛。加載/內存瓶頸通常是資源流送Streaming跟不上、紋理池爆了、Shader編譯卡頓表現(xiàn)為游戲過程中突然頓一下或者切換場景時明顯卡頓。判斷到底是哪一類最簡單的方法就是打開控制臺輸入stat unit。這個命令會顯示三行關鍵數(shù)據(jù)Frame總幀耗時、Game游戲線程耗時、Draw渲染線程耗時、GPUGPU耗時。如果Game耗時接近Frame耗時說明CPU游戲邏輯是瓶頸如果Draw和GPU很大那就是渲染端有問題如果GPU遠大于Draw多半是GPU自身壓力過大。這個命令是我每次開始優(yōu)化前必敲的第一個命令沒有之一。1.2 幀率、幀時間與流暢感的真實關系聊性能繞不開幀率但我要說一個經(jīng)常被誤解的點優(yōu)化目標是幀時間而不只是幀率。60幀對應的幀預算是16.6ms30幀是33.3ms。很多團隊一上來就說我們要穩(wěn)定60幀但問他們當前幀預算是多少往往答不上來。沒有明確的幀預算優(yōu)化就沒有錨點。另外幀時間的穩(wěn)定性比平均值更重要。有些場景平均幀率看著有55幀但每過幾秒就掉到40幀以下這種卡頓感比穩(wěn)定45幀還要難受。所以在看性能數(shù)據(jù)時一定要關注P9999%幀的耗時和P1最差1%幀的耗時而不是只看平均值。UE的stat fps只能看平均幀率stat unit可以看到每幀耗時更專業(yè)的做法是用Unreal Insights抓一段時間的幀數(shù)據(jù)分析幀時間的分布曲線。我自己的習慣是先確定目標設備的最低配置定出幀預算比如中端手機按30幀優(yōu)化、33ms預算高端PC按60幀優(yōu)化、16.6ms預算然后再開始逐項排查。沒有這個前提后面所有優(yōu)化動作都可能白做。1.3 優(yōu)化目標的制定先畫紅線再動手優(yōu)化目標不是盡量不卡而是可以量化的紅線。我通常會定這幾個指標目標幀率與幀預算比如PC端60幀/16.6ms移動端30幀/33ms。P99幀時間上限比如PC端不超過20ms移動端不超過40ms。內存上限根據(jù)目標設備定比如移動端紋理池不超過256MB總內存控制在1.5GB以內。加載時長關卡初始加載不超過5秒切換場景不超過3秒。這些紅線定下來之后每次改動都有明確的驗證標準改完跑一遍Profile看數(shù)據(jù)是不是達標了。不達標就繼續(xù)排查達標就收手。這一步聽起來簡單但實際項目里很多團隊就是缺這條紅線導致優(yōu)化方向反復橫跳。2. 必備工具鏈學會用數(shù)據(jù)說話2.1 Unreal Insights與stat命令的正確用法UE自帶的分析工具其實非常強很多團隊卻只用了冰山一角。最常用的是控制臺命令推薦先記住這幾個stat fps # 查看實時幀率 stat unit # 查看Game/Frame/Draw/GPU耗時定位瓶頸種類 stat scenerendering # 查看渲染相關的Draw Call、三角形數(shù)量等 stat rhi # 查看RHI層數(shù)據(jù)比如Draw Call、三角形、紋理切換次數(shù) stat memory # 查看各模塊內存占用 stat streaming # 查看資源流送狀態(tài) stat game # 查看GameThread各Task的耗時 stat initviews # 查看視錐剔除耗時 stat gpu # 查看GPU各Pass耗時啟用GPU Profiler后這些命令可以疊加使用比如同時輸入stat unit和stat scenerendering。在Editor里運行時注意要勾選Use Less CPU when in Background選項否則后臺運行會影響數(shù)據(jù)。另外編譯Development包后的性能表現(xiàn)和Editor里差別很大所以正式測量必須在打包后的版本上進行。Unreal InsightsUI是更專業(yè)的工具它能看到每一幀里每個線程、每個任務的詳細耗時還能定位出到底是哪個函數(shù)、哪個系統(tǒng)占用了大量時間。使用方式是在打包版本里通過命令行參數(shù)開啟TraceYourGame.exe -tracehost127.0.0.1 -tracefiletraces/game.utrace然后在編輯器里打開Unreal Insights加載這個trace文件可以逐幀分析GameThread、RenderThread、RHI線程各自的耗時分布。這套流程是我做項目性能評審時的標準動作。2.2 GPU Profiler與RenderDoc的配合定位到渲染層瓶頸后還要進一步找到是哪個渲染Pass或者哪類材質最耗。UE的GPU Profiler最直接的入口是編輯器里CtrlShift,打開GPU Visualizer或者在運行時執(zhí)行ProfileGPU這會生成一份GPU各Pass的耗時列表比如BasePass、ShadowDepths、Translucency、PostProcessing分別花了多少毫秒。看到哪個Pass異常高再針對性去查。RenderDoc則用于抓幀分析具體繪制調用。它能導出每個Draw Call的頂點數(shù)、像素數(shù)、渲染狀態(tài)甚至能看到某個物體的Shader復雜度。很多某個材質在特定角度下特別卡的問題用RenderDoc一抓就明白了——通常是Overdraw像素被繪制多次太高或者某個特效沒有加半透明裁剪導致大量像素在透明通道里反復混合。2.3 移動端與主機平臺的Profile方法移動端和PC的Profile方式差別很大。PC上可以做全分辨率Profile但移動端必須用真機測試因為GPU架構差異太大了——同一張PowerVR顯卡和Adreno顯卡同一個場景的渲染耗時可能差出兩倍。移動端最常用的工具是Unreal Insights的移動端Trace通過-tracehost配置在真機上錄制性能數(shù)據(jù)。各廠商Profiler比如高通的Snapdragon Profiler、 ARM的Streamline它們能給出GPU計數(shù)器級別數(shù)據(jù)比如ALU占用率、紋理帶寬、頂點吞吐量。Systrace/PerfettoAndroid可以看到系統(tǒng)級的CPU調度和GPU負載適合排查掉幀波動問題。Xcode InstrumentsiOS查看Metal相關的GPU幀耗時。主機平臺則需要用廠商SDK比如PlayStation的剖析工具和Xbox的PIX。這類平臺一般能在系統(tǒng)級看到更深入的GPU和CPU計數(shù)器數(shù)據(jù)但門檻也高一些。對我的日常工作來說PIX對DX12渲染的調試尤其有用能直接看到每個Draw Call的狀態(tài)和耗時。3. 渲染層面的性能優(yōu)化實操3.1 從LOD到Nanite模型精度的科學控制場景里模型數(shù)量一多三角形數(shù)量就會直線上升。傳統(tǒng)做法是用LODLevel of Detail離相機近時用高精度模型遠距離自動切換低精度模型。UE里可以手動配置LOD距離也可以用Auto Generate LOD自動生成。設置LOD時的關鍵參數(shù)是切換距離。切換太早玩家靠近時會看到模型跳變切換太晚性能又扛不住。我的經(jīng)驗是一個角色模型近距LOD0在2~4米內顯示LOD1在4~10米LOD2在10~20米更遠直接顯示Impostor公告板或剔除。這個數(shù)值要根據(jù)鏡頭運動速度來調鏡頭拉得越快切換距離要拉得越大否則彈跳感會很明顯。UE5引入的Nanite徹底改變了這個思路。Nanite采用虛擬化幾何技術可以在運行時動態(tài)細化和簡化網(wǎng)格體開發(fā)者不需要手動生成LOD也不需要擔心三角形數(shù)量。開啟方式是模型資產的Enable Nanite Support勾選上然后在項目設置里啟用Nanite。Nanite在PC和高端的移動設備上效果極好場景里放幾十個高精度雕塑都不帶卡的。但需要注意Nanite目前不能用于所有材質比如帶半透明的物體就不支持也不適合做植被這類大量動態(tài)對象的渲染。所以我的建議是靜態(tài)建筑、雕塑、地形大件用Nanite動態(tài)角色、植被、道具用傳統(tǒng)LOD。3.2 光照與陰影減少Overdraw和過采樣光照是渲染性能的大頭尤其是動態(tài)陰影。實時陰影的代價是每一幀都要額外渲染一次深度圖陰影級聯(lián)CSM級別越高渲染Pass越多GPU壓力越大。場景里如果放了太多投射動態(tài)陰影的燈陰影Pass數(shù)量會成倍增加。優(yōu)化的幾個實操要點限制動態(tài)光源數(shù)量主光源Directional Light只保留一個投影陰影次要光源盡量用手工放置的靜態(tài)光照烘培Lightmass代替動態(tài)光。調整CSM級聯(lián)數(shù)默認4級級聯(lián)對性能影響很大移動端通常降到2級甚至1級PC段用3級即可。對應控制臺變量r.Shadow.CSM.MaxCascades。設置陰影距離把無效的遠處陰影裁掉比如r.Shadow.DistanceScale設為0.6遠處的陰影直接消失肉眼幾乎不會察覺。避免全屏半透明半透明物體每幀都要做多次混合且不能深度排序Overdraw極高?？梢杂肕asked材質代替半透明效果比如柵欄、葉子或者把半透明特效控制在屏幕的一小部分區(qū)域。靜態(tài)光照烘培也值得重新重視。很多團隊嫌Lightmass烘焙慢全部用動態(tài)光照結果性能一塌糊涂。我的建議是靜態(tài)場景的固定燈光比如建筑物里的壁燈、走廊的燈帶一律烘焙只保留主光源和必要交互光源為動態(tài)。這樣能省下大量實時光照預算。3.3 后處理與半透明最容易爆顯存的坑后處理效果PostProcess是GPU開銷的大戶尤其是**泛光Bloom、屏幕空間反射SSR、景深Depth of Field**這三個。場景里加一個全分辨率SSRGPU耗時能直接增加2~3ms。優(yōu)化時優(yōu)先檢查這三個效果的范圍和分辨率Bloom關閉或者降低質量通常視覺差距并不大但性能差異明顯。對應r.Bloom.Quality移動端建議設為0或1。SSR能關就關或者降低反射分辨率。對應r.SSR.QualityPC端中檔設為2移動端建議0關閉用屏幕空間反射的替代方案比如Planar Reflection或簡單的反射捕獲。景深過場動畫里可以用但游戲實操中建議關閉或縮小焦點范圍。全焦外模糊的景深效果代價極大很容易拖垮幀率。動態(tài)模糊Motion Blur很多項目默認開了還調得很高實際對流暢感幫助有限反而會掩蓋掉幀問題。建議關閉或只保留低檔對應r.MotionBlur.Max。半透明物體還有個隱形坑它會導致關閉Depth Prepass讓后面的不透明物體也無法利用早期深度測試間接拖慢了整個場景的渲染。所以場景里的半透明物體不要滿世界亂放尤其不要放在視口中心位置盡量讓半透明物體集中在固定區(qū)域。3.4 材質復雜度Shader指令數(shù)量的隱性成本材質Material是渲染性能中經(jīng)常被忽視的因素。一個材質里如果疊加太多紋理采樣、太多數(shù)學運算節(jié)點編譯出來的Shader指令數(shù)量會爆炸GPU執(zhí)行成本直線上升。UE的材質編輯器里可以直接查看Shader Complexity視圖用顏色標識每個像素的復雜度綠色是安全區(qū)黃色警告紅色危險。控制材質復雜度的幾個規(guī)則少用多層紋理混合尤其是Layer Blend節(jié)點每個混合層都意味著額外的紋理采樣和ALU操作。慎用大量Feature Switch在材質里堆很多根據(jù)條件啟用的節(jié)點最終編譯時會全部保留指令數(shù)不降反升。移動端要特別注意法線貼圖在低端設備上建議直接拿掉法線采樣解包在移動GPU上的開銷比PC大得多。片段著色器復雜度Pixel Shader Cost要控制在預算內我一般要求PC端主場景材質每像素指令數(shù)不超過300條移動端不超過150條。超出這個預算就要考慮拆分材質或簡化。用r.ShaderComplexity可以查看每像素的Shader復雜度顏色越鮮艷越耗。這個視圖在排查某個區(qū)域為什么特別卡的時候很有用。4. CPU與游戲邏輯層的優(yōu)化4.1 GameThread、RenderThread、RHI線程的分工UE的渲染架構里CPU側其實分三個線程GameThread游戲邏輯、RenderThread渲染命令產生、RHIThread渲染硬件接口提交。GameThread處理藍圖、物理、AI、動畫然后把渲染指令發(fā)給RenderThreadRenderThread組織這些指令生成RHI命令RHIThread最終提交給GPU。性能排查時stat unit里的Game、Draw分別對應對應GameThread和RenderThread的耗時。如果Draw很長往往是場景里Draw Call太多、剔除效率低或者有大量動態(tài)陰影、半透明物體。Game很長則說明游戲邏輯太重需要優(yōu)先優(yōu)化Actor生命周期、藍圖邏輯和物理計算。三者之間還有跨線程等待的問題某一線程跑太慢會拖累其他線程導致整個幀時間上升。4.2 藍圖的性能陷阱與C遷移策略藍圖是UE開發(fā)效率的利器但它天生比C慢。一個復雜的藍圖Tick方法每幀執(zhí)行幾十次性能開銷就不可忽略了。我的觀點是藍圖本身不是罪濫用藍圖才是。大量密集計算、高頻更新邏輯放在藍圖里性能和同功能的C實現(xiàn)能差出好幾倍。優(yōu)化策略有幾條每幀執(zhí)行的邏輯能用C就C。尤其是Actor的Tick遍歷場景里所有Actor的Tick每個人的藍圖Tick都在跑開銷累積起來非常可觀。優(yōu)先用Tick的替代方案比如定時器Set Timer by Event、事件驅動只有事件發(fā)生時更新一次、延遲調用Delay代替每幀輪詢。使用Fast Ticking Group如果確實要每幀更新把移動、動畫這些高頻Actor放到Fast Ticking GroupUE會優(yōu)化它們的Tick順序。禁用不必要的Tick場景里大量的靜態(tài)裝飾物根本不需要Tick在類默認值里把bCanEverTick設成False或者運行時SetActorTickEnabled(false)。C遷移時不要一上來就把所有藍圖改成C先定位性能熱點比如stat game里哪個Actor的Tick耗時最長然后把那部分邏輯抽離到C。實踐中最常見的高耗邏輯是每幀檢索和遍歷比如用GetAllActorsOfClass每幀查一次這種代碼改C后用Engine的TActorIterator或者維護一個Actor列表緩存性能會好很多。4.3 Actor管理、對象查詢與事件分發(fā)場景里Actor數(shù)量太多本身就是原罪。一個1000米x1000米的開放場景如果隨便放幾萬個靜態(tài)Actor每個Actor就算不Tick光是為它們管理的開銷和剔除計算就夠CPU喝一壺的了。優(yōu)化方式包括能合并的網(wǎng)格就合并靜態(tài)物體可以用HISMHierarchical Instanced Static Mesh或者ISMCInstanced Static Mesh Component合并減少Actor數(shù)量和Draw Call。UE5的Nanite也支持實例化可以大幅壓低場景里的Actor數(shù)量。事件分發(fā)避免廣播風暴藍圖里大量使用Event Dispatcher或者AllActorsOfClass監(jiān)聽廣播當事件一觸發(fā)所有Actor都被喚醒執(zhí)行一遍代價很高。優(yōu)先用Interface或者GameplayMessage的輕量級事件系統(tǒng)按需訂閱。避免每幀GetActorLocation反復調在藍圖里每幀多次獲取Actor位置、組件位置時會有C調用開銷批量處理或者緩存數(shù)據(jù)能顯著降低耗時。場景查詢Sweep、Overlap慎用物理查詢是很昂貴的操作尤其是每幀進行大量SphereOverlap。合理做法是降低查詢頻率每0.2秒查一次、縮小查詢范圍或者用異步查詢。4.4 多線程與異步加載UE本身是多線程引擎但GameThread的很多操作仍然是串行的。要讓CPU利用率更高可以考慮用并行For循環(huán)ParallelFor和TaskGraph系統(tǒng)把可以并行的計算分散到工作線程上。比如AI的批量尋路計算、海量物件的批量位置更新都適合通過AsyncTask放到后臺線程執(zhí)行。異步加載Async Loading更是優(yōu)化加載卡頓的關鍵。默認情況下Level加載時會同步加載所有資源Lightmass烘焙貼圖、角色動畫序列等在加載時全都要讀取到內存里如果資源過大畫面就會卡住。開啟異步加載的方式是在Project Settings里勾選Async Loading Time Limit合理設置每幀加載預算讓資源分幀加載避免大面積卡頓。配合PreloadLevel Streaming可以在玩家接近某區(qū)域前提前加載資源實現(xiàn)無縫切換。5. 內存、加載與烘焙設置的細節(jié)5.1 資源加載與Level StreamingLevel Streaming是開放世界和大地圖項目的必備方案。把大場景拆成多個子關卡Sub-Level玩家進入某區(qū)域時動態(tài)加載相鄰關卡離開時卸載這樣內存占用和初始加載時間都能控制在合理范圍。核心配置參數(shù)包括Streaming Distance子關卡的加載半徑和卸載半徑距離設置太大會提前加載過多資源太小會導致玩家突然看到空地。Level Streaming的加載方式支持Always Loaded一開始就加載、Blueprint動態(tài)控制加載和Distance按距離自動加載。我習慣用Blueprint方式自由度更高可以在玩家到達前根據(jù)條件提前觸發(fā)加載。子關卡內的資源粒度一個子關卡不要塞太多大資源最好控制在50~100MB以內。工程再大拆得越細加載就越流暢。此外還要管理好每個關卡里的資源Ref。一個常見的坑是某子關卡明明已經(jīng)卸載了但因為場景里某個Actor還引用著它的資源內存一直不被釋放。所以要用Size Map和Reference Viewer檢查資源引用關系盡量讓子關卡之間不互相引用。5.2 紋理池與內存預算紋理是內存占用的絕對大頭。UE的紋理流送Texture Streaming機制會自動管理紋理在內存中的駐留情況但如果不做預算控制很容易爆顯存。相關的控制臺變量r.Streaming.PoolSize # 紋理池大小PC默認1000MB移動端建議256~512MB r.Streaming.MaxTempMemoryAllowed # 臨時內存上限 r.Streaming.NumStaticComponentsProcessedPerFrame # 每幀處理的靜態(tài)組件數(shù)量調節(jié)流送速度項目里要嚴格執(zhí)行紋理尺寸預算遠景貼圖用512x512以內角色貼圖控制在2048x2048以內貼圖壓縮格式優(yōu)先選擇ASTC移動端或BC7PC。材質里也不要隨便加載原尺寸紋理資源導入時統(tǒng)一設置最大紋理尺寸防止4K貼圖被到處拖進場景。5.3 Cook/烘焙參數(shù)與平臺差異化打包Cook時的參數(shù)直接影響運行性能。幾個關鍵設置Shader CompressionShader壓縮對于移動端項目勾選Share Material Shader Code和Shared Non-Native Shader Libraries可以大幅減少了包體和運行時Shader編譯壓力。Cook設置里關閉不需要的平臺比如PC版本不要打包移動端Shader能顯著減少包體。Texture Bake設置針對不同平臺設置不同的紋理格式否則PC的高清紋理被塞進手機包內存直接爆。使用Per-Platform Render Settings比如PC上的陰影質量、后期特效等級可以高一些移動端用低檔配合Scalability設置控制不同檔位的效果。5.4 Shader編譯卡頓與PSO預緩存游戲運行過程中突然卡頓一大半最常見的原因就是PSOPipeline State Object編譯。首次遇到一個未緩存的材質組合時驅動要現(xiàn)場編譯會導致幾十毫秒甚至幾百毫秒的停頓。解決辦法是開啟PSO預緩存Pipeline State Cacher.ShaderPipelineCache.Enabled1 r.ShaderPipelineCache.BatchSize50 r.ShaderPipelineCache.SaveAfterPSOsLogged1再加上Precache PSO的啟動場景讓游戲加載時預先把常用材質組合編譯好。UE5還提供了Shader Code LibraryShader代碼庫把常用Shader預先編譯進包體進一步減少運行時編譯。這塊對開放世界、多材質項目尤其重要不開PSO緩存的項目就算幀率再高也會因為頻繁卡頓被玩家噴死。6. 實戰(zhàn)案例把一個Demo從40幀優(yōu)化到穩(wěn)定60幀6.1 初始性能數(shù)據(jù)采集拿一個我最近處理過的場景為例一個典型的PC端Demo城市街道場景包含建筑、植被、路燈、行人NPC場景范圍約200米x200米目標幀率60幀。初始狀態(tài)下跑起來用stat unit看到的數(shù)據(jù)Frame: 24.5ms Game: 10.2ms Draw: 13.8ms GPU: 19.6ms平均幀率40幀左右且不穩(wěn)定偶爾掉到30幀以下。明顯瓶頸在渲染端GPU 19.6ms超過了16.6ms預算但Draw也有13.8ms說明渲染線程組織命令的開銷也不少GameThread相對健康。6.2 問題定位與優(yōu)化動作先用ProfileGPU看GPU各Pass耗時結果發(fā)現(xiàn)BasePass6.8ms偏高說明不透明物體的繪制像素量太大Shadows4.2ms動態(tài)陰影太重Translucency3.5ms半透明物體過度繪制嚴重PostProcessing2.1ms后處理疊加太多于是做了這些優(yōu)化關閉場景里大部分裝飾燈的動態(tài)投影只保留主光源的CSM。陰影Pass從4.2ms降到了1.5ms。把場景里的玻璃欄桿改成了Masked材質減少半透明混合同時把幾個大面積半透明廣告牌刪掉。Translucency從3.5ms降到0.8ms。降低PostProcess的Bloom質量關閉SSR和MBPost從2.1ms降到0.6ms。給所有建筑模型生成LOD并檢查Nanite部分靜態(tài)結構改成Nanite后三角形數(shù)量下降BasePass降到3.5ms。另外檢查stat scenerendering發(fā)現(xiàn)Draw Call有4000多次偏高。用HISM把同種植被批量合并Draw Call降到1800次。Draw耗時從13.8ms降到8.5ms。6.3 優(yōu)化前后的數(shù)據(jù)對比與總結經(jīng)過這一輪調整同樣的場景再測Frame: 14.8ms Game: 8.5ms Draw: 8.2ms GPU: 13.5ms穩(wěn)定在60幀以上偶爾復雜角度掉到55幀但P99從原來的40ms降到了22ms流暢感提升非常明顯。這就印證了一點性能優(yōu)化的本質是找出最貴的幾個開銷點集中火力打掉它們而不是均勻地到處削減。如果你平均分配優(yōu)化精力可能最后每一項都優(yōu)化了但幀率并沒有本質提升。7. 常見問題與排查技巧實錄7.1 典型問題速查表問題現(xiàn)象排查方法常見解決方案整體幀率低但不確定瓶頸stat unit查看Game/Draw/GPU耗時按耗時最高的部分定向優(yōu)化場景中某區(qū)域特別卡打開ProfileGPU或使用r.ShaderComplexity查看查看是否有大量半透明或復雜材質游戲過程中間歇性卡頓Unreal Insights抓取幀時間曲線定位卡頓點查看是否有資源加載或PSO編譯切換到某關卡時長時間黑屏檢查加載方式和同步加載資源開啟異步加載、優(yōu)化Level Streaming距離內存持續(xù)上升不釋放stat memory觀察增長Memory Profiler抓取內存申請檢查資源引用泄漏、紋理流送池設置移動端同場景比PC端掉幀嚴重真機Profile查看Imagination/Adreno計數(shù)器關閉SSR、降低陰影級聯(lián)、減少半透明紋理格式改為ASTCDraw Call高但場景明顯簡單stat scenerendering查看Buckets數(shù)據(jù)使用HISM/ISM合批檢查是否有重復粒子特效陰影閃爍或遠景陰影跳動檢查CSM級聯(lián)數(shù)和陰影距離設置調整r.Shadow.DistanceScale、級聯(lián)層級、或開啟穩(wěn)定化7.2 獨家避坑技巧第一個坑全部依賴GPU開銷分析忽略CPU線程之間的等待。有些項目GPU耗時看著不高幀率卻上不去多半是GameThread耗時太長導致RenderThread在等待。stat unit里的Draw耗時對應渲染線程但如果你用了大量跨線程通信或藍圖事件RenderThread可能被GameThread拖住。這種問題用Unreal Insights看線程時間軸才能看出來單看平均值很難發(fā)現(xiàn)。第二個坑優(yōu)化后不看P99只看平均幀率。平均幀率達標了但偶爾卡一下的感受其實很糟糕。我在項目里每次改動后都要看P99和P1數(shù)據(jù)尤其是開放世界項目加載、流送、Shader編譯都可能造成瞬間卡頓如果不盯P99這些卡頓會被平均值掩蓋掉。第三個坑過早優(yōu)化和過度優(yōu)化。有些團隊在原型階段就瘋狂追求60幀結果功能迭代被拖慢有些項目到后期才做性能優(yōu)化改起來傷筋動骨。我的經(jīng)驗是原型階段別太較真性能但架構上要有預留比如瓦片關卡拆分、資源命名規(guī)范、LOD框架功能穩(wěn)定后每個里程碑做一次性能評審對照紅線數(shù)據(jù)決定改還是不改。優(yōu)化跟隨版本走而不是等最后一次性大掃除。第四個坑移動端項目用PC數(shù)據(jù)推算手機性能。PC上60幀跑的飛起挪到中端手機可能掉到20幀。不同GPU架構的差異極大移動端的Fillrate、帶寬、功率限制都不同。所以移動端項目一定要從第一天就用真機做Build驗證而且至少準備兩臺不同檔次的目標機一臺高配一臺低配分別定性能基線。寫在最后的一點體會做UE性能優(yōu)化這幾年最深的體會是性能不是調出來的是設計出來的。好的關卡設計、好的資源管理、嚴謹?shù)腖OD策略、合理的Actor架構這些在開發(fā)早期定下了基調后期優(yōu)化只是在補漏洞。如果前期不管不顧后期再多優(yōu)化技巧也救不回一個到處是半透明特效、幾萬個Actor滿天飛、所有資源都是4K貼圖的場景。所以我建議每一個剛接觸UE優(yōu)化的朋友先從建立一個可量化的性能預算表開始針對自己的目標平臺把GPU耗時、Draw Call、內存、加載時間逐項列出來每完成一個功能就對照著檢查一次。等你把這個表跑順了再回頭看那些卡頓問題會發(fā)現(xiàn)大多數(shù)根本不用優(yōu)化從一開始就不該犯。最后分享一個小技巧優(yōu)化完一個場景后隨便找一個不太好看的視角截一張stat unit數(shù)據(jù)圖存下來當性能基線。項目越往后這個基線的價值就越大——它能幫你快速判斷新加的功能是不是又把性能拉垮了。我之前就是靠這幾個基線文件在版本迭代時省下了大量排查時間。