1. 項(xiàng)目概述為什么你的Unity場(chǎng)景總是“卡”做Unity開(kāi)發(fā)尤其是涉及到稍微復(fù)雜一點(diǎn)的3D場(chǎng)景最頭疼的問(wèn)題莫過(guò)于“卡頓”。明明美術(shù)資源很精美邏輯代碼也寫(xiě)得沒(méi)問(wèn)題但游戲跑起來(lái)就是幀率不穩(wěn)手機(jī)發(fā)燙玩家體驗(yàn)直線下降。這背后十有八九是場(chǎng)景優(yōu)化沒(méi)做到位。場(chǎng)景優(yōu)化不是一個(gè)炫技的“高級(jí)”話題而是每個(gè)Unity開(kāi)發(fā)者從項(xiàng)目初期就必須貫穿始終的“基本功”。它直接決定了你的游戲能否流暢運(yùn)行能否適配更多中低端設(shè)備最終影響產(chǎn)品的留存率和口碑。很多人對(duì)優(yōu)化的理解還停留在“最后再做”的階段或者簡(jiǎn)單地認(rèn)為就是降低模型面數(shù)、壓縮貼圖。這其實(shí)是一個(gè)巨大的誤區(qū)。真正的場(chǎng)景優(yōu)化是一個(gè)系統(tǒng)工程涵蓋了從資源導(dǎo)入、場(chǎng)景搭建、實(shí)時(shí)渲染到最終打包的完整管線。它要求開(kāi)發(fā)者具備“全局視野”能像偵探一樣在游戲運(yùn)行的每一幀里精準(zhǔn)地找到性能瓶頸的“元兇”——是CPU算力不足是GPU渲染壓力過(guò)大還是內(nèi)存和顯存在瘋狂“吃緊”這次我們就拋開(kāi)那些零散的知識(shí)點(diǎn)系統(tǒng)地拆解一套Unity游戲場(chǎng)景優(yōu)化的“全攻略”。我會(huì)結(jié)合自己踩過(guò)的無(wú)數(shù)個(gè)坑從底層原理到上層實(shí)踐從靜態(tài)場(chǎng)景到動(dòng)態(tài)交互為你梳理出一條清晰的優(yōu)化路徑。無(wú)論你是在做一款開(kāi)放世界手游還是一個(gè)精致的獨(dú)立游戲這套方法都能幫你構(gòu)建出既好看又流暢的游戲世界。2. 優(yōu)化前的核心準(zhǔn)備建立性能基準(zhǔn)與監(jiān)控體系在動(dòng)手優(yōu)化之前盲目地東改西改是最低效的做法。優(yōu)化必須有明確的目標(biāo)和可量化的指標(biāo)。這就好比醫(yī)生治病得先做檢查拿到化驗(yàn)單才知道問(wèn)題出在哪里。2.1 確立性能目標(biāo)與量化指標(biāo)首先你需要為你的項(xiàng)目設(shè)定明確的性能目標(biāo)。這個(gè)目標(biāo)不能是模糊的“不卡”而必須是具體的數(shù)字。目標(biāo)幀率 (Target FPS)對(duì)于移動(dòng)端通常目標(biāo)是穩(wěn)定30FPS或60FPS對(duì)于PC端可能是60FPS或更高。這是最直觀的體驗(yàn)指標(biāo)。每幀耗時(shí) (Frame Time)幀率的倒數(shù)。例如目標(biāo)60FPS意味著每幀必須在16.67毫秒ms內(nèi)完成。這個(gè)指標(biāo)能更精確地定位是CPU還是GPU成了瓶頸。內(nèi)存占用 (Memory Usage)包括總內(nèi)存、托管堆內(nèi)存、紋理內(nèi)存等。過(guò)高的內(nèi)存占用是導(dǎo)致游戲閃退的罪魁禍?zhǔn)子绕涫窃谝苿?dòng)設(shè)備上。Draw Call數(shù)量這是CPU向GPU發(fā)送渲染指令的次數(shù)。Draw Call過(guò)高會(huì)嚴(yán)重消耗CPU時(shí)間是早期優(yōu)化最需要關(guān)注的指標(biāo)之一。三角形面數(shù) (Tris Count)和頂點(diǎn)數(shù) (Vert Count)衡量GPU幾何處理壓力的核心指標(biāo)。注意不同平臺(tái)、不同設(shè)備性能差異巨大。你的目標(biāo)應(yīng)該是“在目標(biāo)設(shè)備上達(dá)到目標(biāo)幀率”。例如你的目標(biāo)用戶是使用三年前中端安卓機(jī)的玩家那么你就需要用這類設(shè)備作為測(cè)試基準(zhǔn)而不是用最新的旗艦機(jī)。2.2 掌握核心性能分析工具工欲善其事必先利其器。Unity提供了一套強(qiáng)大的性能分析工具你必須像熟悉自己的代碼編輯器一樣熟悉它們。Profiler (分析器)這是你的“終極武器”。通過(guò)Window Analysis Profiler打開(kāi)。CPU Usage查看每一幀CPU時(shí)間都花在了哪里。重點(diǎn)關(guān)注Rendering、Scripts、Physics等模塊。如果Rendering占比過(guò)高可能是Draw Call太多或GPU壓力大如果Scripts占比過(guò)高就需要檢查你的邏輯代碼。GPU Usage需要獨(dú)立顯卡支持?？梢圆榭碐PU在各個(gè)渲染階段如頂點(diǎn)著色、像素著色的耗時(shí)精準(zhǔn)定位圖形瓶頸。Memory查看詳細(xì)的內(nèi)存分配情況。關(guān)注GC Alloc垃圾回收分配頻繁的GC會(huì)導(dǎo)致卡頓。也要關(guān)注紋理、網(wǎng)格等資產(chǎn)的內(nèi)存占用。Rendering查看Draw Calls、SetPass Calls材質(zhì)球切換次數(shù)、三角形/頂點(diǎn)數(shù)量等關(guān)鍵渲染指標(biāo)。Frame Debugger (幀調(diào)試器)通過(guò)Window Analysis Frame Debugger打開(kāi)。它可以讓你“暫?！痹谀骋粠⒁徊讲讲榭碪nity是如何執(zhí)行每一個(gè)Draw Call的。你可以清晰地看到每個(gè)物體的渲染順序、使用的Shader、渲染狀態(tài)是分析渲染性能特別是Overdraw和材質(zhì)合并的神器。Stats 窗口在Game視圖的右上角點(diǎn)擊Stats按鈕。這是一個(gè)快速查看當(dāng)前幀性能概覽的窗口包括FPS、CPU/GPU時(shí)間、Draw Calls、三角形面數(shù)等非常方便。實(shí)操心得我習(xí)慣在開(kāi)發(fā)過(guò)程中始終在Game視圖旁打開(kāi)Stats窗口。一旦發(fā)現(xiàn)幀率下降或Draw Call激增就立刻打開(kāi)Profiler進(jìn)行深度分析。養(yǎng)成“數(shù)據(jù)驅(qū)動(dòng)優(yōu)化”的習(xí)慣而不是憑感覺(jué)猜測(cè)。3. 資源導(dǎo)入與預(yù)處理從源頭控制性能消耗很多性能問(wèn)題其實(shí)在資源導(dǎo)入U(xiǎn)nity的那一刻就已經(jīng)埋下了種子。優(yōu)化要從源頭抓起。3.1 模型網(wǎng)格 (Mesh) 優(yōu)化模型是場(chǎng)景的骨架其復(fù)雜度直接影響GPU的頂點(diǎn)處理和三角形光柵化。合理控制面數(shù)沒(méi)有絕對(duì)標(biāo)準(zhǔn)但有一個(gè)原則離攝像機(jī)越近、出現(xiàn)頻率越高的物體可以分配更多的面數(shù)反之則要大力精簡(jiǎn)。例如主角手中的武器模型可能需要5000個(gè)三角面而遠(yuǎn)處的一棵樹(shù)可能只需要200個(gè)面?？梢允褂?D建模軟件如Blender、Maya的減面工具進(jìn)行預(yù)處理。優(yōu)化頂點(diǎn)數(shù)據(jù)在模型的導(dǎo)入設(shè)置Import Settings中檢查Mesh Compression選項(xiàng)。開(kāi)啟后可以減小網(wǎng)格文件大小和運(yùn)行時(shí)內(nèi)存但可能會(huì)引入微小的精度誤差對(duì)于需要精確碰撞檢測(cè)的模型需謹(jǐn)慎。移除多余屬性在Rig和Animation標(biāo)簽頁(yè)如果模型不需要?jiǎng)赢?huà)確保Animation Type設(shè)置為None并關(guān)閉Skin Weights選項(xiàng)。這可以避免導(dǎo)入不必要的骨骼和蒙皮數(shù)據(jù)節(jié)省內(nèi)存。利用LOD (Level of Detail)這是處理中遠(yuǎn)景模型的王牌技術(shù)。為同一個(gè)模型創(chuàng)建多個(gè)細(xì)節(jié)層次高模、中模、低模根據(jù)物體與攝像機(jī)的距離自動(dòng)切換。Unity內(nèi)置了LOD Group組件。關(guān)鍵技巧低模不僅要減少面更要重新拓?fù)涫蛊漭喞c高模近似避免切換時(shí)明顯的“跳動(dòng)”感。3.2 紋理貼圖 (Texture) 優(yōu)化紋理是顯存和內(nèi)存帶寬的“大戶”優(yōu)化紋理往往是提升性能最有效的手段之一。格式與壓縮平臺(tái)選擇在紋理導(dǎo)入設(shè)置的Platform覆蓋中為不同平臺(tái)Android, iOS, PC選擇最優(yōu)的壓縮格式。例如Android常用ASTCiOS用PVRTCPC用DXT/BC系列。這些是硬件支持的壓縮格式能大幅減少顯存占用和帶寬。Max Size絕不盲目使用4096x4096的大圖。根據(jù)紋理在屏幕上最終顯示的最大尺寸來(lái)設(shè)定。一個(gè)UI圖標(biāo)可能只需要128x128一個(gè)角色皮膚貼圖2048x2048可能就足夠了。實(shí)測(cè)經(jīng)驗(yàn)在移動(dòng)設(shè)備上2048已經(jīng)是很大的尺寸了很多情況下1024甚至512都能獲得不錯(cuò)的效果。Mipmaps務(wù)必為3D場(chǎng)景中的紋理開(kāi)啟Mipmaps。它是一系列逐漸縮小的紋理鏈當(dāng)物體離遠(yuǎn)時(shí)GPU會(huì)自動(dòng)使用更小的紋理既能減少像素填充率壓力也能有效避免遠(yuǎn)處紋理的“閃爍”瑕疵。雖然會(huì)增加約33%的紋理內(nèi)存但帶來(lái)的渲染質(zhì)量和性能提升是值得的。圖集 (Atlas) 打包將大量小紋理如UI元素、道具圖標(biāo)、場(chǎng)景小物件貼圖打包到一張大紋理中。這能極大地減少材質(zhì)球數(shù)量和Draw Call。可以使用Unity自帶的Sprite Atlas針對(duì)2D精靈或第三方工具如TexturePacker來(lái)生成圖集。3.3 音頻與動(dòng)畫(huà)資源音頻將較長(zhǎng)的背景音樂(lè)設(shè)置為Streaming流式加載避免一次性加載到內(nèi)存。短音效則使用Decompress On Load加載時(shí)解壓或Compressed In Memory內(nèi)存中壓縮在內(nèi)存和CPU解壓開(kāi)銷間取得平衡。動(dòng)畫(huà)對(duì)于人形動(dòng)畫(huà)啟用Optimize Game Objects選項(xiàng)可以在運(yùn)行時(shí)移除不必要的GameObject層級(jí)提升動(dòng)畫(huà)計(jì)算性能。對(duì)于大量重復(fù)的簡(jiǎn)單動(dòng)畫(huà)如旋轉(zhuǎn)的風(fēng)車考慮使用腳本驅(qū)動(dòng)而非Animator以節(jié)省開(kāi)銷。4. 場(chǎng)景構(gòu)建與渲染管線優(yōu)化當(dāng)資源準(zhǔn)備就緒開(kāi)始搭建場(chǎng)景時(shí)你的每一個(gè)設(shè)計(jì)決策都會(huì)影響最終性能。4.1 降低Draw Call合批 (Batching) 的藝術(shù)Draw Call是CPU準(zhǔn)備并命令GPU渲染一個(gè)物體的開(kāi)銷。減少Draw Call是優(yōu)化早期最立竿見(jiàn)影的手段。靜態(tài)合批 (Static Batching)原理將標(biāo)記為Static靜態(tài)且使用相同材質(zhì)的物體在運(yùn)行前或運(yùn)行時(shí)合并成一個(gè)大的網(wǎng)格從而用一個(gè)Draw Call渲染多個(gè)物體。操作在場(chǎng)景中不動(dòng)的物體如建筑、地面、巖石在其Inspector右上角勾選Static復(fù)選框。然后在Player Settings中確保開(kāi)啟了靜態(tài)合批。注意事項(xiàng)靜態(tài)合批會(huì)增加內(nèi)存和磁盤(pán)空間占用因?yàn)樗鎯?chǔ)了合并后的網(wǎng)格數(shù)據(jù)。對(duì)于大量重復(fù)的靜態(tài)物體如草地、碎石效果極佳。動(dòng)態(tài)合批 (Dynamic Batching)原理Unity在運(yùn)行時(shí)每幀自動(dòng)將滿足條件頂點(diǎn)數(shù)少于300、使用相同材質(zhì)、縮放一致等的動(dòng)態(tài)物體進(jìn)行合批。局限性條件苛刻對(duì)頂點(diǎn)屬性有要求且CPU開(kāi)銷隨批次數(shù)增加而增加。對(duì)于現(xiàn)代項(xiàng)目尤其是移動(dòng)端不應(yīng)過(guò)度依賴動(dòng)態(tài)合批。它更適合處理少量、簡(jiǎn)單的UI或粒子。GPU Instancing原理這是處理大量相同物體如樹(shù)木、草叢、子彈的最優(yōu)解。它通過(guò)一次Draw Call向GPU傳遞一個(gè)基礎(chǔ)網(wǎng)格和一批變換位置、旋轉(zhuǎn)、縮放矩陣由GPU實(shí)例化渲染。操作需要Shader支持。Unity標(biāo)準(zhǔn)著色器已默認(rèn)支持。確保材質(zhì)的Enable GPU Instancing選項(xiàng)被勾選。然后在代碼中使用MaterialPropertyBlock來(lái)為每個(gè)實(shí)例設(shè)置不同的顏色、浮點(diǎn)參數(shù)等避免材質(zhì)變體爆炸。優(yōu)勢(shì)CPU開(kāi)銷極低能輕松渲染成千上萬(wàn)的實(shí)例物體。是開(kāi)放世界、大規(guī)模植被場(chǎng)景的必備技術(shù)。避坑技巧合批的核心是“相同材質(zhì)”。這意味著不僅Shader要一樣紋理、著色器屬性都要一樣。如果你需要讓一片樹(shù)林里的樹(shù)有不同的顏色不要?jiǎng)?chuàng)建多個(gè)材質(zhì)球而應(yīng)該使用MaterialPropertyBlock來(lái)修改_Color屬性這樣它們依然可以被合批或?qū)嵗?.2 遮擋剔除 (Occlusion Culling)攝像機(jī)看不到的物體就不應(yīng)該被渲染。遮擋剔除就是實(shí)現(xiàn)這一點(diǎn)的技術(shù)。原理在烘焙階段Unity會(huì)預(yù)先計(jì)算場(chǎng)景中從不同視角哪些物體會(huì)被其他物體擋住。運(yùn)行時(shí)根據(jù)攝像機(jī)位置快速剔除那些被完全遮擋的物體減少發(fā)送給GPU的渲染數(shù)據(jù)。操作在Window Rendering Occlusion Culling打開(kāi)窗口。在Object標(biāo)簽頁(yè)為場(chǎng)景中較大的、能擋住其他物體的物體如墻壁、山體勾選Occluder Static為被遮擋的小物體勾選Occludee Static。切換到Bake標(biāo)簽頁(yè)設(shè)置參數(shù)如Smallest Occluder決定多小的物體會(huì)被視為遮擋體然后點(diǎn)擊Bake。這會(huì)生成一個(gè)遮擋數(shù)據(jù)文件。適用場(chǎng)景室內(nèi)場(chǎng)景、城市街道等遮擋關(guān)系復(fù)雜的場(chǎng)景效果顯著。對(duì)于一望無(wú)際的平原或天空盒則沒(méi)有效果。注意事項(xiàng)烘焙過(guò)程較慢且會(huì)增加構(gòu)建后的大小。需要仔細(xì)調(diào)整參數(shù)避免過(guò)度剔除物體閃爍或剔除不足性能提升不明顯。4.3 光照與陰影優(yōu)化實(shí)時(shí)光照和陰影非常消耗性能尤其是動(dòng)態(tài)光源和陰影。烘焙光照 (Baked Lighting)策略將場(chǎng)景中靜態(tài)物體的光照信息直接光、間接光、陰影預(yù)先計(jì)算并“烘焙”到光照貼圖Lightmap上。運(yùn)行時(shí)直接使用貼圖幾乎沒(méi)有性能開(kāi)銷。操作將靜態(tài)物體標(biāo)記為L(zhǎng)ightmap Static。使用Mixed或Baked模式的光源進(jìn)行烘焙。這是提升場(chǎng)景視覺(jué)質(zhì)量和幀率的首選方案。技巧合理設(shè)置光照貼圖的分辨率和壓縮格式在質(zhì)量和內(nèi)存間權(quán)衡。使用Progressive Lightmapper漸進(jìn)光照烘焙器可以更直觀地控制烘焙質(zhì)量和時(shí)間。實(shí)時(shí)光照與陰影精簡(jiǎn)數(shù)量嚴(yán)格限制每幀激活的實(shí)時(shí)光源數(shù)量特別是投射陰影的光源。移動(dòng)端可能只支持1-2個(gè)。優(yōu)化陰影分辨率在Quality Settings中降低陰影貼圖Shadow Map的分辨率如從High降到Medium。距離減小陰影的渲染距離Shadow Distance遠(yuǎn)處的物體不渲染陰影。級(jí)聯(lián)陰影映射 (Cascaded Shadow Maps, CSM)對(duì)于方向光如太陽(yáng)開(kāi)啟CSM。它將攝像機(jī)的視錐體分成近、中、遠(yuǎn)幾個(gè)層級(jí)分別用不同精度的陰影貼圖渲染。這能保證近處陰影清晰遠(yuǎn)處陰影性能可接受。調(diào)整級(jí)聯(lián)數(shù)量和分割比例是關(guān)鍵。使用Light Probes光照探針為動(dòng)態(tài)物體角色、車輛提供高質(zhì)量的間接光照。光照探針存儲(chǔ)了場(chǎng)景空間某一點(diǎn)的烘焙光照信息動(dòng)態(tài)物體經(jīng)過(guò)時(shí)采樣這些信息能讓它們更好地融入烘焙光照的環(huán)境且開(kāi)銷很低。4.4 后期處理與特效屏幕后處理效果如Bloom, SSAO, 景深和粒子特效是“幀率殺手”使用需克制。按需啟用不是所有場(chǎng)景都需要全屏后處理?？梢詾楦叨藱C(jī)開(kāi)啟低端機(jī)關(guān)閉。使用Quality Settings來(lái)配置不同質(zhì)量等級(jí)下的后處理?xiàng)?。降低采樣許多后處理效果支持降采樣如以一半分辨率進(jìn)行計(jì)算能大幅提升性能對(duì)最終畫(huà)質(zhì)影響可能并不明顯。粒子系統(tǒng)控制最大粒子數(shù)量。使用簡(jiǎn)單的Shader避免在粒子著色器中進(jìn)行復(fù)雜計(jì)算。對(duì)于大量重復(fù)的粒子效果如遠(yuǎn)處森林的飛鳥(niǎo)群可以考慮用公告板Billboard或極簡(jiǎn)的實(shí)例化網(wǎng)格來(lái)代替。5. 腳本與運(yùn)行時(shí)邏輯優(yōu)化當(dāng)渲染層面的優(yōu)化做到一定程度后CPU邏輯就可能成為新的瓶頸。腳本寫(xiě)得不好同樣能讓高端機(jī)卡成幻燈片。5.1 避免昂貴的每幀操作有些函數(shù)或操作開(kāi)銷很大應(yīng)避免在Update()中頻繁調(diào)用。Find()、GetComponent()系列這些函數(shù)會(huì)遍歷場(chǎng)景層級(jí)或組件列表是性能黑洞。絕對(duì)不要在Update中調(diào)用Find(“ObjectName”)。正確的做法是在Start()或Awake()中緩存引用。使用序列化字段在Inspector面板中直接拖拽賦值。Camera.main這背后其實(shí)是一個(gè)FindGameObjectsWithTag(“MainCamera”)。應(yīng)該緩存攝像機(jī)引用。字符串操作在頻繁調(diào)用的循環(huán)中避免拼接字符串如Debug.Log(“Score: “ score)這會(huì)生成大量臨時(shí)字符串引發(fā)GC垃圾回收。對(duì)于需要頻繁更新的UI文本可以考慮使用StringBuilder。5.2 管理好垃圾回收 (Garbage Collection)托管語(yǔ)言如C#的GC是導(dǎo)致幀率周期性卡頓的常見(jiàn)原因。目標(biāo)是減少乃至消除每幀的堆內(nèi)存分配。識(shí)別分配源使用Profiler的CPU模塊查看GC Alloc列。任何非零的分配都可能在未來(lái)引發(fā)GC。常見(jiàn)分配陷阱與解決方案陷阱原因解決方案在Update中創(chuàng)建新Vector3等值類型值類型裝箱如放入Listobject或方法返回新實(shí)例復(fù)用變量使用ref參數(shù)避免裝箱使用foreach循環(huán)某些集合可能產(chǎn)生枚舉器對(duì)象分配改用for循環(huán)LINQ查詢會(huì)產(chǎn)生中間集合分配在性能關(guān)鍵處避免使用或使用非分配版本如Unity的BurstCollections包閉包和匿名方法會(huì)捕獲上下文生成類實(shí)例在頻繁調(diào)用的地方如每幀事件避免使用GetComponentT()返回新組件引用通常較小緩存結(jié)果對(duì)象池 (Object Pooling)對(duì)于需要頻繁創(chuàng)建和銷毀的對(duì)象如子彈、敵人、特效使用對(duì)象池是黃金法則。預(yù)先創(chuàng)建一批對(duì)象放入池中需要時(shí)取出激活用完放回池中禁用避免反復(fù)的Instantiate和Destroy帶來(lái)的內(nèi)存分配與釋放開(kāi)銷。Unity官方現(xiàn)在也提供了ObjectPool類。5.3 物理與動(dòng)畫(huà)性能物理引擎 (Physics)簡(jiǎn)化碰撞體用簡(jiǎn)單的BoxCollider、SphereCollider代替復(fù)雜的MeshCollider。分層管理通過(guò)Physics Layers和碰撞矩陣避免不必要的物體間碰撞檢測(cè)。調(diào)整更新頻率對(duì)于不需要精確物理模擬的物體可以降低Rigidbody的Interpolate和Collision Detection模式甚至將物理更新頻率Fixed Timestep調(diào)低如從0.02s調(diào)到0.04s但要小心影響游戲手感。動(dòng)畫(huà)系統(tǒng) (Animator)減少動(dòng)畫(huà)狀態(tài)機(jī)中不必要的過(guò)渡和條件檢查。對(duì)于大量相同的敵人可以考慮使用Animator的Culling Mode設(shè)置為Based on Renderers當(dāng)敵人不在屏幕內(nèi)時(shí)動(dòng)畫(huà)更新頻率會(huì)自動(dòng)降低。在Unity 2022 LTS及以后版本積極評(píng)估并使用Animation Rigging和Unity PhysicsDOTS等更高效的新技術(shù)棧來(lái)替代傳統(tǒng)方案處理大規(guī)模角色動(dòng)畫(huà)和物理模擬。6. 平臺(tái)特定優(yōu)化與發(fā)布設(shè)置最后針對(duì)目標(biāo)平臺(tái)進(jìn)行微調(diào)能榨取出最后一點(diǎn)性能。6.1 圖形API與質(zhì)量設(shè)置圖形API選擇在Player Settings Graphics中設(shè)置圖形API的順序。例如對(duì)于AndroidVulkan可能比OpenGL ES 3性能更好但兼容性稍差需要測(cè)試。iOS通常首選Metal。質(zhì)量等級(jí) (Quality Settings)這是控制圖形質(zhì)量的全局開(kāi)關(guān)。通常預(yù)設(shè)Low、Medium、High、Ultra幾個(gè)等級(jí)。你需要為每個(gè)等級(jí)精細(xì)配置Pixel Light Count像素光數(shù)量調(diào)低。Texture Quality紋理質(zhì)量Full Res或Half Res。Anisotropic Textures各向異性過(guò)濾可關(guān)閉或設(shè)為Per Texture。Anti Aliasing抗鋸齒移動(dòng)端可關(guān)閉或使用FXAA。Soft Particles軟粒子關(guān)閉。Shadows陰影相關(guān)設(shè)置分辨率、距離、級(jí)聯(lián)數(shù)是調(diào)優(yōu)重點(diǎn)。運(yùn)行時(shí)切換可以在游戲內(nèi)根據(jù)設(shè)備性能或玩家選擇動(dòng)態(tài)切換QualitySettings.SetQualityLevel()。6.2 構(gòu)建與打包優(yōu)化構(gòu)建壓縮在Player Settings Publishing Settings中選擇合適的應(yīng)用包壓縮方式如LZ4HC在大小和加載速度間平衡。資源分包與按需加載對(duì)于大型場(chǎng)景不要把所有資源都打在一個(gè)包里。使用AssetBundle或Addressable Assets系統(tǒng)將資源按場(chǎng)景、功能模塊拆分實(shí)現(xiàn)動(dòng)態(tài)加載和卸載減少初始內(nèi)存壓力。腳本編譯優(yōu)化確保使用Release模式構(gòu)建這會(huì)啟用代碼優(yōu)化。對(duì)于IL2CPP后端可以嘗試更高的編譯優(yōu)化等級(jí)。6.3 目標(biāo)平臺(tái)特性利用iOS充分利用Metal的特性如Tile-Based Deferred Rendering (TBDR)。注意內(nèi)存警告iOS對(duì)內(nèi)存使用極其敏感。Android設(shè)備碎片化嚴(yán)重必須進(jìn)行廣泛的真機(jī)測(cè)試。關(guān)注GLES版本兼容性以及不同GPU廠商Mali, Adreno, PowerVR的驅(qū)動(dòng)差異。使用Android Profiler或Adreno Profiler進(jìn)行深度分析。WebGL這是限制最多的平臺(tái)。內(nèi)存限制嚴(yán)格代碼需要全部預(yù)編譯。務(wù)必大幅降低紋理分辨率積極使用壓縮紋理減少Draw Call并注意JavaScript與WebAssembly的交互開(kāi)銷。優(yōu)化是一個(gè)永無(wú)止境的過(guò)程也是一門權(quán)衡的藝術(shù)。沒(méi)有“最好”的方案只有“最適合”你當(dāng)前項(xiàng)目目標(biāo)和目標(biāo)硬件的方案。我的習(xí)慣是在項(xiàng)目初期就建立一個(gè)簡(jiǎn)單的性能測(cè)試場(chǎng)景定期用目標(biāo)低端設(shè)備跑一下將性能監(jiān)控作為開(kāi)發(fā)流程的一部分。記住讓游戲流暢運(yùn)行所獲得的成就感絲毫不亞于實(shí)現(xiàn)一個(gè)酷炫的功能。當(dāng)你的游戲能在千元機(jī)上穩(wěn)定跑滿30幀時(shí)你會(huì)感謝今天在優(yōu)化上投入的每一分鐘。