隨著開發工具的不斷迭代和開發人員能力的不斷提升，製作一款遊戲也不再是一個難事。每一個開發團隊無論規模大小，都在努力讓自己的產品盡善盡美。但有時候可能由於經驗不足、時間緊迫等原因，還是會遇到一些自身無法解決的困難。這時候他們其實很需要得到一些行業專家的指導和幫助，而騰訊遊戲學院恰好就提供了這樣的資源。
騰訊代理的一款暗黑類ARPG手遊《拉結爾》即將上線，這款遊戲由騰訊遊戲學院專家進行了歷時4個多月的打磨指導，從線上溝通到現場分析，重點解決了一些客戶端的問題。下面就為大家總結一下項目組遇到的問題以及專家董根的解決方案，相信會給有類似困惑的開發者們一些幫助。
提升遊戲流暢度，降低場景內存佔用
拉結爾的開發團隊和專家之間先是通過郵件進行了初步的溝通，針對開發團隊提出的性能問題，給出了一些針對性的建議。
研發團隊提出了以下幾個問題：
問題1：項目中使用的PSS比標準的（UWA），超過1G；遊戲啟動400+MB，進入到遊戲景1+G了；在Xcode看到在登錄完成後內存高達660+MB，其中數據表(MONO)的200+MB，其他未知模塊消耗400+MB，請問這部分的內存能降低麼？怎麼降低？
專家解答：MONO內存包含的不只是數據表，如果是整體MONO內存比較高，建議可以通過Unity官方開源的Memory Profiler進一步分析，如果確認是數據表的部分，可以看看是否表格設計的列過多，能不能精簡一下，或者在加載的時候用更精簡的結構轉存一下，能手動定義的字段不要通過Key-Value訪問。表格中的字符串統一讀到字符串表中，原先記錄中的字符串用id來代替，這樣可以減少重複字符串。這些是常用的手段，但建議項目組結合實際的分析結論確定優化辦法。
問題2：Unity3d 5.6.4自帶的Cloth組件，無規律的出現閃退，Cloth布料的製作和使用是否是有一些規則，能讓Cloth運行更穩定？另外Cloth組件中的SleepThreahold是間隔時間停頓麼？怎麼使用？能對Cloth組件的性能消耗能降低麼？
當前項目使用Cloth組件，發現在導入fbx的時候勾選了Optimize Mesh選項，Cloth組件同級掛載的SkinnedMeshRenderer的Bounds很大概率（70&~80%）出現NaN；不勾選Optimize Mesh後，NaN錯誤沒有再出現了；請問這個NaN是否會對布料的計算產生性能消耗？
專家解答：SleepThreahold是指布料頂點的移動速度在多小的時候就進入asleep狀態不再更新。Bound變成NaN這個有可能是一個Unity的Bug，這個主要會影響Unity做視椎裁剪，帶來視覺錯誤或者額外的性能開銷，同時對其他依賴Bound的邏輯也會有影響。
按現在的移動設備跑布料系統壓力非常大，效果上要有保證的話性能開銷非常高，壓低參數又比較容易出現模擬穿幫，另外Unity的布料也是集成的NvCloth，這個布料庫在移動端的穩定性確實不好，所以手機上還是建議不要使用布料。通常情況下用Dynamic Bone等插件也能做到不錯的效果。
問題3：(Android平臺下)音頻加載和播放都會出現較為嚴重的卡頓(CPU耗時300毫秒以上)，怎麼平衡效果和效率?（目前沒有進行太多音頻的平臺設置，直接拿起就播放的）
專家解答：如果是長時間的背景音樂，建議在資源上打開Streaming，短時間（1、2秒以內）的音效如果都很卡的話，主要就要靠壓低採樣率了，或者嘗試採用不壓縮的格式。
問題4：當前項目使用了T4M的地表插件，美術使用了4層，導致渲染耗時比較嚴重（4ms）;就當前項目而言如何兼顧美術的需求又降低消耗?
專家解答：地表的多層混合建議在渲染本身上做優化，一方面是減少貼圖，在可接受的範圍內儘量減少貼圖的尺寸，如果可以的話去掉一些層的法線貼圖。另一方面可以重寫一下地形的Shader，用最簡單的光照模型，減少不必要的貼圖採樣。地形的頂點數也留意一下，不要太誇張就好。如果能對多層的權重做一些限制（例如單個位置同時僅允許2層權重有效），則有更多的辦法。
問題5：煙霧的特效（已經用了序列幀），但是overdraw還是很高；如何降低overdraw？
專家解答：這樣的問題還是要從美術方面入手，儘量降低半透明面片的大小和數量，避免使用充滿全屏或接近全屏的煙霧，可以提供一下具體overdraw比較高的畫面看看。
問題6：目前場景物件比較多，全部都是Static。然後烘焙後Lightmap可能會造成batch斷掉，造成drawcall很高。對於這種場景物件很多的情況，有沒有什麼好的做法或建議？
專家解答：最直接的辦法就是在可接受的範圍內儘量降低LightMap精度，使烘培出來的LightMap儘量少，越少就越不容易打斷batch，最優的狀態是隻有一張，那麼就不存在打斷batch的問題了。
還可以對場景進行切塊，把每個塊單獨放在一個臨時場景中，內容保證在一張Lightmap的容量內，然後單獨烘培這個場景，最後把烘培結果取出，運行時手動給設置上。這樣可以保證單塊之內不會因為LightMap而打斷batch。
解決資源丟失，顯示異常問題
為適應手遊快速更新的節奏以及方便控制戰鬥場景內存，由Resources方式調整成AB包的方式，針對調整過程中的一些坑點，專家也耐心提供解答。
研發團隊提出了以下幾個問題：
問題1：目前存在很多shader丟失問題該如何解決？
專家解答：是否將Shader打了依賴包？或者代碼中有動態切換Shader宏的操作？如果有，建議在Shader的包中帶上一組空材質，將可能的變體組合都在材質上設置一下，因為Shader打包因為沒有材質引用，所以無法識別所有的變體。研發解決後也反饋瞭解決方式：shader的丟失是U3D的著色器剝離，已設置成手動的，一些使用shader.find的方式都替換成讀取AB中的方式了。
問題2：關於資源下載的大小，因為資源是零散的，然後相互之間有依賴關係；可能會分配到不同的chunk中，導致，每下一個都要多帶上之前的資源；目前我採用的是，把chunk塊分的大小從32擴大到128塊，如果設置到128塊，會不會性能相關問題，讀取上會不會卡頓，依賴關係是否會增加？
專家解答：再多分細一些完全沒有問題，以後熱更新粒度也會更細。
問題3：在ui上的角色怪物顯示在安卓平臺上出現了問題，表現為rt的透明度全部為1，導致角色相機在沒有渲染的地方也顯示了camera的clear color。問題出於一個bloom的後處理，整個腳本取消了就沒問題，但我們把OnRenderImage換成只有一行blit(src,dest)以後問題還是存在。
專家解答：目標RT和源RT相同的時候，Untiy會創建一張臨時RT作為目標RT，最後再將它拷貝回來，拷貝的過程通過截幀看到在部分平臺下寫入A通道被關閉，雖然暫時不清楚Unity內部的機制，但是通過CommandBuffer重新實現的話，可以手動控制後期流程中的每個環節，規避掉這個問題
Crash率從10%降至1%
從19年三月份開始，騰訊專家也利用週末時間直接出差到開發團隊所在地，現場協助分析和解決問題。
初次線下溝通的過程中，在沒有log只有底層堆棧的情況下，騰訊專家針對實際情況給出一定的分析。在內存分配失敗的時候，要先確認一下當時的內存佔用情況，有幾種可能：一是確實內存不足，二是內存碎片太多導致找不到連續空間，三是資源上有問題導致傳了一個未初始化的值作為size去分配內存。如果是最後一種情況可以把資源加載的記錄打印一下，看看是否和特定資源的加載有關聯，如果是前兩種情況就比較麻煩了，只有持續優化內存了。
第二次線下溝通專家通過現場分析崩潰規律和日誌，建議增加更多定位日誌，查閱代碼，發現unsfae指針，存在越界風險，可能帶來閃退問題，並且排除閃退是由於接入sdk的可能性。
最後專家也針對特殊字體/字符，提出調用系統字體的方法，以減少閃退的問題。與此同時，專家還和研發主程交流了開發流程和規範等問題，分享了一些個人的經驗，有效提升了開發效率。至此《拉結爾》項目組一系列的問題都得到了有效解決。
關於騰訊遊戲學院專家團
如果你的遊戲也富有想法充滿創意，如果你的團隊現在也遇到了一些開發瓶頸，那麼歡迎你來聯繫我們。騰訊遊戲學院聚集了騰訊及行業內策劃、美術、程序等領域的遊戲專家，我們將為全世界的創意遊戲團隊提供專業的技術指導和遊戲調優建議，解決團隊在開發過程中遇到的一系列問題。
項目指導合作請聯繫微信：18698874612
閱讀更多 騰訊創意遊戲合作計劃 的文章
