題記：這是補一篇應該在將近一年前就應該寫的記錄，今天終於補上。
記憶體洩露是乙個老話題了，之前我專門寫過一篇 排查 lua 虛擬機器記憶體洩露 的文章，並且附帶了乙個工具來查詢 lua 中具體的記憶體洩露。但是這只是整個 unity 專案中記憶體洩漏的一小部分，c# **中一般記憶體洩露可能會更加嚴重。
ptr - 記憶體位址
type - 資料型別
size - 記憶體大小
stack - 該記憶體被分配時的呼叫堆疊
reference - 被引用的位址，如果這裡有多個，就是被多個其它的位址引用了
type來歸類，將同型別的size相加，最後生成乙個檔案，裡面兩列：型別和大小。然後用 excel 開啟並按照大小降序排列，便可以直接看到那些新增的記憶體，根據專案情況分析新增部分從型別和大小兩個角度來講是否應該出現就立即分析出潛在的洩露，然後把洩露的型別拿到原始的快照(第二次主城快照)中去搜尋，然後檢視該型別到底被什麼地方引用，一直追溯下去，便能找到最終的引用點，說明是因為「它」的引用才造成洩露。
接下來的事情就是去專案中實際分析**，檢視建立和釋放的地方是否有紕漏，需要比較耐心的去專案**中查詢和分析，其實這都是苦活，髒活兒，要的都是耐心，你需要從成千上萬條資料中揪出可能的洩露。
後來做完這次優化，我再次感受到，出現這些洩露的原因歸根結底還是**不夠規範引起的，不注重必要的初始化和釋放成對呼叫等，大致總結起來有以下幾點：
總結起來很簡單，這次優化就大致發現這幾條，但是都不經意間，日積月累，引起了比較嚴重的問題，所以不要小看**規範，和框架的遵守。
下面是專案優化前後的記憶體走勢，總時長相同。
以上可以看出，經過一輪粗獷優化後記憶體依然保持小幅的總體增長，但是比優化前的總體大小已經大幅降低，並且漲幅也更加平緩。接下來可能會需要更大的精力和更多的手段去查詢剩下的「一點點」記憶體洩露。
Unity專案中的資源管理
貼圖資源配置 對於這資源管理，unity提供非常豐厚的支援。以貼圖為例子，unity支援直接把原始貼圖直接放進工程，不需要做任何額外處理。unity根據貼圖配置會自動生成最後的貼圖資料。不同平台 ios android pc 支援的貼圖格式不一樣，通過配置檔案的形式，最後方便的生成不同格式的貼圖。這...
專案中 關於AlertDialog的顯示
因為很多頁面要用到這個打 的dialog，所以做成乙個utils，直接呼叫。public static void showfindaitdialog final context context yesbutton.setonclicklistener new onclicklistener log ...
Unity 之 專案中如何坑害你的同事
維護根本不存在的，讓他們知道你就這個專案的上帝，你寫的不是 你寫的是密碼！加密性很高的密碼！只要你離開，專案就會分崩離析，而且你也是遊走在崩潰的邊緣，就是這麼6，玩的就是心跳 我們宗旨是 前人挖坑，後人埋雷，最後乙個被炸飛！1.預製體名稱字尾加空格 載入的時候明明和預製體名稱一致但是無法找到，是不是...