Q1：iOS上PVRTC不支持NPOT的貼圖壓縮，在Android上可以用ETC2，但在iOS上不能壓縮，內(nèi)存消耗大。請問在iOS上有沒有好的處理方案？

ETC2僅能在支持OpenGL ES3.0的手機(jī)上進(jìn)行使用，請研發(fā)團(tuán)隊在使用前謹(jǐn)慎考察支持ES3.0的手機(jī)在國內(nèi)的覆蓋范圍。
PVRTC不支持NPOT的貼圖壓縮，這是Apple規(guī)定的，上層應(yīng)用無權(quán)對此更改。我們僅能建議將紋理盡可能做成POT形式，否則只能接受內(nèi)存較大的開銷，沒有其他更好的辦法。

Q2：Unity對Dynamic Batching的數(shù)量是否有限制？或者說對Saved by Batch的數(shù)量是否有限制？

Unity對于任何Mesh的面片都有65536的個數(shù)限制，拼合后的面片數(shù)也是如此。

Q3：請問游戲中特效使用的很多貼圖, 一般有什么好的方式去管理嗎 ? 不合并圖集的話會有上千張小的透明貼圖, 合并圖集又會有占用內(nèi)存過多的問題。

可以合并成Atlas，一般將盡可能同時出現(xiàn)頻率較高的Texture合成Atlas，這樣并不會造成內(nèi)存過大。在這方面也可以參考我們前不久推薦的插件Mesh Baker。

Q4：在同一場景里烘培的Lightmap，我用了2張10241024的光照圖，大小是5.3MB；別人用了3張10241024的圖，大小是4.3MB。請問是什么影響這個光照圖的大小，在哪里調(diào)？

首先，請確認(rèn)下Lightmap的類型，Single類型只生成一張，而Dual和Directional會生成兩張。 其次，請確認(rèn)下當(dāng)前的發(fā)布平臺，Android下的Lightmap會比Standalone更小。因為不同平臺采用的壓縮格式不同。此外，Lightmapping中的Lock Atlas，Resolution，Padding等選項也會影響最后烘焙光照圖的大小。

Q5：我們打出來的ipa包大概有220MB ，相同的資源APK包只有120MB左右， 相差100多MB 。我們查過網(wǎng)上其他已上市游戲的ipa,apk兩個包，兩個包體都只相差15~30MB，請問我們這種情況是否正常，有沒有辦法進(jìn)一步壓縮ipa安裝包？

首先，放在項目工程Resources文件夾下的文件都會被打包進(jìn)resources.assets，為了減小發(fā)布包的大小，在發(fā)布的時候請?zhí)蕹齊esources里以及streamingassets里不必要的文件。
其次Unity有篇官方文檔，專門介紹了如何減小發(fā)布包的體積。

Q6：下圖一是剛進(jìn)游戲時獲取的信息，第二張是開關(guān)幾次同一個UI界面后獲取，對比兩圖我們發(fā)現(xiàn)有多份重復(fù)的Texture。請問這是為什么？我們的加載方式是UI通過AssetBundle加載，加載后會釋放AssetBundle，然后再次加載 UI 就會造成紋理資源的冗余。
(圖我省略了)

<ul><li>剛進(jìn)游戲時獲取的圖中出現(xiàn)的“重復(fù)”資源可能并不是冗余，因為 Atlas的一個 Group 中可能包含多張一樣大小的Page（即紋理），而這幾個Page在內(nèi)存中的名字是一樣的。</li><li>但是，如果同一UI界面多次開啟后，內(nèi)存中出現(xiàn)了更多同樣的資源，則說明UI的管理方式存在一定問題。對于頻繁使用的UI，我們建議在加載之后通過緩沖池對其進(jìn)行緩存，后續(xù)使用時，直接通過緩沖池獲取即可。而不要每次均通過AssetBundle進(jìn)行加載，這種做法既會造成更大的CPU占用，同樣會很大幾率造成資源的冗余。</li><li>同時，如果多次開啟的是不同UI界面，并且造成內(nèi)存中同種資源的增加，則很有可能是UI在AssetBundle打包時形成了冗余（這種情況在目前的UGUI系統(tǒng)中較為常見）。對此，如果開發(fā)團(tuán)隊使用的是UGUI，那么我們的建議如下：</li>1.對于使用Unity 5.x的新AssetBundle打包系統(tǒng)，則打包時盡可能將同種Atlas的UI界面打成一個AssetBundle文件，否則將很有可能出現(xiàn)資源冗余的情況；
2.對于使用Unity 4.x的老AssetBundle打包系統(tǒng)，則可以將一個含有Atlas的Prefab（或其他Object）先打包，其他UI元素對其進(jìn)行依賴即可。
此外，開發(fā)團(tuán)隊可以考慮用 WWW.LoadFromCacheOrDownload 來加載共享包，因為 new WWW 的方式會在內(nèi)存中形成 WebStream 造成較多的內(nèi)存開銷。關(guān)于該函數(shù)的具體優(yōu)劣，開發(fā)者可以參考你應(yīng)該知道的AssetBundle管理機(jī)制。</ul>

Q7: 請問粒子特效的Shader是否不能使用依賴打包？ 我們對Shader的模型和特效使用了依賴打包，運行的時候發(fā)現(xiàn)模型顯示是正常的，但是粒子特效使用的Shader就不能正常運行，特效顯示不正常。而在編輯器中，我們看到Material中的Shader是存在的。這時候如果重新手動給這個Material指定同樣的Shader，這個粒子特效就能正常顯示，請問這是什么原因引起的？

部分 Shader 在打包到 Android 版本的 Assetbundle 之后，會因為平臺不兼容而無法正確顯示，這是因為打包后的 Shader 代碼只保留了目標(biāo)平臺的預(yù)編譯代碼，不一定能夠在 Editor 下運行，所以這是正?，F(xiàn)象。 但這并不會影響依賴打包，因為在真機(jī)上并不會出現(xiàn)類似的問題。

Q8: iOS平臺需要對圖集做RGB和Alpha通道的分離嗎？我發(fā)現(xiàn)在同樣大小的圖片（正方形），RGB Compressed PVRTC 4bits和RGBA Compressed PVRTC 4bits兩種格式，占用內(nèi)存是一樣的，如果把一張圖片分成兩張，那么在iOS平臺是不是占用內(nèi)存多一倍？有透明通道的，對于它的圖集怎么處理會更好一點？

通常iOS下是不需要做通道分離的，因為 iOS 通用的 PVRTC 格式支持 Alpha 通道。但目前也有團(tuán)隊反饋，在 iOS 上進(jìn)行通道分離有助于減少失真，可以在一定程度上提高視覺效果，因此也可以嘗試做一個對比。
如果發(fā)現(xiàn)占用內(nèi)存是一樣的，那么原始圖片是RGB的。如果iOS上做通道分離，內(nèi)存確實會增加一倍。UI的紋理在iOS下可以直接選擇默認(rèn)的 Compress，在打Atlas時會自動處理成 PVRTC，開發(fā)團(tuán)隊可以從Sprite packer窗口來看Atlas的壓縮格式做個確認(rèn)

Q9：我有一個UI預(yù)設(shè)，它使用了一個圖集， 我在打包的時候把圖集和UI一起打成了AssetBundle。我在加載生成了GameObject后立刻卸載了AssetBundle對象， 但是當(dāng)我后面再銷毀GameObject的時候發(fā)現(xiàn)圖集依然存在，這是什么情況呢？

這是很可能出現(xiàn)的。unload(false)卸載AssetBundle并不會銷毀其加載的資源 ，是必須調(diào)用 Resources.UnloadUnusedAssets才行。關(guān)于AssetBundle加載的詳細(xì)解釋可以參考我們之前的文章：你應(yīng)該知道的AssetBundle管理機(jī)制。

Q10：Prefab中的GameObject的tag設(shè)置為EditorOnly仍然會被打進(jìn)Resoures包嗎？有其它EditorOnly方案嗎？

EditorOnly理論上只對場景中的 GameObject起效。因此 Project 目錄中的 Prefab 打上 EditorOnly 后，放在 Resources 目錄下依然會被打進(jìn)游戲包中。但只要將其放在 Resources 目錄以外，則其就會因為沒有場景中的物件引用而被排除在外。