Unity3d 綜合性能竅門
下面的內容並不一定很詳細，但能夠引導unity3d開發者如何製作性能流暢的遊戲應用
內容：
1.官方提示文檔
2.性能優化概述
3.模型網格
4.燈光
5.貼圖
6.音頻
7.物理碰撞
8.Shader
9.腳本
官方提示文檔
圖形性能優(http://docs.unity3d.com/Documentation/Manual/OptimizingGraphicsPerformance.html)
如何減少包大小(http://docs.unity3d.com/Documentation/Manual/ReducingFilesize.html)
角色動畫(技巧比較零散) ( http://unity3d.com/Documentation/Manual/Character-Animation.html)
優化技巧概述
分析第一步，不要試圖花時間去優化一些模糊不清的程序或者降低圖片的大小除非你確實知道他們是瓶頸。首要的是去一直分析你的遊戲找到瓶頸在哪裏。Apple的Shark是一個分析OpenGL基礎應用不錯的工具。
分析第二步，不要忘了在優化後對遊戲再分析一次以便查看他們是否有效，同時你也有可能會發現另一些瓶頸。
開發工作第一 – 性能優化第二。儘可能花時間使你的遊戲更加平滑順暢。能夠使得更改和更新遊戲變得更快也將減輕以後的性能變化。 在觀察屏中測試場景，它會告訴你的性能是被場景中的物體拖慢速度還是被綁定在物體上的腳本拖慢速度。如果是觀察屏中遲鈍緩慢，你可能需要優化一下模型或者貼圖，如果不是，瓶頸可能在程序中或者物理碰撞上。關閉個別的遊戲物體，在編輯器裏試圖關掉一些個別的物體，這樣通常能排查到那些拖慢遊戲的物體。
模型網格
儘可能的將鄰近的模型合併爲單個模型單個材質球。例如，如果你的場景裏的桌子上堆疊有很多個物體，合併這些物體將會很有意義(有可能會需要將一些貼圖合併一張大的貼圖圖集)。減少Unity渲染物體的數量能顯著促進性能。
一個材質球一個模型，每個材質球都會被視爲分開的模型進行渲染。
使用極致低模的模型(500個多邊形以下)會使得性能增加。大多數的顯卡都有轉換和照明功能，這意味他們每秒都處理一些奇怪的多邊形。並且通常會提交一個網格讓顯卡渲染，所以太過於減少模型的多邊形可能使你的遊戲模型看起來像塊狀。
開始吧，用大約1500-2000的三角形做角色，這個數字可以變化大些，但是作爲一個首發的美術人員應該在一個細節層級上對質量和性能有一個比較好的妥協。注意，如果你有模型使用四邊形，(四邊形)Unity將會把每個四邊形都轉換成2個三角形再導入。
光照
每個像素光渲染都會生效另外的渲染管道。像素光會使你的遊戲看起來更好但不要太過於熱衷於他們。然而，使用Quality Manager去調整像素光在每個質量等級上的渲染是一個很好的方式，這在你發佈的遊戲裏提供了性能與質量的平衡。
聚光燈比點光源和方向光更加費性能。光照一個場景最好的方式是先確定你想要的效果，然後去看所有的燈光中哪個是重要的哪個可以削減掉使得場景效果與你想要的相似。
點光源和聚光燈值影響在他們範圍內的模型網格。如果模型在點光源和聚光燈範圍以外，光的影響將被削弱，模型將不會被燈光影響從而節省性能消耗。這個方式可以在理論上解釋擁有很多小的點光源卻任然擁有好的性能表現，因爲他們隻影響一小部分的物體。記住，一個模型最多隻能被8個光源所影響。
貼圖
在看起來可以接受的情況下儘量縮小貼圖的大小。如果你的顯卡沒有擁有足夠的內存來存放這些貼圖時，他們將被放置在系統內存裏，當他們需要被渲染時再被上傳。這在新的電腦上沒什麼問題因爲他們有很多可以使用的空間。但如果你執着於完全能在低端顯存設備上運行你的遊戲的話，不用在圖片工具上改變貼圖的大小，你可以使用Unity導入圖片並對其設置大小。
不要使用低品質的圖片文件，試圖使用jpeg的低品質文件或者低色彩png或者gif文件也不會降低遊戲中的大小。Unity會在打包發佈時自動壓縮所有圖片，所以請保持原始的高品質貼圖文件。這樣一來多種方式的壓縮和解壓縮達到品質變化變得很方便。
音頻
使用.ogg對音頻壓縮，其他的音頻格式在發佈打包時將被作爲非壓縮的PCM音頻格式存儲在包內。
對小的音效使用非壓縮音頻，Unity(從1.6開始)導入時會解壓縮所有ogg文件。它讓短音效播放時使用非壓縮的wav或者aiff文件，這樣可以不消耗CPU在解壓音頻文件上。例如那些急速開槍、腳步等類似的聲音。
物理
每個rigidbody都消耗計算，所以越少越理想。已有的Rigidbody物體同樣最好關閉起來當他們的旋轉速度和移動速度到減少到一定程度的時候。當這個發生的時候，大量計算被顯著去除並保持比較低的量，直到他們受到手動受力或者碰撞其他的碰撞體如果存在的話。
複雜的碰撞比普通的消耗更多的計算量，大量堆疊在一起的球形rigidbody碰撞體在地形上會比相隔較遠的消耗更多的複雜計算過程。
着色器
很多複雜的着色器比簡單的可能消耗性能。VertexLit Diffuse 着色器應該是帶貼圖和光照最快的着色器了。然而，如果沒有像素燈光在場景裏或者所有像素光都被Quality Manager關掉了，那麼大多數着色器將回退到更加簡單的頂點渲染版本。
腳本
1.你是否使用了好的算法？如果可能的話選擇一個好的算法對工作收益來說比其他的調整會有更好的優化效果。
注意最好的算法不總是那個最低平均複雜度的算法。對於小數據量來說，通常使用一個簡單的低速算法比智能卻帶高初始化的算法要來的好。(例如可以用hash表或二叉樹作爲以名字存取的大型數據，但你可以使用一個簡單鏈表和線性算法如果你存取小型數據的話。雖然dotnet的哈希表類在這種情況下已經選擇了最佳的方式根據你的數據量大小。)
2.FixedUpdate方法裏儘可能保持少的邏輯。這些邏輯可以被調用大約50-100次每秒在每個有效腳本的每個物體裏，所以他們是優化的重要目標。如果某些邏輯確實需要在渲染更新後執行再把這些代碼放進update方法裏去。
儘可能把一些物體上的腳本關掉當不再需要他們的時候。如果你的遊戲有一個大型的場景，裏面的怪物在幾公里遠的地方，你可以關掉他的AI腳本直到攝像頭靠近他們時再開啓。這裏有個好方法去開關它們，就是使用gameObject.SetActiveRecursively(false)並且設置球形和方形碰撞體爲觸發器(trigger)。
3.小心空的Update方法。當使用資源菜單創建新的腳本時他們包含了空的Update方法。去掉它如果你不需要它的話，因爲它會帶來一些(少量的)性能消耗。這個性能消耗點應用所有在MonoBehaviour腳本里的重載方法，以Update和FixedUpdate爲主要的目標。
4.關於一個GameObject中最合邏輯的組件，某人可以理論上這樣寫: someGameObject.transform.gameObject.rigidbody.transform.gameObject.rigidbody.transform，但這個有大部分都是不需要的。如果你需要去處理一個物體的Transform，可以映射它到你的腳本里的開頭部分。
5.協程是你的好朋友。協程只有很少的開銷並更適合被選擇，而一個update方法在他們不需要的時候也總是被調用。例如，你有一個腳本去實現一個命令觸發的漸進漸出的燈光效果，你可以用協程去實現漸進漸出替換Update。這樣做在大部分時候當燈光不進行漸進漸出時，腳本是最低的性能消耗。如果漸進漸出在Update方法裏實現，你將低效的輪詢去查看是否漸進漸出結束了。
6.在沒有必要的情況下不要用方法去搜索物體，這包括方法GameObject.FindByTag() 和 GameObject.GetComponent()，與所有便利的屬性(transform,light,等)一樣，這些方法可以被優化的運行起來地儘可能的快，但他們仍然必須去通過搜索關聯的物體去找到你想要的那個。最重要的事是避免調用搜索方法在Update和FixedUpdate方法裏，於之替換的是調用某方法一次並存儲它在你的類成員變量裏，然後在你下次需要它時從這個成員變量裏取得。
7.不要使用SendMessage(或類似的方法)當你不是必要的時候，SendMessage比直接調用方法慢至少100倍，並且這個倍數還會增加當很多腳本和方法在物體上生效時。如果你能得到你的腳本你最好儘早去找，同樣的直接調用這個方法。
8.JavaScripts(和Boos)的duck類型會消耗已少量的計算量。在性能零界區域和在使用javascript時，請直接嘗試聲明你使用的變量類型。(儘管這個通常計算機會自動識別那個有效的你所指定的類型，所以你的程序可以多樣化)
翻譯自：http://wiki.unity3d.com/index.php?title=General_Performance_Tips