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