記憶體洩漏
資源製作
q1：我們測試發現，當animator controller掛載的動作比較多時，即使切換成另外乙個動作很少的animator controller，任務的動作資訊還是不會釋放。我們將英雄打成乙個assetbundle，然後又把定製的runtime animator controller載入替換進去，英雄自帶的runtime animator controller是掛了所有動作的。我們試了替換runtime animator controller之後，把先前的runtime animator controller destroy掉，貌似記憶體也沒釋放。
銷毀animator controller並不會釋放其內所引用的animationclip資源的，所以記憶體沒有明顯下降是正常的。建議按照以下方式做個試驗：q1：optimize game objects對於老版本的animation系統有沒有作用呢？1）銷毀animator controller 後，通過unity profiler立刻真機take sample，檢視animation clip的ref count是否為0；
2）如果不是，則需要進一步檢視這些資源的索引出處；如果為0，則可以通過unloadunusedassets或unloadasset來將其從記憶體》 中去除。
沒有作用。optimize game objects功能是unity4.3版本推出的功能，且僅對mecanim動畫系統起作用。如果可以的話，建議研發團隊盡可能使用mecanim來作為專案動畫系統的解決方案。q2：在uwa效能報告中，你們建議我們選中optimize gameobject來提公升mecanim動畫模組的執行效能，但是這個功能會隱蔽角色骨骼，那麼要掛載該骨骼上的這個點就無法查詢了，有什麼辦法可以解決這個問題嗎？
是的，開啟optimize gameobject預設情況下會將動畫網格下的所有骨骼結點隱藏，但是，你可以通過「extra transform to expose」檢視你想通過指令碼獲取的骨骼結點，這樣既可以提公升該角色的動畫模組效能，又可以達到獲取某個關鍵結點的需求。q3：skinnedmeshrenderer.bakemesh這個函式一般是什麼時候呼叫呢?在instantiate後呼叫麼？
q4：在uwa給出的報告中，我們發現了animator過高的情況，其中ui和角色各佔一半。我們之前一直選擇cullupdatetransforms，通過閱讀unity官方文件發現cullcompletely更符合我們的現狀，想請教下如果我們選擇cullcompletely可能會有什麼隱患呢？
使用 cullcompletely 在開啟 rootmotion 時是需要注意的，比如人物有乙個巡邏動畫是通過 rootmotion 製作的，那麼在人物走出螢幕後，其動畫就停止了，即不會再走回螢幕中。q5：我們在美術製作時做了40根骨骼，但在動作中僅用到了其中的30根。這種做法和30根骨骼用到了30根相比，在蒙皮計算上會明顯增加嗎？（animation經過了壓縮處理）
理論上是有增加的，骨骼運算均是每個骨骼階段的matrix乘起來的，所以理論上會有開銷。建議使用optimize gameobejct選項，可以減少一些不必要的cpu開銷。
關於Unity粒子系統優化，你可能遇到這些問題
粒子系統合批 q1 我們在uwa報告中看到有拼合粒子系統和未拼合粒子系統，請問如何拼合粒子系統？有沒有什麼規則呢？粒子系統的draw call動態拼合與半透明物體的動態拼合機制相當 粒子基本都是半透明材質 而對半透明物體，由於其渲染順序的限制 必須從後向前渲染，以保證渲染結果的正確性 動態拼合只能對...
Unity舊版動畫系統
一 layer和weight 的概念 動畫層和layermask沒有關係，它是乙個只和動畫有關的東西。這也是unity本身的一套東西，別的引擎上沒有層的概念，正因為這個動畫系統在unity裡面很靈活，有人說已經有animator，沒有人用舊版的動畫系統了，其實不然，animator就像一套編好的動畫...
關於Unity 動畫繪製原理
動畫繪製的原理 現在螢幕中確定動畫的顯示區域，然後將動畫中的每一幀按固定的時間在這個區域中按順序切換，從而實現動畫的效果。建立資料夾textures private var anim object 動畫陣列 private var nowfram int 幀序列 private var mframe...