Unity3D
用UNITY開發(fā)手機游戲，背景圖片和UI圖片顯示的比PC機上模糊很多，怎么解決？？
在unity里選中資源?
1.TextureType 改成 Advanced
2.NonPower of 2 改成 non
3.把 generate Mip maps 的勾去掉
4.Format壓縮格式 選中rgba32bit
5.保存下 apply?
http://www.xuanyusong.com/archives/1019 ?在unity中播放視頻 用到 moivetexture
刪除多余內(nèi)存垃圾
GC.Collect();卸載0代垃圾 GC.Collect(1)；卸載1代垃圾 GC.Collect(2);卸載2代垃圾 Resources.UnloadUnusedAssets (卸載未使用的資源) 傳個true作為參數(shù)貌似可以卸載所有的
Unity3d的Player setting中包括一個選項“Submit HW Statistics”，根據(jù)這個選項，Unity收集到了很多設(shè)備狀態(tài)信息，并公開給大家形成參考資料。Mobile設(shè)備地址，1、iOS?http://t.cn/zRq6uXK?；2、Android?http://t.cn/zTqKwLr?；各位參考吧。 http://stats.unity3d.com/mobile/index.html http://stats.unity3d.com/mobile/index-ios.html
Unity的C#腳本中GetComponentsInChildren<>()能夠獲取一個物體所有子物體的元素集合
Vector3的變量是Float,單精度浮點小數(shù)。
GameObject. AddComponent為新產(chǎn)生的物體添加一個腳本
發(fā)布Android應(yīng)用時，PlayerSettings中必須更改Bundle Identifier
使用PlayerPrefs類提供的方法可以把當(dāng)前游戲的數(shù)據(jù)保存到本地
想要在當(dāng)前場景的基礎(chǔ)上疊加加載一個新的場景，使用Application.LoadLevelAdditive();
在Edit→Preference中的General選項卡下勾選Always show Project Wizard可以使Unity在一臺機器上啟動多個程序?qū)嵗?br style="line-height:28px" /> Camera.WorldToScreenPoint可以把物體的世界坐標轉(zhuǎn)換成相機的屏幕坐標
需要添加到物體上的腳本必須繼承自MonoBehavior
gameObject.transform內(nèi)部機制相當(dāng)于是find，一直覺得很扯蛋，不知道官方為什么要這么做，非要用戶自己做一個引用變量，gameObject.transform這樣不能是引用
面象對象的語言有自動垃圾銷毀功能，但有的變量必須手動銷毀，像某些情況下的數(shù)組里的元素，還有就是游戲?qū)ο?#xff0c;不用時也得手動銷毀哦，制作游戲時敵人盡量保持一定的數(shù)量，達到動態(tài)平衡，而不是越來越多，最終導(dǎo)致死機。
u3d打包時 資源里面的它都打包 所以不必要的物件盡量刪除 ?
怎么去掉pc上開啟游戲時候的
File - Build Settings -Pc and Mac Standalone -Player Settings -Resolution and Presentation -Display Resolution 選項改為 Dialog Disabled ? ? ?
Edit->Project setting->player 下選中有windows標志的那個圖標，在resolution and presentation下display resolution 為disable ?
一些Unity的使用和優(yōu)化心得（大部分內(nèi)容摘自網(wǎng)絡(luò)）
下面由一個基礎(chǔ)的問題引出全文（題目與解答由Jare師父提供）：
有兩段代碼，循環(huán)執(zhí)行兩個比較耗時的方法，假設(shè)語言和編譯器相同，哪一段會比較快？
for (int i = 0; i < 100; i++)
{
?? ?DoSomethingA();
?? ?DoSomethingB();
}
和
for (int i = 0; i < 100; i++)
?? ?DoSomethingA();
for (int i = 0; i < 100; i++)
?? ?DoSomethingB();
?
相信有很多人一樣，第一眼看起來認為第一段更快點。但實際上答案是第二段快。原因如下：
在這里性能的瓶頸不是循環(huán)本身。而是里面的方法。
如果重復(fù)執(zhí)行一個方法，那么CPU的寄存器、一級、二級緩存都很容易命中，比起到內(nèi)存拿數(shù)據(jù)快多了。
如果執(zhí)行完一個執(zhí)行另一個，那么緩存很可能就被替換掉了，只能到內(nèi)存拿，甚至內(nèi)存不夠，要到硬盤上的虛擬內(nèi)存拿。
?
緩存組件查找（以下內(nèi)容摘自網(wǎng)絡(luò)）
這種優(yōu)化需要一些代碼并且不是總有必要。但是如果你的代碼真的很大，并且你需要盡可能的性能提升，它會是很好的優(yōu)化。
當(dāng)你通過GetComponent獲取一個組件或一個變量時，Unity必須從游戲物體里找到正確的組件。這時你便能通過一個緩存組件引用到一個私有變量。
將：
void Update () {
?? ?transform.Translate(new Vector3(0, 0, 5));
}
轉(zhuǎn)換為：
private Transform myTransform ;
void Awake () {
?? ?myTransform = transform;
}
void Update () {
?? ?myTransform.Translate(new Vector3(0, 0, 5));
}
后面的代碼運行較快，因為Unity不用在每一幀尋找變換組件。同樣，支持腳本組件。你可以使用GetComponent獲取組件或其他快捷屬性。
渲染
一個Mesh 建議使用的面數(shù)在1500~4000 之間。
一個 Mesh 建議只用一個 Material。
注意：兩個Mesh結(jié)合成一個Mesh，但是卻使用兩個Material，并不會提高效能。
如果要提高效能必須把這兩個Mesh的Material也合并成一個。
換句話說，一個Mesh使用多個Material 和一個Material 使用多個render，其實耗能是差不多的。
所以，盡可能的讓物件共用相同的Texture 才是提升效能的根本之道。
?
把物體設(shè)為static可以提高渲染效率，缺點是不能使用動態(tài)uv（可能還有別的缺點，不過沒試過）
?
算法
?1. 盡量避免每幀處理
比如：
function Update() { DoSomeThing(); }
可改為每5幀處理一次：
function Update() { if(Time.frameCount % 5 == 0) { DoSomeThing(); } }
2. 定時重復(fù)處理用 InvokeRepeating 函數(shù)實現(xiàn)
比如，啟動0.5秒后每隔1秒執(zhí)行一次 DoSomeThing 函數(shù)：
function Start() { InvokeRepeating("DoSomeThing", 0.5, 1.0); }
3. 優(yōu)化 Update, FixedUpdate, LateUpdate 等每幀處理的函數(shù)
函數(shù)里面的變量盡量在頭部聲明。
比如：
function Update() { var pos: Vector3 = transform.position; }
可改為
private var pos: Vector3; function Update(){ pos = transform.position; }
4. 主動回收垃圾
給某個 GameObject 綁上以下的代碼：
function Update() { if(Time.frameCount % 50 == 0) { System.GC.Collect(); } }
??
5. 運行時盡量減少 Tris 和 Draw Calls
預(yù)覽的時候，可點開 Stats，查看圖形渲染的開銷情況。特別注意 Tris 和 Draw Calls 這兩個參數(shù)。
一般來說，要做到：
Tris 保持在 7.5k 以下
Draw Calls 保持在 20 以下
6. 壓縮 Mesh
導(dǎo)入 3D 模型之后，在不影響顯示效果的前提下，最好打開 Mesh Compression。
Off, Low, Medium, High 這幾個選項，可酌情選取。
7. 避免大量使用 Unity 自帶的 Sphere 等內(nèi)建 Mesh
Unity 內(nèi)建的 Mesh，多邊形的數(shù)量比較大，如果物體不要求特別圓滑，可導(dǎo)入其他的簡單3D模型代替。
8. 優(yōu)化數(shù)學(xué)計算
比如，如果可以避免使用浮點型(float)，盡量使用整形(int)，盡量少用復(fù)雜的數(shù)學(xué)函數(shù)比如 Sin 和 Cos 等等。
使用#pragma strict
現(xiàn)在問題是，你通常不會意識到你在使用動態(tài)類型。#pragma strict可以解決這個問題！簡單的添加#pragma strict在腳本頂部，之后Unity將禁用腳本的動態(tài)類型，強制你使用靜態(tài)類型。如果有一個類型未知，Unity將報告編譯錯誤。下面，foo將在編譯時報錯：
#pragma strict
function Start ()
{
?? ?var foo = GetComponent(MyScript);
?? ?foo.DoSomething();
}
?
使用內(nèi)置數(shù)組
內(nèi)置數(shù)組是非常快的。ArrayList或Array類很容易使用，你能輕易添加元件。但是他們有完全不同的速度。 內(nèi)置數(shù)組有固定長度，并且大多時候你會事先知道最大長度然后填充它。內(nèi)置數(shù)組最好的一點是他們直接嵌入結(jié)構(gòu)數(shù)據(jù)類型在一個緊密的緩存里，而不需要任何額外類型信息或其他開銷。因此，在緩存中遍歷它是非常容易的，因為每個元素都是對齊的。
privatevar positions : Vector3[];
function Awake () {
?? ?positions = new ?Vector3[100];
?? ?for (var i=0;i<100;i++)
?? ?positions = ?Vector3.zero;
}
未選中物體變灰色：
改變物體shader中最后計算出來的rgb值即可，將其轉(zhuǎn)換成lab，然后用（l，l，l）來代表其最終的rgb即可，對于選中的物體不需要進行處理，這樣就會出現(xiàn)上述的視覺效果了
代碼如何控制是否使用lightmaps
unity是通過shader來加載lightmap的，你可以設(shè)置一個全局參數(shù)來控制是否需要lightmap進行最后的光照計算，然后通過白天還是夜晚控制這個全局參數(shù)即可。
billboard：
公告版.transform.LookAt（new Vecter3（Camera.main.transform.position.x，公告版.transform.position.y，Camera.main.transform.z））。這個方法hog在論壇里發(fā)過
下面給你提供寫方法以剝離減小包的大小，有些我也沒試過：
降低的播放機大小主要有兩個途徑：一是更改Xcode內(nèi)的Active Build Configuration，二是更改Unity的Stripping級別。
在發(fā)布模式下生成
你可以在 Xcode的Active Build Configuration下拉菜單中的調(diào)試和發(fā)布選項之間進行選擇。根據(jù)自身游戲的大小，選擇發(fā)布模式生成的player會比選擇調(diào)試模式減少2-3MB的大小。
在發(fā)布模式下，player會去掉任何的調(diào)試信息進行生成，所以如果你的游戲崩潰或有其他問題，將是沒有可用的、可輸出的堆棧跟蹤信息。這適合發(fā)布已完成的游戲，但你更應(yīng)該在開發(fā)過程中使用調(diào)試模式。
iOS Stripping級別（Advanced License feature）
尺寸優(yōu)化工作可通過以下幾種方式被剝離機制激活：
Strip assemblies級別：通過分析腳本的字節(jié)碼，來將這些腳本沒有引用的類和方法從 Dll 中刪除，從而使其不進入 AOT編譯階段。這種優(yōu)化減少了主要的二進制以及相應(yīng) Dll的大小。在不使用反射的條件下，這種優(yōu)化是安全的。
Strip ByteCode級別：任何.Net Dll（存儲數(shù)據(jù)文件夾中）將從元數(shù)據(jù)中被剝離出來。這是可能的，因為所有的代碼都已經(jīng) AOT階段被預(yù)編譯并鏈接到主要的二進制文件中
使用micro mscorlib級別：使用一種特殊的、較小的mscorlib版本。某些部件將從此庫中被移除，例如，安全，Reflection.Emit，遠程處理，非公歷日歷等組件都將被刪除。此外，內(nèi)部組件之間的相互依賴性也會被降至最低。該種優(yōu)化減少了主要的二進制以及mscorlib.dll的大小，但不能與一些系統(tǒng)和 System.Xml程序集類兼容。因此，小心地使用它。
這些級別是累積的，第3級優(yōu)化隱式地包含級別 2和級別1，而第 2級優(yōu)化則包含級別1。
Micro mscorlib是核心庫的最低級版本。只有這些項目是目前Unity中的Mono運行庫所需要的。使用micro mscorlib的最佳做法是不使用任何你的應(yīng)用程序所不需要的.Net的類或其他功能。GUID就是一個你可以忽略的例子，她可以輕松地被自定義的偽 Guid所替代，這樣做將產(chǎn)生更好的性能和更小的應(yīng)用程序。
如何處理使用反射機制的Strip
Strip程度取決于靜態(tài)代碼的分析，但有時侯，這種分析并不是很有效，特別是針對使用類似反射一樣的動態(tài)功能的代碼。在這種情況下，有必要給出一些提示來指出哪些類是不應(yīng)該被觸動的。Unity支持對于每個項目都給出一個自定義Strip黑名單。使用黑名單是創(chuàng)建 link.xml 文件并將它放入Assets文件夾的一個簡單方法。以下是一個的 link.xml文件的示例。其中有保留標記的類將不會被Strip：
有時侯，我們很難確定哪些類會被進行錯誤的Strip。通常你可以通過在模擬器上運行已被Strip的應(yīng)用程序和檢查 Xcode 控制臺的錯誤消息來獲取有用的信息。
簡單的清單，使你的發(fā)布版本盡可能地小
1.最小化你的資源（assets）：啟用 PVRTC壓縮紋理，并盡可能低降低其分辨率。此外，盡量縮減無損壓縮的音頻的個數(shù)。這里還有一些額外的縮減文件大小的提示。
2.設(shè)置iOSStrip級別為Use micro mscorlib。
3.設(shè)置腳本調(diào)用優(yōu)化級別為Fast but no exceptions。
4.不要讓你的任何代碼與System.dll或 System.Xml.dll有關(guān)聯(lián)，因為這些庫并不兼容micro mscorlib。
5.去掉不必要的代碼關(guān)聯(lián)。
6.將API兼容性級別設(shè)置為.Net 2.0子集。請注意.Net 2.0子集與其他庫與兼容性比較有限。
7.設(shè)置目標平臺為armv6 (OpenGL ES1.1)。
8.不要使用 JS陣列。
9.避免泛型容器與結(jié)構(gòu)等類型相結(jié)合。
我能用Unity創(chuàng)造出低于 20 mb的應(yīng)用程序嗎？
當(dāng)然可以。如果所有優(yōu)化被都關(guān)掉，一個空項目在AppStore中大小大致為 13 MB左右。這在游戲中為你提供了大約7 MB的壓縮資源預(yù)算。如果你擁有先進的許可證（并因此獲得Strip選項），那么只含有主相機的空場景在AppStore中可壓縮到大約 6 MB （zipped和 DRM連接），這樣，你就可以有大約 14 MB可用空間用于壓縮資源。
為什么我的應(yīng)用程序發(fā)布到AppStore后大小增加了？
當(dāng)他們發(fā)布你的應(yīng)用程序時，蘋果首先對二進制文件進行加密，然后將它通過 zip壓縮。最常見的，蘋果 DRM會使二進制文件大小增加大約 4 MB左右。作為一般規(guī)則，你應(yīng)預(yù)見到的文件最終大小大致為所有文件（除了可執(zhí)行文件）的 zip壓縮大小，再加上未壓縮的可執(zhí)行文件的大小。
boxcollider或者其他任何collider 都是為物理碰撞或者碰撞檢測做準備。
rigidbody 剛體屬性組件，在任何物體下的Add component （添加零件、添加組件）可添加。 物體勾了tigger 那個屬性，或者是地面勾了那個屬性。tigger是能進入內(nèi)部的，通常做判斷觸發(fā)范圍
------------------------------------------
通常在變換場景后，上個場景中除了使用 DontDestroyOnLoad() 保留的物件，將會被釋放掉，但如果在沒有變換場景的情形下，想把未使用的資源卸載掉，該如何做呢？
一般情況下，我們會利用 Unity 的編輯器來部屬每個關(guān)卡或場景中的物件，這些物件在載入場景后都是必要的，也不太會持續(xù)增加物件數(shù)，在關(guān)卡結(jié)束后即轉(zhuǎn)換到下個場景，所以原本場景中的物件 將不再需要，所以 Unity 將會自動將前一場景的物件都銷毀掉，所以我們通常不太需要去管理記憶體的使用或是否釋放，但如果你的游戲全部是在單一個場景中運行的，那麼物件的產(chǎn)生、銷 毀、釋放資源等等的動作就變得格外重要。
我做了一個寶石類型的游戲，畫面上除了 GUI 及背景外就只有寶石，所以我事先將寶石做成 Prefabs ，在需要時利用 Instantiate() 產(chǎn)生，我在不同的關(guān)卡利用 renderer.material.mainTexture 變更背景圖，利用 GetComponent(MeshFilter).sharedMesh 變更寶石的形狀以及利用 renderer.material.color 變更寶石顏色，如此一個Prefabs 可以重復(fù)無限使用，所以在游戲場景中只設(shè)置了簡單幾個場景物件，在這種場景不需要變化太多的情況下，每個關(guān)卡都換場景重新配置一樣的物件似乎有點多餘，所 以這個游戲便只有一個場景，在需要時產(chǎn)生寶石，然后再視情況使用 Destroy() 銷毀掉，這樣看起來只要在產(chǎn)生寶石時控制畫面上的物件數(shù)量，那麼也就不用擔(dān)心記憶體使用過量或沒釋放掉的問題。
但是，這個游戲在連續(xù)玩好幾個關(guān)卡后，也就是連續(xù)玩一段時間后，會發(fā)生停頓或畫面變慢的問題，游戲剛開始玩時是相當(dāng)順暢的，但長時間執(zhí)行將使效能降低，直 覺上的判斷應(yīng)該是記憶體累積到一定程度造成的，每個物件在不使用時都使用 Destroy() 銷毀掉，那麼，堆積的記憶體是從哪裡來的呢？ 打開 Profiler 視窗看看，會發(fā)現(xiàn)其中的 Memory 的 Total Object Count 數(shù)值，不斷的增減變化，但隨著時間的增加會慢慢的往上累積，查看官網(wǎng) (http://unity3d.com/support/documentation/Manual/Profiler.html) 是這樣說的 "If this number rises over time then it means your game is creating some objects that are never destroyed."，有些物件未銷燬，很奇怪吧！都有使用 Destroy()，那為何還有未銷毀的物件？其實，主要是因為我這裡有對 renderer.material 設(shè)置改變其內(nèi)容，在這個執(zhí)行時期并不會真的去改變 Project 中的 material，而是產(chǎn)生這個物件實例(instance) 的材質(zhì)實例以供該物件使用，所以如果只是 Destroy(gameObject) 的話，將會殘留部份物件數(shù)，每個產(chǎn)生的物件都殘留一點點的話，慢慢的長時間下來將會累積相當(dāng)多，記憶體將會不敷使用，所以在 Destroy(gameObject) 的同時，應(yīng)該也要 Destroy(renderer.material) 才行。
如果程式結(jié)構(gòu)簡單，給物件使用的 Script 檔案也不多的話，也許多加一句并不困難，但我們有時候無法確定是否有在適當(dāng)時機為每個物件做到完整的銷毀，也許還有殘留別的東西也會有這種情形持續(xù)累積記 憶體，這時又該尋找更簡單統(tǒng)一的方法了，於是我們可以在每個關(guān)卡開始前或結(jié)束時執(zhí)行一句 Resources.UnloadUnusedAssets() ，讓 Unity 自行去卸載掉不使用的資源，如此在平時物件銷毀時，我們已經(jīng)先行釋放掉大部份不使用的資源，然后再由 Resources.UnloadUnusedAssets() 卸載我們未清理掉的部份，如此的話查看 Profiler 視窗的 Memory 的 Total Object Count 數(shù)值就可以維持在一定范圍內(nèi)起伏，而不再隨著時間增加，當(dāng)然我們在關(guān)卡設(shè)置上都會有難度上的差異，在某些關(guān)卡裡，玩家可能必須花較多時間才能完成關(guān)卡，所 以如果我們只在關(guān)卡開始或結(jié)束時使用 Resources.UnloadUnusedAssets() 也許會不夠，此時也可另外定義每過一段時間就執(zhí)行 Resources.UnloadUnusedAssets() ，如此將可避免掉系統(tǒng)資源不足的問題。?
http://blog.sina.com.cn/s/blog_6af6af4b0100yy7n.html
在做項目過程中，經(jīng)常會遇到一種情況： 場景中有不同種類的實例對象，這些實例可以是不同的3D物體。當(dāng)我們需要點擊其中一個物體（GameObject）時，希望他能夠自動刪除自己，并且將也要把對應(yīng)的數(shù)組記錄刪除，保證數(shù)據(jù)統(tǒng)一。要實現(xiàn)以上所說的，需要建立一種自調(diào)用方法來實現(xiàn)。http://www.easyunity3d.com/unity3d-destroy-gameobject.html
在unity里選中資源?
1.TextureType 改成 Advanced
2.NonPower of 2 改成 non
3.把 generate Mip maps 的勾去掉
4.Format壓縮格式 選中rgba32bit
5.保存下 apply?
http://www.xuanyusong.com/archives/1019 ?在unity中播放視頻 用到 moivetexture
刪除多余內(nèi)存垃圾
GC.Collect();卸載0代垃圾 GC.Collect(1)；卸載1代垃圾 GC.Collect(2);卸載2代垃圾 Resources.UnloadUnusedAssets (卸載未使用的資源) 傳個true作為參數(shù)貌似可以卸載所有的
Unity3d的Player setting中包括一個選項“Submit HW Statistics”，根據(jù)這個選項，Unity收集到了很多設(shè)備狀態(tài)信息，并公開給大家形成參考資料。Mobile設(shè)備地址，1、iOS?http://t.cn/zRq6uXK?；2、Android?http://t.cn/zTqKwLr?；各位參考吧。 http://stats.unity3d.com/mobile/index.html http://stats.unity3d.com/mobile/index-ios.html
Unity的C#腳本中GetComponentsInChildren<>()能夠獲取一個物體所有子物體的元素集合
Vector3的變量是Float,單精度浮點小數(shù)。
GameObject. AddComponent為新產(chǎn)生的物體添加一個腳本
發(fā)布Android應(yīng)用時，PlayerSettings中必須更改Bundle Identifier
使用PlayerPrefs類提供的方法可以把當(dāng)前游戲的數(shù)據(jù)保存到本地
想要在當(dāng)前場景的基礎(chǔ)上疊加加載一個新的場景，使用Application.LoadLevelAdditive();
在Edit→Preference中的General選項卡下勾選Always show Project Wizard可以使Unity在一臺機器上啟動多個程序?qū)嵗?br style="line-height:28px" /> Camera.WorldToScreenPoint可以把物體的世界坐標轉(zhuǎn)換成相機的屏幕坐標
需要添加到物體上的腳本必須繼承自MonoBehavior
gameObject.transform內(nèi)部機制相當(dāng)于是find，一直覺得很扯蛋，不知道官方為什么要這么做，非要用戶自己做一個引用變量，gameObject.transform這樣不能是引用
面象對象的語言有自動垃圾銷毀功能，但有的變量必須手動銷毀，像某些情況下的數(shù)組里的元素，還有就是游戲?qū)ο?#xff0c;不用時也得手動銷毀哦，制作游戲時敵人盡量保持一定的數(shù)量，達到動態(tài)平衡，而不是越來越多，最終導(dǎo)致死機。
u3d打包時 資源里面的它都打包 所以不必要的物件盡量刪除 ?
怎么去掉pc上開啟游戲時候的
File - Build Settings -Pc and Mac Standalone -Player Settings -Resolution and Presentation -Display Resolution 選項改為 Dialog Disabled ? ? ?
Edit->Project setting->player 下選中有windows標志的那個圖標，在resolution and presentation下display resolution 為disable ?
一些Unity的使用和優(yōu)化心得（大部分內(nèi)容摘自網(wǎng)絡(luò)）
下面由一個基礎(chǔ)的問題引出全文（題目與解答由Jare師父提供）：
有兩段代碼，循環(huán)執(zhí)行兩個比較耗時的方法，假設(shè)語言和編譯器相同，哪一段會比較快？
for (int i = 0; i < 100; i++)
{
?? ?DoSomethingA();
?? ?DoSomethingB();
}
和
for (int i = 0; i < 100; i++)
?? ?DoSomethingA();
for (int i = 0; i < 100; i++)
?? ?DoSomethingB();
?
相信有很多人一樣，第一眼看起來認為第一段更快點。但實際上答案是第二段快。原因如下：
在這里性能的瓶頸不是循環(huán)本身。而是里面的方法。
如果重復(fù)執(zhí)行一個方法，那么CPU的寄存器、一級、二級緩存都很容易命中，比起到內(nèi)存拿數(shù)據(jù)快多了。
如果執(zhí)行完一個執(zhí)行另一個，那么緩存很可能就被替換掉了，只能到內(nèi)存拿，甚至內(nèi)存不夠，要到硬盤上的虛擬內(nèi)存拿。
?
緩存組件查找（以下內(nèi)容摘自網(wǎng)絡(luò)）
這種優(yōu)化需要一些代碼并且不是總有必要。但是如果你的代碼真的很大，并且你需要盡可能的性能提升，它會是很好的優(yōu)化。
當(dāng)你通過GetComponent獲取一個組件或一個變量時，Unity必須從游戲物體里找到正確的組件。這時你便能通過一個緩存組件引用到一個私有變量。
將：
void Update () {
?? ?transform.Translate(new Vector3(0, 0, 5));
}
轉(zhuǎn)換為：
private Transform myTransform ;
void Awake () {
?? ?myTransform = transform;
}
void Update () {
?? ?myTransform.Translate(new Vector3(0, 0, 5));
}
后面的代碼運行較快，因為Unity不用在每一幀尋找變換組件。同樣，支持腳本組件。你可以使用GetComponent獲取組件或其他快捷屬性。
渲染
一個Mesh 建議使用的面數(shù)在1500~4000 之間。
一個 Mesh 建議只用一個 Material。
注意：兩個Mesh結(jié)合成一個Mesh，但是卻使用兩個Material，并不會提高效能。
如果要提高效能必須把這兩個Mesh的Material也合并成一個。
換句話說，一個Mesh使用多個Material 和一個Material 使用多個render，其實耗能是差不多的。
所以，盡可能的讓物件共用相同的Texture 才是提升效能的根本之道。
?
把物體設(shè)為static可以提高渲染效率，缺點是不能使用動態(tài)uv（可能還有別的缺點，不過沒試過）
?
算法
?1. 盡量避免每幀處理
比如：
function Update() { DoSomeThing(); }
可改為每5幀處理一次：
function Update() { if(Time.frameCount % 5 == 0) { DoSomeThing(); } }
2. 定時重復(fù)處理用 InvokeRepeating 函數(shù)實現(xiàn)
比如，啟動0.5秒后每隔1秒執(zhí)行一次 DoSomeThing 函數(shù)：
function Start() { InvokeRepeating("DoSomeThing", 0.5, 1.0); }
3. 優(yōu)化 Update, FixedUpdate, LateUpdate 等每幀處理的函數(shù)
函數(shù)里面的變量盡量在頭部聲明。
比如：
function Update() { var pos: Vector3 = transform.position; }
可改為
private var pos: Vector3; function Update(){ pos = transform.position; }
4. 主動回收垃圾
給某個 GameObject 綁上以下的代碼：
function Update() { if(Time.frameCount % 50 == 0) { System.GC.Collect(); } }
??
5. 運行時盡量減少 Tris 和 Draw Calls
預(yù)覽的時候，可點開 Stats，查看圖形渲染的開銷情況。特別注意 Tris 和 Draw Calls 這兩個參數(shù)。
一般來說，要做到：
Tris 保持在 7.5k 以下
Draw Calls 保持在 20 以下
6. 壓縮 Mesh
導(dǎo)入 3D 模型之后，在不影響顯示效果的前提下，最好打開 Mesh Compression。
Off, Low, Medium, High 這幾個選項，可酌情選取。
7. 避免大量使用 Unity 自帶的 Sphere 等內(nèi)建 Mesh
Unity 內(nèi)建的 Mesh，多邊形的數(shù)量比較大，如果物體不要求特別圓滑，可導(dǎo)入其他的簡單3D模型代替。
8. 優(yōu)化數(shù)學(xué)計算
比如，如果可以避免使用浮點型(float)，盡量使用整形(int)，盡量少用復(fù)雜的數(shù)學(xué)函數(shù)比如 Sin 和 Cos 等等。
使用#pragma strict
現(xiàn)在問題是，你通常不會意識到你在使用動態(tài)類型。#pragma strict可以解決這個問題！簡單的添加#pragma strict在腳本頂部，之后Unity將禁用腳本的動態(tài)類型，強制你使用靜態(tài)類型。如果有一個類型未知，Unity將報告編譯錯誤。下面，foo將在編譯時報錯：
#pragma strict
function Start ()
{
?? ?var foo = GetComponent(MyScript);
?? ?foo.DoSomething();
}
?
使用內(nèi)置數(shù)組
內(nèi)置數(shù)組是非常快的。ArrayList或Array類很容易使用，你能輕易添加元件。但是他們有完全不同的速度。 內(nèi)置數(shù)組有固定長度，并且大多時候你會事先知道最大長度然后填充它。內(nèi)置數(shù)組最好的一點是他們直接嵌入結(jié)構(gòu)數(shù)據(jù)類型在一個緊密的緩存里，而不需要任何額外類型信息或其他開銷。因此，在緩存中遍歷它是非常容易的，因為每個元素都是對齊的。
privatevar positions : Vector3[];
function Awake () {
?? ?positions = new ?Vector3[100];
?? ?for (var i=0;i<100;i++)
?? ?positions = ?Vector3.zero;
}
未選中物體變灰色：
改變物體shader中最后計算出來的rgb值即可，將其轉(zhuǎn)換成lab，然后用（l，l，l）來代表其最終的rgb即可，對于選中的物體不需要進行處理，這樣就會出現(xiàn)上述的視覺效果了
代碼如何控制是否使用lightmaps
unity是通過shader來加載lightmap的，你可以設(shè)置一個全局參數(shù)來控制是否需要lightmap進行最后的光照計算，然后通過白天還是夜晚控制這個全局參數(shù)即可。
billboard：
公告版.transform.LookAt（new Vecter3（Camera.main.transform.position.x，公告版.transform.position.y，Camera.main.transform.z））。這個方法hog在論壇里發(fā)過
1、角色模型制作
unity3d支持Skin動畫 ?但是不支持Physique動畫 ?會發(fā)現(xiàn)Physique動畫在unity里嚴重變形 ?
因此在模型的骨骼動畫的制作上面 ?要用Skin ?
當(dāng)然也可以做成Physique ?然后用插件轉(zhuǎn)換一下 ?3dsmax的插件PhyToSkin
3dsmax中轉(zhuǎn)換之前 ?為了避免出錯 ?先隱藏骨骼 ? 然后對綁定了骨骼的模型進行單獨轉(zhuǎn)換 ?因為批量也會出錯
轉(zhuǎn)換以后在修改面板中加入可編輯網(wǎng)格 ?同時為了避免出錯 ?檢查一下uv是否貼反了
?
2、角色模型導(dǎo)出
確保導(dǎo)出的模型是已經(jīng)綁定了骨骼的 ?在導(dǎo)出設(shè)置中根據(jù)需要選擇是否導(dǎo)出Animation ?
以及3dsmax和unity3d中的單位關(guān)系
? ? ?備注：max中導(dǎo)出戴有骨骼動畫的mesh：
1 導(dǎo)出時需包含骨骼信息和mesh，mesh包含對應(yīng)的skin影響器，physique不支持。
2 導(dǎo)出時在導(dǎo)出面板勾選導(dǎo)出動畫，并設(shè)置要導(dǎo)出的動畫時間長度
? ? max中單位： ?按1unit=1m制作，之后導(dǎo)出設(shè)置單位為M，這樣縮放因子在1則為正確。fbx進入unity中后，模型要將縮放因子由0.01 改為1，則單位與max中 的單位以及真實世界的單位對齊了
?
3、官方CharacterCustomization中的模型
從官方換裝demo中會發(fā)現(xiàn)他的一個角色模型里包含了要換裝的多個模型 ?比如有兩個衣服模型、三個頭發(fā)模型等
那我們在美術(shù)制作的過程中是不是也要這樣進行“模型疊加”呢 ? 其實沒必要
demo這樣的目的是為了使得模型公用一套骨骼 ?那么我們在角色模型的制作過程中 ?就確保模型使用的是同一套骨骼
比如男性角色使用一套 ?女性角色使用另一套 ?當(dāng)進入創(chuàng)建角色場景后 ?根據(jù)玩家選擇角色的性別 ?顯示不同的動畫即可
?
4、角色模型打包技巧
前面提到 ?官方demo里換裝的實現(xiàn) ?原因是因為公用了一套骨骼 ?
那么我們在打包的時候 ?就將骨骼和模型分離 ?將模型各個部件（比如頭發(fā)、手臂等）分開打包 ?
比如一個男性的角色 ?將他的基礎(chǔ)骨骼打進一個包 ? 再將身體各個部分的模型分別打包 ?
如果一個模型由頭、臉、身體、手臂、腳五個部分組成 ?那么打包后將會有六個資源包 ?分別是基礎(chǔ)骨骼、頭、臉、身體、手臂、腳
這樣游戲的創(chuàng)建角色過程中 ?就可以單獨地對模型的身體部位進行切換
打包的過程和官方demo的打包大同小異 ?只不過這里作者在打包時捎帶生成了換裝的配置表
?
6、角色模型的加載
unity3d中使用www進行資源的加載 ?如果將資源放在了http服務(wù)器上的話（包括本機的IIS） ?則需要一個crossdomain的xml配置 ?本地則不需要
加載時應(yīng)該首先去加載基礎(chǔ)骨骼 ?加載完以后再去加載要顯示的默認角色模型 ?比如新手模型
在加載完以后 ?則要提取各個模型中所記錄的骨骼信息 ?根據(jù)這些信息將模型掛到對應(yīng)的骨骼上
為了避免模型之間出現(xiàn)縫隙 ?應(yīng)當(dāng)進行模型網(wǎng)格的合并 ?
完成以上工作以后模型的加載就已經(jīng)實現(xiàn)了
?
7、角色模型的換裝
回到角色模型打包的話題 ?
設(shè)想一個男性角色有10套服裝用來更換 ?而公用的骨骼是一套 ?
因此在打包時仍然將這一套骨骼單獨打包 ?然后再將其他所有的模型打包 ?
一句話總結(jié)就是 ? 一套骨骼對應(yīng)N個模型 ?這N個模型都公用這一套骨骼
換裝的實現(xiàn)實際上就是將相應(yīng)的身體部分進行更換 ?
比如要換一個手臂 ?則將新的手臂與身體上除了手臂以外的模型再進行一次網(wǎng)格合并
換句話說 ?要更換身體某一個部位 ?實際上就是更新了整個角色模型
這里需要注意的一點是 ?基礎(chǔ)的骨骼不用再去更新 ?
設(shè)想一下 ?換裝時候 ?一般角色都會有個“站立”或者“呼吸”的動作在播放 ?那么如果同時去更新了一遍基礎(chǔ)骨骼 ?那么結(jié)果勢必會讓本來連貫的動作有“一閃”的現(xiàn)象
這是因為 ?之前的動畫還沒播放完 ?然后就更新了骨骼 ?那么動畫又重頭開始播 ?這之間沒有過渡 ?肯定會有點問題
?
控制抗鋸齒
設(shè)置Edit---ProjectSettings---Quality
我們主要使用3dsmax2010進行制作，輸出FBX的類型導(dǎo)入Unity3D中。 默認情況下，3dsmax8可以和U3D軟件直接融合，自動轉(zhuǎn)換為FBX物體。 注意事項如下： 1.面數(shù)控制 在MAX軟件中制作單一GameObject物體的面數(shù)不能超過65000個三角形，即32500個多邊形Poly，如果超過這個數(shù)量的物體不會顯示出來，這就需要我們合理分布多邊形和模型數(shù)量。 打開MAX場景，選擇File/Properties/SummaryInfo可以打開文件屬性記錄。 其中Faces可以看到每個物體的實際數(shù)量，個體數(shù)量不能超過65000個Faces面。 2.建模控制 Unity3D軟件支持Line渲染和編輯之后所產(chǎn)生的模型。大部分模型都依靠Polygon進行制作。在模型表面可以承認多出四邊形的面，但不渲染交錯的面。 默認情況下，U3D引擎是不承認雙面材質(zhì)的，除非使用植物材質(zhì)球Nature類型。 所以在制作窗戶、護欄等物體，如果想在兩面都能看到模型，那需要制作出厚度，或者復(fù)制兩個面翻轉(zhuǎn)其中一個的Normal法線。 3.文件的放置 模型可以繼承MAX的材質(zhì)，但是文件的設(shè)置要按照以下形式進行放 在項目的Assets文件夾內(nèi)，新創(chuàng)建一個Object文件夾。 并在其中創(chuàng)建Materials和Texture文件夾（分別自動存放材質(zhì)球和貼圖）。 模型物體并列保存在Object文件夾內(nèi)。 這個規(guī)律模式不要打亂，否則會破壞整個系統(tǒng)邏輯。 4.材質(zhì)數(shù)量控制 如果一個物體給與一個材質(zhì)球，那么Unity3D對于材質(zhì)數(shù)量和貼圖數(shù)量沒有任何的限制。 如果一個物體給與多個材質(zhì)球，我們需要用Multi/SubObject來實現(xiàn)，但是這種羅列的材質(zhì)球的數(shù)量沒有嚴格的控制，但盡量保持在10以內(nèi)，過多的數(shù)量會導(dǎo)致一些錯誤。 如果不使用Multi/SubObject材質(zhì)球，也可以選擇一些面，然后給與一個材質(zhì)球。這樣系統(tǒng)會自動將其轉(zhuǎn)換成Multi/SubObject材質(zhì)。 綜合而言Unity3D軟件對于材質(zhì)的兼容還是很好的。 5.物體的質(zhì)感 Diffuse Diffuse Bumped Bumped Specular 這三種類型為常用類型，其中Bumped需要增加Normal法線貼圖來實現(xiàn)凹凸。 Decal 這種材質(zhì)為貼花材質(zhì)，即相當(dāng)于Mask類型，可以再Decal(RGBA)貼與一個帶有Alpha通道的圖像，形成和原圖像相疊加的效果 Diffuse Detail 這種材質(zhì)可以創(chuàng)造出污跡和劃痕的效果，即相當(dāng)于Blend混合材質(zhì)。 Reflective 其中各種類型可以創(chuàng)造出金屬反射效果，需要增加Cubmap貼圖。 Transparent 其中各種類型可以創(chuàng)造出透明的效果，需要增加具有Alpha的通道貼圖。 注意：如果要做玻璃貼圖，Alpha如果全是灰色或黑色（即要求全透明），那么Alpha就會失效，如果要全透明，材質(zhì)Alpha其中必須至少有1像素為白色。 Nature 其中SoftOcclusion Leaves類型主要應(yīng)用于片狀的樹葉材質(zhì)。 6.物體尺寸 默認情況下U3D系統(tǒng)單位1等于1米，等于軟件1單位。如果我們制作是按照實際大小比例制作，那么導(dǎo)入U3D引擎會自動變成原來的1%的大小。 因為默認情況下，U3D的FBXImporter中的Scale Factor的數(shù)值為0.01。 那個我們可以將ScaleFactor的數(shù)值恢復(fù)為1，但是這樣會占用模型資源，比較消耗物理緩存。 我們也可以將這個物體從Hierarchy中選擇，并使用Scale放大100倍，這種設(shè)置可以有很多好處，并且還能通過用腳本制作動畫。 7.關(guān)于復(fù)制 場景中的燈光布局，重復(fù)的模型物體都可以使用系統(tǒng)Prefab進行關(guān)聯(lián)復(fù)制，這樣可以改變一個參數(shù)的同時將所有關(guān)聯(lián)物體屬性改變。 8.山脈控制 在創(chuàng)建山脈之后，選擇Terrain/Set Resolution可以設(shè)置山脈的大小和屬性。 需要注意的是，默認情況下TerrainWidth和Terrain Height為1000米。如果設(shè)置這個數(shù)值太小，那么繪制草的時候會產(chǎn)生偏移，因為草的尺寸必須減少到0.1的單位。 也就是說，山脈在處理0.1單位的時候會產(chǎn)生0.01的偏差，如果模型太小，這種偏差是顯而易見的，所以建議用戶不要讓模型過小。 9.光暈控制 光暈又稱為Lens Flare即燈光光效。 可以選擇一個GameObject物體給與Component/Rendering/LensFlare，并在Flare中增加一個StandardAssets/Light Flares/50mm Zoom項目。這樣在運行之后就會產(chǎn)生光暈。 但有時候如果光暈太遠太高卻看不到。 一種辦法是將光暈離近，另一種辦法是將所有攝影機Camera的Far clip plane的數(shù)值增加。 10.攝影機控制 如果場景中有多架攝影機，那么如何確定第一打開時間所顯示的攝影機，就需要設(shè)置Camera屬性中的Depth數(shù)值，數(shù)值越大的攝影機越優(yōu)先顯示。 |
下面給你提供寫方法以剝離減小包的大小，有些我也沒試過：
降低的播放機大小主要有兩個途徑：一是更改Xcode內(nèi)的Active Build Configuration，二是更改Unity的Stripping級別。
在發(fā)布模式下生成
你可以在 Xcode的Active Build Configuration下拉菜單中的調(diào)試和發(fā)布選項之間進行選擇。根據(jù)自身游戲的大小，選擇發(fā)布模式生成的player會比選擇調(diào)試模式減少2-3MB的大小。
在發(fā)布模式下，player會去掉任何的調(diào)試信息進行生成，所以如果你的游戲崩潰或有其他問題，將是沒有可用的、可輸出的堆棧跟蹤信息。這適合發(fā)布已完成的游戲，但你更應(yīng)該在開發(fā)過程中使用調(diào)試模式。
iOS Stripping級別（Advanced License feature）
尺寸優(yōu)化工作可通過以下幾種方式被剝離機制激活：
Strip assemblies級別：通過分析腳本的字節(jié)碼，來將這些腳本沒有引用的類和方法從 Dll 中刪除，從而使其不進入 AOT編譯階段。這種優(yōu)化減少了主要的二進制以及相應(yīng) Dll的大小。在不使用反射的條件下，這種優(yōu)化是安全的。
Strip ByteCode級別：任何.Net Dll（存儲數(shù)據(jù)文件夾中）將從元數(shù)據(jù)中被剝離出來。這是可能的，因為所有的代碼都已經(jīng) AOT階段被預(yù)編譯并鏈接到主要的二進制文件中
使用micro mscorlib級別：使用一種特殊的、較小的mscorlib版本。某些部件將從此庫中被移除，例如，安全，Reflection.Emit，遠程處理，非公歷日歷等組件都將被刪除。此外，內(nèi)部組件之間的相互依賴性也會被降至最低。該種優(yōu)化減少了主要的二進制以及mscorlib.dll的大小，但不能與一些系統(tǒng)和 System.Xml程序集類兼容。因此，小心地使用它。
這些級別是累積的，第3級優(yōu)化隱式地包含級別 2和級別1，而第 2級優(yōu)化則包含級別1。
Micro mscorlib是核心庫的最低級版本。只有這些項目是目前Unity中的Mono運行庫所需要的。使用micro mscorlib的最佳做法是不使用任何你的應(yīng)用程序所不需要的.Net的類或其他功能。GUID就是一個你可以忽略的例子，她可以輕松地被自定義的偽 Guid所替代，這樣做將產(chǎn)生更好的性能和更小的應(yīng)用程序。
如何處理使用反射機制的Strip
Strip程度取決于靜態(tài)代碼的分析，但有時侯，這種分析并不是很有效，特別是針對使用類似反射一樣的動態(tài)功能的代碼。在這種情況下，有必要給出一些提示來指出哪些類是不應(yīng)該被觸動的。Unity支持對于每個項目都給出一個自定義Strip黑名單。使用黑名單是創(chuàng)建 link.xml 文件并將它放入Assets文件夾的一個簡單方法。以下是一個的 link.xml文件的示例。其中有保留標記的類將不會被Strip：
有時侯，我們很難確定哪些類會被進行錯誤的Strip。通常你可以通過在模擬器上運行已被Strip的應(yīng)用程序和檢查 Xcode 控制臺的錯誤消息來獲取有用的信息。
簡單的清單，使你的發(fā)布版本盡可能地小
1.最小化你的資源（assets）：啟用 PVRTC壓縮紋理，并盡可能低降低其分辨率。此外，盡量縮減無損壓縮的音頻的個數(shù)。這里還有一些額外的縮減文件大小的提示。
2.設(shè)置iOSStrip級別為Use micro mscorlib。
3.設(shè)置腳本調(diào)用優(yōu)化級別為Fast but no exceptions。
4.不要讓你的任何代碼與System.dll或 System.Xml.dll有關(guān)聯(lián)，因為這些庫并不兼容micro mscorlib。
5.去掉不必要的代碼關(guān)聯(lián)。
6.將API兼容性級別設(shè)置為.Net 2.0子集。請注意.Net 2.0子集與其他庫與兼容性比較有限。
7.設(shè)置目標平臺為armv6 (OpenGL ES1.1)。
8.不要使用 JS陣列。
9.避免泛型容器與結(jié)構(gòu)等類型相結(jié)合。
我能用Unity創(chuàng)造出低于 20 mb的應(yīng)用程序嗎？
當(dāng)然可以。如果所有優(yōu)化被都關(guān)掉，一個空項目在AppStore中大小大致為 13 MB左右。這在游戲中為你提供了大約7 MB的壓縮資源預(yù)算。如果你擁有先進的許可證（并因此獲得Strip選項），那么只含有主相機的空場景在AppStore中可壓縮到大約 6 MB （zipped和 DRM連接），這樣，你就可以有大約 14 MB可用空間用于壓縮資源。
為什么我的應(yīng)用程序發(fā)布到AppStore后大小增加了？
當(dāng)他們發(fā)布你的應(yīng)用程序時，蘋果首先對二進制文件進行加密，然后將它通過 zip壓縮。最常見的，蘋果 DRM會使二進制文件大小增加大約 4 MB左右。作為一般規(guī)則，你應(yīng)預(yù)見到的文件最終大小大致為所有文件（除了可執(zhí)行文件）的 zip壓縮大小，再加上未壓縮的可執(zhí)行文件的大小。
boxcollider或者其他任何collider 都是為物理碰撞或者碰撞檢測做準備。
rigidbody 剛體屬性組件，在任何物體下的Add component （添加零件、添加組件）可添加。 物體勾了tigger 那個屬性，或者是地面勾了那個屬性。tigger是能進入內(nèi)部的，通常做判斷觸發(fā)范圍
------------------------------------------
通常在變換場景后，上個場景中除了使用 DontDestroyOnLoad() 保留的物件，將會被釋放掉，但如果在沒有變換場景的情形下，想把未使用的資源卸載掉，該如何做呢？
一般情況下，我們會利用 Unity 的編輯器來部屬每個關(guān)卡或場景中的物件，這些物件在載入場景后都是必要的，也不太會持續(xù)增加物件數(shù)，在關(guān)卡結(jié)束后即轉(zhuǎn)換到下個場景，所以原本場景中的物件 將不再需要，所以 Unity 將會自動將前一場景的物件都銷毀掉，所以我們通常不太需要去管理記憶體的使用或是否釋放，但如果你的游戲全部是在單一個場景中運行的，那麼物件的產(chǎn)生、銷 毀、釋放資源等等的動作就變得格外重要。
我做了一個寶石類型的游戲，畫面上除了 GUI 及背景外就只有寶石，所以我事先將寶石做成 Prefabs ，在需要時利用 Instantiate() 產(chǎn)生，我在不同的關(guān)卡利用 renderer.material.mainTexture 變更背景圖，利用 GetComponent(MeshFilter).sharedMesh 變更寶石的形狀以及利用 renderer.material.color 變更寶石顏色，如此一個Prefabs 可以重復(fù)無限使用，所以在游戲場景中只設(shè)置了簡單幾個場景物件，在這種場景不需要變化太多的情況下，每個關(guān)卡都換場景重新配置一樣的物件似乎有點多餘，所 以這個游戲便只有一個場景，在需要時產(chǎn)生寶石，然后再視情況使用 Destroy() 銷毀掉，這樣看起來只要在產(chǎn)生寶石時控制畫面上的物件數(shù)量，那麼也就不用擔(dān)心記憶體使用過量或沒釋放掉的問題。
但是，這個游戲在連續(xù)玩好幾個關(guān)卡后，也就是連續(xù)玩一段時間后，會發(fā)生停頓或畫面變慢的問題，游戲剛開始玩時是相當(dāng)順暢的，但長時間執(zhí)行將使效能降低，直 覺上的判斷應(yīng)該是記憶體累積到一定程度造成的，每個物件在不使用時都使用 Destroy() 銷毀掉，那麼，堆積的記憶體是從哪裡來的呢？ 打開 Profiler 視窗看看，會發(fā)現(xiàn)其中的 Memory 的 Total Object Count 數(shù)值，不斷的增減變化，但隨著時間的增加會慢慢的往上累積，查看官網(wǎng) (http://unity3d.com/support/documentation/Manual/Profiler.html) 是這樣說的 "If this number rises over time then it means your game is creating some objects that are never destroyed."，有些物件未銷燬，很奇怪吧！都有使用 Destroy()，那為何還有未銷毀的物件？其實，主要是因為我這裡有對 renderer.material 設(shè)置改變其內(nèi)容，在這個執(zhí)行時期并不會真的去改變 Project 中的 material，而是產(chǎn)生這個物件實例(instance) 的材質(zhì)實例以供該物件使用，所以如果只是 Destroy(gameObject) 的話，將會殘留部份物件數(shù)，每個產(chǎn)生的物件都殘留一點點的話，慢慢的長時間下來將會累積相當(dāng)多，記憶體將會不敷使用，所以在 Destroy(gameObject) 的同時，應(yīng)該也要 Destroy(renderer.material) 才行。
如果程式結(jié)構(gòu)簡單，給物件使用的 Script 檔案也不多的話，也許多加一句并不困難，但我們有時候無法確定是否有在適當(dāng)時機為每個物件做到完整的銷毀，也許還有殘留別的東西也會有這種情形持續(xù)累積記 憶體，這時又該尋找更簡單統(tǒng)一的方法了，於是我們可以在每個關(guān)卡開始前或結(jié)束時執(zhí)行一句 Resources.UnloadUnusedAssets() ，讓 Unity 自行去卸載掉不使用的資源，如此在平時物件銷毀時，我們已經(jīng)先行釋放掉大部份不使用的資源，然后再由 Resources.UnloadUnusedAssets() 卸載我們未清理掉的部份，如此的話查看 Profiler 視窗的 Memory 的 Total Object Count 數(shù)值就可以維持在一定范圍內(nèi)起伏，而不再隨著時間增加，當(dāng)然我們在關(guān)卡設(shè)置上都會有難度上的差異，在某些關(guān)卡裡，玩家可能必須花較多時間才能完成關(guān)卡，所 以如果我們只在關(guān)卡開始或結(jié)束時使用 Resources.UnloadUnusedAssets() 也許會不夠，此時也可另外定義每過一段時間就執(zhí)行 Resources.UnloadUnusedAssets() ，如此將可避免掉系統(tǒng)資源不足的問題。?
http://blog.sina.com.cn/s/blog_6af6af4b0100yy7n.html
在做項目過程中，經(jīng)常會遇到一種情況： 場景中有不同種類的實例對象，這些實例可以是不同的3D物體。當(dāng)我們需要點擊其中一個物體（GameObject）時，希望他能夠自動刪除自己，并且將也要把對應(yīng)的數(shù)組記錄刪除，保證數(shù)據(jù)統(tǒng)一。要實現(xiàn)以上所說的，需要建立一種自調(diào)用方法來實現(xiàn)。http://www.easyunity3d.com/unity3d-destroy-gameobject.html
總結(jié)
- 上一篇： matlab图像加椒盐噪声,用matla
- 下一篇： FreeRTOS入门知识（教你快速入门）