些容易導致掉幀的原因

1. 向量圖（圖形) 不要用向量圖，點選區域可用空的元件替代，遮罩的bar用點陣圖替代 比如fgui不要用圖片裝載器畫一個圖.

2. 遮罩 儘量少的用遮罩，有些《靜態》地方沒辦法必須要用遮罩的（比如頭像要切成六邊形），必須cacheAsBitmap儘量少的用遮罩，有些《靜態》地方沒辦法必須要用遮罩的（比如頭像要切成六邊形），必須cacheAsBitmap

3. 元件元素太多（在列表元素體現比較明顯) 元件中不要刻意追求檔案小而把圖片切的很細，直接做成一張圖切九宮就好

4. 顯示卡壓力

   1. 濾鏡的使用，每使用一個濾鏡，就要多一個drawcall，一個帶文字濾鏡的文字按鈕，佔3個draw。儘量少用濾鏡，尤其是在列表元素中，一些程式數字要帶濾鏡的，讓美術做成圖片字，這樣效率比較高
   2. 按鈕沒有置灰態，而用系統自帶的濾鏡置灰（迭代置灰，影響drawcall很大）。按鈕加上置灰態的控制器選項，並用顯示控制做一下置灰態。
   3. 圖集穿插太頻繁，渲染一個檔案的時候，重複上傳同一個圖集到GPU上，導致drawcall上漲。元件儘量做扁平化，儘量同一圖集的元素一起繪製，降低圖集穿插導致drawcall升高，尤其是列表元素，更要注意
   4. 同一畫素座標上的元素越多，越耗顯示卡。儘量用扁平化顯示層級，同一畫素上疊加的元素要儘量少

5. cpu太高

   1. 某一時刻程式碼無必要的執行導致那一時刻很卡（MsgFieldsUpdate會導致主介面頭像框重新編制、主介面上各種監聽按鈕重新設定控制器。表的首次解析等非常嚴重掉幀）
   2. （個例）引用了滑鼠庫，但是在手遊地址沒有將滑鼠庫禁用，導致手機上每幀執行顯示物件的hitTest，CPU超高佔用，掉幀嚴重
   3. GC太頻繁（用好物件池，比如CallBackVO，不要隨手一個new）
   4. 介面中儘量重用元素，比如有一個item裡有多個圖示，以“一個圖示在不同控制器下顯示不同位置”來代替“放兩個圖示，通過控制器控制顯示哪個”，這樣能加快初始化速度

6. 記憶體洩露常犯

   1. 一個複雜元件（如BonusIcon），它裡面有很多個元素，但是同一時間只顯示一個元素（比如有CommonItemIcon和PetIcon，同一時間只會顯示CommonItemIcon或PetIcon），這時呼叫dispose，不會呼叫不顯示元件的dispose，需要手動呼叫（比如這邊的PetIcon）1. 一個複雜元件（如BonusIcon），它裡面有很多個元素，但是同一時間只顯示一個元素（比如有CommonItemIcon和PetIcon，同一時間只會顯示CommonItemIcon或PetIcon），這時呼叫dispose，不會呼叫不顯示元件的dispose，需要手動呼叫（比如這邊的PetIcon）
   2. Dictionary裡面刪除一項的時候，只調用了delete方法，沒有先取出來dispose
   3. static方法裡面new出來的東西如果沒有管理，就會GCROOT，不能釋放。應該要用物件池等方式來建立物件。
   4. 事件沒移除
   5. fairygui.UIPackage.createObject出來的物件，一定要看一下是否在新增它的元件裡dispose的時候，它會被dispose，不然要手動dispose（這裡有一個特殊情況，剛開始做的時候是有手動呼叫createObject出來物件的dispose，但是由於重構，不要這個createObject出來的物件了，忘記把createObject這行刪掉，但是dispose刪掉了，導致記憶體洩露）
   6. 區分好MVC各模組的職責，Data.ts裡面就好好放data，不要出現顯示物件，因為Data裡面的dispose很暴力，詞典直接dic = null或dic = {}，如果dic是createObject出來的顯示物件，直接導致大片記憶體洩露（h5_hero中的tipItemDic就存在這個問題）。詞典如果是顯示物件，要先取出來dispose，再設空
   7. egret.Timer只調用了移除onTimer事件，但是並沒有stop，導致一直在後臺跑
   8. TipMgr.addTip和TipMgr.removeTip所傳的目標不一致，導致記憶體洩露（遊戲中非常普遍存在）