Android開發中常見的內存泄漏的現象：舉栗子
現象一：連續多次打開應用之後，界面卡頓，動畫不流暢
現象二：操作過程中，LogCat頻繁輸出GC日誌：
垃圾回收的現象：
垃圾回收之後
初步推斷：頻繁的打印GC日誌，說明系統頻繁觸發GC來釋放內存，初步判斷可能存在內存泄漏
輔助驗證工具：DDMS（設備的截圖、虛擬地理位置、針對特定的進程查看對應的信息）
使用：
第一步：選中需要測試的進程
第二步、點擊upHeap按鈕，DDM通知應用，告訴他我可能要收集內存信息了！（準備）
第三步、點擊Heap標籤，展示應用的內存信息
第四步、點擊Cause GC，DDMS應用的內存信息，log出來
查看信息：
連續打開應用，觀察Total Size變化，驗證是否有內存泄露
反覆打開應用，觀察Total Size變化
Total Size 隨着打開次數的增加逐步增大，確實存在內存泄漏
內存泄露的原因：
MAT工具：主要能夠分析內存中的狀態以及所使用的內存的大小
MAT分析的過程：
思路：分析內存中佔用比較大的對象
工具：Dominator Tree:能夠列出所有對象，以及他們佔用的內存大小
Dominator Tree截圖
篩選之後的截圖
最後查找的原因：
驗證分析是否正確：
思路：查看內存中是否存在多個有Tread持有，導致無法回收的activtiy 實例
方法：Histogram:列出內存中所有的類，以及每個類的實例個數
內存中11個無法回收的Activity實例，由此判斷，這裏存在內存泄露
找到對應的代碼：
根據代碼分析：其內存泄露的根本原因：長生命週期對象（Tread）持有短生命週期對象（Activity）的引用，而導致的內存泄露
解決方案：
方案一：將Tread移到後臺服務，使Tread和Activity解除依賴關係
舉栗子：Tread功能和activity聯繫不是很緊密的時候：緩存數據的Tread
方案二：Activity退出時，停止Tread，使Tread與Activity的生命週期保持一致
更多案例：
構造Adapter時，沒有使用緩存converView
正確寫法：
不當的使用Context
總結：
