Unity3d优化总结2
優化：
1. 更新不透明貼圖的壓縮格式為ETC 4bit，因為android市場的手機中的GPU有多種，
每家的GPU支持不同的壓縮格式，但他們都兼容ETC格式，
2. 對于透明貼圖，我們只能選擇RGBA 16bit 或者RGBA 32bit。
3. 減少FPS，在ProjectSetting-> Quality中的
VSync Count 參數會影響你的FPS，EveryVBlank相當于FPS=60，EverySecondVBlank = 30；
這兩種情況都不符合游戲的FPS的話，我們需要手動調整FPS，首先關閉垂直同步這個功能，然后在代碼的Awake方法里手動設置FPS（Application.targetFrameRate = 45;）
降低FPS的好處：
1）省電，減少手機發熱的情況；
2）能都穩定游戲FPS，減少出現卡頓的情況。
4. 當我們設置了FPS后，再調整下Fixed timestep這個參數，
這個參數在ProjectSetting->Time中，目的是減少物理計算的次數，來提高游戲性能。
5. 盡量少使用Update LateUpdate FixedUpdate，這樣也可以提升性能和節省電量。
多使用事件（不是SendMessage，使用自己寫的，或者C#中的事件委托）。
6. 待機時，調整游戲的FPS為1，節省電量。
7. 圖集大小最好不要高于1024，否則游戲安裝之后、低端機直接崩潰、原因是手機系統版本低于2.2、超過1000的圖集無法讀取、導致。2.2 以上沒有遇見這個情況。
注意手機的RAM 與 ROM、小于 512M的手機、直接放棄機型適配。
VSCount 垂直同步
在新建一個場景空的時候，幀速率（FPS總是很低），大概在60~70之間。
一直不太明白是怎么回事，現在基本上明白了。我在這里解釋一下原因，如有錯誤，歡迎指正。
在Unity3D中當運行場景打開Profiler的時候，我們會看到VSync 這一項占了很大的比重。
這個是什么呢，這個就是垂直同步，稍后再做解釋。
我們可以關閉VSync來提高幀速率，選擇edit->project settings->Quality。
在右側面板中可以找到VSync Count,把它選成Don't Sync。
這就關閉了VSync(垂直同步)，現在在運行場景看看，幀速率是不是提高很多。
現在來說說什么是垂直同步，要知道什么是垂直同步，必須要先明白顯示器的工作原理，
顯示器上的所有圖像都是一線一線的掃描上去的，無論是隔行掃描還是逐行掃描，
顯示器都有兩種同步參數——水平同步和垂直同步。
什么叫水平同步？什么叫垂直同步？
垂直和水平是CRT中兩個基本的同步信號，水平同步信號決定了CRT畫出一條橫越屏幕線的時間，
垂直同步信號決定了CRT從屏幕頂部畫到底部，再返回原始位置的時間，
而恰恰是垂直同步代表著CRT顯示器的刷新率水平。
為什么關閉垂直同步信號會影響游戲中的FPS數值？
如果我們選擇等待垂直同步信號（也就是我們平時所說的垂直同步打開），
那么在游戲中或許強勁的顯卡迅速的繪制完一屏的圖像，但是沒有垂直同步信號的到達，
顯卡無法繪制下一屏，只有等85單位的信號到達，才可以繪制。
這樣FPS自然要受到操作系統刷新率運行值的制約。
而如果我們選擇不等待垂直同步信號（也就是我們平時所說的關閉垂直同步），那么游戲中作完一屏畫面，
顯卡和顯示器無需等待垂直同步信號就可以開始下一屏圖像的繪制，自然可以完全發揮顯卡的實力。
但是不要忘記，正是因為垂直同步的存在，才能使得游戲進程和顯示器刷新率同步，使得畫面更加平滑和穩定。
取消了垂直同步信號，固然可以換來更快的速度，但是在圖像的連續性上勢必打折扣。
這也正是很多朋友抱怨關閉垂直后發現畫面不連續的理論原因。
合并材質球unity 3d中每倒入一次模型就多一個材質球，可我的這些模型都是共用一張貼圖的就想共用一個材質球，所以每次都要刪除再附上，很麻煩。怎么才能合并這些材質球？
采用TexturePacking吧
1、遍歷gameobject，取出material，并根據shader來將material分類
2、調用Unity自帶的PackTextures函數來合并每個shader分類中的material所對應的textures（PackTextures函數有缺陷，不過可以將就用）
3、根據合并的大的texture來更新原有模型的texture、material已經uv坐標值。
需要注意的是：需要合并的紋理應該是物體在場景中距離相近的，如果物體在場景中的距離較遠，
則不建議合并紋理，因為這樣做很有可能非但起不到優化的作用，反而降低了運行效率。
mesh合并
分為2種方式合并
1.自帶的合并必須勾選靜態。
所有被勾選了“Static”的GameObject，其中的Mesh Filter中的mesh都會被合并到 "Combined Mesha (root: scene)" 中
2.也可以用腳本來合并mesh 。
|
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 |
|
1. 先在 Unity 中建立 空物件 ( Empty )
2. 再創建2個 Cube 方塊，并放入 空物件底下 (可以改成你自己的模型)
3. 把 MyClass 代碼丟進 空物件上 。
4. (可選) 建立一個 Material 材質，并且丟進 空物件上
5. 執行
前
后
========================================分割線====================================
角色Material數量
2-3個
骨骼數量
小于30個
面片數量
300-1500
一般角色應該沒有IK結點
這是因為角色的動作大多數都是事先設定好的，并不需要經過IK操作來進行實時計算（Rogdoll除外），所以在模型導入時，不要將IK結點一起導入。
2、靜態實體
不要附加 Component
在靜態實體上附加Animation部件雖然對結果沒有影響，但卻會增加一定的CPU開銷來調用這一組件，所以盡量去掉該組件。
網格頂點數
小于500
UV值范圍盡量不要超過（0, 1）區間
盡量保證UV值不越界，這對于將來的紋理拼合優化很有幫助。
3、地形
地形的分辨率大小
長寬均盡量小于257。這是因為地形太大，會造成大量頂點數據，給你的內存帶寬造成一定的影響，在目前的ios設備中，內存帶寬是非常有限的，需要盡量節省。同時，如果用Unity自帶的地形，一定也要使用Occlusion
Culling，因為Unity的刷地形工具雖然方便，但卻是framekiller，刷過之后，你會發現drawcall增加的非常多。
混合紋理數量
不要超過4。地形的混合操作是很耗時的，應該盡量避免。能合并的紋理盡量合并。
4、紋理
紋理格式
建議png或tga。不用轉成ios硬件支持的PVRTC格式，因為Unity在發布時會幫你自動轉的。
紋理尺寸
長寬小于1024。同時應該盡可能地小，夠用就好，以保證紋理對內存帶寬的影響達到最小。
支持Mipmap
建議生成Mipmap。雖然這種做法會增加一些應用程序的大小，但在游戲運行時，系統會根據需求應用Mipmap來渲染，從而減少內存帶寬。
檢查Alpha值
如果紋理的alpha通道均為1，則用RGB的24位紋理來代替RGBA的32位紋理。（據說Unity內部會進行自動檢測）
5、光源
光源“Important”個數
建議1個，一般為方向光。“Important”個數應該越小越少。個數越多，drawcall越多。
Pixel Light數目
1-2個。
6、粒子特效
屏幕上的最大粒子數
建議小于200個粒子。
每個粒子發射器發射的最大粒子數
建議不超過50個。
粒子大小
如果可以的話，粒子的size應該盡可能地小。因為Unity的粒子系統的shader無論是alpha test還是alpha blending都是一筆不小的開銷。同時，對于非常小的粒子，建議粒子紋理去掉alpha通道。
盡量不要開啟粒子的碰撞功能。
非常耗時。
7、音頻
游戲中播放時間較長的音樂（如背景音樂）
使用.ogg或.mp3的壓縮格式。
較短音樂（如槍聲）
使用.wav和.aif的未壓縮音頻格式。
8、相機
裁剪平面
將遠平面設置成合適的距離。遠平面過大會將一些不必要的物體加入渲染，降低效率。
根據不同的物體設置不同的遠裁剪平面
Unity提供了可以根據不同的layer來設置不同的view distance，所以我們可以實現將物體進行分層，大物體層設置的可視距離大些，而小物體層可以設置地小些，另外，一些開銷比較大的實體（如粒子系統）可以設置得更小些等等。
9、碰撞
盡量不用MeshCollider
如果可以的話，盡量不用MeshCollider，以節省不必要的開銷。如果不能避免的話，盡量用減少Mesh的面片數，或用較少面片的代理體來代替。
10、其他
Drawcall
盡可能地減少Drawcall的數量。IOS設備上建議不超過100。減少的方法主要有如下幾種：Frustum
Culling，Occlusion Culling，Texture Packing。Frustum
Culling是Unity內建的，我們需要做的就是尋求一個合適的遠裁剪平面；Occlusion
Culling，遮擋剔除，Unity內嵌了Umbra，一個非常好OC庫。但Occlusion
Culling也并不是放之四海而皆準的，有時候進行OC反而比不進行還要慢，建議在OC之前先確定自己的場景是否適合利用OC來優化；Texture
Packing，或者叫Texture Atlasing，是將同種shader的紋理進行拼合，根據Unity的static
batching的特性來減少draw
call。建議使用，但也有弊端，那就是一定要將場景中距離相近的實體紋理進行拼合，否則，拼合后很可能會增加每幀渲染所需的紋理大小，加大內存帶寬的負擔。這也就是為什么會出現“DrawCall降了，渲染速度也變慢了”的原因。
非運動物體盡量打上Static標簽
Unity在運行時會對static物體進行自動優化處理，所以應該盡可能將非運行實體勾上static標簽。
場景中盡可能地使用prefab
盡可能地使用prefab的實例化物體，以降低內存帶寬的負擔。檢查實體的PrefabType，盡量將其變成PrefabInstance，而不是ModelPrefabInstance。
========================================分割線====================================
移動平臺相對于PC機，具有體積小，計算弱，帶寬少的特點。
因此做手機游戲的開發，優化的方向，與力度對比PC游戲都有所區別。
必須要做到優化流程，合理利用資源。
目前在手機上面，還不能夠像PC游戲那樣追求高質量渲染效果，為了讓手機不那么容易發燙，還要控制cpu，gpu，不能讓他們全速運算。
材質方面：
紋理方面，建議使用壓縮紋理，
上面使用ETC1，蘋果上面使用PVRTC。
UV坐標控制在0到1之間，人物模型面數控制在1500內，骨骼控制在30個以內。
場景中使用一個主光（不能再多了）。
盡量減少alphaTest和alphaBlend材質的使用。在手機上，這是很殺效率的。
骨骼動畫方面：
在動畫方面可以考慮不使用插值，固定的幀率的動畫。
如果要做插值，考慮使用四元數（表示旋轉）和向量（表示位移）來做插值。
四元數做插值速度比矩陣來的快，Slerp提供了平滑插值。
========================================分割線====================================
優化的常規技巧
剖析你的游戲。
不要花費時間來優化那些晦澀的代碼或者縮減圖形文件的大小，除非這是你游戲的瓶頸。
第一次剖析你的游戲將會使你發現你游戲的瓶頸。Apple's Shark是一個很好的用來剖析基于OpenGL的程序的工具。
再次剖析你的游戲。
優化之后不要忘記再剖析一次你的游戲，這樣可以檢查你所做的優化是否達到了預期的效果。
當然，這樣做也可能會使你發現更多的瓶頸。
流程第一、性能第二。花費時間來使你游戲的創建盡可能地流暢。
盡可能快地修正游戲中的錯誤將會使你后期更容易優化你的游戲。
在Scene View中測試場景。
這樣做將會使你清楚了解這個場景中的物體或者附加在物體上的腳本是否降低了游戲性能。
如果Scene View反應遲鈍，那么有可能是圖形方面的原因，如果Scene View反應不遲鈍，那么瓶頸可能出在腳本或者物理系統上。
禁用指定游戲物體。
在play模式下，嘗試禁用并啟用游戲物體來排查出游戲慢的原因。
網格
如果可能的話，把相鄰的物體（網格）合并為一個只有一個材質的物體（網格）。比如，你的游戲中包含一個桌子，上面有一堆東西，你完全可以在3D程序中將它們合并在一起（這可能也需要你將這些物體的紋理合并為一個大的紋理集）。減少需要渲染的物體的數量可以極大地提高游戲性能。
不要有不必要的網格。
如果你的游戲場景中有一個人物，那么他應該是一個網格。如果你有一個船，那么它也應該只是一個網格。
每一個網格只用一種材質。
使用極少的面數的網格（比如500個多邊形以下）。
最好把你人物的三角面數量控制在1500-2000個之間。
這個數量可以說是游戲質量和性能之間一個均衡值。如果你的模型有四邊形，那么在導入模型的時候，引擎將會把每個四邊形變為兩個三角形。
光照
像素光。
像素光可以讓你的游戲看起來效果很牛逼，但是不要使用過多的像素光。
在你的游戲中可以使用質量管理器來調節像素光的數量來取得一個性能和質量的均衡點.
性能占用順序：聚光燈>點光源>平行光。
一個好的點亮場景的方法就是先得到你想要的效果，然后看看哪些光更重要；
在保持光效的前提下看看哪些光可以去掉。
點光源和聚光燈只影響它們范圍內的網格。
如果一個網格處于點光源或者聚光燈的照射范圍之外，并且光源的attenuate開關是打開的，那么這個網格將不會被光源所影響，這樣就可以節省性能開銷。
這樣做理論上來講可以使用很多小的點光源而且依然能有一個好的性能，因為這些光源只影響一小部分物體。
一個網格在有8個以上光源影響的時候，只響應前8個最亮的光源。
貼圖
在外觀不變的前提下，貼圖大小越小越好。
如果你的顯卡的顯存不夠大的話，你游戲中的貼圖將會被轉存到系統內存中，在顯卡調用它們的時候再傳到顯卡中。
對于比較新的電腦來說，內存和顯卡之間有足夠的帶寬來達到一個很好的性能；
如果你很無恥地用了巨多的大圖片的話，在低顯存的電腦上運行你的游戲的時候，你的游戲必然會掛掉。
倒是沒有必要在圖形編輯軟件中調整貼圖的大小。你可以在unity導入貼圖的時候進行調整。
不要使用低質量的圖片。
在小播放界面的游戲中使用低質量的jpeg圖片或者低色彩的png圖片亦或是gif圖片沒什么問題。
在發布游戲的時候，引擎會自動壓縮這些圖片，多重壓縮和解壓將會降低圖片的質量，所以最好保持貼圖文件的分辨率為原始分辨率。
這樣就會減少多重壓縮和解壓所導致的圖片失真現象。
Shaders
多重效果的shader就比看起來樣式很單一的shader要更耗費資源。
同樣在一個擁有貼圖和光反射的物體上，使用VertexLit Diffuse shader無疑是最省資源的。
========================================分割線====================================
在美術制作場景的過程中，會使用到大量的粒子系統。
比如場景中的火把。在我們的一個地下城場景中，美術們放置了大量的火把。整個場景中的各個地方，有100來個火把。
unity中，在攝像機范圍外的粒子系統雖然不會被繪制。
但是update是一直持續的。這也就意味著，這100多個火把，不論是否可見都在更新。
這個設計應該是很不合理的，在我看過的其他引擎中，都會有一個開關，來控制不可見的粒子系統是否需要update。
有的粒子系統在不可見的時候需要更新,比如爆炸。有的不需要更新，比如火堆火把。
為了避免不必要的update開銷，尤其是最后游戲是要發布到頁游平臺（web player只能使用一個cpu的核）。
于是寫了一個腳本，控制不可見的粒子系統就不更新。
該腳本主要是用到了2個MonoBehaviour的函數。
OnBecameInvisible() 當變為不可見 和 OnBecameVisible() 當變成可見。
要這2個函數起作用的前提是，該GameObject綁定了MeshRender組件。
所以，我們要在粒子系統的GameObject放置在一個GameObject下，且給該GameObject綁定一個MeshRender 與 MeshFilter。
MeshFilter中的mesh可以隨便找個cube。
在Start（） 的時候，把最GameObject的scale設置為很小，以保證該cube不被看見。
其實遍歷所有的child，把active設置為false。
在OnBecameVisible 中 遍歷所有child，把active設置為true。
在OnBecameInvisible中 遍歷所有child，把active設置為false。
========================================分割線====================================
Unity 性能優化 Draw Call
Unity（或者說基本所有圖形引擎）生成一幀畫面的處理過程大致可以這樣簡化描述：引擎首先經過簡單的可見性測試，確定攝像機可以看到的物體，然后把這些物體的頂點（包括本地位置、法線、UV等），索引（頂點如何組成三角形），變換（就是物體的位置、旋轉、縮放、以及攝像機位置等），相關光源，紋理，渲染方式（由材質/Shader決定）等數據準備好，然后通知圖形API——或者就簡單地看作是通知GPU——開始繪制，GPU基于這些數據，經過一系列運算，在屏幕上畫出成千上萬的三角形，最終構成一幅圖像。
在Unity中，每次引擎準備數據并通知GPU的過程稱為一次Draw
Call。這一過程是逐個物體進行的，對于每個物體，不只GPU的渲染，引擎重新設置材質/Shader也是一項非常耗時的操作。因此每幀的Draw
Call次數是一項非常重要的性能指標，對于iOS來說應盡量控制在20次以內，這個值可以在編輯器的Statistic窗口看到。
Unity內置了Draw Call Batching技術，從名字就可以看出，它的主要目標就是在一次Draw
Call中批量處理多個物體。只要物體的變換和材質相同，GPU就可以按完全相同的方式進行處理，即可以把它們放在一個Draw Call中。Draw
Call
Batching技術的核心就是在可見性測試之后，檢查所有要繪制的物體的材質，把相同材質的分為一組（一個Batch），然后把它們組合成一個物體（統一變換），這樣就可以在一個Draw
Call中處理多個物體了（實際上是組合后的一個物體）。
但Draw Call
Batching存在一個缺陷，就是它需要把一個Batch中的所有物體組合到一起，相當于創建了一個與這些物體加起來一樣大的物體，與此同時就需要分配相應大小的內存。這不僅會消耗更多內存，還需要消耗CPU時間。特別是對于移動的物體，每一幀都得重新進行組合，這就需要進行一些權衡，否則得不償失。但對于靜止不動的物體來說，只需要進行一次組合，之后就可以一直使用，效率要高得多。
Unity提供了Dynamic Batching和Static Batching兩種方式。Dynamic
Batching是完全自動進行的，不需要也無法進行任何干預，對于頂點數在300以內的可移動物體，只要使用相同的材質，就會組成Batch。Static
Batching則需要把靜止的物體標記為Static，然后無論大小，都會組成Batch。如前文所說，Static
Batching顯然比Dynamic Batching要高效得多，于是，Static Batching功能是收費的……
要有效利用Draw Call
Batching，首先是盡量減少場景中使用的材質數量，即盡量共享材質，對于僅紋理不同的材質可以把紋理組合到一張更大的紋理中（稱為Texture
Atlasing）。然后是把不會移動的物體標記為Static。此外還可以通過CombineChildren腳本（Standard
Assets/Scripts/Unity
Scripts/CombineChildren）手動把物體組合在一起，但這個腳本會影響可見性測試，因為組合在一起的物體始終會被看作一個物體，從而會增加GPU要處理的幾何體數量，因此要小心使用。
對于復雜的靜態場景，還可以考慮自行設計遮擋剔除算法，減少可見的物體數量同時也可以減少Draw Call。
總之，理解Draw Call和Draw Call Batching原理，根據場景特點設計相應的方案來盡量減少Draw Call次數才是王道，其它方面亦然。
Draw Call Batching （繪制調用批處理）
To draw an object on the screen, the engine has to issue a draw call to
the graphics API (OpenGL ES in the case of iOS). Every single draw call
requires a significant amount of work on the part of the graphics API,
causing significant performance overhead on the CPU side.
在屏幕上渲染物體，引擎需要發出一個繪制調用來訪問圖形API（iOS系統中為OpenGL ES）。
每個繪制調用需要進行大量的工作來訪問圖形API，從而導致了CPU方面顯著的性能開銷。
Unity combines a number of objects at runtime and draws them together
with a single draw call. This operation is called "batching". The more
objects Unity can batch together, the better rendering performance you
will get.
Unity在運行時可以將一些物體進行合并，從而用一個繪制調用來渲染他們。這一操作，我們稱之為“批處理”。
一般來說，Unity批處理的物體越多，你就會得到越好的渲染性能。
Built-in batching support in Unity has significant benefit over simply
combining geometry in the modeling tool (or using theCombineChildren
script from the Standard Assets package). Batching in Unity happensafter
visibility determination step. The engine does culling on each object
individually, and the amount of rendered geometry is going to be the
same as without batching. Combining geometry in the modeling tool, on
the other hand, prevents effecient culling and results in much higher
amount of geometry being rendered.
Unity中內建的批處理機制所達到的效果要明顯強于使用幾何建模工具（或使用Standard Assets包中的CombineChildren腳本）的批處理效果。
這是因為，Unity引擎的批處理操作是在物體的可視裁剪操作之后進行的。
Unity先對每個物體進行裁剪，然后再進行批處理，這樣可以使渲染的幾何總量在批處理前后保持不變。
但是，使用幾何建模工具來拼合物體，會妨礙引擎對其進行有效的裁剪操作，從而導致引擎需要渲染更多的幾何面片。
Materials
材質
Only objects sharing the same material can be batched together.
Therefore, if you want to achieve good batching, you need to share as
many materials among different objects as possible.
只有擁有相同材質的物體才可以進行批處理。
因此，如果你想要得到良好的批處理效果，你需要在程序中盡可能地復用材質和物體。
If you have two identical materials which differ only in textures, you
can combine those textures into a single big texture - a process often
calledtexture atlasing. Once textures are in the same atlas, you can use
single material instead.
如果你的兩個材質僅僅是紋理不同，那么你可以通過 紋理拼合 操作來將這兩張紋理拼合成一張大的紋理。
一旦紋理拼合在一起，你就可以使用這個單一材質來替代之前的兩個材質了。
If you need to access shared material properties from the scripts, then
it is important to note that modifyingRenderer.material will create a
copy of the material. Instead, you should useRenderer.sharedMaterial to
keep material shared.
如果你需要通過腳本來訪問復用材質屬性，那么值得注意的是改變Renderer.material將會造成一份材質的拷貝。
因此，你應該使用Renderer.sharedMaterial來保證材質的共享狀態。
Dynamic Batching
動態批處理
Unity can automatically batch moving objects into the same draw call if they share the same material.
如果動態物體共用著相同的材質，那么Unity會自動對這些物體進行批處理。
Dynamic batching is done automatically and does not require any additional effort on your side.
動態批處理操作是自動完成的，并不需要你進行額外的操作。
Tips:
提醒：
1、 Batching dynamic objects has certain overheadper vertex, so
batching is applied only to meshes containing less than900 vertex
attributes in total.
批處理動態物體需要在每個頂點上進行一定的開銷，所以動態批處理僅支持小于900頂點的網格物體。
2、 If your shader is using Vertex Position, Normal and single UV,
then you can batch up to 300 verts and if your shader is using Vertex
Position, Normal, UV0, UV1 and
Tangent, then only 180 verts.
Please note: attribute count limit might be changed in future
如果你的著色器使用頂點位置，法線和UV值三種屬性，那么你只能批處理300頂點以下的物體；
如果你的著色器需要使用頂點位置，法線，UV0，UV1和切向量，那你只
能批處理180頂點以下的物體。
請注意：屬性數量的限制可能會在將來進行改變。
4、 Don't use scale. Objects with scale (1,1,1) and (2,2,2) won't batch.
不要使用縮放尺度（scale）。分別擁有縮放尺度(1,1,1)和(2,2,2)的兩個物體將不會進行批處理。
5、 Uniformly scaled objects won't be batched with non-uniformly scaled ones.
統一縮放尺度的物體不會與非統一縮放尺度的物體進行批處理。
Objects with scale (1,1,1) and (1,2,1) won't be batched. On the other hand (1,2,1) and (1,3,1) will be.
使用縮放尺度(1,1,1)和 (1,2,1)的兩個物體將不會進行批處理，但是使用縮放尺度(1,2,1)和(1,3,1)的兩個物體將可以進行批處理。
6、 Using different material instances will cause batching to fail.
使用不同材質的實例化物體（instance）將會導致批處理失敗。
7、 Objects with lightmaps have additional (hidden) material
parameter: offset/scale in lightmap, so lightmapped objects won't be
batched (unless they point to same
portions of lightmap)
擁有lightmap的物體含有額外（隱藏）的材質屬性，比如：lightmap的偏移和縮放系數等。所以，擁有lightmap的物體將不會進行批處理（除非他們指向lightmap的同一
部分）。
8、 Multi-pass shaders will break batching. E.g. Almost all unity
shaders supports several lights in forward rendering, effectively doing
additional pass for them
多通道的shader會妨礙批處理操作。比如，幾乎unity中所有的著色器在前向渲染中都支持多個光源，并為它們有效地開辟多個通道。
9、 Using instances of a prefab automatically are using the same mesh and material.
預設體的實例會自動地使用相同的網格模型和材質。
Static Batching
靜態批處理
Static batching, on the other hand, allows the engine to reduce draw
calls for geometry of any size (provided it does not move and shares the
same material). Static batching is significantly more efficient than
dynamic batching. You should choose static batching as it will require
less CPU power.
相對而言，靜態批處理操作允許引擎對任意大小的幾何物體進行批處理操作來降低繪制調用（只要這些物體不移動，并且擁有相同的材質）。因此，靜態批處理比動態批處理更加有效，你應該盡量低使用它，因為它需要更少的CPU開銷。
In order to take advantage of static batching, you need explicitly
specify that certain objects are static and willnot move, rotate or
scale in the game. To do so, you can mark objects as static using the
Static checkbox in the Inspector:
為了更好地使用靜態批處理，你需要明確指出哪些物體是靜止的，并且在游戲中永遠不會移動、旋轉和縮放。想完成這一步，你只需要在檢測器（Inspector）中將Static復選框打勾即可，如下圖所示：
Using static batching will require additional memory for storing the
combined geometry. If several objects shared the same geometry before
static batching, then a copy of geometry will be created for each
object, either in the Editor or at runtime. This might not always be a
good idea - sometimes you will have to sacrifice rendering performance
by avoiding static batching for some objects to keep a smaller memory
footprint. For example, marking trees as static in a dense forest level
can have serious memory impact.
使用靜態批處理操作需要額外的內存開銷來儲存合并后的幾何數據。在靜態批處理之前，如果一些物體共用了同樣的幾何數據，那么引擎會在編輯以及運行狀態對每個物體創建一個幾何數據的備份。這并不總是一個好的想法，因為有時候，你將不得不犧牲一點渲染性能來防止一些物體的靜態批處理，從而保持較少的內存開銷。比如，將濃密森里中樹設為Static，會導致嚴重的內存開銷。
Static batching is only available in Unity iOS Advanced.
靜態批處理目前只支持Unity iOS Advanced。
=======================分割線========================
一、程序方面
01、務必刪除腳本中為空或不需要的默認方法；
02、只在一個腳本中使用OnGUI方法；
03、避免在OnGUI中對變量、方法進行更新、賦值，輸出變量建議在Update內；
04、同一腳本中頻繁使用的變量建議聲明其為全局變量，腳本之間頻繁調用的變量或方法建議聲明為全局靜態變量或方法；
05、不要去頻繁獲取組件，將其聲明為全局變量；
06、數組、集合類元素優先使用Array，其次是List；
07、腳本在不使用時腳本禁用之，需要時再啟用；
08、可以使用Ray來代替OnMouseXXX類方法；
09、需要隱藏/顯示或實例化來回切換的對象，盡量不要使用SetActiveRecursively或active，而使用將對象遠遠移出相機范圍和移回原位的做法；
10、盡量少用模運算和除法運算，比如a/5f，一定要寫成a*0.2f。
11、對于不經常調用或更改的變量或方法建議使用Coroutines & Yield；
12、盡量直接聲明腳本變量，而不使用GetComponent來獲取腳本；
iPhone
13、盡量使用整數數字，因為iPhone的浮點數計算能力很差；
14、不要使用原生的GUI方法；
15、不要實例化（Instantiate）對象，事先建好對象池，并使用Translate“生成”對象；
二、模型方面
01、合并使用同貼圖的材質球，合并使用相同材質球的Mesh；
02、角色的貼圖和材質球只要一個，若必須多個則將模型離分離為多個部分；
02、骨骼系統不要使用太多；
03、當使用多角色時，將動畫單獨分離出來；
04、使用層距離來控制模型的顯示距離；
05、陰影其實包含兩方面陰暗和影子，建議使用實時影子時把陰暗效果烘焙出來，不要使用燈光來調節光線陰暗。
06、少用像素燈和使用像素燈的Shader；
08、如果硬陰影可以解決問題就不要用軟陰影，并且使用不影響效果的低分辨率陰影；
08、實時陰影很耗性能，盡量減小產生陰影的距離；
09、允許的話在大場景中使用線性霧，這樣可以使遠距離對象或陰影不易察覺，因此可以通過減小相機和陰影距離來提高性能；
10、使用圓滑組來盡量減少模型的面數；
11、項目中如果沒有燈光或對象在移動那么就不要使用實時燈光；
12、水面、鏡子等實時反射/折射的效果單獨放在Water圖層中，并且根據其實時反射/折射的范圍來調整；
13、碰撞對效率的影響很小，但碰撞還是建議使用Box、Sphere碰撞體；
14、建材質球時盡量考慮使用Substance；
15、盡量將所有的實時反射/折射（如水面、鏡子、地板等等）都集合成一個面；
16、假反射/折射沒有必要使用過大分辨率，一般64*64就可以，不建議超過256*256；
17、需要更改的材質球，建議實例化一個，而不是使用公共的材質球；
18、將不須射線或碰撞事件的對象置于IgnoreRaycast圖層；
19、將水面或類似效果置于Water圖層
20、將透明通道的對象置于TransparentFX圖層；
21、養成良好的標簽（Tags）、層次（Hieratchy）和圖層（Layer）的條理化習慣，將不同的對象置于不同的標簽或圖層，三者有效的結合將很方便的按名稱、類別和屬性來查找；
22、通過Stats和Profile查看對效率影響最大的方面或對象，或者使用禁用部分模型的方式查看問題到底在哪兒；
23、使用遮擋剔除（Occlusion Culling）處理大場景，一種較原生的類LOD技術，并且能夠“分割”作為整體的一個模型。
三、其它
場景中如果沒有使用燈光和像素燈，就不要使用法線貼圖，因為法線效果只有在有光源（Direct Light/Point Light/Angle Light/Pixel Light）的情況下才有效果。
總結
以上是生活随笔為你收集整理的Unity3d优化总结2的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python电脑推荐_6款Python必
- 下一篇： springfox源码_Spring b