PDF檔案下載地址：（https://download.csdn.net/download/JianZuoGuang/21943001）

第一章渲染原理和流程

1.1. 概述

1.2. 應用階段

1.2.1. 概述

1.2.2. 參與硬體

1.2.3. 階段任務

1.2.4. 資料準備

1.2.5. 粗粒度剔除

1.2.6. 設定渲染狀態

1.2.7. 呼叫DrawCall

1.3. 幾何階段

1.3.1. 概述

1.3.2. 參與硬體

1.3.3. 階段任務

1.4. 光柵化階段

1.4.1. 概述

1.4.2. 參與硬體

1.4.3. 階段任務

1.5. UGUI渲染程序分析

第二章影響性能的因素

1.1. 硬體因素

1.1.1. CPU

1.1.2. GPU

1.1.3. 記憶體

1.2. 軟體\平臺\系統因素

1.2.1. Mono虛擬機

1.2.2. IL2Cpp

1.2.3.
圖形API(DirectX\OpenGL\Vulkan\Metal)

第三章資源標準以及優化方案

1.1. 美術資源制作標準

1.1.1. PC平臺制作標準

1.1.2. 移動平臺制作標準

1.2. 美術資源優化方案

1.3. U3D優化方案

1.3.1. CPU優化

1.3.2. GPU優化

1.3.3. 記憶體優化

1.3.4. UGUI優化

第四章 Todo（附錄）

1.1. 渲染方案（URP）

1.1.1. 正向渲染（Forward Rendering）

1.1.2. 延遲渲染(Deferred Rendering
當前版本不支持)

1.1.3. 總結

1.2. 光照方案(URP）

1.2.1. 混合光照+反射探針+光照探針

1.2.2. 低端硬體設備光照方案

1.2.3. 中、高端硬體設備光照方案

1.3.
MeshBake資源（網格\材質\貼圖）烘焙方案

1.4. UnIty3D資源制作標準參考

渲染原理和流程

概述

渲染到設備螢屏的每一幀畫面，其程序都是將場景中的三維模型、紋理渲染到二維的螢屏上，以像素的形式展現，看似一個簡單的程序，分別需要CPU\GPU\記憶體等硬體資源的參與和配合；CPU\記憶體\GPU相互呼叫的程序，簡稱為渲染流水線，圖形的渲染流水線主要分為以下三個階段：應用階段、幾何階段、光柵化階段，

在這里插入圖片描述

（圖：圖形渲染流水線）

應用階段

概述

獲取需要渲染的網格、材質、貼圖等資訊，并針對不同的繪制需求，設定相應的渲染狀態，將收集的資料加載到顯存中，并通過DrawCall呼叫底層DirectX/OpenGL/Vulkan
API 執行圖元繪制，

參與硬體

由CPU端主導，涉及硬體包括RAM、顯存，

階段任務

收集需要參與繪制的資料，講資料加載到顯存中，
設定渲染狀態，
呼叫DrawCall，提交GPU執行渲染，

資料準備

將需要渲染的資料從硬碟中加載到系統記憶體中，紋理、網格、材質等資料需要被加載到顯存中，
從記憶體RAM中移除渲染資料（頂點坐標、法線方向、頂點顏色、紋理坐標）等，此部分資料已經存盤在顯存中了，RAM中只保留一些CPU仍需要訪問的資料，

粗粒度剔除

剔除一些不在攝像機視野范圍內的網格資料，
視椎體剔除（Frustum Culling）：剔除不在視椎體范圍內的三角形網格，
遮擋剔除（Occlusion Culling）：剔除被遮擋的三角形網格，

設定渲染狀態

指定著色器、材質、光照，
配置材質引數（渲染模式、渲染佇列）
輸出下一渲染階段所需的幾何資訊-渲染圖元（點、線、三角形等）

呼叫DrawCall

輸出渲染圖元，CPU發起繪制命令，向GPU指定一個圖元串列；通知GPU執行渲染，

幾何階段

概述

幾何階段（GPU）：獲取應用階段提交的資料，進行頂點變換計算；將模型頂點從模型空間中變換到螢屏空間中，幾何階段在整個渲染流水線中的主要任務就是：變換三維頂點坐標和執行逐頂點的光照計算，

在這里插入圖片描述

（圖：幾何階段渲染流程）

參與硬體

GPU/顯存

階段任務

頂點著色器（Vertex Shader）

頂點著色器通常用于實作坐標變換、頂點空間變換，逐頂點光照計算，為片元著色器階段提供資料來源，計算頂點中包含的法線、紋理坐標、色彩、光照等資訊，
頂點著色器的目標：將頂點坐標從模型空間變換到齊次裁剪空間，
GPU針對每個頂點執行變換操作（在此階段可編程實作一些特殊的頂點影片），且為了提供頂點著色器的運行效率，頂點之間無法獲取頂點與頂點之間的關系，
基于GPU的并行特性，可執行大量的頂點運算，

在這里插入圖片描述

（圖：頂點坐標變換程序）

曲面細分著色器(Tessellation Stage)

曲面細分著色器是一個可選著色器，通過曲面細分著色器可以實作對三角面進行細分，增加網格的三角面數，提升網格的表現細節，

可對三角網格/三角面進行細分，
基于高度圖/法線圖進行細分，增加細節（置換貼圖）

幾何著色器(Geometry Shader)

幾何著色器是可選著色器，用于執行逐圖元著色操作；或生成更多圖元，開發者可以控制GPU對頂點進行增刪改操作，
要求硬體支持Shader Model 3.0以上

投影（Projection）

GPU將頂點從攝像機觀察空間轉換到裁剪空間
投影方式:正交投影和透視投影

在這里插入圖片描述
(圖左：透視投影/圖右：正交投影)

裁剪(Projection)

裁剪由硬體通過固定演算法來實作，無法通過編程來控制裁剪的程序；但可以通過自定義裁剪操作來配置裁剪，

對攝像機視野范圍外的三角形頂點，根據攝像機的視角范圍生成新的頂點，

在這里插入圖片描述

（圖：圖元裁剪程序）

螢屏映射

螢屏映射階段接收的輸入坐標仍然是三維坐標系下的坐標，螢屏映射的目的是將每個圖元的x和y坐標轉換到螢屏坐標系下，螢屏坐標系是一個二維坐標系，和螢屏解析度有很大的關系，
在這里插入圖片描述

（圖：螢屏映射程序）

光柵化階段

概述

光柵化階段（GPU）：獲取經過幾何階段變換后的三角形片元，并對每個三角形片元進行設定、遍歷、逐片元操作，其中片元著色器用于實作逐片元操作，可編程實作；而逐片元操作階段則執行一些如：顏色修改、深度測驗、alpha測驗等操作，最后提交渲染結果到幀緩沖中，

在這里插入圖片描述

（圖：光柵化階段）

參與硬體

GPU/顯存

階段任務

三角形設定（Triangle Setup）

三角形設定的目標是計算光柵化一個三角網格所需要的必要資訊，由于幾何階段輸出的物件為三角網格的頂點，一個三角形由基礎的點、線、面組成，我們需要獲取三角網格對像素的覆寫情況，我們必須計算每條邊上的像素坐標，

三角形遍歷(Triangle Traversal)

三角形遍歷的目標是檢查每個像素是否被一個三角網格所覆寫，如果像素被三角網格覆寫的話，就會生成一個片元，GPU查找像素被哪些三角網格覆寫的程序就是三角形遍歷的程序，

片元著色器(Fragment Shader)

片元著色器是一個非常重要的可編程著色階段，片元著色器也被稱之為像素著色器，三角形設定和三角形遍歷并不會影響螢屏上每個像素的顏色值，而是會產生一系列的資料資訊，用來描述一個三角形網格是怎樣覆寫每個像素的，

片元著色器接收上一個階段對頂點資訊插值得到的結果，
對紋理進行紋理采樣，根據頂點著色階段輸出的每個頂點對應的紋理坐標（UV）,以光柵化的方式對三角網格的3個頂點對應的紋理坐標進行插值運算，獲取當前片元對應的紋理坐標（UV），
執行紋理采樣、UV插值、光照計算等圖形計算操作，

在這里插入圖片描述

（圖：頂點/片元著色器處理流程）

逐片元操作(Per-Fragment Operation)

逐片元操作作為渲染流水線的最后階段，也稱之為輸出合并階段,針對片元著色器輸出的每一個片元進行一些相關的操作，同時將片元顏色與顏色緩沖區中的顏色進行混合，

這個階段以片元作為資料基礎，決定片元需要被渲染還是丟棄，即逐片元操作階段是決定片元可見性問題的一個重要階段，

檢測片元的可見性：檢測程序包括對片元執行（Alpha測驗\剪切測驗（Scissor
Test）\模板測驗（Stencil Test）\深度測驗（Depth
Test）\混合測驗（Blending））等，
將通過測驗檢驗的片元與顏色緩沖區中的顏色按照指定的方式進行混合，將沒有通過檢測的片元丟棄（Discard），

（圖：逐片元操作流程）

模板測驗（Stencil Test）

模板測驗：在模板測驗中主要參與物件包括某個片元與模板緩沖區，片元為片元著色器階段的輸出的物件；模板緩沖是一個特定的記憶體塊，與螢屏緩沖的大小一致，每個片元在執行模板測驗時，首先取得當前片元所在的位置，并將當前位置與模板緩沖區中的位置進行對比，如果當前片元滿足模板測驗指定的測驗條件，即模板測驗通過，模板測驗通過之后，當前片元的會被寫入到模板緩沖中，在整個渲染幀結束前，模板緩沖區不會被重置，
在這里插入圖片描述

（圖：模板測驗流程圖）

在模板測驗中，由開發者指定一個參考參考值，這個參考值為當前物體的片元提供了標準參考，然后這個參考值會與模板緩沖(Stencil
Buffer)區中當前片元位置的模板值進行比較，模板緩沖區的值，是由之前通過其它測驗的片元寫入的值，比較當前片元的位置與緩沖區中的值，根據比較的結果決定片元是否需要丟棄（Discard），判斷陳述句如下：

模板緩沖條件	說明
Grater	當前片元值＞模板緩沖中的值，通過
GEqual	當前片元值≥模板緩沖中的值，通過
Less	當前片元值＜模板緩沖中的值，通過
LEqual	當前片元值≤模板緩沖中的值，通過
Equal	當前片元值＝模板緩沖中的值，通過
NotEqual	當前片元值≠模板緩沖中的值，通過
Alaways	總是通過
Nerver	總是不通過

深度測驗（Depth Test）

深度測驗：深度測驗主要目的是將當前片元的深度值與已經存在深度緩沖區中的深度值進行比較，根據比較的結果判斷當前片元是否需要被丟棄，通常情況下，我們僅想渲染距離攝像機進且在攝像機可是范圍內的物體，對于那些被遮擋的物體，我們不希望它被渲染到螢屏上，

深度測驗的作業分為兩塊：其中一塊是將片元與緩沖區中的值進行比較，即ZTest;另外一塊是：將片元深度值寫入到緩沖區中，即ZWrite.

深度值：在幾何階段，片元頂點坐標由區域坐標空間變換到了螢屏坐標空間；由一個三維坐標系變換到二維坐標系，在變換程序中，頂點的Z坐標在變換程序中被轉化為深度值，深度值的記錄主要用于記錄片元距離攝像機的遠近程度，

在這里插入圖片描述

（圖：深度測驗程序描述）

UGUI渲染程序分析

Unity3D中UI渲染的本質也是也是基于網格(Mesh)和材質（Material）,所以針對UGUI的渲染程序，其實也和其它三角圖元的渲染流程一致，UGUI中的渲染主要分為三個部分：

CanvasUpdateRegistry：負責通知需要渲染的UI組件，通常UI組件需要自己記錄當前是否需要被重新渲染，并把渲染的事件注冊給Registry,當UI本身的狀態發生改變，由Registry去出發重新渲染事件，當前UI提交需要重新渲染的資料，進行UI重新繪制，由于UI的各種資料可能會在一幀內發生多次改變，如果每次UI發生改變都去通知重新渲染會極大的影響渲染效率，通過一幀處理一次繪制呼叫會極大的提高UI渲染效率，
每個UI組件均繼承自Graphic組件，Graphic的核心功能是組織Mesh和Materail傳遞給底層API進行繪制，即CanvasRenderer類，CanvasRenderer連接畫布（Canvas）和其它UI渲染組件，CanvasRenderer把網格繪制到Canvas上，Canvas對當前接收到的網格進行合批處理，Canvas合批之后，再通過DrawCall呼叫底層API進行渲染，CanvasRenderer中有兩個方法，分別是：SetMesh和SetMaterial；如果網格或者材質沒有發生變化，UGUI通過呼叫底層快取進行繪制，不需要每一幀都去呼叫SetMesh或者SetMaterial，
每個組件都繼承自Graphic,每個Graphic都保存了當前UI組件的Mesh和Material;但是并不會每個Graphic都會呼叫一個DrawCall進行繪制呼叫；而是在底層將這個組件傳遞給Canvas，由Canvas對當前節點下的Graphic進行批處理合并，再由Canvas去進行繪制呼叫，
如果一個UI組件如果對Dirty進行了設定，整個Canvas都需要重新計算合批，會導致較大的性能消耗，

在這里插入圖片描述

（圖：UGUI渲染程序）

UI重繪觸發條件（Rebatch和Rebuild）：

組件Enable\Disable\Validate都會觸發UI組件重新繪制
SetVerticesDirty操作：MeshEffect改變\Shadows屬性改變\Transform大小改變\Image型別、層級、填充方式改變\Rawimage:Texture、UVRect、影片效果\Text內容改變，開關Rich\Text內容的變化是最影響dirty的，
SetMaterialDirty操作：Material替換、Image觸發影片、Transform層級變化、重新計算Mask\Rawimage替換Texture\Layout布局變化，包括Horizontal
Layout、Vertical Layout和Content Size Fill資料變化，

影響性能的因素

硬體因素

在這里插入圖片描述

（圖：移動平臺硬體架構）

在這里插入圖片描述

(圖：PC平臺硬體架構)

在這里插入圖片描述

（圖：移動端3D應用畫面渲染程序）

CPU

CPU在游戲運行程序中，主要承擔游戲中的邏輯運算、資源呼叫、網路操作、物理檢測、GC垃圾回收、繪制呼叫（DrawCall）等一些計算操作，CPU性能通常受需要渲染的批次數限制，需要渲染的批次數越多，需要消耗的CPU計算量越大，CPU的占用率越高，針對CPU端的性能優化可以從這些方面入手，

生成繪制命令（收集需要渲染的資訊）
業務邏輯/物理檢測/
網路通信
I/O操作
GC垃圾回收
繪制呼叫

GPU

GPU在游戲中主要承擔圖形著色的功能，包括頂點坐標變換、頂點著色、片元著色、光照計算等操作，GPU性能通常受填充率或記憶體帶寬限制，如果降低游戲解析度后，游戲幀率有明顯的提升，表明GPU填充率是影響游戲運行的主要因素，

頂點坐標變換、法線、切線
頂點著色/紋理采樣
片元著色/光照計算/像素繪制

GPU在圖形渲染流水線中主要承擔兩大流水線操作：幾何著色階段和光柵化階段，

記憶體

記憶體主要用來存盤游戲運行程序中的各種資料資源，包括：資源記憶體占用、引擎模塊自身記憶體占用、程式托管堆記憶體占用，

Mono托管記憶體：堆疊和托管堆
資源存盤記憶體：網格、紋理、材質、Shader、UI、音頻、視頻、圖片、文字、Assetbudle

軟體\平臺\系統因素

Mono虛擬機

Mono虛擬機的組成組件：C#編譯器、CLI虛擬機以及核心程式集，

Mono虛擬機的三種轉譯方式：

即時編譯（Just In Time,JIT）:程式運行程序中，將CIL的byte Code
轉譯為目標平臺的原生碼，（IOS端不支持JIT編譯）
提前編譯（Ahead of time,AOT）：程式運行之前，將.exe或.dll檔案中的CIL的byte
code部分完全轉譯為目標平臺的原生碼并存盤，程式運行中任有部分CIL的byte
code需要JIT編譯，
完全靜態編譯(Full Ahead Of
Time,Full-AOT)：程式運行前，將所有原始碼編譯成目標平臺的原生碼，

在這里插入圖片描述

(圖：MonoVM代碼執行程序)

特點：

構建、打包應用非常快
由于Mono的JIT機制，支持更多托管類別庫
支持運行時代碼執行
必須代碼發布成托管程式集（.dll檔案，由mono或者.net生成）
各平臺分別需要對應多個虛擬機（WebGL和UWP僅支持IL2Cpp）
IOS不支持32位Mono

IL2Cpp

基于AOT編譯（靜態編譯），把IL中間語言轉換成CPP檔案
運行時庫(libil2cpp)

其中AOT將IL轉換為C++代碼，再提交給各平臺的C++編譯器進行編譯，達到平臺兼容的目的；運行時庫則會提供諸如垃圾回收、執行緒、檔案獲取、內部呼叫直接修改托管資料結構的原生代碼與抽象，

在這里插入圖片描述

(圖：IL2Cpp執行程序)

特點：

可調式生成的C++代碼，
可以啟用引擎代碼剝離（Engine Code Stripping）來減少代碼大小，
程式運行效率相比Mono更高，執行速率更快，
多平臺移植較為方便
相比Mono構建、打包速度較慢，
只支持AOT(Ahead Of Time)編譯，不支持JIT編譯，
代碼執行效率是基于Mono虛擬機的2倍，

圖形API(DirectX\OpenGL\Vulkan\Metal)

資源標準以及優化方案

美術資源制作標準

PC平臺制作標準

移動平臺制作標準

美術資源優化方案

U3D優化方案

CPU優化

DrawCall優化

DrawCall是CPU去呼叫底層圖形API告訴GPU進行圖形渲染的一個程序中產生的一個繪制命令，DrawCall的數量決定了CPU呼叫底層API的次數，DrawCall的數量與CPU的性能成負相關，即DrawCall的數量越多，占用的CPU計算性能資源越多，造成游戲的性能下降，

DrawCall的優化目的主要是降低DrawCall的呼叫次數，DrawCall的主要目的在于將網格、材質、紋理等資訊傳遞到顯存中，有幾個網格就需要傳遞，就有幾個DrawCall需要呼叫，因此我們可以通過合并網格的數量，來減少DrawCall的呼叫次數，

靜態批處理（Staic Batch）

靜態批處理是Unity3D默認提供的網格合并功能，只需要在Inspector面板中，將不會移動、縮放、旋轉的物件且需要批處理的物件標記為靜態的（勾選Static），且保證物件之間相互使用相同的材質，其原理就是：把物體的網格進行合并，變成一個靜態的更大的網格體，再使用同一的材質進行渲染，

優缺點（使用限制和說明）

使用靜態批處理需要額外的記憶體開銷來保存合并之后的網格資料，這會增加較多的記憶體占用，
降低CPU計算資源，減少DrawCall呼叫次數，

靜態批處理的時間點

打包時，在Player Setting中勾選static
batching,在匯出包時會進行批處理，匯出來的包包體就會大，
1. 在游戲場景中勾選場景物體的static選項，在加載場景的時候，會進行一次靜態批處理的合并，這樣匯出來的包體不大，但是當運行時，運行時記憶體占用會增大，

靜態批處理的基本原理

場景中有四個物體ABCD，如果在Inspector面板中勾選靜態選項，在進行靜態批處理時，引擎會判斷這四個物體使用公用同一材質球，如果共用材質球，則引擎會將四個獨享視為可以進行靜態批處理的物件，引擎會基于單個渲染物件的大小拷貝出3個，總共變成4個Mesh，此時這四個Mesh會存盤在一個Index
Buffer中，此時記憶體的占用會增大4倍；渲染時會將批處理之后的大網格傳遞給GPU進行渲染，此處DrawCall由4變成1.

為什么需要使用靜態批處理

游戲運行程序中，如果性能瓶頸在CPU端，如果CPU端的運行速度較慢，則會出現GPU等待CPU的狀態，CPU在游戲運行程序中主要作業為：設定渲染狀態和呼叫DrawCall，設定渲染狀態主要包括：游戲資源的加載（貼圖、網格、材質、shader、燈光）等，如果每個物體的材質和貼圖都不一樣，則CPU會花費較多的時間來設定渲染狀態(SetPass)，同時也會產生更多的DrawCall.因此，在游戲中，對于大量不需要改變位置的物體，均可采用靜態批處理的方式來解決CPU端的性能瓶頸，

由于靜態批處理會增加記憶體的占用，在Unity中針對靜態批處理的物件，需要宣告一個較大的記憶體緩沖來存盤物件，當把網格傳遞給GPU進行渲染時，并不會對視錐體范圍內的網格進行裁剪，導致渲染壓力上升，因此如果游戲中大量的靜態物體均使用靜態批處理方式，會占用較大的記憶體buffer.因此，可以通過對需要靜態批處理的物件進行一個分塊的處理，將場景中的物件分成多個塊，每個小塊更加實際專案來做設定，這種方式可以減少批處理的記憶體占用，同時也利于進行視錐體裁剪，

動態批處理(Dynamic Batch)

動態批處理是專門為優化場景中共享同一材質的動態Gameobject的渲染而設計的，為了合并渲染批次，動態批處理每一幀都會消耗一些CPU性能；當開啟動態批處理時，Unity會自動的將所有符合條件的共享同一材質的動態Gameobject進行批處理合并，通過一個DrawCall進行繪制，其原理即：將場景中所有共享同一材質的模型的頂點資訊變換到世界空間中，然后通過呼叫一次DrawCall來繪制這個大網格，達到合批的目的，

優缺點（使用限制和說明）

彌補了靜態批處理無法處理相同材質的動態物件的不足，
增加了CPU計算消耗，需要通過CPU來將頂點坐標變換到世界空間坐標系中，
降低DrawCall呼叫次數，
動態批處理僅支持網格頂點小于900的網格體，
縮放比例不同，Unity將無法對物體進行批處理，比如：縮放為（1，1，1）和（1，2，2）的物件就不會進行動態批處理，但是（1，1，1）和（2，2，2）會進行動態批處理，

使用MeshBake工具進行網格/材質/貼圖合并

MeshBake烘焙工具主要用于減少CPU端的計算壓力，提供以下方式來降低CPU的DrawCall呼叫次數，使用MeshBake優化的結果是：降低Batches和SetPass，

網格合并（多個網格合并為一個網格）
材質合并（多個材質合并為一個材質）
貼圖合并（多張貼圖合并為一個到一張圖集中）

SetPass Call 設定渲染狀態

SetPassCall
代表渲染狀態的切換，主要出現在材質不一致的時候，會進行渲染狀態的切換，一個批處理的程序包括：提供頂點緩沖、索引緩沖，提交shader，設定硬體渲染狀態，設定光源屬性等，如果一個batch和另外一個batch使用的是不同的材質或者是同一個材質不同的pass，那么就需要觸發一次SetPassCall來重新設定渲染狀態，

通常SetPassCall的數量和DrawCall的數量成正相關，只需要降低其中一個的呼叫次數，那么另外一個的呼叫次數也會隨之下降，

業務邏輯(核心邏輯/UI互動邏輯)

業務邏輯的優化主要集中在代碼上的優化，即C#代碼的優化；包括托管堆疊的優化、變數申請、邏輯運算優化，

不使用的物件盡量不使用Destroy方法進行銷毀，而是SetActive(fasle)
使用For回圈代替Foreach,每次Foreach會產生一個Enumator，迭代器會額外分配記憶體，
控制StartCorountin()的次數，開啟一個一個協程，至少分配37B的記憶體，
使用StringBuilder來代替String做字串拼接：StringBuilder.Append方法在拼接字串時，變換總是發生在同一個記憶體塊中，而String+String這種字串拼接方式會頻繁申請記憶體釋放，導致GC頻繁呼叫，
組件快取：每次GetComponent均會分配一定的GCAlloc;每次獲取物件名稱Object.name會分配39B的堆記憶體，
避免使用Gameobject.Find\GameObject.FindWithTag\Object.FindObjectOfType等查詢方法，
使用物件池ObjectPool來管理物件；避免頻繁的Institiate和Destroy,避免頻繁的IO操作，
盡量不要在Update()函式中做復雜的計算；可使用間隔幀計算，
避免大量的裝箱\拆箱操作，比如：int型別轉string型別，int.Parse32，

網路通信、I/O操作

GC垃圾回收

GC本質上是用來回收記憶體的，但是每一次進行GC操作，均需要消耗CPU的計算性能，因此避免頻繁的GC呼叫，是優化CPU性能的重要一步，

C#值型別和參考型別區別

C#中值型別變數的宣告和參考型別的宣告時在記憶體中有以下區別：

創建參考型別時，CLR運行時為為其分配兩個空間，一塊空間分配在記憶體堆上，存盤參考型別本身的資料；另一塊空間分配在堆疊上，存盤對堆上資料的參考（即堆上存盤物件的地址，即指標），
創建值型別時，CLR運行時會為其向記憶體申請一個地址，這塊記憶體在變數申請的地方，如：
1. 如果值型別是在方法內部創建的，則跟隨方法入堆疊，分配到堆疊上存盤，
2. 如果值型別是參考型別的成員變數，則跟隨參考型別，存盤在記憶體堆上，

GC產生的原因

頻繁的變數宣告和記憶體操作，
裝箱、拆箱操作(值型別和參考型別互相轉化)，

在這里插入圖片描述

（圖：GC產生的原因）

GC的作業流程

GC的作業流程主要分為以下幾個步驟：

標記（Mark）->計劃（Plan）->清理（Sweep）->參考更新（Relocate）->壓縮（Compact）

在這里插入圖片描述

(圖：GC的作業流程)

Unity記憶體管理機制

Unity中主要采用自動記憶體管理的機制，開發時在代碼中不需要詳細地告訴Unity如何進行記憶體管理，Unity內部自身會進行記憶體管理，

關于Unity的記憶體管理可以理解為以下幾部分：

Unity中的兩大記憶體型別；堆疊型別和堆記憶體；堆疊記憶體主要用來存盤存盤較小和短暫的資料，堆記憶體主要用來存盤較大和存盤時間較長的資料，
Unity中的記憶體分配主要在堆疊和托管堆中進行，要么分配在堆疊中，要么分配在托管堆中，
只要變數處于激活狀態，則其占用的記憶體會被標記為使用狀態，則該部分的記憶體處于被分配的狀態，
一旦變數不再激活，則該變數所占用的記憶體不在需要，該部分記憶體可以回收到記憶體池中被再次使用，即記憶體回收，處于堆疊上的記憶體回收速度較快，而處內托管堆中記憶體并不是及時回收的，此時其對應的記憶體依然會被標記為使用狀態，
垃圾回收主要是指托管堆記憶體的分配和回收，Unity會根據當前的記憶體使用狀況，定時對堆記憶體進行GC操作，
Unity會定時進行垃圾回收操作，回收沒有有效參考的物件的記憶體，

堆疊記憶體分配和回識訓制

堆疊上的記憶體分配極其簡單和快捷，因為堆疊上只會存盤短暫或者較小的變數，記憶體分配和回收都會以一種順序和大小可控制的形式進行，

堆疊的運行方式和Stack類似：其本質只是一個資料的集合，資料的進出都以一種固定的方式運行；堆疊以先進后出的方式進行資料管理，

托管堆記憶體分配和回識訓制

堆記憶體的分配和回收相對復雜，主要是堆記憶體上可以存盤短期較小的資料，也可以存盤各種型別和大小的資料，其上的記憶體分配和回收順序并不可控；當變數分配在記憶體堆上時，主要分為以下幾步：

首先，unity檢測是否有足夠的閑置記憶體單元用來存盤資料，如果有，則分配對應大小的記憶體單元，
如果沒有足夠的記憶體單元，Unity會觸發垃圾回收GC機制來釋放不再被使用的堆記憶體；如果垃圾回收GC之后有足夠的記憶體單元，則進行記憶體分配，
如果進行垃圾回收之后仍沒有足夠的記憶體空間，則Unity會擴展記憶體堆的大小，重新向作業系統申請更大的記憶體空間，這是一個非常耗時的程序，

進行垃圾回收（GC Collect）時的操作

當堆上一個變數不再處于激活狀態的時候，其所占用的記憶體并不會被立刻回收，不再使用的記憶體只會再GC呼叫的時候才會被回收，

GC運行時，會進行如下操作：

GC檢查堆記憶體上存盤的每個存盤變數
對每個變數檢測其參考是否處于激活狀態
如果變數的參考不處于激活狀態，則會被標記為可回收
被標記的變數會被移除，其所占用的記憶體會被回收到堆記憶體上，

垃圾回收（GC Collect）的觸發時間

主要由以下三個操作時會觸發垃圾回收：

在堆記憶體上進行記憶體分配操作而當前內次不夠時會觸發垃圾回收來利用閑置的記憶體，
GC的自動觸發機制觸發，不同平臺觸發機制不一樣，
顯式呼叫System.GC.Collect()方法，
當在托管堆記憶體上頻繁進行記憶體分配且剩余記憶體單元不足時，GC會被頻繁觸發，這也就意味著頻繁的堆記憶體分配和回識訓觸發GC頻繁操作，

垂直同步（VSync）

垂直同步（VSync,Vertical
Synchronization）是一種顯示設定，可以用來限制游戲的幀率來匹配顯示幕的重繪率，以防止影像撕裂，

簡單來說，垂直同步的作用是用來防止畫面撕裂的，因為畫面的渲染并不是整個畫面一起渲染的，是逐行\逐列進行渲染的，如果關閉垂直同步，而電腦的硬體性能跟不上的話，在畫面\攝像機高速移動程序中會出現當前畫面還沒有渲染完畢就開始渲染下一個畫面的情況，會導致畫面撕裂，

垂直同步的開啟和關閉主要區別在于游戲畫面\攝像機是否處于高速運動狀態，如果開啟垂直同步，可以防止畫面\攝像機在高速運動程序中畫面被撕裂，

Unity3D中的幀率渲染機制

如果設定了VSync
Count的屬性，將會忽略TargetFrameRate設定，游戲將使用VSyncCount的設定和平臺默認的渲染率來確定目標幀率，例如，如果平臺的默認渲染速率為60幀且VSyncCount的設定為2，則游戲將以每秒30幀作為渲染目標，

VSync Count(每幀之間的垂直同步數)

Don’t’t Sync :不開啟垂直同步
Every V Black: VSync
將游戲幀率同步到顯示幕的重繪速率，傳統顯示幕重繪率為60HZ;即游戲幀率設定為60FPS/S；在一些120HZ和144HZ的顯示幕上，當設定VSync
Count為Every V Blank時，目標幀率被限制在120FPS/S和144FPS/S.
Every Second V Black:當把VSync Count設定為Every Scecond V
Blank時，即目標幀率為顯示幕重繪率的一半；即（60Hz重繪率的顯示幕其目標幀率為30FPS/S）.

TargetFrameRate(指定目標渲染幀率)

Application.targetFrameRate指示游戲以指定的幀率渲染，TargetFrameRate的默認值為-1，表示游戲以平臺的默認幀率渲染，

PC平臺，默認幀率為平臺硬體可實作的最大幀率，
移動平臺，由于需要節省電池電量，默認幀率小于可實作的最大幀率，移動平臺的默認幀率通常為30FPS/S.
所有移動平臺可實作的最大幀率都有固定的上限，和移動端設備的螢屏重繪率有關（60Hz=60fps,40Hz=40FPS）.
IOS會忽略Quality.Setting.VSyncCount設定，
基于VR的平臺,Unity將使用SDK指定的目標幀率并忽略游戲指定的幀率值，
設定了targetFrameRate的值不保證會實作幀率，其取決于平臺的硬體規格，如果設定了QualitySettings.vSyncCount的屬性，將會忽略/targetFrameRate/，而游戲將使用VsyncCount和平臺的默認重繪率來確定
目標幀率，例如：如果平臺的默認渲染速率為每秒60幀且VsyncCount設定為2，則游戲將以每秒30幀作為渲染目標，

物理模擬（PhysX）

Unity內置的物理模擬引擎為Navida
PhysX物理引擎，來模擬物理世界中的一些效果，比如：重力、阻力、彈性、碰撞等，其中使用一些內置的組件來實作這些模擬，如：剛體、碰撞器、恒力、物理材質、鉸鏈關節、彈簧關節等，

Unity3D提供了一個專門針對物理計算的重繪方法：FixedUpdate().FixedUpdate()和Update()的區別在于，兩個函式處于不同的幀回圈中，FixedUpdate()處于Physical回圈中，而Update()的更新頻率受場景物件的渲染影響，和游戲幀率有關，Update()中幀與幀之間的間隔時間是不相等且不固定的，而FixedUpdate()在每個幀渲染之間的時間是固定的，所以一些設計物理計算的程序，都需要在FixedUpdate()中進行，

將物理模擬的時間步長間隔設定合適的的大小，一般大于16ms,小于30ms.
謹慎使用網格碰撞器（MeshCollider）,使用更加簡單的BoxCollider\SphereCollider替代，
自己使用數學演算法模擬替代真實物理模擬，

GPU優化

GPU性能影響因素

CPU通過底層圖形API向GPU發送渲染指令，再通過硬體驅動程式發送給GPU設備，CPU產生的指令會放在命令緩沖區的佇列中，這些指令由GPU接收逐一處理，直到命令緩沖區為空；只要GPU能再下一幀開始之前能夠跟上指令的速度和復雜度，游戲就能夠保證以穩定的幀率運行，如果GPU跟不上或者CPU的負載過高，會導致繪制的延遲，造成幀率的下降，

造成GPU渲染壓力，往往有幾個重要的性能指標：填充率、像素和幾何復雜度
，如果能夠找到一種方法來將更多的渲染器剔除，均可降低填充率、像素和幾何復雜度的計算壓力，

性能瓶頸判斷

在移動平臺，GPU性能本質上受填充率的限制（填充率=螢屏像素*著色器復雜度*過度繪制）;

過于復雜的著色器會是導致性能產生瓶頸的原因之一，盡可能簡化著色器的復雜度可提高性能，
如果降低紋理質量（Quality->Texture
Quality）能提高游戲運行速度，表明游戲可能受到記憶體帶寬的限制，可對紋理進行壓縮、使用Mipmap、減小紋理大小等方式，

填充率

填充率：GPU每秒可以渲染到螢屏的像素數量（填充率=總像素數*Shader復雜度*OverDraw）如果游戲受到填充率的限制，那么說明我們的游戲每一幀輸出到螢屏的像素數量超過了GPU承載限度，如果一個片元未通過任意測驗（Alpha測驗、模板測驗、深度測驗、混合測驗），就被丟棄，可跳過性能消耗昂貴的繪制步驟，直接處理下一個片元，

過度繪制（OverDraw）

由于渲染物件的順序問題，我們總是會重復的繪制一些相同的像素，將這以繪制程序稱之為過度繪制，過度繪制越多，覆寫片元資料浪費的填充率也就越多，可通過Unity的Scene視窗下的OverDraw來觀察填充率，

Unity中有兩種型別的佇列用于渲染物件：不透明物件和透明物件；不透明佇列中渲染的佇列可以通過Z-Test剔除片元，但是在透明佇列中，僅通過Z-Test并不能解決這個問題，不管有多少物件擋在前面，都不能假設它們不需要被繪制，這就必然會導致大量的過度繪制（OverDraw），Unity
UI物件通常在透明佇列中進行渲染，這也是過度繪制產生的主要來源，

記憶體帶寬

GPU VRAM
的某個部位將紋理拉入更低級別（更快）的記憶體中，就會消耗記憶體帶寬，這個程序通常發生在紋理采樣程序，片元著色器嘗試選擇匹配的紋理像素，以便在給定的位置繪制給定的片元，由于GPU多核心并行運算的特性，每個核心都可以訪問顯存相同的區域，如果需要被采樣的紋理已經被存盤在內核的本地紋理快取中，會加快采樣的速率，否則將需要從VRAM中提取紋理資訊，這個操作會消耗一定數量可用的記憶體帶寬，

如果記憶體帶寬方面遇到瓶頸，GPU將繼續獲取必要的紋理檔案，但整個程序受到限制，因為紋理快取將等待資料獲取后，才會處理給定的片元，GPU無法及時將資料推送到幀緩沖區中并渲染到螢屏上，整個程序都會被阻塞，幀速率也會被降低，

提升GPU渲染性能的方案

保證材質的數量盡可能的少，這樣Unity可以更容易進行批處理，
使用紋理圖集（包含子影像集合的大影像）代替多個單獨的紋理；使用紋理圖集可以保證紋理圖集的加載速度更快、狀態切換更少，且支持批處理，
如果使用紋理圖集和共享材質，使用Renderer.sharedMaterial替換Renderer.material.
前向渲染的像素光源（Pixel
Light）的成本很高，盡可能使用光照貼圖替換實時光照，
調整Quality設定中的像素光源數量：本質上只需要主光源（Diretional
Light）采用像素光（Per Pixel）,其它Additional Light采用逐頂點(Per
Vertex)光照模式，
避免使用鏤空著色器（Alpha測驗），保持透明（Alpha混合）螢屏覆寫率最小化，
盡量避免多個光源為單個網格體提供光照，減少著色器通道（陰影、像素光源、反射）的總數，
保證正確的渲染順序，一般正常渲染順序為：完全不透明物件渲染->Alpha測驗物件->天空盒->Alpha混合物件，
螢屏后處理在移動端的使用成本非常高，
檢查游戲是否受到GPU填充率的影響很簡單，通過降低游戲運行的解析度，觀察游戲運行速度是否會加快，如果是：表明當前游戲的性能受限于填充率的影響，
降低著色器的復雜性：
1. 避免使用Alpha Test 測驗著色器，采用Alpha Blend混合著色器
2. 使用簡單、優化的著色器代碼，如（URP中的Simple Lit）
3. 避免在著色器代碼中使用成本過高的數學函式（pow\exp\log\cos\sin\tan）
4. 采用精度較低的數字精度（float\half\fixed）以獲得最佳性能，

視錐體剔除(View Frustum Culling)

視錐體剔除是在Unity3D攝像機視野范圍內針對場景物件進行剔除的一種方式，其基本思想是：判斷物件是否在相機的視錐體內（包含相交），不在則將其剔除，在CPU提交DrawCull繪制時，不會將此物件傳遞到GPU進行渲染，其主要的判斷原理是：根據物件的BoundBox(邊界包圍盒)與攝像機視錐體的六個裁剪平面的相交關系來判斷物件是否在視錐體范圍內，

由于視錐體剔除的物件針對的是物件，即場景中的網格體；根據網格體的AABB包圍盒檢測視錐體與網格碰撞體的相交情況來進行檢測，所以，在做合并大網格進行DrawCall優化時需要尤其注意；如果物件的網格體過大，其相應的BoundingBox也會相應變大，做視錐體剔除時，視錐體的每個面都會和BoundingBox相交，導致視視錐體無法剔除物件，加大GPU的渲染壓力，

在這里插入圖片描述

（圖：視錐體剔除）

遮擋剔除(Occlusion Culling)

遮擋剔除，顧名思義就是當物件被其它物件阻擋而不能被攝像機看到時，使用遮擋剔除功能會禁用物件的渲染，Unity中物件的繪制機制為，距離攝像機最遠的物件最先繪制，而距離攝像機較近的物件則在先前物件的基礎上進行繪制，這種繪制方式稱之為過度繪制（OverDraw），遮擋剔除與視錐體剔除不同，視錐體僅禁用攝像機視野之外的渲染器，而不會禁用由過度繪制而被隱藏的任何物件的渲染器，遮擋剔除和視錐體剔除可以同時作業，總之：視錐體剔除可以用于解區域分過度繪制（OverDarw）的問題，

在這里插入圖片描述

（圖左：未執行遮擋剔除；圖右：執行遮擋剔除）

在這里插入圖片描述
（圖：未執行遮擋剔除，過度繪制（OverDraw）嚴重）

未執行遮擋剔除，主要性能指標如下：

指標名稱	指標性能
Batches	296
Triangles	428.9k
Verts	616.3k
SetPassCalls	247
ShadowCasters	2706

在這里插入圖片描述

(圖：執行遮擋剔除，過度繪制（OverDraw）大幅降低)

執行遮擋剔除，主要性能指標如下：

指標名稱	指標性能
Batches	62
Triangles	150.2k
Verts	210.0k
SetPassCalls	53
ShadowCasters	1820

明顯看出使用遮擋剔除技術之后：各項主要的性能指標都有明顯的下降，

遮擋剔除使用參考手冊：https://docs.unity3d.com/cn/2018.4/Manual/OcclusionCulling.html

多層次細節LOD（Level Of Detail）

LOD也稱之為多層次細節，根據物體在游戲畫面中所占視圖的百分比來呼叫不同復雜度的模型，簡單來說，就是當一個物體距離攝像機較遠時，使用低模進行渲染，當攝像機距離攝像機比較近時使用高模進行渲染，這是優化游戲運行效率的常用手法，缺點就是記憶體占用較大，一般用來解決游戲運行時的流暢度問題，采用的是空間換時間的方式，

實作方式

準備三組不同精度的模型：高精度模型、中精度模型、低精度模型，
根據顯示效果，調整LODGroup的顯示距離，

優缺點

使用LOD，由于需要三套不同精度的模型，會增加記憶體負載，
由于可根據與攝像機的距離實時切換不同精度的模型，當攝像機切換到大視角或者攝像機在場景移動程序中，CPU向GPU傳遞不同精度的三維模型，可極大的降低GPU端的渲染壓力，

LOD解決方案

美術制作三套不同精度的三維模型（高模\中模\低模）,手動制作LOD.
使用Unity3D的解決方案
1. Unity HLOD System.
2. AutoLOD\Mantis LOD Editor\Mesh Baker LOD.
3. Mesh Combine Studio2\Amplify Impostors.

烘焙光照貼圖(Mixed Lighting)

Unity3D的光照計算處于渲染流水線中的片元著色階段，計算機圖形學中的光照技術是為了模擬真實世界的光照計算，通過各種方法計算光源發射的光線和物體之間互動作用后到達視線的能量強弱，

Unity3D光照模型及解決方案

Unity3D使用的是GI全域光照模型：全域光照=直接光照+間接光照，

簡介光照不僅會計算光源和物體，還會計算光的能量在物體之間的間接傳遞，得到更加真實的渲染效果，一般來說，全域光照技術是為了更好的計算間接光照的演算法，所以我們也將Indirect
ighting稱之為GI.

在這里插入圖片描述

（圖：U3D光照模型解決方案）

光照和陰影的渲染程序

物件的渲染很少能夠在一個步驟中完成，主要原因是光照和陰影，這些任務通常在片元著色器的多個（Pass）中進行處理，對于對各光源中每一個都處理一次，最后將渲染結果進行合并，以及使用更多的燈光效果，

陰影資訊的收集需要執行多個復雜的計算程序，首先需要未場景設定陰影投射器和陰影接收器，分別用來創建和接收陰影；然后，每次渲染陰影的接收器時，GPU都會從光源的角度將陰影投射器物件渲染成紋理（深度紋理），目標是手機每個片元的距離資訊，對陰影接收器進行同樣的動作，除了陰影投射器和光源重疊的片元之外，GPU可將片元的顏色渲染得更暗，因為這類片元位于陰影投射器產生得陰影下，

簡而言之，主要分為兩個程序：

一個是燈光空間，用相機渲染一張深度圖，把深度值寫入其中，
而是渲染程序中：把接收陰影得物體從模型空間變換到燈光空間中，得到深度值，將得到得深度值拿去和深度緩沖中得值進行比較，如果當前Z值大于勝讀紋理中保存得值，就說明這個片元在燈光空間中被遮擋了，

光照和陰影往往會消耗大量得計算資源，我們需要為每個頂點提供法矢方向，來確定光線如何從表面反射出去，同時需要附加頂點顏色屬性，來應用一些額外得著色，這要求CPU和前端提供更多傳遞得資訊，由于片元著色器需要多次傳遞資訊來完成最終得渲染，因此GPU光柵化階段在填充率（繪制、重繪、合并像素）和記憶體帶寬將處于高負荷狀態，

Unity3D光源型別以及光源數量支持

Unity3D URP渲染管線中主要包含以下幾種光源型別:Directional Light/Point
Light/SpotLight/Area Light;

以下表格對比除Dirrectional主方向光之外的其它附加光源，AdditionalLight

平臺	光源型別	支持光源數量(場景中)	支持數量（攝像機裁剪后）
Direct3D 11/Switch	Point Light	無限制	256 個
	Spot Light	無限制	256 個
	Area Light	無限制	256 個
OpenGL3.0/Metal/Vulkan	Point Light	無限制	32 個
	Spot Light	無限制	32 個
	Area Light	無限制	32 個
每個渲染物件支持的光源數量上限	D3D	8個
	OpenGL ES 2.0	4個
	OpenGL ES 3.0	8個

在UnityEngine.Rendering命名空間下有一個PerObjectData類，它負責持有每幀進行視錐體裁剪之后視野內的逐物件渲染引數，在渲染物件時將這些物件傳遞給GPU，其中就包括當前的光源資料，相機對場景物件進行視錐體裁剪之后，即渲染管線中的應用階段；相機主要對光源做如下兩件事；

從所有的方向光中挑一個最亮的光作為主光源，即Directional Light.
將剩下的其它型別（Additional
Light）的光源按照光照強度進行排序，放進一個陣列里;準備好光源資料之后，將光源分配給其需要渲染的物件，

如果攝像機視錐體范圍內的光源數量超過當前平臺所能支持的最大光源數量，則根據排序規則，多余的光源會被忽略，

在這里插入圖片描述

(圖：視錐體裁剪之后場景光源資料)

Baked Global ILLumination (烘焙全域光照)

Baked Indirect (烘焙間接光照)

Baked Indirect
:烘焙間接光照，顧名思義將間接光照烘焙到光照貼圖中，使用MixedLighting會為游戲物件投射實時陰影，陰影投射距離根據渲染管線Shadow
Distance的設定進行，將場景中的LightingMode設定為Baked
Indirect時，混合光源的行為如下：

為游戲物件提供直接光照，
烘焙間接光照（使用光照探針）
在Shadow Distance范圍內，為動態游戲物件提供實時陰影，
在Shadow Distance范圍內，為靜態游戲物件提供實時陰影，
1. 優缺點（Bake Indirect）
所有物件的陰影都是實時的，可能會影響游戲性能，可通過設定Shadows
Distance屬性來降低影響，
可在運行時修改光源屬性，由于只是烘焙間接光照，直接修改MixedLight的屬性會影響場景中的實時光照，但不會影響已經烘焙好的間接光照，
1. Subtractive （減性烘焙）
  
  Subtractive:減式光照模式，基于這種光照模式，場景中所有的混合光源（Mixed
  Lighting）都提供直接光照和間接光照，Unity將靜態物件的投射的陰影烘焙到光照貼圖中，除了烘焙的光照陰影，Mixed
  Lighting還會為動態的游戲物件提供實時陰影，
  
  由于靜態物件的陰影被烘焙到了光照貼圖中，所以Unity在運行時缺少將烘焙陰影和實時陰影準確的結合在一起所需的資訊，但是，通過Unity提供的Realtime
  Shadow
  Coor屬性可以減少來自光照貼圖的影響，從而在烘焙陰影和實時陰影之間創建正確的混合視覺效果，
  
  Subtractive特別適用于低端硬體設備，因為低端硬體設備更加注重運行性能，并且只需要一個實時陰影投射光源，適合卡通風格，基于Subtractive模式進行光照烘焙，靜態物件不接受高光，
  
  將場景光照模式設定為Subtractive時，其光照行為如下：

動態游戲物件將接收

實時直接光照，
烘焙間接光照（使用光照探針），
在Shadow Distance 距離內，為動態游戲物件提供實時陰影，
靜態物件實時陰影（光照探針）

靜態游戲物件將接收

烘焙直接光照（光照貼圖）
烘焙直接光照（光照貼圖）
靜態游戲物件的陰影烘焙（光照貼圖）
在Shadow Distance 距離內，為動態游戲物件提供實時陰影，
1. ShadowMask （陰影遮罩）

URP 10 以下版本不支持ShadowMask光照模式，

類似于Baked
Indirect光照模式，Shadowmask光照模式將實時直接光照與烘焙間接光照結合在一起，但是，ShadowsMask光照模式與Maked
Indirect光照模式的不同之處在于渲染陰影的方式不同，Shadowmask光照模式允許Unity在運行時結合烘焙陰影和實時陰影，并允許渲染遠處的陰影，實作這一點的方法是使用”陰影遮罩”的附加光照貼圖紋理并將附加資訊存盤在光照探針中，

Shadowmask質量設定

Distance Shadowmask:以更高的性能成本提供更高保真度的陰影，
Shadowmask：以更低的性能成本提供更高保真度的陰影，

GPUInstance

使用GPUInstance可以使用少量的繪制呼叫（DrawCall）一次性渲染同一網格的多個副本，它對于繪制諸如建筑物、樹木和草地之類的在場景中重復出現的物件非常有用，GPU實體化在每次繪制呼叫時僅渲染相同的網格，但每個實體可以具有不同的引數（基于CBuffer
常量緩沖）,可以增加變化并減少外觀上的重復，基于GPUInstance實體化技術可以降低每個場景使用的繪制呼叫數量，可以顯著提高專案的渲染性能，

GPUInstance的使用限制

Unity自動選取需要實體化的網格渲染器（MeshRender）和Graphics.DrawMesh呼叫,注意：不支持SkinnedMeshRenderer(網格蒙皮)，
Unity
僅在單個GPU實體化繪制呼叫中批量處理那些共享網格和相同材質的游戲物件；使用少量網格和材質可以提高實體化的效率，如需要創建變體，需要修改著色器腳本為每個實體添加資料（CBuffer
常量緩沖），

GPUInstance支持平臺

支持平臺	支持API
Windows	DirectX11和DirectX12
Windows/Macos/Linux/IOS/Android	OpenGL Core 4.1+/OpenGL ES 3.0+
macOS和IOS	Metal
Windows/Linux/Android	Vulkan
PlayStation和Xbox one
WebGL	WebGL 2.0 及以上API

URP針對網格材質的GPUInstance

相同材質(Same Material)和相同屬性(Same Property)值的網格體

SRP Batcher On Material GPU Instance OFF	SRP Batched
SRP Batcher On Material GPU Instance On	SRP Batched (如果開啟SRP Batched，GPUInstancing究竟被忽略)
SRP Batcher Off Material GUP Instance On	GPUInstance

不同材質(Different Material)和不同屬性(Different Property)值的網格體

SRP Batcher On Material GPU Instance OFF	SRP Batched
SRP Batcher On Material GPU Instance On	SRP Batched (如果開啟SRP Batched，GPU Instancing究竟被忽略)
SRP Batcher Off Material GUP Instance On	無法啟用SRP Batcher 和GPU Instance (因為材質不同)

相同材質(Same Material)和通過Material PropertyBlock設定不同屬性(Same
Property)值

SRP Batcher On Material GPU Instance OFF	無法啟用SRP Batched和GPU Instance (因為MaterialPropertyBlock值不一樣)
SRP Batcher On Material GPU Instance On	無法啟用SRP Batched和GPU Instance (因為MaterialPropertyBlock值不一樣)
SRP Batcher Off Material GUP Instance On	無法啟用SRP Batcher 和GPU Instance (因為屬性值未被實體化)

Unity傳統的基于MaterialPropertyBlock的GPU Instance在URP不再適用，

URP 不兼容傳統管線GPU Instance的原因：

URP 中Shader 中的Properties 需要使用基于SRP Batcher
定義的宏”CBUFFER_START(UnityPerMaterial)
GPU Instance 需要使用“UNITY_INSTANCEING_BUFFER_START(MyProps)定義

記憶體優化

Mono記憶體優化（堆疊\托管堆）

盡量避免重復的Instantiate和Destroy
Object，對應需要頻繁創建的物件；應使用ObjectPool對其進行快取，頻繁的實體化物件，會頻繁觸發GC呼叫，
使用StringBuilder進行字串操作，避免直接使用string進行字串拼接，
避免再Update函式中進行組件\標簽\物件的查找，如：GameObject.FindWithTag()\GetComponent();可以再Start()函式中將需要查找的組件預先快取起來，
陣列的宣告盡量使用Gameobject[]\Transform[],避免使用C#
自帶的ArrayList或Array類，子類陣列再進行記憶體分配的時候會進行大量的拆箱、裝箱操作，頻繁進行托管堆疊的記憶體操作，
單場景使用單例模式，宣告的資源實體，如：VideoClip\Texture\GameObject\Sprite時，當卸載場景時需要手動釋放場景資源；

void OnDestroy(){

videoClip=null;

sprite=null;

texture=null;

instance=null;

}

Unity3D資源記憶體

AssetBundle

AssetBundle是一種用來動態加載資源的資源加載方式，AssetBundle一般從網路地址下載或者從本地磁盤中加載，

Assetbundle系統提供了一種壓縮檔案格式，可以把一個到多個檔案進行索引和序列化，Assetbundle和傳統的壓縮包類似，由兩個部分組成：包頭和資料段，包頭包含Assetbundle相關的資訊，比如：識別符號、壓縮型別和內容清單，資料段包含通過序列化Assetbudle中的Assets而生成的原始資料，如果指定LZMA為壓縮方案，則對所有序列化Asset后的完整位元組陣列進行壓縮，如果指定LZ4壓縮，則單獨壓縮單獨的Assets的位元組，如果不壓縮資料段將保持原始位元組流，

在這里插入圖片描述

(圖：Assetbundle加載卸載程序)

AssetBundle加載機制

Assetbundle可以通過不同的API進行加載，針對Assetbundle行為的不同，其API呼叫的形式也不相同，

Assetbundle的壓縮方式：LZMA\LZ4\未壓縮
Assetbundle的加載平臺，（UnityWebRequest\WWW\Memory\LocalFile）

Assetbundle加載API:
Assetbundle.LoadFromMemory(Async optional)
AssetBundle.LoadFromFile(Async oprional)
UnityWebRequest’s DownloadHandlerAssetBundle
[WWW.LoadFromCacheOrDownLoad(Unity](http://WWW.LoadFromCacheOrDownLoad(Unity)
5.6 or older)
1. AssetBundle.LoadFromMemory(Async)

LoadFromMemory(Async)是從托管代碼的位元組陣列里加載Assetbundle.也就是說需要提前用其它方式將資源的二進制陣列加入到記憶體中，然后該介面會將資料源從托管代碼位元組陣列中復制到新分配的、連續的本機記憶體塊中，不建議使用此API進行Assetbundle加載，由于此API消耗的最大記憶體是AssetBundle本身的兩倍：本機記憶體中的一個副本和LoadFromMemory(Async)從托管位元組陣列中復制的一個副本，

通過此API進行Assetbundle加載的資產將在記憶體中冗余三次：第一次在托管代碼的位元組陣列中，第二次在Assetbundle的堆疊記憶體副本中，第三次在GPU或系統記憶體中，用于Asset本身，

AssetBundle.LoadFromFile(Async)

LoadFromFile是一種高效的API，用于從本地存盤加載未壓碩訓者LZ4壓縮格式的Assetbundle，

在桌面、移動平臺上，API將只加載Assetbundle的頭部資料，并將剩余的

資料段資源留在磁盤上，

Assetbundle的Objects會按需加載，比如：呼叫Assetbundle.Load加載方法或者InstanceID被間接參考時，不會消耗過多的記憶體，

但在Editor環境下,API還是會把整個AssetBundle加載到記憶體中，Editor環境中加載程序和Assetbundle.LoadFromMemoryAsync一樣，

需要注意的是：這個API只針對未進行壓碩訓者LZ4壓縮格式的Assetbundle，因為基于LZMA壓縮，是對整個生成后的資料包進行壓縮的，所有在未解壓前是無法拿到AssetBundle的頭資訊的，

AssetbundleDownloadHandler

DownloadHandlerAssetBundle的操作是通過UnityWebRequest的API來完成的，基于UnityWebRequest
API
能精確的指定Unity應如何處理下載的資料，并允許開發人員消除不必要的記憶體使用，使用UnityWebRequest下載Assetbundle的最簡單方法是呼叫UnityWebRequest.GetAssetBundle.其下載程序如下：將下載的資料流存盤到一個固定大小的緩沖區，然后根據下載處理程式的配置方式將緩沖資料放到臨時存盤或者Assetbundle快取中，所有的這些操作都發生在非托管代碼中，消除了增加堆記憶體的風險，此外，該下載處理程式并不會保留所有下載位元組的堆疊記憶體副本，從而減少了下載Assetbundle的記憶體開銷，LZMA壓縮的Assetbundle在下載和快取是更改為LZ4壓縮，如果將快取資訊提供給UnityWebRequest物件，一旦有請求的Assetbundle以及存在于Unity的快取中，即Assetbundle可以被立即實體化，并且此API的行為將會與Assetbundle.LoadFromFile相同，

AssetBundle卸載

Assetbundle.Unload(false)是釋放Assetbundle檔案的記憶體鏡像，不包含Load創建的Asset記憶體物件，
Assetbundle.Unload(true)是釋放Assetbundle檔案記憶體鏡像并銷毀所有用Load創建的Asset記憶體物件，

在這里插入圖片描述
(圖：Assetbundle加載卸載程序)

Texture/Material

針對不同的平臺采用不同的紋理壓縮方案，使用壓縮紋理可以節省大量記憶體和加快資源讀取速度，，

平臺	壓縮型別
Android OpenGL 2.0	ETC(default)
Android OpenGL 3.0	ETC2.0
IOS	PVRTC
Windows	DXT

2D 紋理如果沒有必要，請關閉mimap選項，關閉read/write選項

Mesh

減少網格頂點數量，降低模型精度，進行模型資源壓縮和優化，
合并網格頂點（MeshBake網格、材質、貼圖合并）

UGUI優化

Sprite打包（Texture Packer和Unity Sprite Packer）

Rebuild和Rebatch呼叫優化

UGUI將UI的渲染分為兩部分，對Mesh的操作稱之為Rebatch,對Material和Layout的操作稱之為Rebuild;UGUI的性能消耗主要集中在這兩部分，影響UI運行性能的原因，

GPU片段著色器使用率過高（即過度使用填充率），
CPU花費過多時間在Canvas的批處理合并上，
Canvas批處理次數重建次數過多，
CPU花費過多時間來生成網格頂點，

Rebatch(重合批)

Rebatch觸發原因

Rebatch發生在C++層面，由Canvas對當前Canvas下的UI節點進行分析，并形成一個最優合并批次的程序，節點的數量過多會導致合批的耗時較長，對應呼叫SetVerticesDirty，當一個Canvas中包含的Mesh發生改變時就會觸發，例如：SetActive\Transform改變\顏色改變\文本內容改變等，性能消耗點主要在于對Mesh按照深度和重疊情況進行排序、共享材質檢測等，

Batch以Canvas為單位，同一個Canvas下的UI元素最終都會被Batch到一個Mesh中，合批前，UGUI根據UI材質以及UI的渲染順序進行重排，在不改變渲染結果的前提下，盡可能將相同材質的UI元素合并在同一個SubMesh中，以減少DrawCall呼叫，合批只在U元素發生變化時進行，合成的Mesh越大，耗時越長，Rebuild對Canvas下的所有UI元素都生效，不論是UI否有變動，

針對Rebatch的優化方法

Canvas動靜分離，將經常需要更新的UI和不動的UI分離到不同的Canvas下，
減少節點的層次和數量，提升合批速度和效率，
使用相同材質的UI時盡量保持深度相同，對合批演算法友好，
修改Image的Color屬性，其本質時修改頂點的顏色，會引起網格Rebatch,同時觸發Canvas.SendWillRenderCanvas.

Rebuild（重繪）

Rebuild觸發原因

Rebuild發生在C#層，是指UGUI庫中的Layout組件調整RectTransform尺寸、Graphic組件更新Materail以及Mask執行Cull的程序，耗時和發生節點數量基本成正相關，

更改LayoutGroup（Horizontal/Vertical/Grid）的直接子節點,并且子節點的基型別為Graphic時，會觸發SetLayoutDirty，
改變Graphic的大小、旋轉以及文字的變化、圖片更換等修改會觸發SetMaterialDirty，

針對Rebuild的優化方法

減少Layout的頻繁使用，在編輯器中布好局之后，洗掉相關布局組件，
Canvas動靜分離，按型別劃分不同的Canvas.

UGUI通用優化方法

不要使用空Image,只接收事件不顯示的物件，繼承自Graphic
不顯示的物件，不使用SetActive(false)，而是設定CanvasGroup的Alpha為0，Scale為0，這樣VBO頂點緩沖物件不會被清楚，或者設定CanvasRenderer.Cull為True.
分離事件相機和UI渲染相機，設定Canvas的渲染模式為：World Space或者Screen
Space Camera.
減少Mask組件的使用，采用RectMask2D代替
替換原生文字組件（TextMeshPro）
壓縮圖片大小，降低記憶體占用
UI打包圖集\動態圖集
簡化UI結構，減少空節點數量\層級

Todo（附錄）

Unity渲染順序從近到遠，根據渲染物件的排序，會為每一個渲染物件的每一個材質，生成一個渲染批次的batch,在不考慮動態批處理和靜態批處理的情況下，總的batch量就是每個渲染物件所包含材質的總和，

渲染方案（URP）

根據物理學的定理：人眼能夠看到物體的顏色，有黃色、紅色、白色、紫色，波長從紅光到紫光，白光是由多種顏色的光復合而成，如我們所見的太陽光，由赤、橙、黃、綠、青、藍、紫等構成；人的眼睛之所以能夠看到世界中各式各樣的顏色，并不是由于物體本身會發光，而是由于物體反射了對應顏色的光，同樣，在計算機圖形學中，對物體光照的計算是非常重要的，通過為每個頂點計算一次光照顏色，然后再通過頂點所在多邊形覆寫的區域對像素顏色進行插值，其光照值取決于光線角度，表面法線和觀察位置，逐像素光照計算，即在片元著色器中進行光照計算，對每一個像素執行光照計算，無論是逐頂底光斬訓是逐像素光照，都造成GPU的運算負載，計算機圖形學中，執行光照渲染的方案主要分為正向渲染和延遲渲染兩大方案，

正向渲染（Forward Rendering）

URP中,URP實作了一個渲染回圈告訴Unity如何渲染一幀得資料，

在這里插入圖片描述

（圖：Unity URP RenderLoop）

特性

先執行光照著色計算，再執行alpha測驗、模板測驗、混合測驗，Unity中，可對場景中的光源型別進行光照型別配置（逐頂點、逐像素執行光照著色計算）
正向渲染中：所有的光照在單個Pass中進行；GI+自發光+霧
進行光照計算的程序：根據光照的強度以及重要程度進行排序，對每一個光源都單獨執行一次光照著色計算，
使用正向渲染的物體，其光照計算復雜度與光源數量成正比，渲染m個物體在n個光源下的著色，其復雜度O（m*n）
正向渲染適用于實時光源數量較少的場景，

渲染流程

在這里插入圖片描述

（圖：正向渲染流程）

圖形渲染管線中，深度測驗是用來消除場景中不可見的面，比如圖元的遮擋，由于三維場景的Z軸層次關系，一個物體可能覆寫到另外一個物體上，那么對被覆寫住的物體執行計算是沒有任何必要的，因為它根本不會在螢屏上顯示出來，由于正向渲染的特性，先執行著色計算，再進行深度測驗，會導致一些不需要再顯示的片元也參與了著色計算，導致渲染的性能浪費，

延遲渲染(Deferred Rendering 當前版本不支持)

特性

先執行深度測驗，再執行著色計算，
相比正向渲染程序，將光照著色計算程序延后，先對片元執行深度測驗，將被片元遮擋的其它片元從渲染管線中剔除和丟棄，最后再對有效的片元執行光照著色計算，
對片元執行幾何變換、深度測驗之后，將指定的片元以及相關資訊存盤到G-Buffer中，根據現有光源數量以及重要程度，分別對G-Buffer中的片元進行光照計算，

渲染流程

在這里插入圖片描述

(圖：延遲渲染流程)

延遲渲染的光照著色程序和正向渲染的光照著色程序不同，延遲渲染首先將簡單的幾何資訊（頂點坐標、法向量、紋理坐標）等存盤到中間緩沖區中；即G-Buffer（幾何緩沖中），著色的程序只需要渲染出一個螢屏大小的矩形，使用G-Buffer中的幾何資料與光照模型進行光照計算，

總結

正向渲染與延遲渲染各自有各自的優勢；兩者之間最大的區別在于允許參與光照計算的光源數量的支持程度；同樣，有光源意味著，光源照射物體會產生陰影，陰影的計算是很消耗圖形設備的性能的，不僅會造成CPU的計算負載，同時也會加大GPU的渲染壓力，

光照方案(URP）

混合光照+反射探針+光照探針

全域光照=直接光照+間接光照+自發光

主光源采用Mixed方式提供：直接光照+場景物件實時陰影（不論物件動態還是靜態）
間接光照采用Bake
Indirect光照烘焙方案：將光照資訊存盤到光照貼圖和光照探針中，（間接光照無法提供實時影音）
環境光照采用：Gradient
模式（最侄訓境光照資訊也會被烘焙到光照貼圖和反射探針中存盤起來，為場景物件提供環境光照）0.15
反射探針：根據場景內容和需求，可選擇烘焙模式和手動重繪模式（為場景物件提供周圍環境的光照資訊）

光照方案	方式	說明
主光源（Directional Light）	Mixed	提供直接光照+實時陰影+高光反射
烘焙方案（Bake）	Baked Indirect	主光源提供直接光照，間接光照烘焙到光照貼圖和光照探針中
光照探針（Light Probe）	Bake	記錄間接光照的光照資訊，為動態加入的物件提供間接光照
反射探針（Reflection）	Bake或Awake或腳本烘焙	存盤場場景中周圍物體的相互反射資訊，為物件提供環境反射資訊
環境光（Enviorment）	Gradient	為場景提供間接光照（被烘焙到光照貼圖+光照探針中）

低端硬體設備光照方案

無需為靜態游戲物件渲染陰影和提高光照，
為動態游戲提高直接直接光照和實時陰影，
無法針對靜態物件表現高光效果，

光照方案	方式	說明
主光源（Directional Light）	Mixed	為動態游戲物件提供實時直接光照和實時陰影渲染，
烘焙方案（Bake）	Subtractive	為靜態物件提供直接光照+間接光照烘焙，動態物件接收實時直接光照并將為動態物件得陰影渲染在靜態物件上，
光照探針（Light Probe）	Bake	記錄間接光照的光照資訊，為動態加入的物件提供間接光照
反射探針（Reflection）	Bake或Awake或腳本烘焙	存盤場場景中周圍物體的相互反射資訊，為物件提供環境反射資訊
環境光（Enviorment）	Gradient（Bake）	為場景提供間接光照（被烘焙到光照貼圖+光照探針中）

中、高端硬體設備光照方案

光照方案	方式	說明
主光源（Directional Light）	Mixed	提供直接光照+實時陰影+高光反射
烘焙方案（Bake）	Baked Indirect	主光源提供直接光照，間接光照烘焙到光照貼圖和光照探針中
光照探針（Light Probe）	Bake	記錄間接光照的光照資訊，為動態加入的物件提供間接光照
反射探針（Reflection）	Bake或Awake或腳本烘焙	存盤場場景中周圍物體的相互反射資訊，為物件提供環境反射資訊
環境光（Enviorment）	Gradient/Skybox	為場景提供間接光照（被烘焙到光照貼圖+光照探針中）

MeshBake資源（網格\材質\貼圖）烘焙方案

UnIty3D資源制作標準參考

資源型別	說明建議
場景	同屏三角面數控制在10萬面以內（Triangle）
	Additional光源數量控制在50盞以內（點光、聚光等）
	粒子系統數量控制在50以內
	盡量使用效率較高得Shader（如Simple Lit）
	盡可能采用共用材質（shareMaterial）、影片
	盡量采用壓縮紋理（Android ETC2.0/IOS ）
紋理壓縮	平臺	顏色模型	無	Normal	Hight	Low
	Windows	RGB	RGB24 位	RGB_C_DXT1	RGB(A)_C_BC7	RGB_C_DXT1
		RGBA	RGB32 位	RGBA_C_DXT5	RGB(A)_C_BC7	RGBA_C_DXT5
	Android	RGB	RGB24 位	RGB_C_ETC	RGB_C_ETC	RGB_C_ETC
		RGBA	RGBA32位	RGBA_C_ETC2	RGBA_C_ETC2	RGBA_C_ETC2
紋理選項	盡量對紋理采取壓縮方案
	保證紋理尺寸滿足長寬位2得n次冪，即256256\10241024\2048*2048
	針對目標終端記憶體情況決定是否啟用mipmap(會提升渲染效率，但會增加記憶體消耗)；如果沒有必要，請關閉，貼圖得Read/Write選項
音頻	時間長的音頻采用.ogg或者.mp3壓縮格式
	時間短的音頻采用.wav或.aif未壓縮格式
燈光型別	控制光源數量（Additional Light在攝像機裁剪之后最多渲染50盞）
	限定Per Pixel 光照型別，Additional Light盡量采用Per Vertex光照

                                     | RGBA     | RGBA32位 | RGBA_C_ETC2 | RGBA_C_ETC2  | RGBA_C_ETC2 |

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/297935.html

標籤：其他

上一篇：C++貪吃蛇游戲

下一篇：學習Opencv+Python之檔案矯OCR

Unity3D最全性能優化參考手冊（渲染、代碼、UI）

渲染原理和流程

概述

應用階段

概述

參與硬體

階段任務

資料準備

粗粒度剔除

設定渲染狀態

呼叫DrawCall

幾何階段

概述

參與硬體

階段任務

頂點著色器（Vertex Shader）

曲面細分著色器(Tessellation Stage)

幾何著色器(Geometry Shader)

投影（Projection）

裁剪(Projection)

螢屏映射

光柵化階段

概述

參與硬體

階段任務

三角形設定（Triangle Setup）

三角形遍歷(Triangle Traversal)

片元著色器(Fragment Shader)

逐片元操作(Per-Fragment Operation)

模板測驗（Stencil Test）

深度測驗（Depth Test）

UGUI渲染程序分析

影響性能的因素

硬體因素

CPU

GPU

記憶體

軟體\平臺\系統因素

Mono虛擬機

IL2Cpp

圖形API(DirectX\OpenGL\Vulkan\Metal)

資源標準以及優化方案

美術資源制作標準

PC平臺制作標準

移動平臺制作標準

美術資源優化方案

U3D優化方案

CPU優化

DrawCall優化

靜態批處理（Staic Batch）

優缺點（使用限制和說明）

靜態批處理的時間點

靜態批處理的基本原理

為什么需要使用靜態批處理

動態批處理(Dynamic Batch)

優缺點（使用限制和說明）

使用MeshBake工具進行網格/材質/貼圖合并

SetPass Call 設定渲染狀態

業務邏輯(核心邏輯/UI互動邏輯)

網路通信、I/O操作

GC垃圾回收

C#值型別和參考型別區別

GC產生的原因

GC的作業流程

Unity記憶體管理機制

堆疊記憶體分配和回識訓制

托管堆記憶體分配和回識訓制

進行垃圾回收（GC Collect）時的操作

垃圾回收（GC Collect）的觸發時間

垂直同步（VSync）

Unity3D中的幀率渲染機制

VSync Count(每幀之間的垂直同步數)

TargetFrameRate(指定目標渲染幀率)

物理模擬（PhysX）

GPU優化

GPU性能影響因素

性能瓶頸判斷

填充率

過度繪制（OverDraw）

記憶體帶寬