【技術小札】是UWA推出的技術交流欄目，我們會將開發團隊中反饋的常見問題加以總結並梳理在此，以供大家參考。同時如果你也是個熱愛分享、願與大家抱團進步的程序員，歡迎加入UWA的QQ群（465082844），與我們奇文分享，疑義相析。

內存管理

Q1：如果一個模型對應Skinned Mesh Renderer實例，那其所佔的內存會隨著角色增加而增長么 ？

簡單地從一個角色Prefab實例化（Instantiate）出多個實例時，Mesh並不會出現多份（這個行為與其他資源是一致的，包括Texture，AnimationClip，Material等等）。如果在內存中發現多份，可以考慮從項目中AssetBundle的載入方式入手，因為即使是同一個AssetBundle中的同一個角色Prefab，如果被反覆進行「載入-實例化-卸載」操作，依然是會導致Mesh出現多份的（當然其他的資源也是一樣）。

資源管理

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

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

NGUI

Q3：NGUI變形，如下圖走樣了，請問是不是圖片壓縮導致的？

當UI紋理在設備上的顯示解析度低於原始解析度時，會因為出現aliasing現象，導致UI局部變形。通常對於粗線條、塊狀的UI圖素，變形通常是不明顯的，但對於細線條的UI圖素，則可能非常明顯。

通常該問題可以考慮三種方式來改善：

• 在NGUI中將UIRoot的Scaling Style設置為Flexible，這種方式的好處在於UI紋理不會因為設備解析度的限制而降低，而缺點在於相同的UI紋理在高解析度設備上顯得比較小，而在低解析度設備上顯得比較大，從而提高了UI布局的複雜度；
• 將UI紋理的顯示解析度（Sprite的size屬性）設定為高於原始解析度，其缺點在於高解析度設備上可能會產生模糊，但大多數情況下「模糊」相比於「走樣」更不易察覺；
• 開啟UI紋理的Mipmap，從而在低解析度設備上自動切換到低Level，以「模糊」替換「走樣」，但缺點在於增加了紋理的大小，因此只適用於出現了明顯變形的少量UI。

圖形渲染

Q4：在遊戲中，有些Mesh在編輯時候是接收Lightmap的，出於某些原因我們合併了相同的Mesh（材質也相同）。但是發現原先的Lightmap不再影響合併後的Mesh，請問怎麼才能實現讓合併後的Mesh也接收原先的Lightmap？

如果Lightmap不止一個的話，手動合併Mesh是會出現問題的，因為合併的Mesh烘焙信息很可能出現在不同的Lightmap中，但合併之後的Mesh在渲染時只能使用一個Lightmap，這樣uv2讀取到Lightmap信息就會出現問題，進而出現這種現象。其實，對於材質相同的Static物體並不需要手動對其Mesh進行combine，因為Unity的Static Batching會自行完成。而如果由於某種特定需求一定要將Mesh進行合併的話，那麼也要將其所需要的Lightmap也一併合併，同時改變相應的uv2。不僅如此，Shader中Lightmap也需要進行相應修改，這是比較複雜的，所以我們並不建議這樣的做法，因為可能會花掉開發團隊大量的開發時間。

資源管理

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

首先，放在項目工程Resources文件夾下的文件都會被打包進resources.assets，為了減小發布包的大小，在發布的時候請剔除Resources里以及streamingassets里不必要的文件。

其次Unity有篇官方文檔，專門介紹了如何減小發布包的體積。

推薦閱讀：