Unity 性能优化归纳
1、SimpleLOD ：
除了同樣擁有Mesh Baker所具有的Mesh合并、Atlas烘焙等功能，它還能提供Mesh的簡化，并對動態(tài)蒙皮網(wǎng)格進行了很好的支持。
該插件可在Run-time和Editor中都可以使用，同時開放了源碼，大家可以根據(jù)項目的實際情況而作修改。
http://download.csdn.net/download/jasonczy/10178526
?
一、
轉(zhuǎn)載自?http://blog.csdn.net/game_jqd/article/details/51899000
使用Profiler工具分析內(nèi)存占用情況
- System.ExecutableAndDlls：系統(tǒng)可執(zhí)行程序和DLL，是只讀的內(nèi)存，用來執(zhí)行所有的腳本和DLL引用。不同平臺和不同硬件得到的值會不一樣，可以通過修改Player Setting的Stripping Level來調(diào)節(jié)大小。
?
Ricky：我試著修改了一下Stripping Level似乎沒什么改變，感覺雖占用內(nèi)存大但不會影響游戲運行。我們暫時忽略它吧(- -)!
?
- GfxClientDevice：GFX（圖形加速\圖形加速器\顯卡 (GraphicsForce Express)）客戶端設備。
?
Ricky：雖占用較大內(nèi)存，但這也是必備項，沒辦法優(yōu)化。繼續(xù)忽略吧(- -)!!
?
- ManagedHeap.UsedSize：托管堆使用大小。
?
Ricky：重點監(jiān)控對象，不要讓它超過20MB，否則可能會有性能問題！
?
- ShaderLab：Unity自帶的著色器語言工具相關資源。
?
Ricky：這個東西大家都比較熟悉了，忽略它吧。
?
- SerializedFile：序列化文件，把顯示中的Prefab、Atlas和metadata等資源加載進內(nèi)存。
?
Ricky：重點監(jiān)控對象，這里就是你要監(jiān)控的哪些預設在序列化中在內(nèi)存中占用大小，根據(jù)需求進行優(yōu)化。
?
?
- PersistentManager.Remapper：持久化數(shù)據(jù)重映射管理相關
?
Ricky：與持久化數(shù)據(jù)相關，比如AssetBundle之類的。注意監(jiān)控相關的文件。
?
- ManagedHeap.ReservedUnusedSize：托管堆預留不使用內(nèi)存大小，只由Mono使用。
?
Ricky：無法優(yōu)化。
?
?
- AudioManager：音頻管理器
?
Ricky：隨著音頻文件的增多而增大。
?
- AudioClip：音效及聲音文件
?
Ricky：重點優(yōu)化對象，播放時長較長的音樂文件需要進行壓縮成.mp3或.ogg格式，時長較短的音效文件可以使用.wav 或.aiff格式。
?
- Cubemap：立方圖紋理
?
Ricky：這個一般在天空盒中比較常見，我也不知道如何優(yōu)化這個。。。
?
- Mesh：模型網(wǎng)格
?
Ricky：主要檢查是否有重復的資源，還有盡量減少點面數(shù)。
- Mesh：場景中使用的網(wǎng)格模型
?
Ricky：注意網(wǎng)格模型的點面數(shù)，能合并的mesh盡量合并。
1）ManagedHeap.UsedSize: 移動游戲建議不要超過20MB.
2）SerializedFile: 通過異步加載(LoadFromCache、WWW等)的時候留下的序列化文件,可監(jiān)視是否被卸載.
3）WebStream: 通過異步WWW下載的資源文件在內(nèi)存中的解壓版本，比SerializedFile大幾倍或幾十倍，不過我們現(xiàn)在項目中展示沒有。
4）Texture2D: 重點檢查是否有重復資源和超大Memory是否需要壓縮等.
5）AnimationClip: 重點檢查是否有重復資源.
6）Mesh： 重點檢查是否有重復資源.
1.Device.Present:
1）GPU的presentdevice確實非常耗時，一般出現(xiàn)在使用了非常復雜的shader.
2）GPU運行的非常快，而由于Vsync的原因，使得它需要等待較長的時間.
3）同樣是Vsync的原因，但其他線程非常耗時，所以導致該等待時間很長，比如：過量AssetBundle加載時容易出現(xiàn)該問題.
4）Shader.CreateGPUProgram:Shader在runtime階段（非預加載）會出現(xiàn)卡頓(華為K3V2芯片).
5）StackTraceUtility.PostprocessStacktrace()和StackTraceUtility.ExtractStackTrace(): 一般是由Debug.Log或類似API造成，游戲發(fā)布后需將Debug API進行屏蔽。
2.Overhead:
1）一般情況為Vsync所致.
2）通常出現(xiàn)在Android設備上.
3.GC.Collect:
原因：
1）代碼分配內(nèi)存過量(惡性的)
2）一定時間間隔由系統(tǒng)調(diào)用(良性的).
占用時間：
1）與現(xiàn)有Garbage size相關
2）與剩余內(nèi)存使用顆粒相關（比如場景物件過多，利用率低的情況下，GC釋放后需要做內(nèi)存重排)
4.GarbageCollectAssetsProfile:
1）引擎在執(zhí)行UnloadUnusedAssets操作（該操作是比較耗時的,建議在切場景的時候進行）。
2）盡可能地避免使用Unity內(nèi)建GUI，避免GUI.Repaint過渡GCAllow.
3）if(other.tag == a.tag)改為other.CompareTag(a.tag).因為other.tag為產(chǎn)生180B的GC Allow.
4）少用foreach，因為每次foreach為產(chǎn)生一個enumerator(約16B的內(nèi)存分配)，盡量改為for.
5）Lambda表達式，使用不當會產(chǎn)生內(nèi)存泄漏.
5.盡量少用LINQ：
1）部分功能無法在某些平臺使用.
2）會分配大量GC Allow.
6.控制StartCoroutine的次數(shù)：
1）開啟一個Coroutine(協(xié)程)，至少分配37B的內(nèi)存.
2）Coroutine類的實例 -> 21B.
3）Enumerator -> 16B.
7.使用StringBuilder替代字符串直接連接.
8.緩存組件:
1）每次GetComponent均會分配一定的GC Allow.
2）每次Object.name都會分配39B的堆內(nèi)存.
?
?
?
.框架設計層面。
?
一個相對中大型的游戲，系統(tǒng)非常的多。這時候合理的適時的釋放內(nèi)存有助于游戲的正常體驗，甚至可以防止內(nèi)存快速到達峰值，導致設備Crash。
目前主流平臺機型可用內(nèi)存：
Android平臺：在客戶端最低配置以上，均需滿足以下內(nèi)存消耗指標（PSS）：
1)內(nèi)存1G以下機型：最高PSS<=150MB
2)內(nèi)存2G的機型：最高PSS<=200MB
iOS平臺：在iPhone4S下運行，消耗內(nèi)存（real mem）不大于150MB
?
1.場景切換時避開峰值。
當前一個場景還未釋放的時候，切換到新的場景。這時候由于兩個內(nèi)存疊加很容易達到內(nèi)存峰值。解決方案是，在屏幕中間遮蓋一個Loading場景。在舊的釋放完，并且新的初始化結(jié)束后，隱藏Loading場景，使之有效的避開內(nèi)存大量疊加超過峰值。
?
2.GUI模塊加入生命周期管理。
?
主角、強化、技能、商城、進化、背包、任務等等。通常一個游戲都少不了這些系統(tǒng)。但要是全部都打開，或者這個時候再點世界地圖，外加一些邏輯數(shù)據(jù)內(nèi)存的占用等等。你會發(fā)現(xiàn)，內(nèi)存也很快就達到峰值。
這時候有效的管理系統(tǒng)模塊生命周期就非常有必要。首先將模塊進行劃分：
?
1)經(jīng)常打開 Cache_10；
2)偶爾打開 Cache_5；
3)只打開一次 Cache_0。
?
創(chuàng)建一個ModuleMananger 類，內(nèi)部Render方法每分鐘輪詢一次。如果是“Cache_0”這個類型，一關閉就直接Destroy釋放內(nèi)存；“Cache_10”這個類型為10分鐘后自動釋放內(nèi)存；" Cache_5"這種類型為5分鐘后自動釋放內(nèi)存。每次打開模塊，該模塊就會重新計時。這樣就可以有效合理的分配內(nèi)存。
?
?
?
1、? 由于實時對戰(zhàn)游戲的數(shù)據(jù)包數(shù)量巨大，早期版本的幀同步策略會導致比較明顯的卡頓，通過進行數(shù)據(jù)包的合并與優(yōu)化逐漸解決了卡頓問題；
2、? 頻繁創(chuàng)建和銷毀的小兵對象讓CPU爆表了，大量的小兵如果采用實時內(nèi)存的分配和回收，會產(chǎn)生大量的內(nèi)存碎片和系統(tǒng)開銷，解決方法之一就是采用高效的對象池進行優(yōu)化，對每個內(nèi)存對象的狀態(tài)進行操作即可；
3、? 性能分析過程中，發(fā)現(xiàn)單人同屏和多人同屏時的開銷都很大，通過視野裁剪技術，使得玩家視野外的不必要的特效和渲染可以全部關閉，極大降低了CPU、GPU和內(nèi)存的開銷；
4、? 在高中低三檔機型上玩游戲時，分別加載不同層次的特效包，這也有助于降低CPU和內(nèi)存的開銷；性能分析過程中發(fā)現(xiàn)副本內(nèi)wwise音頻組件占了30%的CPU時間，果斷拋棄之，采用Unity自帶音頻功能，優(yōu)化很明顯；
5、? 游戲內(nèi)界面采用了UGUI的方式實現(xiàn)，但大量的實時UI變化使得副本內(nèi)每幀會有230以上的drawcall，導致中低端機型感受到明顯卡頓，最終采用UGUI+自研究UI的組合拳，重寫了一套緊密結(jié)合游戲自身特性的UI來實現(xiàn)戰(zhàn)斗血條和浮動文字的效果。
6、? ??資源使用總量是否在合理范圍之內(nèi)。
7、? ?一個場景內(nèi)的資源重復率。
8、? ?資源對象拷貝的數(shù)量是否合理。
9、? 場景切換時保留的資源詳情。
10、?????????????網(wǎng)格、紋理、音頻、動畫、GameObject等資源是否超標。
?
11、?????????????貼圖：
12、?????????????l??控制貼圖大小，盡量不要超過?1024x1024；
13、?????????????l??盡量使用2的n次冪大小的貼圖，否則GfxDriver里會有2份貼圖；
14、?????????????l??盡量使用壓縮格式減小貼圖大小；
15、?????????????l??若干種貼圖合并技術；
16、?????????????l??去除多余的alpha通道；
17、?????????????l??不同設備使用不同的紋理貼圖，分層顯示；
18、??????????????
19、?????????????模型：
20、?????????????l??盡量控制模型的面數(shù)，小于1500會比較合適；
21、?????????????l??不同設備使用不同的模型面數(shù)；
22、?????????????l??盡量保持在30根骨骼內(nèi)；
23、?????????????l??一個網(wǎng)格不要超過3個material；
24、?????????????動畫：
25、?????????????l??N種動畫壓縮方法；
26、?????????????l??盡量減少骨骼數(shù)量；
27、?????????????聲音：
28、?????????????l??采用壓縮MP3?和?wav；
29、?????????????資源方面的優(yōu)化：
30、?????????????l??使用?Resource.Load?方法在需要的時候再讀取資源；
31、?????????????l??各種資源在使用完成后，盡快用Resource.UnloadAsset和UnloadUnusedAsset卸載掉；
32、?????????????l??靈活運用AssetBundle的Load和Unload方法動態(tài)加載資源，避免主要場景內(nèi)的初始化內(nèi)存占用過高；（實現(xiàn)起來真的很難…）
33、?????????????l??采用www加載了AssetBundle后，要用www.Dispose?及時釋放；
34、?????????????l??在關卡內(nèi)謹慎使用DontDestroyOnLoad，被標注的資源會常駐內(nèi)存；
35、?????????????代碼的優(yōu)化：
36、?????????????l??盡量避免代碼中的任何字符串連接，因為這會給GC帶來太多垃圾；
37、?????????????l??用簡單的“for”循環(huán)代替“foreach”循環(huán)；
38、?????????????l??為所有游戲內(nèi)的動態(tài)物體使用內(nèi)存對象池，可以減少系統(tǒng)開銷和內(nèi)存碎片，復用對象實例，構建自己的內(nèi)存管理模式，減少Instantiate和Destory；
39、?????????????l??盡量不使用LINQ命令，因為它們一般會分配中間緩器，而這很容易生成垃圾內(nèi)存；
40、?????????????l??將引用本地緩存到元件中會減少每次在一個游戲?qū)ο笾惺褂?“GetComponent” 獲取一個元件引用的需求；
41、?????????????l??減少角色控制器移動命令的調(diào)用。移動角色控制器會同步發(fā)生，每次調(diào)用都會耗損較大的性能；
42、?????????????l??最小化碰撞檢測請求（例如raycasts和sphere checks），盡量從每次檢查中獲得更多信息；
43、?????????????l??AI邏輯通常會生成大量物理查詢，建議讓AI更新循環(huán)設置低于圖像更新循環(huán)，以減少CPU負荷；
44、?????????????l??要盡量減少Unity回調(diào)函數(shù)，哪怕是空函數(shù)也不要留著；（例如空的Update、FixedUpdate函數(shù)）
45、?????????????l??盡量少使用FindObjectsOfType函數(shù)，這個函數(shù)非常慢，盡量少用且一定不要在Update里調(diào)用；
46、?????????????l??千萬一定要控制mono堆內(nèi)存的大小；
47、??????????????
48、?????????????unity3D 對于移動平臺的支持無可厚非，但是也有時候用Unity3D 開發(fā)出來的應用、游戲在移動終端上的運行有著明顯的效率問題，比如卡、畫質(zhì)等各種問題。自己在做游戲開發(fā)的時候偶有所得。對于主要影響性能的因素做個總結(jié)。
49、?????????????
50、?????????????主要因素有：
51、?????????????????????1.??????Savedby batching 值過大???---- > 這個值主要是針對Mesh的批處理，這個值越高，應用就越卡???
52、?????????????????????2.?????Drawcall值過大 ---- >??Drawcall 值過大，所需要的 GPU 的處理性能較高，從而導致CPU的計算時間過長，于是就卡了
53、?????????????????????3.?????點、面過多???????????----> 點、面過多，GPU 根據(jù)不同面的效果展開計算，并且CPU計算的數(shù)據(jù)也多，所以效果出來了，但是卡巴斯基
54、?????????????由于 Saved by batching 和 Drawcall 值過大所引起的卡的問題我所做的優(yōu)化方式有：
55、?????????????????????1.????對于模型 ：Mesh 合并，有個不錯的插件（DrawCallMinimizer???--->??直接上AssetStore 下載即可，免費的，而且有文檔，很容易上手）
56、?????????????????????2.????對于UI??:??盡量避免使用Unity3D自帶的 GUI 換用 NGUI或者EZGUI；因為這兩個UI插件對于UI中的圖片處理是將UI圖片放置在一個 Atlas中，一個 Atlas 對應一個Drawcall
57、?????????????????????3.???對于燈光：?可以使用 Unity3D 自帶的??Lightmapping插件來烘焙場景中的燈光效果到物體材質(zhì)上?
58、?????????????????????4.??對于場景： 可以使用 Unity3D 自帶的 OcclusionCulling 插件把靜止不動的場景元素烘焙出來
59、?????????????????????4.???對于特效：盡量把材質(zhì)紋理合并
60、?????????????對于Unity3D 在移動終端上支持的Drawcall 數(shù)到底多少，主要是跟機子性能有關的，當然也不是說值小性能就一定沒問題（本人親測，也有17就卡的，主要是模型材質(zhì)紋理過大所引起的），目前我做的是70左右的，還OK，挺正常的
61、??????????????
62、?????????????由于點、面過多所導致的性能問題，最好用簡模，用四面體來做復雜的模型，但是面、點也別太多，至于Unity3D 到底支持多少點、面的說法各異，我也搞不懂，總之少些肯定OK
63、??????????????
64、??????????????
65、??????????????
66、?????????????檢測方式：
67、?????????????一，Unity3D 渲染統(tǒng)計窗口
68、?????????????Game視窗的Stats去查看渲染統(tǒng)計的信息:
69、?????????????1、FPS
70、?????????????fps其實就是 framesper second,也就是每一秒游戲執(zhí)行的幀數(shù)，這個數(shù)值越小，說明游戲越卡。
71、??????????????
72、?????????????2、Draw calls
73、?????????????batching之后渲染mesh的數(shù)量，和當前渲染到的網(wǎng)格的材質(zhì)球數(shù)量有關。
74、??????????????
75、?????????????3、Saved?by?batching?
76、?????????????渲染的批處理數(shù)量，這是引擎將多個對象的繪制進行合并從而減少GPU的開銷;
77、?????????????很多GUI插件的一個好處就是合并多個對象的渲染，從而降低DrawCalls ，保證游戲幀數(shù)。
78、??????????????
79、?????????????4、Tris 當前繪制的三角面數(shù)
80、??????????????
81、?????????????5、Verts 當前繪制的頂點數(shù)
82、??????????????
83、?????????????6、Used Textures 當前幀用于渲染的圖片占用內(nèi)存大小
84、??????????????
85、?????????????7、Render Textures 渲染的圖片占用內(nèi)存大小，也就是當然渲染的物體的材質(zhì)上的紋理總內(nèi)存占用
86、??????????????
87、?????????????8、VRAM usage 顯存的使用情況，VRAM總大小取決于你的顯卡的顯存
88、??????????????
89、?????????????9、VBO Total 渲染過程中上載到圖形卡的網(wǎng)格的數(shù)量，這里注意一點就是縮放的物體可能需要額外的開銷。
90、??????????????
91、?????????????10、VisibleSkinned Meshes 蒙皮網(wǎng)格的渲染數(shù)量
92、??????????????
93、?????????????11、Animations 播放動畫的數(shù)量
94、?????????????注意事項：
95、?????????????1,運行時盡量減少 Tris 和 Draw Calls
96、?????????????預覽的時候，可點開 Stats，查看圖形渲染的開銷情況。特別注意 Tris 和 Draw Calls 這兩個參數(shù)。
97、?????????????一般來說，要做到：
98、?????????????Tris 保持在 7.5k 以下，有待考證。
99、?????????????Draw Calls 保持在 20 以下，有待考證。
100、??????????2，FPS，每一秒游戲執(zhí)行的幀數(shù)，這個數(shù)值越小，說明游戲越卡。
101、??????????3，Render Textures 渲染的圖片占用內(nèi)存大小。
102、??????????4，VRAM usage 顯存的使用情況，VRAM總大小取決于你的顯卡的顯存。
103、???????????
104、??????????二，代碼優(yōu)化
105、??????????1. 盡量避免每幀處理
106、??????????比如：
107、??????????function Update() {DoSomeThing(); }
108、??????????可改為每5幀處理一次：
109、??????????function Update() { if(Time.frameCount% 5 == 0) { DoSomeThing(); } }
110、??????????2. 定時重復處理用InvokeRepeating 函數(shù)實現(xiàn)
111、??????????比如，啟動0.5秒后每隔1秒執(zhí)行一次 DoSomeThing 函數(shù)：
112、???????????
113、??????????function Start() {InvokeRepeating("DoSomeThing", 0.5, 1.0); }
114、???????????
115、??????????3. 優(yōu)化 Update,FixedUpdate, LateUpdate 等每幀處理的函數(shù)
116、??????????函數(shù)里面的變量盡量在頭部聲明。
117、??????????比如：
118、??????????function Update() { var pos:Vector3 = transform.position; }
119、??????????可改為
120、??????????private var pos: Vector3;function Update(){ pos = transform.position; }
121、???????????
122、??????????4. 主動回收垃圾
123、??????????給某個 GameObject 綁上以下的代碼：
124、??????????function Update() {if(Time.frameCount % 50 == 0) { System.GC.Collect(); } }
125、???????????
126、??????????5. 優(yōu)化數(shù)學計算
127、??????????比如，如果可以避免使用浮點型(float)，盡量使用整形(int)，盡量少用復雜的數(shù)學函數(shù)比如 Sin 和 Cos 等等
128、???????????
129、??????????6，減少固定增量時間
130、??????????將固定增量時間值設定在0.04-0.067區(qū)間（即，每秒15-25幀）。您可以通過Edit->Project Settings->Time來改變這個值。這樣做降低了FixedUpdate函數(shù)被調(diào)用的頻率以及物理引擎執(zhí)行碰撞檢測與剛體更新的頻率。如果您使用了較低的固定增量時間，并且在主角身上使用了剛體部件，那么您可以啟用插值辦法來平滑剛體組件。
131、??????????7，減少GetComponent的調(diào)用
132、??????????使用 GetComponent或內(nèi)置組件訪問器會產(chǎn)生明顯的開銷。您可以通過一次獲取組件的引用來避免開銷，并將該引用分配給一個變量（有時稱為"緩存"的引用）。例如，如果您使用如下的代碼：
133、??????????function Update () {
134、??????????transform.Translate(0, 1, 0);
135、???????????
136、??????????}
137、??????????通過下面的更改您將獲得更好的性能：
138、???????????
139、??????????var myTransform : Transform;
140、??????????function Awake () {
141、??????????myTransform = transform;
142、??????????}
143、??????????function Update () {
144、??????????myTransform.Translate(0, 1, 0);
145、??????????}
146、???????????
147、??????????8，避免分配內(nèi)存
148、??????????您應該避免分配新對象，除非你真的需要，因為他們不再在使用時，會增加垃圾回收系統(tǒng)的開銷。您可以經(jīng)常重復使用數(shù)組和其他對象，而不是分配新的數(shù)組或?qū)ο蟆＿@樣做好處則是盡量減少垃圾的回收工作。同時，在某些可能的情況下，您也可以使用結(jié)構（struct）來代替類（class）。這是因為，結(jié)構變量主要存放在棧區(qū)而非堆區(qū)。因為棧的分配較快，并且不調(diào)用垃圾回收操作，所以當結(jié)構變量比較小時可以提升程序的運行性能。但是當結(jié)構體較大時，雖然它仍可避免分配/回收的開銷，而它由于"傳值"操作也會導致單獨的開銷，實際上它可能比等效對象類的效率還要低。
149、???????????
150、??????????9，使用iOS腳本調(diào)用優(yōu)化功能
151、??????????UnityEngine 命名空間中的函數(shù)的大多數(shù)是在 C/c + +中實現(xiàn)的。從Mono的腳本調(diào)用 C/C++函數(shù)也存在著一定的性能開銷。您可以使用iOS腳本調(diào)用優(yōu)化功能（菜單：Edit->Project Settings->Player）讓每幀節(jié)省1-4毫秒。此設置的選項有：
152、??????????Slow and Safe – Mono內(nèi)部默認的處理異常的調(diào)用
153、???????????
154、??????????Fast and Exceptions Unsupported–一個快速執(zhí)行的Mono內(nèi)部調(diào)用。不過，它并不支持異常，因此應謹慎使用。它對于不需要顯式地處理異常（也不需要對異常進行處理）的應用程序來說，是一個理想的候選項。
155、???????????
156、??????????10，
157、??????????優(yōu)化垃圾回收
158、???????????
159、??????????如上文所述，您應該盡量避免分配操作。但是，考慮到它們是不能完全杜絕的，所以我們提供兩種方法來讓您盡量減少它們在游戲運行時的使用：
160、??????????如果堆比較小，則進行快速而頻繁的垃圾回收
161、??????????這一策略比較適合運行時間較長的游戲，其中幀率是否平滑過渡是主要的考慮因素。像這樣的游戲通常會頻繁地分配小塊內(nèi)存，但這些小塊內(nèi)存只是暫時地被使用。如果在iOS系統(tǒng)上使用該策略，那么一個典型的堆大小是大約 200 KB，這樣在iPhone 3G設備上，垃圾回收操作將耗時大約 5毫秒。如果堆大小增加到1 MB時，該回收操作將耗時大約 7ms。因此，在普通幀的間隔期進行垃圾回收有時候是一個不錯的選擇。通常，這種做法會讓回收操作執(zhí)行的更加頻繁（有些回收操作并不是嚴格必須進行的），但它們可以快速處理并且對游戲的影響很小：
162、??????????if (Time.frameCount % 30 == 0)
163、??????????{
164、??????????System.GC.Collect();
165、??????????}
166、???????????
167、??????????但是，您應該小心地使用這種技術，并且通過檢查Profiler來確保這種操作確實可以降低您游戲的垃圾回收時間
168、??????????如果堆比較大，則進行緩慢且不頻繁的垃圾回收
169、??????????這一策略適合于那些內(nèi)存分配 (和回收）相對不頻繁，并且可以在游戲停頓期間進行處理的游戲。如果堆足夠大，但還沒有大到被系統(tǒng)關掉的話，這種方法是比較適用的。但是，Mono運行時會盡可能地避免堆的自動擴大。因此，您需要通過在啟動過程中預分配一些空間來手動擴展堆（ie，你實例化一個純粹影響內(nèi)存管理器分配的"無用"對象）：
170、???????????
171、??????????function Start() {
172、???????????
173、??????????var tmp = newSystem.Object[1024];
174、???????????
175、??????????// make allocations in smallerblocks to avoid them to be treated in a special way, which is designed forlarge blocks
176、???????????
177、??????????for (var i : int = 0; i <1024; i++)
178、???????????
179、??????????tmp[i] = new byte[1024];
180、???????????
181、??????????// release reference
182、???????????
183、??????????tmp = null;
184、???????????
185、??????????}
186、???????????
187、??????????游戲中的暫停是用來對堆內(nèi)存進行回收，而一個足夠大的堆應該不會在游戲的暫停與暫停之間被完全占滿。所以，當這種游戲暫停發(fā)生時，您可以顯式請求一次垃圾回收：
188、???????????
189、??????????System.GC.Collect();
190、???????????
191、??????????另外，您應該謹慎地使用這一策略并時刻關注Profiler的統(tǒng)計結(jié)果，而不是假定它已經(jīng)達到了您想要的效果。
192、???????????
193、??????????三，模型
194、??????????1,壓縮 Mesh
195、??????????導入 3D 模型之后，在不影響顯示效果的前提下，最好打開 Mesh Compression。
196、??????????Off, Low, Medium, High 這幾個選項，可酌情選取。
197、??????????2,避免大量使用 Unity 自帶的 Sphere 等內(nèi)建 Mesh
198、??????????Unity 內(nèi)建的 Mesh，多邊形的數(shù)量比較大，如果物體不要求特別圓滑，可導入其他的簡單3D模型代替。
?
199、???????????
200、??????????1不是每個主流手機都支持的技術（就是如果可以不用就不用或有備選方案）
201、??????????屏幕特效
202、??????????動態(tài)的pixel光照計算（如法線）
203、??????????實時的陰影
204、???????????
205、??????????2優(yōu)化建議
206、??????????2.1渲染
207、??????????1.不使用或少使用動態(tài)光照，使用light mapping和light probes（光照探頭）
208、??????????2.不使用法線貼圖（或者只在主角身上使用），靜態(tài)物體盡量將法線渲染到貼圖
209、??????????3．不適用稠密的粒子，盡量使用UV動畫
210、??????????4.不使用fog，使用漸變的面片（參考shadowgun）
211、??????????5.不要使用alpha–test（如那些cutout shader），使用alpha-blend代替
212、??????????6．使用盡量少的material，使用盡量少的pass和render次數(shù)，如反射、陰影這些操作
213、??????????7.如有必要，使用Per-LayerCull Distances，Camera.layerCullDistances
214、??????????8.只使用mobile組里面的那些預置shader
215、??????????9.使用occlusionculling
216、??????????11.遠處的物體繪制在skybox上
217、??????????12.使用drawcallbatching：
218、??????????????????對于相鄰動態(tài)物體：如果使用相同的shader，將texture合并
219、??????????????????對于靜態(tài)物體，batching要求很高，詳見Unity Manual>Advanced>Optimizing Graphics Performance>Draw Call Batching
220、???????????
221、??????????規(guī)格上限
222、??????????1.??????每個模型只使用一個skinnedmesh renderer
223、??????????2.??????每個mesh不要超過3個material
224、??????????3.??????骨骼數(shù)量不要超過30
225、??????????4.??????面數(shù)在1500以內(nèi)將得到好的效率
226、??????????2.2物理
227、??????????1.真實的物理（剛體）很消耗，不要輕易使用，盡量使用自己的代碼模仿假的物理
228、??????????2.對于投射物不要使用真實物理的碰撞和剛體，用自己的代碼處理
229、??????????3.不要使用meshcollider
230、??????????4.在edit->projectsetting->time中調(diào)大FixedTimestep（真實物理的幀率）來減少cpu損耗
231、??????????2.3腳本編寫
232、??????????1.盡量不要動態(tài)的instantiate和destroyobject，使用object pool
233、??????????2.盡量不要再update函數(shù)中做復雜計算，如有需要，可以隔N幀計算一次
234、??????????3.不要動態(tài)的產(chǎn)生字符串，如Debug.Log("boo"+ "hoo")，盡量預先創(chuàng)建好這些字符串資源
235、??????????4.cache一些東西，在update里面盡量避免search，如GameObject.FindWithTag("")、GetComponent這樣的調(diào)用，可以在start中預先存起來
236、??????????5.盡量減少函數(shù)調(diào)用棧，用x= (x > 0 ? x : -x);代替x = Mathf.Abs(x)
237、??????????6.下面的代碼是幾個gc“噩夢”
238、???????????String的相加操作，會頻繁申請內(nèi)存并釋放，導致gc頻繁，使用System.Text.StringBuilder代替
239、?????????????functionConcatExample(intArray: int[]) {
240、?????????????????????????varline = intArray[0].ToString();
241、???????????
242、?????????????????????????for(i = 1; i < intArray.Length; i++) {
243、?????????????????????????????????????????line+= ", " + intArray[i].ToString();
244、?????????????????????????}
245、???????????
246、?????????????????????????returnline;
247、??????????}
248、??????????在函數(shù)中動態(tài)new array，最好將一個array、傳進函數(shù)里修改
249、??????????functionRandomList(numElements: int) {
250、????????????????????varresult = new float[numElements];
251、???????????
252、????????????????????for(i = 0; i < numElements; i++) {
253、???????????????????????????????????result[i]= Random.value;
254、????????????????????}
255、???????????
256、????????????????????returnresult;
257、??????????}
258、???????????
259、??????????2.4 shader編寫
260、??????????1.數(shù)據(jù)類型
261、???????????fixed?/?lowp?-for colors, lighting information and normals,
262、??????????half?/?mediump?-for texture UV coordinates,
263、??????????float?/?highp?-avoid in pixel shaders, fine to use in vertex shader for position calculations.
264、??????????2.少使用的函數(shù)：pow,sin,cos等
265、??????????2.4 GUI
266、??????????1.不要使用內(nèi)置的onGUii函數(shù)處理gui，使用其他方案，如NGUI
267、???????????
268、??????????3.格式
269、??????????1.貼圖壓縮格式：ios上盡量使用PVRTC，android上使用ETC
?
?
270、??????????最簡單的優(yōu)化建議：
1.PC平臺的話保持場景中顯示的頂點數(shù)少于200K~3M，移動設備的話少于10W，一切取決于你的目標GPU與CPU。
2.如果你用U3D自帶的SHADER，在表現(xiàn)不差的情況下選擇Mobile或Unlit目錄下的。它們更高效。
3.盡可能共用材質(zhì)。
4.將不需要移動的物體設為Static，讓引擎可以進行其批處理。
5.盡可能不用燈光。
6.動態(tài)燈光更加不要了。
7.嘗試用壓縮貼圖格式，或用16位代替32位。
8.如果不需要別用霧效(fog)
9.嘗試用OcclusionCulling,在房間過道多遮擋物體多的場景非常有用。若不當反而會增加負擔。
10.用天空盒去“褪去”遠處的物體。
11.shader中用貼圖混合的方式去代替多重通道計算。
12.shader中注意float/half/fixed的使用。
13.shader中不要用復雜的計算pow,sin,cos,tan,log等。
14.shader中越少Fragment越好。
15.注意是否有多余的動畫腳本，模型自動導入到U3D會有動畫腳本，大量的話會嚴重影響消耗CPU計算。
16.注意碰撞體的碰撞層，不必要的碰撞檢測請舍去。
1.為什么需要針對CPU（中央處理器）與GPU（圖形處理器）優(yōu)化？
CPU和GPU都有各自的計算和傳輸瓶頸，不同的CPU或GPU他們的性能都不一樣，所以你的游戲需要為你目標用戶的CPU與GPU能力進行針對開發(fā)。
2.CPU與GPU的限制
GPU一般具有填充率(Fillrate)和內(nèi)存帶寬(Memory Bandwidth)的限制，如果你的游戲在低質(zhì)量表現(xiàn)的情況下會快很多，那么，你很可能需要限制你在GPU的填充率。
CPU一般被所需要渲染物體的個數(shù)限制，CPU給GPU發(fā)送渲染物體命令叫做DrawCalls。一般來說DrawCalls數(shù)量是需要控制的，在能表現(xiàn)效果的前提下越少越好。通常來說，電腦平臺上DrawCalls幾千個之內(nèi)，移動平臺上DrawCalls幾百個之內(nèi)。這樣就差不多了。當然以上并不是絕對的，僅作一個參考。
往往渲染(Rendering)并不是一個問題，無論是在GPU和CPU上。很可能是你的腳本代碼效率的問題，用Profiler查看下。
關于Profiler介紹：http://docs.unity3d.com/Documentation/Manual/Profiler.html
需要注意的是:
在GPU中顯示的RenderTexture.SetActive()占用率很高，是因為你同時打開了編輯窗口的原因，而不是U3D的BUG。
3.關于頂點數(shù)量和頂點計算
CPU和GPU對頂點的計算處理都很多。GPU中渲染的頂點數(shù)取決于GPU性能和SHADER的復雜程度，一般來說，每幀之內(nèi)，在PC上幾百萬頂點內(nèi)，在移動平臺上不超過10萬頂點。
CPU中的計算主要是在蒙皮骨骼計算，布料模擬，頂點動畫，粒子模擬等。GPU則在各種頂點變換、光照、貼圖混合等。
【個人認為，具體還是看各位的項目需求，假設你項目的是3d游戲。你游戲需要兼容低配置的硬件、流暢運行、控制硬件發(fā)熱的話，還要達到一定效果（LIGHTMAP+霧效），那么頂點數(shù)必定不能高。此時同屏2W頂點我認為是個比較合適的數(shù)目，DRAWCALL最好低于70。另，控制發(fā)熱請控制最高上限的幀率，流暢的話，幀率其實不需要太高的。】
4.針對CPU的優(yōu)化——減少DRAW CALL 的數(shù)量
為了渲染物體到顯示器上，CPU需要做一些工作,如區(qū)分哪個東西需要渲染、區(qū)分開物體是否受光照影響、使用哪個SHADER并且為SHADER傳參、發(fā)送繪圖命令告訴顯示驅(qū)動，然后發(fā)送命令告訴顯卡刪除等這些。
假設你有一個上千三角面的模型卻用上千個三角型模型來代替，在GPU上花費是差不多的，但是在CPU上則是極其不一樣，消耗會大很多很多。為了讓CPU更少的工作，需要減少可見物的數(shù)目：
a.合并相近的模型，手動在模型編輯器中合并或者使用UNITY的Draw call批處理達到相同效果(Draw call batching)。具體方法和注意事項查看以下鏈接：
Draw call batching :http://docs.unity3d.com/Documentation/Manual/DrawCallBatching.html
b.在項目中使用更少的材質(zhì)(material)，將幾個分開的貼圖合成一個較大的圖集等方式處理。
如果你需要通過腳本來控制單個材質(zhì)屬性，需要注意改變Renderer.material將會造成一份材質(zhì)的拷貝。因此，你應該使用Renderer.sharedMaterial來保證材質(zhì)的共享狀態(tài)。
有一個合并模型材質(zhì)不錯的插件叫Mesh Baker，大家可以考慮試下。
c.盡量少用一些渲染步驟，例如reflections,shadows,per-pixel light 等。
d.Draw call batching的合并物體，會使每個物體（合并后的物體）至少有幾百個三角面。
假設合并的兩個物體（手動合并）但不共享材質(zhì)，不會有性能表現(xiàn)上的提升。多材質(zhì)的物體相當于兩個物體不用一個貼圖。所以，為了提升CPU的性能，你應該確保這些物體使用同樣的貼圖。
另外，用燈光將會取消(break)引擎的DRAW CALL BATCH，至于為什么，查看以下：
Forward Rendering Path Details:
http://docs.unity3d.com/Documentation/Components/RenderTech-ForwardRendering.html
e.使用相關剔除數(shù)量直接減少Draw Call數(shù)量，下文有相關提及。
5.優(yōu)化幾何模型
最基本的兩個優(yōu)化準則：
a.不要有不必要的三角面。
b.UV貼圖中的接縫和硬邊越少越好。
需要注意的是，圖形硬件需要處理頂點數(shù)并跟硬件報告說的并不一樣。不是硬件說能渲染幾個點就是幾個點。模型處理應用通展示的是幾何頂點數(shù)量。例如，一個由一些不同頂點構成的模型。在顯卡中，一些集合頂點將會被分離(split)成兩個或者更多邏輯頂點用作渲染。如果有法線、UV坐標、頂點色的話，這個頂點必須會被分離。所以在游戲中處理的實際數(shù)量顯然要多很多。
6.關于光照
若不用光肯定是最快的。移動端優(yōu)化可以采用用光照貼圖(Lightmapping)去烘培一個靜態(tài)的貼圖，以代替每次的光照計算，在U3D中只需要非常短的時間則能生成。這個方法能大大提高效率，而且有著更好的表現(xiàn)效果（平滑過渡處理，還有附加陰影等）。
在移動設備上和低端電腦上盡量不要在場景中用真光，用光照貼圖。這個方法大大節(jié)省了CPU和GPU的計算，CPU得到了更少的DRAWCALL，GPU則需要更少頂點處理和像素柵格化。
Lightmapping : http://docs.unity3d.com/Documentation/Manual/Lightmapping.html
7.對GPU的優(yōu)化——圖片壓縮和多重紋理格式
Compressed Textures（圖片壓縮):
http://docs.unity3d.com/Documentation/Components/class-Texture2D.html
圖片壓縮將降低你的圖片大小（更快地加載更小的內(nèi)存跨度(footprint)），而且大大提高渲染表現(xiàn)。壓縮貼圖比起未壓縮的32位RGBA貼圖占用內(nèi)存帶寬少得多。
之前U3D會議還聽說過一個優(yōu)化，貼圖盡量都用一個大小的格式（512 * 512 ， 1024 * 1024），這樣在內(nèi)存之中能得到更好的排序，而不會有內(nèi)存之間空隙。這個是否真假沒得到過測試。
MIPMAps（多重紋理格式）：
http://docs.unity3d.com/Documentation/Components/class-Texture2D.html
跟網(wǎng)頁上的略縮圖原理一樣，在3D游戲中我們?yōu)橛螒虻馁N圖生成多重紋理貼圖，遠處顯示較小的物體用小的貼圖，顯示比較大的物體用精細的貼圖。這樣能更加有效的減少傳輸給GPU中的數(shù)據(jù)。
8.LOD 、 Per-Layer Cull Distances 、 Occlusion Culling
LOD (Level Of Detail) 是很常用的3D游戲技術了，其功能理解起來則是相當于多重紋理貼圖。在以在屏幕中顯示模型大小的比例來判斷使用高或低層次的模型來減少對GPU的傳輸數(shù)據(jù)，和減少GPU所需要的頂點計算。
攝像機分層距離剔除(Per-Layer Cull Distances)：為小物體標識層次，然后根據(jù)其距離主攝像機的距離判斷是否需要顯示。
遮擋剔除（Occlusion Culling）其實就是當某個物體在攝像機前被另外一個物體完全擋住的情況，擋住就不發(fā)送給GPU渲染，從而直接降低DRAW CALL。不過有些時候在CPU中計算其是否被擋住則會很耗計算，反而得不償失。
以下是這幾個優(yōu)化技術的相關使用和介紹：
Level Of Detail :
http://docs.unity3d.com/Documentation/Manual/LevelOfDetail.html
Per-Layer Cull Distances :
http://docs.unity3d.com/Documentation/ScriptReference/Camera-layerCullDistances.html
Occlusion Culling ：
http://docs.unity3d.com/Documentation/Manual/OcclusionCulling.html
9.關于Realtime Shadows（實時陰影）
實時陰影技術非常棒，但消耗大量計算。為GPU和CPU都帶來了昂貴的負擔，細節(jié)的話參考下面：
http://docs.unity3d.com/Documentation/Manual/Shadows.html
10.對GPU優(yōu)化：采用高效的shader
a.需要注意的是有些(built-in)Shader是有mobile版本的，這些大大提高了頂點處理的性能。當然也會有一些限制。
b.自己寫的shader請注意復雜操作符計算，類似pow,exp,log,cos,sin,tan等都是很耗時的計算，最多只用一次在每個像素點的計算。不推薦你自己寫normalize,dot,inversesqart操作符，內(nèi)置的肯定比你寫的好。
c.需要警醒的是alpha test，這個非常耗時。
d.浮點類型運算:精度越低的浮點計算越快。
在CG/HLSL中--
float ：32位浮點格式，適合頂點變換運算，但比較慢。
half：16位浮點格式，適合貼圖和UV坐標計算，是highp類型計算的兩倍。
fixed: 10位浮點格式，適合顏色，光照，和其他。是highp格式計算的四倍。
寫Shader優(yōu)化的小提示:
http://docs.unity3d.com/Documentation/Components/SL-ShaderPerformance.html
11.另外的相關優(yōu)化：
a.對Draw Call Batching的優(yōu)化
http://docs.unity3d.com/Documentation/Manual/DrawCallBatching.html
b.對Rendering Statistics Window的說明和提示：
http://docs.unity3d.com/Documentation/Manual/RenderingStatistics.html
c.角色模型的優(yōu)化建議
用單個蒙皮渲染、盡量少用材質(zhì)、少用骨骼節(jié)點、移動設備上角色多邊形保持在300~1500內(nèi)(當然還要看具體的需求)、PC平臺上1500~4000內(nèi)(當然還要看具體的需求)。
http://docs.unity3d.com/Documentation/Manual/ModelingOptimizedCharacters.html
?
?
?
渲染順序
U3D的渲染是有順序的，U3D的渲染順序是由我們控制的，控制好U3D的渲染順序，你才能控制好DrawCall
一個DrawCall，表示U3D使用這個材質(zhì)/紋理，來進行一次渲染，那么這次渲染假設有3個對象，那么當3個對象都使用這一個材質(zhì)/紋理的 時候，就會產(chǎn)生一次DrawCall，可以理解為一次將紋理輸送到屏幕上的過程，（實際上引擎大多會使用如雙緩沖，緩存這類的手段來優(yōu)化這個過程，但在這 里我們只需要這樣子認識就可以了），假設3個對象使用不同的材質(zhì)/紋理，那么無疑會產(chǎn)生3個DrawCall
接下來我們的3個對象使用2個材質(zhì)，A和B使用材質(zhì)1，C使用材質(zhì)2，這時候來看，應該是有2個DrawCall，或者3個DrawCall。 應該是2個DrawCall啊，為什么會有3個DrawCall？？？而且是有時候2個，有時候3個。我們按照上面的DrawCall分析流程來分析一 下：
1.渲染A，使用材質(zhì)1?
2.渲染B，使用材質(zhì)1?
3.渲染C，使用材質(zhì)2
在這種情況下是2個DrawCall，在下面這種情況下，則是3個DrawCall
1.渲染A，使用材質(zhì)1?
2.渲染C，使用材質(zhì)2?
3.渲染B，使用材質(zhì)1
因為我們沒有控制好渲染順序（或者說沒有去特意控制），所以導致了額外的DrawCall，因為A和B不是一次性渲染完的，而是被C打斷了，所以導致材質(zhì)1被分為兩次渲染
那么是什么在控制這個渲染順序呢？首先在多個相機的情況下，U3D會根據(jù)相機的深度順序進行渲染，在每個相機中，它會根據(jù)你距離相機的距離，由遠到近進行渲染，在UI相機中，還會根據(jù)你UI對象的深度進行渲染
那么我們要做的就是，對要渲染的對象進行一次規(guī)劃，正確地排列好它們，規(guī)則是，按照Z軸或者深度，對空間進行劃分，然后確定好每個對象的Z軸和深度，讓使用同一個材質(zhì)的東西，盡量保持在這個空間內(nèi)，不要讓其他材質(zhì)的對象進入這個空間，否則就會打斷這個空間的渲染順序
在這個基礎上，更細的規(guī)則有：
場景中的東西，我們使用Z軸來進行空間的劃分，例如背景層，特效層1，人物層，特效層2?
NGUI中的東西，我們統(tǒng)一使用Depth來進行空間的劃分?
人物模型，當人物模型只是用一個材質(zhì)，DrawCall只有1，但是用了2個以上的材質(zhì)，DrawCall就會暴增（或許對材質(zhì)的RenderQueue 進行規(guī)劃也可以使DrawCall只有2個，但這個要拆分好才行），3D人物處于復雜3D場景中的時候，我們的空間規(guī)則難免被破壞，這只能在設計的時候盡 量去避免這種情況了?
使用了多個材質(zhì)的特效，在動畫的過程中，往往會引起DrawCall的波動，在視覺效果可以接受的范圍內(nèi)，可以將特效也進行空間劃分，假設這個特效是2D顯示，那么可以使用Z軸來劃分空間
?
二、
優(yōu)化：?
1. 更新不透明貼圖的壓縮格式為ETC 4bit，因為android市場的手機中的GPU有多種，
每家的GPU支持不同的壓縮格式，但他們都兼容ETC格式，
2. 對于透明貼圖，我們只能選擇RGBA 16bit 或者RGBA 32bit。
3. 減少FPS，在ProjectSetting-> Quality中的
VSync Count 參數(shù)會影響你的FPS，EveryVBlank相當于FPS=60，EverySecondVBlank = 30；
這兩種情況都不符合游戲的FPS的話，我們需要手動調(diào)整FPS，首先關閉垂直同步這個功能，然后在代碼的Awake方法里手動設置FPS（Application.targetFrameRate = 45;）
降低FPS的好處：
1）省電，減少手機發(fā)熱的情況；
2）能都穩(wěn)定游戲FPS，減少出現(xiàn)卡頓的情況。
4. 當我們設置了FPS后，再調(diào)整下Fixed timestep這個參數(shù)，
這個參數(shù)在ProjectSetting->Time中，目的是減少物理計算的次數(shù)，來提高游戲性能。
5. 盡量少使用Update LateUpdate FixedUpdate，這樣也可以提升性能和節(jié)省電量。
多使用事件（不是SendMessage，使用自己寫的，或者C#中的事件委托）。
6. 待機時，調(diào)整游戲的FPS為1，節(jié)省電量。
7. 圖集大小最好不要高于1024，否則游戲安裝之后、低端機直接崩潰、原因是手機系統(tǒng)版本低于2.2、超過1000的圖集無法讀取、導致。
2.2 以上沒有遇見這個情況。
注意手機的RAM 與 ROM、小于 512M的手機、直接放棄機型適配。
VSCount 垂直同步
? ?中新建一個場景空的時候，幀速率（FPS總是很低），大概在60~70之間。
一直不太明白是怎么回事，現(xiàn)在基本上明白了。我在這里解釋一下原因，如有錯誤，歡迎指正。
在Unity3D中當運行場景打開Profiler的時候，我們會看到VSync 這一項占了很大的比重。
這個是什么呢，這個就是垂直同步，稍后再做解釋。
我們可以關閉VSync來提高幀速率，選擇edit->project settings->Quality。
<ignore_js_op>
?
在右側(cè)面板中可以找到VSync Count,把它選成Don't Sync。
<ignore_js_op>?
這就關閉了VSync(垂直同步)，現(xiàn)在在運行場景看看，幀速率是不是提高很多。
現(xiàn)在來說說什么是垂直同步，要知道什么是垂直同步，必須要先明白顯示器的工作原理，
顯示器上的所有圖像都是一線一線的掃描上去的，無論是隔行掃描還是逐行掃描，
顯示器都有兩種同步參數(shù)——水平同步和垂直同步。
什么叫水平同步？什么叫垂直同步？
垂直和水平是CRT中兩個基本的同步信號，水平同步信號決定了CRT畫出一條橫越屏幕線的時間，
垂直同步信號決定了CRT從屏幕頂部畫到底部，再返回原始位置的時間，
而恰恰是垂直同步代表著CRT顯示器的刷新率水平。
為什么關閉垂直同步信號會影響游戲中的FPS數(shù)值？
如果我們選擇等待垂直同步信號（也就是我們平時所說的垂直同步打開），
那么在游戲中或許強勁的顯卡迅速的繪制完一屏的圖像，但是沒有垂直同步信號的到達，
顯卡無法繪制下一屏，只有等85單位的信號到達，才可以繪制。
這樣FPS自然要受到操作系統(tǒng)刷新率運行值的制約。
而如果我們選擇不等待垂直同步信號（也就是我們平時所說的關閉垂直同步），那么游戲中作完一屏畫面，
顯卡和顯示器無需等待垂直同步信號就可以開始下一屏圖像的繪制，自然可以完全發(fā)揮顯卡的實力。
但是不要忘記，正是因為垂直同步的存在，才能使得游戲進程和顯示器刷新率同步，使得畫面更加平滑和穩(wěn)定。
取消了垂直同步信號，固然可以換來更快的速度，但是在圖像的連續(xù)性上勢必打折扣。
這也正是很多朋友抱怨關閉垂直后發(fā)現(xiàn)畫面不連續(xù)的理論原因。
合并材質(zhì)球unity 3d中每倒入一次模型就多一個材質(zhì)球，可我的這些模型都是共用一張貼圖的就想共用一個材質(zhì)球，所以每次都要刪除再附上，很麻煩。怎么才能合并這些材質(zhì)球？
采用TexturePacking吧
1、遍歷gameobject，取出material，并根據(jù)shader來將material分類
2、調(diào)用Unity自帶的PackTextures函數(shù)來合并每個shader分類中的material所對應的textures（PackTextures函數(shù)有缺陷，不過可以將就用）
3、根據(jù)合并的大的texture來更新原有模型的texture、material已經(jīng)uv坐標值。
需要注意的是：需要合并的紋理應該是物體在場景中距離相近的，如果物體在場景中的距離較遠，
則不建議合并紋理，因為這樣做很有可能非但起不到優(yōu)化的作用，反而降低了運行效率。?
mesh合并?
分為2種方式合并
1.自帶的合并必須勾選靜態(tài)。
<ignore_js_op>?
所有被勾選了“Static”的GameObject，其中的Mesh Filter中的mesh都會被合并到 "Combined Mesha (root: scene)" 中
2.也可以用腳本來合并mesh?。
[C#]?純文本查看?復制代碼
| ? 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 | using?UnityEngine; using?System.Collections; ? public?class?MyClass : MonoBehaviour { ????void?Start () ????{ ????????MeshFilter [] meshFilters = GetComponentsInChildren<MeshFilter> (); ????????CombineInstance[] combine = new?CombineInstance[meshFilters.Length]; ? ????????for?(int?i = 0; i < meshFilters.Length; i++) { ????????????combine [i].mesh = meshFilters [i].sharedMesh; ????????????combine [i].transform = meshFilters [i].transform.localToWorldMatrix; ????????????meshFilters [i].gameObject.active = false; ????????} ? ????????????transform.GetComponent<MeshFilter> ().mesh = new?Mesh (); ????????????transform.GetComponent<MeshFilter> ().mesh.CombineMeshes (combine); ????????????transform.gameObject.active = true; ????} } |
1.?先在 Unity 中建立 空物件 ( Empty )?
2.?再創(chuàng)建2個 Cube 方塊，并放入 空物件底下 (可以改成你自己的模型)
3.?把 MyClass 代碼丟進 空物件上 。
4.?(可選) 建立一個 Material 材質(zhì)，并且丟進 空物件上
5.?執(zhí)行
前
<ignore_js_op>?
后
<ignore_js_op>?
========================================分割線====================================
- 角色Material數(shù)量
- 骨骼數(shù)量
- 面片數(shù)量
- 一般角色應該沒有IK結(jié)點
?
2、靜態(tài)實體
- 不要附加 Component
- 網(wǎng)格頂點數(shù)
- UV值范圍盡量不要超過（0, 1）區(qū)間
?
3、地形
- 地形的分辨率大小
- 混合紋理數(shù)量
?
4、紋理
- 紋理格式
- 紋理尺寸
- 支持Mipmap
- 檢查Alpha值
?
5、光源
- 光源“Important”個數(shù)
- Pixel Light數(shù)目
?
6、粒子特效
- 屏幕上的最大粒子數(shù)
- 每個粒子發(fā)射器發(fā)射的最大粒子數(shù)
- 粒子大小
- 盡量不要開啟粒子的碰撞功能。
?
7、音頻
- 游戲中播放時間較長的音樂（如背景音樂）
- 較短音樂（如槍聲）
?
8、相機
- 裁剪平面
- 根據(jù)不同的物體設置不同的遠裁剪平面
?
9、碰撞
- 盡量不用MeshCollider
?
10、其他
- Drawcall
?
- 非運動物體盡量打上Static標簽
?
- 場景中盡可能地使用prefab
========================================分割線====================================?
?
移動平臺相對于PC機，具有體積小，計算弱，帶寬少的特點。
因此做手機游戲的開發(fā)，優(yōu)化的方向，與力度對比PC游戲都有所區(qū)別。
?
必須要做到優(yōu)化流程，合理利用資源。
目前在手機上面，還不能夠像PC游戲那樣追求高質(zhì)量渲染效果，為了讓手機不那么容易發(fā)燙，還要控制cpu，gpu，不能讓他們?nèi)龠\算。
?
材質(zhì)方面：
紋理方面，建議使用壓縮紋理，
上面使用ETC1，蘋果上面使用PVRTC。
?
UV坐標控制在0到1之間，人物模型面數(shù)控制在1500內(nèi)，骨骼控制在30個以內(nèi)。
場景中使用一個主光（不能再多了）。
?
盡量減少alphaTest和alphaBlend材質(zhì)的使用。在手機上，這是很殺效率的。
?
骨骼動畫方面：
在動畫方面可以考慮不使用插值，固定的幀率的動畫。
如果要做插值，考慮使用四元數(shù)（表示旋轉(zhuǎn)）和向量（表示位移）來做插值。
四元數(shù)做插值速度比矩陣來的快，Slerp提供了平滑插值。
========================================分割線====================================?
優(yōu)化的常規(guī)技巧
剖析你的游戲。
不要花費時間來優(yōu)化那些晦澀的代碼或者縮減圖形文件的大小，除非這是你游戲的瓶頸。
第一次剖析你的游戲?qū)鼓惆l(fā)現(xiàn)你游戲的瓶頸。Apple's Shark是一個很好的用來剖析基于OpenGL的程序的工具。
再次剖析你的游戲。
優(yōu)化之后不要忘記再剖析一次你的游戲，這樣可以檢查你所做的優(yōu)化是否達到了預期的效果。
當然，這樣做也可能會使你發(fā)現(xiàn)更多的瓶頸。
流程第一、性能第二。花費時間來使你游戲的創(chuàng)建盡可能地流暢。
盡可能快地修正游戲中的錯誤將會使你后期更容易優(yōu)化你的游戲。
在Scene View中測試場景。
這樣做將會使你清楚了解這個場景中的物體或者附加在物體上的腳本是否降低了游戲性能。
如果Scene View反應遲鈍，那么有可能是圖形方面的原因，如果Scene View反應不遲鈍，那么瓶頸可能出在腳本或者物理系統(tǒng)上。
禁用指定游戲物體。
在play模式下，嘗試禁用并啟用游戲物體來排查出游戲慢的原因。
網(wǎng)格
如果可能的話，把相鄰的物體（網(wǎng)格）合并為一個只有一個材質(zhì)的物體（網(wǎng)格）。比如，你的游戲中包含一個桌子，上面有一堆東西，你完全可以在3D程序中將它們合并在一起（這可能也需要你將這些物體的紋理合并為一個大的紋理集）。減少需要渲染的物體的數(shù)量可以極大地提高游戲性能。
不要有不必要的網(wǎng)格。
如果你的游戲場景中有一個人物，那么他應該是一個網(wǎng)格。如果你有一個船，那么它也應該只是一個網(wǎng)格。
每一個網(wǎng)格只用一種材質(zhì)。
使用極少的面數(shù)的網(wǎng)格（比如500個多邊形以下）。
最好把你人物的三角面數(shù)量控制在1500-2000個之間。
這個數(shù)量可以說是游戲質(zhì)量和性能之間一個均衡值。如果你的模型有四邊形，那么在導入模型的時候，引擎將會把每個四邊形變?yōu)閮蓚€三角形。
光照
像素光。
像素光可以讓你的游戲看起來效果很牛逼，但是不要使用過多的像素光。
在你的游戲中可以使用質(zhì)量管理器來調(diào)節(jié)像素光的數(shù)量來取得一個性能和質(zhì)量的均衡點.
性能占用順序：聚光燈>點光源>平行光。
一個好的點亮場景的方法就是先得到你想要的效果，然后看看哪些光更重要；
在保持光效的前提下看看哪些光可以去掉。
點光源和聚光燈只影響它們范圍內(nèi)的網(wǎng)格。
如果一個網(wǎng)格處于點光源或者聚光燈的照射范圍之外，并且光源的attenuate開關是打開的，那么這個網(wǎng)格將不會被光源所影響，這樣就可以節(jié)省性能開銷。
這樣做理論上來講可以使用很多小的點光源而且依然能有一個好的性能，因為這些光源只影響一小部分物體。
一個網(wǎng)格在有8個以上光源影響的時候，只響應前8個最亮的光源。
貼圖
在外觀不變的前提下，貼圖大小越小越好。
如果你的顯卡的顯存不夠大的話，你游戲中的貼圖將會被轉(zhuǎn)存到系統(tǒng)內(nèi)存中，在顯卡調(diào)用它們的時候再傳到顯卡中。
對于比較新的電腦來說，內(nèi)存和顯卡之間有足夠的帶寬來達到一個很好的性能；
如果你很無恥地用了巨多的大圖片的話，在低顯存的電腦上運行你的游戲的時候，你的游戲必然會掛掉。
倒是沒有必要在圖形編輯軟件中調(diào)整貼圖的大小。你可以在unity導入貼圖的時候進行調(diào)整。
不要使用低質(zhì)量的圖片。
在小播放界面的游戲中使用低質(zhì)量的jpeg圖片或者低色彩的png圖片亦或是gif圖片沒什么問題。
在發(fā)布游戲的時候，引擎會自動壓縮這些圖片，多重壓縮和解壓將會降低圖片的質(zhì)量，所以最好保持貼圖文件的分辨率為原始分辨率。
這樣就會減少多重壓縮和解壓所導致的圖片失真現(xiàn)象。
Shaders
多重效果的shader就比看起來樣式很單一的shader要更耗費資源。
同樣在一個擁有貼圖和光反射的物體上，使用VertexLit Diffuse shader無疑是最省資源的。
========================================分割線====================================?
在美術制作場景的過程中，會使用到大量的粒子系統(tǒng)。
比如場景中的火把。在我們的一個地下城場景中，美術們放置了大量的火把。整個場景中的各個地方，有100來個火把。
unity中，在攝像機范圍外的粒子系統(tǒng)雖然不會被繪制。
但是update是一直持續(xù)的。這也就意味著，這100多個火把，不論是否可見都在更新。
這個設計應該是很不合理的，在我看過的其他引擎中，都會有一個開關，來控制不可見的粒子系統(tǒng)是否需要update。
有的粒子系統(tǒng)在不可見的時候需要更新,比如爆炸。有的不需要更新，比如火堆火把。
為了避免不必要的update開銷，尤其是最后游戲是要發(fā)布到頁游平臺（web player只能使用一個cpu的核）。
于是寫了一個腳本，控制不可見的粒子系統(tǒng)就不更新。
該腳本主要是用到了2個MonoBehaviour的函數(shù)。
OnBecameInvisible()?當變?yōu)椴豢梢? ?和? ?OnBecameVisible()?當變成可見。?
要這2個函數(shù)起作用的前提是，該GameObject綁定了MeshRender組件。
所以，我們要在粒子系統(tǒng)的GameObject放置在一個GameObject??下，且給該GameObject綁定一個MeshRender 與 MeshFilter。
MeshFilter中的mesh可以隨便找個cube。
在Start（） 的時候，把最GameObject的scale設置為很小，以保證該cube不被看見。
其實遍歷所有的child，把active設置為false。
在OnBecameVisible 中 遍歷所有child，把active設置為true。
在OnBecameInvisible中 遍歷所有child，把active設置為false。
========================================分割線====================================?
Unity 性能優(yōu)化 Draw Call?
Unity（或者說基本所有圖形引擎）生成一幀畫面的處理過程大致可以這樣簡化描述：引擎首先經(jīng)過簡單的可見性測試，確定攝像機可以看到的物體，然后把這些物體的頂點（包括本地位置、法線、UV等），索引（頂點如何組成三角形），變換（就是物體的位置、旋轉(zhuǎn)、縮放、以及攝像機位置等），相關光源，紋理，渲染方式（由材質(zhì)/Shader決定）等數(shù)據(jù)準備好，然后通知圖形API——或者就簡單地看作是通知GPU——開始繪制，GPU基于這些數(shù)據(jù)，經(jīng)過一系列運算，在屏幕上畫出成千上萬的三角形，最終構成一幅圖像。
在Unity中，每次引擎準備數(shù)據(jù)并通知GPU的過程稱為一次Draw Call。這一過程是逐個物體進行的，對于每個物體，不只GPU的渲染，引擎重新設置材質(zhì)/Shader也是一項非常耗時的操作。因此每幀的Draw Call次數(shù)是一項非常重要的性能指標，對于iOS來說應盡量控制在20次以內(nèi)，這個值可以在編輯器的Statistic窗口看到。
Unity內(nèi)置了Draw Call Batching技術，從名字就可以看出，它的主要目標就是在一次Draw Call中批量處理多個物體。只要物體的變換和材質(zhì)相同，GPU就可以按完全相同的方式進行處理，即可以把它們放在一個Draw Call中。Draw Call Batching技術的核心就是在可見性測試之后，檢查所有要繪制的物體的材質(zhì)，把相同材質(zhì)的分為一組（一個Batch），然后把它們組合成一個物體（統(tǒng)一變換），這樣就可以在一個Draw Call中處理多個物體了（實際上是組合后的一個物體）。
但Draw Call Batching存在一個缺陷，就是它需要把一個Batch中的所有物體組合到一起，相當于創(chuàng)建了一個與這些物體加起來一樣大的物體，與此同時就需要分配相應大小的內(nèi)存。這不僅會消耗更多內(nèi)存，還需要消耗CPU時間。特別是對于移動的物體，每一幀都得重新進行組合，這就需要進行一些權衡，否則得不償失。但對于靜止不動的物體來說，只需要進行一次組合，之后就可以一直使用，效率要高得多。
Unity提供了Dynamic Batching和Static Batching兩種方式。Dynamic Batching是完全自動進行的，不需要也無法進行任何干預，對于頂點數(shù)在300以內(nèi)的可移動物體，只要使用相同的材質(zhì)，就會組成Batch。Static Batching則需要把靜止的物體標記為Static，然后無論大小，都會組成Batch。如前文所說，Static Batching顯然比Dynamic Batching要高效得多，于是，Static Batching功能是收費的……
要有效利用Draw Call Batching，首先是盡量減少場景中使用的材質(zhì)數(shù)量，即盡量共享材質(zhì)，對于僅紋理不同的材質(zhì)可以把紋理組合到一張更大的紋理中（稱為Texture Atlasing）。然后是把不會移動的物體標記為Static。此外還可以通過CombineChildren腳本（Standard Assets/Scripts/Unity Scripts/CombineChildren）手動把物體組合在一起，但這個腳本會影響可見性測試，因為組合在一起的物體始終會被看作一個物體，從而會增加GPU要處理的幾何體數(shù)量，因此要小心使用。
對于復雜的靜態(tài)場景，還可以考慮自行設計遮擋剔除算法，減少可見的物體數(shù)量同時也可以減少Draw Call。
總之，理解Draw Call和Draw Call Batching原理，根據(jù)場景特點設計相應的方案來盡量減少Draw Call次數(shù)才是王道，其它方面亦然。
Draw Call Batching （繪制調(diào)用批處理）
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.
在屏幕上渲染物體，引擎需要發(fā)出一個繪制調(diào)用來訪問圖形API（iOS系統(tǒng)中為OpenGL ES）。
每個繪制調(diào)用需要進行大量的工作來訪問圖形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在運行時可以將一些物體進行合并，從而用一個繪制調(diào)用來渲染他們。這一操作，我們稱之為“批處理”。
一般來說，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中內(nèi)建的批處理機制所達到的效果要明顯強于使用幾何建模工具（或使用Standard Assets包中的CombineChildren腳本）的批處理效果。
這是因為，Unity引擎的批處理操作是在物體的可視裁剪操作之后進行的。
Unity先對每個物體進行裁剪，然后再進行批處理，這樣可以使渲染的幾何總量在批處理前后保持不變。
但是，使用幾何建模工具來拼合物體，會妨礙引擎對其進行有效的裁剪操作，從而導致引擎需要渲染更多的幾何面片。
Materials
材質(zhì)
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.
只有擁有相同材質(zhì)的物體才可以進行批處理。
因此，如果你想要得到良好的批處理效果，你需要在程序中盡可能地復用材質(zhì)和物體。
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.
如果你的兩個材質(zhì)僅僅是紋理不同，那么你可以通過 紋理拼合 操作來將這兩張紋理拼合成一張大的紋理。
一旦紋理拼合在一起，你就可以使用這個單一材質(zhì)來替代之前的兩個材質(zhì)了。
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.
如果你需要通過腳本來訪問復用材質(zhì)屬性，那么值得注意的是改變Renderer.material將會造成一份材質(zhì)的拷貝。
因此，你應該使用Renderer.sharedMaterial來保證材質(zhì)的共享狀態(tài)。
Dynamic Batching
動態(tài)批處理
Unity can automatically batch moving objects into the same draw call if they share the same material.
如果動態(tài)物體共用著相同的材質(zhì)，那么Unity會自動對這些物體進行批處理。
Dynamic batching is done automatically and does not require any additional effort on your side.
動態(tài)批處理操作是自動完成的，并不需要你進行額外的操作。
Tips:
提醒：
1、? ?? ?Batching dynamic objects has certain overheadper vertex, so batching is applied only to meshes containing less than900 vertex attributes in total.
? ?? ?? ?? ? 批處理動態(tài)物體需要在每個頂點上進行一定的開銷，所以動態(tài)批處理僅支持小于900頂點的網(wǎng)格物體。
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頂點以下的物體。
? ?? ?? ?? ?請注意：屬性數(shù)量的限制可能會在將來進行改變。
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.
? ?? ?? ?? ?統(tǒng)一縮放尺度的物體不會與非統(tǒng)一縮放尺度的物體進行批處理。
? ?? ?? ???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.
? ?? ?? ???使用不同材質(zhì)的實例化物體（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)
? ?? ?? ???擁有l(wèi)ightmap的物體含有額外（隱藏）的材質(zhì)屬性，比如：lightmap的偏移和縮放系數(shù)等。所以，擁有l(wèi)ightmap的物體將不會進行批處理（除非他們指向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.
? ?? ?? ???預設體的實例會自動地使用相同的網(wǎng)格模型和材質(zhì)。
Static Batching
靜態(tài)批處理
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.
相對而言，靜態(tài)批處理操作允許引擎對任意大小的幾何物體進行批處理操作來降低繪制調(diào)用（只要這些物體不移動，并且擁有相同的材質(zhì)）。因此，靜態(tài)批處理比動態(tài)批處理更加有效，你應該盡量低使用它，因為它需要更少的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:
為了更好地使用靜態(tài)批處理，你需要明確指出哪些物體是靜止的，并且在游戲中永遠不會移動、旋轉(zhuǎn)和縮放。想完成這一步，你只需要在檢測器（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.
使用靜態(tài)批處理操作需要額外的內(nèi)存開銷來儲存合并后的幾何數(shù)據(jù)。在靜態(tài)批處理之前，如果一些物體共用了同樣的幾何數(shù)據(jù)，那么引擎會在編輯以及運行狀態(tài)對每個物體創(chuàng)建一個幾何數(shù)據(jù)的備份。這并不總是一個好的想法，因為有時候，你將不得不犧牲一點渲染性能來防止一些物體的靜態(tài)批處理，從而保持較少的內(nèi)存開銷。比如，將濃密森里中樹設為Static，會導致嚴重的內(nèi)存開銷。
Static batching is only available in Unity iOS Advanced.
靜態(tài)批處理目前只支持Unity iOS Advanced。
備注：最近一直在研究Unity3D的性能優(yōu)化問題，這段時間可能會多翻譯這方面的文章。
前兩天，MadFinger，就是當今iOS與Android上畫質(zhì)最牛逼閃閃的游戲之一——ShadowGun的開發(fā)商，令人驚異地放出了一個ShadowGun的樣例關卡以及若干可免費使用的Shader，國外同行們的分享精神真的是令人贊嘆不已。原文在這里，以下是我的一些摘錄和筆記。
首先是一些優(yōu)化常識。針對圖形方面的優(yōu)化主要包括三角形數(shù)量，紋理所占內(nèi)存，以及Shader，前兩項基本沒什么好講的，針對設備機能的限制制定相應的指標即可，所以Shader就成為了圖形性能優(yōu)化的關鍵。
Alpha blending
在Unity官方文檔中講，由于硬件原因，在iOS設備上使用alpha-test會造成很大的性能開銷，應盡量使用alpha-blend代替。這里提到，在同屏使用alpha-blend的面數(shù)，尤其是這些面所占屏幕面積的大小，對性能也會造成很大影響。原因是使用alpha-blend的面會造成overdraw的增加，這尤其對低性能設備的影響很大。不過沒有購買Pro版，沒有Occlusion Culling功能的話，就不必顧慮這一問題了，反正overdraw是必然的。
復雜的Per-pixel shader
Per-pixel shader即Fragment shader，顧名思義是要對每個渲染到屏幕上的像素做處理的shader，如果per-pixel shader比較復雜且需要處理的像素很多時，也就是使用該shader的面占屏幕面積很大時，對性能的影響甚至要超過alpha blending。因此復雜的per-pixel shader只適用于小物體。
下面是對幾個Shader的逐一講解：
Environment specular maps(Shader Virtual Gloss Per Vertex Additive)
Specular map通常都是利用貼圖的alpha通道來定義物體表面的光滑程度（反光度），這個shader的特點是per-vertex計算反光度的，有著相當不錯的效果的同時比per-pixel的shader性能要高得多。這個shader很適用于關卡環(huán)境等占很大區(qū)域的模型。
經(jīng)過優(yōu)化的動態(tài)角色光照和陰影(Light probes和BRDF Shader)
傳統(tǒng)的Lightmaps無法支持動態(tài)物體，對此Unity提供了Light probes技術，預先把動態(tài)物體的光照信息保存在代理對象(即Light probes)中，運行時動態(tài)物體從距離最近的Probe中獲取光照信息。
Unity本身還提供了一個效果非常棒的專為移動設備優(yōu)化過的角色Shader，支持Diffuse、Specular和Normal maps，并通過一個特殊的腳本生成貼圖用于模仿BRDF光照效果。最終產(chǎn)生的效果堪比次時代大作中的角色光影效果。
霧和體積光(Shader Blinking Godrays)
目前在移動設備上要開啟真正的霧效基本不可行，ShadowGun的方案是通過簡單的網(wǎng)格＋透明貼圖(稱為霧面)來模擬霧效。在玩家靠近時，霧面逐漸變淡，同時fog plane的頂點也會移開(即使完全透明的alpha面也會消耗很多渲染時間)。
使用這個Shader的網(wǎng)格需要經(jīng)過處理：
頂點的alpha值用于決定頂點是否可以移動(在例子中0為不可動，1為可動)。
頂點法線決定移動的方向
然后Shader通過計算與觀察者的距離來控制霧面的淡入/淡出。
這個Shader還可以用來做體積光和其它一些alpha效果。
飛機墜毀的濃煙效果(Shader Scroll 2 Layers Sine Alpha-blended)
通過粒子產(chǎn)生濃煙的代價太高，所以ShadowGun中使用了網(wǎng)格＋貼圖動畫來制作這個效果。通過混合兩層貼圖并讓它們交錯移動來產(chǎn)生動畫效果。其中頂點alpha值用于讓網(wǎng)格的邊緣看起來比較柔和，同時使用頂點顏色來模擬從火焰到煙霧的過渡效果。
帶動態(tài)效果的天空盒(Shader Scroll 2 Layers Multiplicative)
通過兩張貼圖的混合和移動產(chǎn)生云的動態(tài)效果。
旗幟和衣服的飄動效果(Shader Lightmap + Wind)
同樣利用頂點alpha值決定哪些頂點可以移動，然后shader的參數(shù)用于調(diào)整擺動的方向和速度。
=======================分割線========================
一、程序方面
01、務必刪除腳本中為空或不需要的默認方法；
02、只在一個腳本中使用OnGUI方法；
03、避免在OnGUI中對變量、方法進行更新、賦值，輸出變量建議在Update內(nèi)；
04、同一腳本中頻繁使用的變量建議聲明其為全局變量，腳本之間頻繁調(diào)用的變量或方法建議聲明為全局靜態(tài)變量或方法；
05、不要去頻繁獲取組件，將其聲明為全局變量；
06、數(shù)組、集合類元素優(yōu)先使用Array，其次是List；
07、腳本在不使用時腳本禁用之，需要時再啟用；
08、可以使用Ray來代替OnMouseXXX類方法；
09、需要隱藏/顯示或?qū)嵗瘉砘厍袚Q的對象，盡量不要使用SetActiveRecursively或active，而使用將對象遠遠移出相機范圍和移回原位的做法；
10、盡量少用模運算和除法運算，比如a/5f，一定要寫成a*0.2f。
11、對于不經(jīng)常調(diào)用或更改的變量或方法建議使用Coroutines & Yield；
12、盡量直接聲明腳本變量，而不使用GetComponent來獲取腳本；
iPhone
13、盡量使用整數(shù)數(shù)字，因為iPhone的浮點數(shù)計算能力很差；
14、不要使用原生的GUI方法；
15、不要實例化（Instantiate）對象，事先建好對象池，并使用Translate“生成”對象；
二、模型方面
01、合并使用同貼圖的材質(zhì)球，合并使用相同材質(zhì)球的Mesh；
02、角色的貼圖和材質(zhì)球只要一個，若必須多個則將模型離分離為多個部分；
02、骨骼系統(tǒng)不要使用太多；
03、當使用多角色時，將動畫單獨分離出來；
04、使用層距離來控制模型的顯示距離；
05、陰影其實包含兩方面陰暗和影子，建議使用實時影子時把陰暗效果烘焙出來，不要使用燈光來調(diào)節(jié)光線陰暗。
06、少用像素燈和使用像素燈的Shader；
08、如果硬陰影可以解決問題就不要用軟陰影，并且使用不影響效果的低分辨率陰影；
08、實時陰影很耗性能，盡量減小產(chǎn)生陰影的距離；
09、允許的話在大場景中使用線性霧，這樣可以使遠距離對象或陰影不易察覺，因此可以通過減小相機和陰影距離來提高性能；
10、使用圓滑組來盡量減少模型的面數(shù)；
11、項目中如果沒有燈光或?qū)ο笤谝苿幽敲淳筒灰褂脤崟r燈光；
12、水面、鏡子等實時反射/折射的效果單獨放在Water圖層中，并且根據(jù)其實時反射/折射的范圍來調(diào)整；
13、碰撞對效率的影響很小，但碰撞還是建議使用Box、Sphere碰撞體；
14、建材質(zhì)球時盡量考慮使用Substance；
15、盡量將所有的實時反射/折射（如水面、鏡子、地板等等）都集合成一個面；
16、假反射/折射沒有必要使用過大分辨率，一般64*64就可以，不建議超過256*256；
17、需要更改的材質(zhì)球，建議實例化一個，而不是使用公共的材質(zhì)球；
18、將不須射線或碰撞事件的對象置于IgnoreRaycast圖層；
19、將水面或類似效果置于Water圖層
20、將透明通道的對象置于TransparentFX圖層；
21、養(yǎng)成良好的標簽（Tags）、層次（Hieratchy）和圖層（Layer）的條理化習慣，將不同的對象置于不同的標簽或圖層，三者有效的結(jié)合將很方便的按名稱、類別和屬性來查找；
22、通過Stats和Profile查看對效率影響最大的方面或?qū)ο?#xff0c;或者使用禁用部分模型的方式查看問題到底在哪兒；
23、使用遮擋剔除（Occlusion Culling）處理大場景，一種較原生的類LOD技術，并且能夠“分割”作為整體的一個模型。
三、其它
場景中如果沒有使用燈光和像素燈，就不要使用法線貼圖，因為法線效果只有在有光源（Direct Light/Point Light/Angle Light/Pixel Light）的情況下才有效果。
?
C#語言 優(yōu)化
一、用屬性代替可訪問的字段
1、.NET數(shù)據(jù)綁定只支持數(shù)據(jù)綁定，使用屬性可以獲得數(shù)據(jù)綁定的好處；
2、在屬性的get和set訪問器重可使用lock添加多線程的支持。
二、readonly（運行時常量）和const（編譯時常量）
1、const只可用于基元類型、枚舉、字符串，而readonly則可以是任何的類型；
2、const在編譯時將替換成具體的常量，這樣如果在引用中同時使用了const和readonly兩種值，則對readonly的再次改變將會改變設計的初衷，這是需要重新編譯所更改的程序集，以重新引用新的常量值。
3、const比readonly效率高，但失去了應用的靈活性。
三、is與as
1、兩者都是在運行時進行類型的轉(zhuǎn)換，as操作符只能使用在引用類型，而is可以使用值和引用類型；
2、通常的做法是用is判斷類型，然后選擇使用as或強類型轉(zhuǎn)換操作符（用operater定義的轉(zhuǎn)換）有選擇地進行。
四、ConditionalAttribute代替#if #endif條件編譯
1、ConditionalAttribute只用于方法級，對其他的如類型、屬性等的添加都是無效的；而#if #endif則不受此限制；
2、ConditionalAttribute可以添加多個編譯條件的或（OR）操作，而#if #endif則可以添加與（AND）[這里可以完全定義為另一個單獨的符號]；
3、ConditioanlAttribute定義可以放在一個單獨的方法中，使得程序更為靈活。
五、提供ToString（）方法
1、可以更友好的方式提供用戶詳細的信息；
2、使用IFormatter.ToString（）方法提供更靈活的定制，如果添加IFormatProvider 和ICustomFormatter接口則更有意義的定制消息輸出。
六、值和引用類型的區(qū)別
1、值類型不支持多態(tài)，適合存儲應用程序操作的數(shù)據(jù)，而引用則支持多態(tài)，適用于定義應用程序的行為；
2、對于數(shù)組定義為值類型可以顯著提高程序的性能；
3、值類型具有較少的堆內(nèi)存碎片、內(nèi)存垃圾和間接訪問時間，其在方法中的返回是以復制的方式進行，避免暴露內(nèi)部結(jié)構到外界；
4、值類型應用在如下的場景中：類型的職責主要是用于數(shù)據(jù)存儲；公共接口完全由一些數(shù)據(jù)成員存取屬性定義；永遠沒有子類；永遠沒有多態(tài)行為。
七、值類型盡可能實現(xiàn)為常量性和原子性的類型
1、使我們的代碼更易于編寫和維護；
2、初始化常量的三種策略：在構造中；工廠方法；構造一個可變的輔助類（如StringBuilder）。
八、確保0為值得有效狀態(tài)
1、值類型的默認狀態(tài)應為0；
2、枚舉類型的0不應為無效的狀態(tài)；在FlagsAttribute是應確保0值為有效地狀態(tài)；
3、在字符串為為空時可以返回一個string.Empty的空字符串；
九、相等判斷的多種表示關系
1、ReferenceEquals（）判斷引用相等，需要兩個是引用同一個對象時方可返回true；
2、靜態(tài)的Equals（）方法先進性引用判斷再進行值類型判斷的；
3、對于引用類型的判斷可以在使用值語義時使用重寫Equals（）方法；
4、重寫Equals（）方法時也應當重寫GetHashCode（）方法，同時提供operater==（）操作。
十、理解GetHashCode（）方法的缺陷
1、GetHashCode（）僅應用在基于散列的集合定義鍵的散列值，如HashTable或Dictionary；
2、GetHashCode（）應當遵循相應的三條規(guī)則：兩個相等對象應當返回相同的散列碼；應當是一個實例不變式；散列函數(shù)應該在所有的整數(shù)中產(chǎn)生一個隨機的分布；
十一、優(yōu)先使用foreach循環(huán)語句
1、foreach可以消除編譯器對for循環(huán)對數(shù)組邊界的檢查；
2、foreach的循環(huán)變量是只讀的，且存在一個顯式的轉(zhuǎn)換，在集合對象的對象類型不正確時拋出異常；
3、foreach使用的集合需要有：具備公有的GetEnumberator（）方法；顯式實現(xiàn)了IEnumberable接口；實現(xiàn)了IEnumerator接口；
4、foreach可以帶來資源管理的好處，因為如果編譯器可以確定IDisposable接口時可以使用優(yōu)化的try…finally塊；
十二、默認字段的初始化優(yōu)于賦值語句
1、字段生命默認會將值類型初始化為0，引用類型初始化為null；
2、對同一個對象進行多次初始化會降低代碼的執(zhí)行效率；
3、將字段的初始化放到構造器中有利于進行異常處理。
十三、使用靜態(tài)構造器初始化靜態(tài)成員
1、靜態(tài)構造器會在一個類的任何方法、變量或者屬性訪問之前執(zhí)行；
2、靜態(tài)字段同樣會在靜態(tài)構造器之前運行，同時靜態(tài)構造器有利于異常處理。
十四、利用構造器鏈（在.NET 4.0已經(jīng)用可選參數(shù)解決了這個問題）
1、用this將初始化工作交給另一個構造器，用base調(diào)用基類的構造器；
2、類型實例的操作順序是：將所有的靜態(tài)字段都設置為0；執(zhí)行靜態(tài)字段初始化器；執(zhí)行基類的靜態(tài)構造器；執(zhí)行當前類型的靜態(tài)構造器；
將所有的實例字段設置為0；執(zhí)行實例字段初始化器；執(zhí)行合適的基類實例構造器；執(zhí)行當前類型的實例構造器。
十五、利用using和try/finally語句來清理資源
在IDisposable接口的Dispose（）方法中用GC.SuppressFinalize()可通知垃圾收集器不再執(zhí)行終結(jié)操作。
十六、盡量減少內(nèi)存垃圾
1、分配和銷毀一個對上的對象都要花費額外的處理器時間；
2、減少分配對象數(shù)量的技巧：經(jīng)常使用的局部變量提升為字段；提供一個類，用于存儲Singleton對象來表達特定類型的常用實例。
3、用StringBuilder進行復雜的字符串操作。
十七、盡量減少裝箱和拆箱
1、關注一個類型到System.Object的隱式轉(zhuǎn)換，同時值類型不應該被替換為System.Object類型；
2、使用接口而不是使用類型可以避免裝箱，即將值類型從接口實現(xiàn)，然后通過接口調(diào)用成員。
十八、實現(xiàn)標準Dispose模式
1、使用非內(nèi)存資源，它必須有一個終結(jié)器，垃圾收集器在完成沒有終結(jié)其的內(nèi)存對象后會將實現(xiàn)了終結(jié)器對象的添加到終結(jié)隊列中，然后垃圾收集器會啟動一個新的線程來運行這些對象上的終結(jié)器，這種防御性的變成方式是因為如果用戶忘記了調(diào)用Dispose（）方法，垃圾回收器總是會調(diào)用終結(jié)器方法的，這樣可以避免出現(xiàn)非托管的內(nèi)存資源不被釋放引起內(nèi)存泄漏的問題；
2、使用IDisposable.Dispose()方法需要做四個方面的工作：釋放所有的非托管資源；釋放所有的托管資源；設置一個狀態(tài)標記來表示是否已經(jīng)執(zhí)行了Dispose（）；調(diào)用GC.SuppressFinalize（this）取消對象的終結(jié)操作；
3、為需要多態(tài)的類型添加一個受保護的虛方法Dispose（），派生類通過重寫這個方法來釋放自己的任務；
4、在需要IDisoposable接口的類型中，即使我們不需要一個終結(jié)器也應該實現(xiàn)一個終結(jié)器。
十九、定義并實現(xiàn)接口優(yōu)于繼承類型
1、不相關的類型可以共同實現(xiàn)一個共同的接口，而且實現(xiàn)接口比繼承更容易；
2、接口比較穩(wěn)定，他將一組功能封裝在一個接口中，作為其他類型的實現(xiàn)合同，而基類則可以隨著時間的推移進行擴展。
二十、明辨接口實現(xiàn)和虛方法重寫
1、在基類中實現(xiàn)一個接口時，派生類需要使用new來隱藏對基類方法的使用；
2、可以將基類接口的方法申明為虛方法，然后再派生類中實現(xiàn)。
二十一、使用委托表達回調(diào)
1、委托對象本身不提供任何異常捕獲，所以任何的多播委托調(diào)用都會結(jié)束整個調(diào)用鏈；
2、通過顯示調(diào)用委托鏈上的每個委托目標可以避免多播委托僅返回最后一個委托的輸出。
二十二、使用事件定義外部接口
1、應當聲明為共有的事件，讓編譯器為我們創(chuàng)建add和renmove方法；
2、使用System.ComponentModel.EventHandlerList容器來存儲各個事件處理器，在類型中包含大量事件時可以使用他來隱藏所有事件的復雜性。
二十三、避免返回內(nèi)部類對象的引用
1、由于值類型對象的訪問會創(chuàng)建一個該對象的副本，所以定義一個值類型的的屬性完全不會改變類型對象內(nèi)部的狀態(tài)；
2、常量類型可以避免改變對象的狀態(tài)；
3、定義接口將訪問限制在一個子集中從而最小化對對象內(nèi)部狀態(tài)的破壞；
4、定義一個包裝器對象來限制另一個對象的訪問；
5、希望客戶代碼更改內(nèi)部數(shù)據(jù)元素時可以實現(xiàn)Observer模式，以使對象可以對更改進行校驗或相應。
二十四、聲明式編程優(yōu)于命令式編程
可以避免在多個類似的手工編寫的算法中犯錯誤的可能性，并提供清晰和可讀的代碼。
二十五、盡可能將類型實現(xiàn)為可序列化的類型
1、類型表示的不是UI控件、窗口或者表單，都應使類型支持序列化；
2、在添加了NonSerializedAttribute的反序列化的屬性時可以通過實現(xiàn)IDeserializationCallback的OnDeserialization（）方法裝入默認值；
3、在版本控制中可以使用ISerializable接口來進行靈活的控制，同時提供一個序列化的構造器來根據(jù)流中的數(shù)據(jù)初始化對象，在實現(xiàn)時還要求SerializationFormatter異常的許可。
4、如果需要創(chuàng)建派生類則需要提供一個掛鉤方法供派生類使用。
二十六、使用IComparable和IComparer接口實現(xiàn)排序關系
1、IComparable接口用于為類型實現(xiàn)最自然的排序關系，重載四個比較操作符，可以提供一個重載版的CompareTo（）方法，讓其接受具體類型作為參數(shù)；
2、IComparer用于提供有別于IComparable的排序關系，或者為我們提供類型本身說沒有實現(xiàn)的排序關系。
二十七、避免ICloneable接口
1、對于值類型永遠不需要支持ICloneable接口使用默認的賦值操作即可；
2、對于可能需要支持ICloneable接口的基類，應該為其創(chuàng)造一個受保護的復制構造器，并應當避免支持IConeable接口。
二十八、避免強制轉(zhuǎn)換操作符
通過使用構造器來代替轉(zhuǎn)換操作符可以使轉(zhuǎn)換工作變得更清晰，由于在轉(zhuǎn)換后使用的臨時對象，容易導致一些詭異的BUG。
二十九、只有當新版積累導致問題是才考慮使用new修飾符
三十、盡可能實現(xiàn)CLS兼容的程序集
1、創(chuàng)建一個兼容的程序集需要遵循兩條規(guī)則：程序集中所有公有和受保護成員所使用的參數(shù)和返回值類型都必須與CLS兼容；任何與CLS不兼容的公有和受保護成員都必須有一個與CLS兼容的替代品；
2、可以通過顯式實現(xiàn)接口來避開CLS兼容類型檢查，及CLSCompliantAttribute不會檢查私有的成員的CLS兼容性。
三十一、盡可能實現(xiàn)短小簡潔的方法
1、JIT編譯器以方法為單位進行編譯，沒有被調(diào)用的方法不會被JIT編譯；
2、如果將較長的Switch中的Case語句的代碼替換成一個一個的方法，則JIT編譯器所節(jié)省的時間將成倍增加；
3、短小精悍的方法并選擇較少的局部變量可以獲得優(yōu)化的寄存器使用；
4、方法內(nèi)的控制分支越少，JIT編譯器越容易將變量放入寄存器。
三十二、盡可能實現(xiàn)小尺寸、高內(nèi)聚的程序集
1、將所有的公有類以及共用的基類放到一些程序集中，把為公有類提供功能的工具類也放入同樣的程序集中，把相關的公有接口打包到他們自己的程序集中，最后處理遍布應用程序中水平位置的類；
2、原則上創(chuàng)建兩種組件：一種為小而聚合、具有某項特定功能的程序集，另一種為大而寬、包含共用功能的程序集。
三十三、限制類型的可見性
1、使用接口來暴露類型的功能，可以使我們更方便地創(chuàng)建內(nèi)部類，同時又不會限制他們在程序集外的可用性；
2、向外暴露的公有類型越少，未來擴展和更改實現(xiàn)所擁有的選擇就越多。
三十四、創(chuàng)建大粒度的Web API
這是在機器之間的交易的頻率和載荷都降到最低，將大的操作和細粒度的執(zhí)行放到服務器執(zhí)行。
三十五、重寫優(yōu)于事件處理器
1、一個事件處理器拋出異常，則事件鏈上的其他處理器將不會被調(diào)用，而重寫的虛方法則不會出現(xiàn)這種情況；
2、重寫要比關聯(lián)事件處理器高效得多，事件處理器需要迭代整個請求列表，這樣占用了更多的CPU時間；
3、事件能在運行時響應，具有更多的靈活性，可以對同一個事件關聯(lián)多個響應；
4、通行的規(guī)則是處理一個派生類的事件是，重寫方式較好。
三十六、合理使用.NET運行時診斷
1、System.Diagnostics.Debug\Trace\EventLog為運行時提供了程序添加診斷信息所需要的所有工具，EventLog提供入口時的應用程序能寫到系統(tǒng)事件日志中；
2、最后不要寫自己的診斷庫，.NET FCL 已經(jīng)擁有了我們需要的核心庫。
三十七、使用標準配置機制
1、.NET框架的System.Windows.Application類為我們定義了建立通用配置路徑的屬性；
2、Application.LocalAppDataPath和Application.userDataPath 會生成本地數(shù)據(jù)目錄和用戶數(shù)據(jù)的路徑名；
3、不要在ProgramFiles和Windows系統(tǒng)目錄中寫入數(shù)據(jù)，這些位置需要更高的安全權限，不要指望用戶擁有寫入的權限。
三十八、定制和支持數(shù)據(jù)綁定
1、BindingMananger和CurrencyManager這兩個對象實現(xiàn)了控件和數(shù)據(jù)源之間的數(shù)據(jù)傳輸；
2、數(shù)據(jù)綁定的優(yōu)勢：使用數(shù)據(jù)綁定要比編寫自己的代碼簡單得多；應該將它用于文本數(shù)據(jù)項之外的范圍-其他顯示屬性也可以被綁定；對于Windowos Forms 數(shù)據(jù)綁定能夠處理多個控件同步的檢查相關數(shù)據(jù)源；
3、在對象不支持所需的屬性時可以通過屏蔽當前的對象然后添加一個想要的對象來支持數(shù)據(jù)綁定。
三十九、使用.NET驗證
1、ASP.NET中有五種控件來驗證有效性，可以用CustomValidator派生一個新類來增加自己的認證器；
2、Windows驗證需要子System.Windows.Forms.Control.Validating些一個事件處理器。
四十、根據(jù)需要選用恰當?shù)募?/h2>
1、數(shù)組有兩個比較明顯的缺陷：不能動態(tài)的調(diào)整大小；調(diào)整大小非常耗時；
2、ArrayList混合了一維數(shù)組和鏈表的特征，Queue和Stack是建立在Array基礎上的特殊數(shù)組；
3、當程序更加靈活的添加和刪除項時，可以使更加健壯的集合類型，當創(chuàng)建一個模擬集合的類時，應當為其實現(xiàn)索引器和IEnumberable接口。
四十一、DataSet優(yōu)于自定義結(jié)構
1、DataSet有兩個缺點個：使用XML序列化機制的DataSet與非.NET 代碼之間的交互不是很好；DataSet是一個非常通用的容器；
2、強類型的DataSet打破了更多的設計規(guī)則，其獲得的開發(fā)效率要遠遠高于自己編寫的看上去更為優(yōu)雅的設計。
四十二、利用特性簡化反射
通過設計和實現(xiàn)特性類，強制開發(fā)人員用他們來聲明可被動態(tài)使用的類型、方法和屬性，可以減少應用程序的運行時錯誤，提高軟件的用戶滿意度。
四十三、避免過度使用反射
1、Invoke成員使用的參數(shù)和返回值都是System.Object，在運行時進行類型的轉(zhuǎn)換，但出現(xiàn)問題的可能性也變得更多了；
2、接口使我們可以得到一個更為清晰、也更具可維護性的系統(tǒng)，反射式一個很強大的晚期綁定機制.NET框架使用它來實現(xiàn)Windows控件和Web控件的數(shù)據(jù)綁定。
四十四、為應用程序創(chuàng)建特定的異常類
1、需要不同的異常類的唯一原因是讓用戶在編寫catch處理器時能夠方便地對不同的錯誤采取不同的做法；
2、可能有不同的修復行為時我們才應該創(chuàng)建多種不同的異常類，通過提供異常基類所支持的所有構造器，可以為應用程序創(chuàng)建功能完整的異常類，使用InnerException屬性可以保存更低級別錯誤條件所產(chǎn)生的所有錯誤信息。
四十五、優(yōu)先選擇異常安全保證
1、強異常保證在從異常中恢復和簡化異常處理之間提供了最好的平衡，在操作因為異常而中斷，程序的狀態(tài)保留不變；
2、對將要修改的數(shù)據(jù)做防御性的復制，對這些數(shù)據(jù)的防御性復制進行修改，這中間的操作可能會引發(fā)異常，將臨時的副本和原對象進行交換；
3、終結(jié)器、Dispose（）方法和委托對象所綁定的目標方法在任何情況下都應當確保他們不會拋出異常。
四十六、最小化互操作
1、互操作有三個方面的代價：數(shù)據(jù)在托管堆和非托管堆之間的列舉成本，托管代碼和非托管代碼之間切換的成本，對開發(fā)人員來說與混合環(huán)境打交道的開發(fā)工作；
2、在interop中使用blittable類型可以有效地在托管和非托管環(huán)境中來回復制，而不受對象內(nèi)部結(jié)構的影響；
3、使用In/Out特性來確保最貼切的不必要的多次復制，通過聲明數(shù)據(jù)如何被列舉來提高性能；
4、使用COM Interop用最簡單的方式實現(xiàn)和COM組件的互操作，使用P/Invoke調(diào)用Win32 API,或者使用C++編譯器的/CLR開關來混合托管和非托管的代碼；
四十七、優(yōu)先選擇安全代碼
1、盡可能的避免訪問非托管內(nèi)存，隔離存儲不能防止來自托管代碼和受信用戶的訪問；
2、程序集在Web上運行時可以考慮使用隔離存儲，當某些算法確實需要更高的安全許可時，應該將那些代碼隔離在一個單獨的程序集中。
四十八、掌握相關工具與資源
1、使用NUnit建立自動單元測試（集成在VS2010 中了）；
2、FXCop工具會獲取程序集中的IL代碼，并將其與異族編碼規(guī)則和最佳實踐對照分析，最后報告違例情況；
3、ILDasm是一個IL反匯編工具，可以幫助我們洞察細節(jié)；
4、Shared Source CLI是一個包含.NET框架內(nèi)核和C#編譯器的實現(xiàn)源碼。
總結(jié)
以上是生活随笔為你收集整理的Unity 性能优化归纳的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： object-c的静态变量（static
- 下一篇： 数字频率系数测试软件,sia smaar