性能優化之記憶體洩露

動腦學院 Ricky老師 2017年11月27日錄制

什麼是記憶體洩露？

記憶體不在GC的掌控之内了。

• 了解幾個問題
  • 垃圾回收機制 GC
    • 某對象不再有任何的引用才會進行回收。
  • GC回收機制的原理
    • GC Root，可以作為GC Root引用點的是
      • JavaStack中的引用對象
      • 方法區中靜态引用指向的對象
      • 方法區中常量引用指向的對象
      • Native方法中JNI引用的對象
      • Thread–活着的線程
  • 怎麼判斷一個對象是垃圾對象？
    • 這是一個主觀的判斷
    • 記憶體洩露多了容易導緻OOM–記憶體溢出，app會崩潰

确定我們的項目當中或者某幾個類中是否存在記憶體洩露

同屏工具：Total Control

初略判斷：

Android Monitor–>System Information–>MemoryUsage檢視Objects裡面是否有沒有釋放的Views或者Activities

指令行：adb shell dumpsys meminfo 包名 -d

确定記憶體洩露的大緻範圍

• Android Studio：檢視Memory Monitor工具
  • 檢查一個一個動作（比如Activity的跳轉）反複多次執行某一個操作，不斷地通過這個工具檢視記憶體的大概變化情況。前後兩個記憶體變化增加了不少。

更仔細地查找洩露的位置

* 在As中使用 Heap SnapShot工具（堆棧快照）
           

問題出現在：

解決：

instance = new CommUtils(mContext.getApplicationContext());//可以傳這個

不使用Activity是下文，而是使用Application的上下文，因為Application的生命周期長，程序退出的時候才會銷毀，和Static的CommUtils的生命周期一樣長。

使用更進階的分析工具來更具體地找到這個洩露的家夥。

LeakCanary 有些使用會不靠譜 ==

MAT工具。需要下載下傳 MemoryAnalyzer

兩個步驟的快照對比。

右鍵 list objects -out（引用了誰|incoming(被誰引用

incoming-右鍵-Merge Shortest Paths to GC Roots–exclude all phatom/weak/soft etc….

對比之後就出現了

第二個Activty的引用：

第一個Activty的引用：系統的輸入法的引用

小結工具：

• Allocation Tracker
• Heap Snapshot
• Heap View
• LeakCanary
• MAT
• TraceView