Hello，大家好，我是Clock。翻了一下簡書，發現有一個多月沒有更新部落格，本來今天打算和妹紙去電影院看《你的名字》，然後再去到處浪的。
結果因為妹紙公司臨時有事，她不得不回公司一趟... 然後我也只能宅家裡了，既然妹紙不在家，剛好最近一直在為專案做記憶體洩漏的優化工作，那就來寫一點個人總結好了。
什麼是記憶體洩漏
對於不同的語言平臺來說，進行標記回收記憶體的演算法是不一樣的，像 Android（Java）則採用 GC-Root 的標記回收演算法。下面這張圖就展示了 Android 記憶體的回收管理策略（圖來自Google 2011的IO大會）
圖中的每個圓節點代表物件的記憶體資源，箭頭代表可達路徑。當圓節點與 GC Roots 存在可達路徑時，表示當前資源正被引用，虛擬機器是無法對其進行回收的（如圖中的黃色節點）。反過來，如果圓節點與 GC Roots 不存在可達路徑，則意味著這塊物件的記憶體資源不再被程式引用，系統虛擬機器可以在 GC 過程中將其回收掉。
有了上面的記憶體回收的栗子，那麼接下來就可以說說什麼是記憶體洩漏了。從定義上講，Android（Java）平臺的記憶體洩漏是指沒有用的物件資源任與GC-Root保持可達路徑，導致系統無法進行回收。舉一個最簡單的栗子，我們在 Activity 的 onCreate 函式中註冊一個廣播接收者，但是在 onDestory 函式中並沒有執行反註冊，當 Activity 被 finish 掉時，Activity 物件已經走完了自身的生命週期，應該被資源回收釋放掉，但由於沒有反註冊， 此時 Activity 和 GC-Root 間任然有可達路徑存在，導致 Activity 雖然被銷燬，但是所佔用的記憶體資源卻無法被回收掉。類似的栗子其實有很多，不一一例舉了。對於 Android（Java）記憶體回收管理想要再深入瞭解的童鞋，可以看看下面資源：
洩漏的源頭
瞭解完記憶體洩漏的理論知識後，再來歸類一下記憶體洩漏的源頭。這裡我將其歸位以下三類：
- 自身編碼引起
由專案開發人員自身的編碼造成。
- 第三方程式碼引起
這裡的第三方程式碼包含兩類：第三方非開源的SDK和開源的第三方框架。
- 系統原因
由 Android 系統自身造成的洩漏，如像 WebView 、 InputMethodManager 等引起的問題，還有某些第三方 ROM 存在的問題。
洩漏的定位
記憶體洩漏不像閃退的BUG，排查起來相對要比較困難些，比較極端的情況是當你的應用 OOM 了才發現存在記憶體洩漏問題，到了這種情況才去排查處理問題的話，對使用者的影響就太大了。為此，我們能夠在編碼中儘早發現到問題就不要拖到上線之後才去填坑，下面介紹一些我比較常用排查記憶體洩漏的工具。
- 靜態程式碼分析工具 —— Lint
Lint 是 Android Studio 自帶的工具，使用姿勢很簡單 Analyze -> Inspect Code 然後選擇想要掃面的區域即可
對可能引起洩漏的編碼，Lint 都會進行溫馨提示。
這裡只是拋磚引玉的介紹 Lint ，實際上玩法還有很多，大家可以自行擴充學習。除了 Lint 外，還有像 FindBugs 、 Checkstyle 等靜態程式碼分析工具也是很不錯的。
- 嚴苛模式 —— StrictMode
StrictMode 是 Android 系統提供的 API ，在開發環境下引入可以更早的暴露發現問題。官方文件連結在下面（需要科學上網）：
以官網的示例程式碼為栗子，一般 StrictMode 只在測試環境下啟用，到了生產環境就會進行關閉，通常我們都會藉助 BuildConfig.DEBUG 來實現。
啟用 StrictMode 後，在過濾日誌的地方加上 StrictMode 的過濾 Tag ，如果手機連線著電腦進行開發，定期觀察一下 StrictMode 這個 Tag 下的日誌，一般你看到一大堆紅色告警的 Log，就需要好好排查一下是否跟記憶體洩漏有關了。
- LeakCanary
Square 公司出品的記憶體分析工具，官方地址如下：
LeakCanary 和 StrictMode 一樣，需要在專案程式碼中整合，不過程式碼也非常簡單，如下的官方示例。
build.gradle 引入，Application 中加入兩三行程式碼，即可搞定。以上只是簡單的引入，還有更多使用姿勢建議詳細閱讀它的 Wiki 下 FAQ：
我對使用 LeakCanary 有以下兩點感受：
- 當記憶體洩漏發生時，LeakCanary 會彈窗提示並生成對應的堆儲存資訊記錄，這讓我們對隱蔽的記憶體洩漏問題有了更加直觀的感覺，但從實際使用來看，LeakCanary 的每個提示也並非是真正存在記憶體洩漏問題，要想確定是否存在問題我們還需要藉助 MAT 來進行最後的確定。
- Android 系統本身就存在一些問題導致應用記憶體洩漏，LeakCanary 的 AndroidExcludedRefs 類幫助我們處理了不少這類問題。
- Android Memory Monitor
AndroidStudio 提供的工具，用於監控應用的記憶體使用狀態，在開發中也是非常實用的工具，可以用來列印出記憶體的狀態資訊。
列印獲得的記憶體資訊如下，可以通過右上角的綠色三角形按鈕去分析洩漏的 Activity 和 一些重複的字串，目前只支援這兩個，希望 Google 後面能夠加入更多可選分析規則
同樣，這裡也只是拋磚引玉的簡單介紹，關於它的使用在官方文件已經說得很詳細了，需要的童鞋自行檢視下方連結（需科學上網）：
- Memory Analyzer (MAT)
老牌子分析工具，可以從 www.eclipse.org/mat/ 下載獲得，網上關於 MAT 使用的文章好多，大家可以自行查詢。上面的 Android Memory Monitor 生成的對儲存資訊檔案可以配置 MAT 一起來分析使用，由於 Android Memory Monitor 生成的 hprof 檔案不是標準格式，所以需要做一下轉換，然後匯入 MAT
然後通過 OQL 先定位出洩漏的物件
通過排除除了強引用之外的其他引用鏈，最後分析到 GC Root 的位置
MAT 使用起來相對繁瑣，但不失為定位根源問題的利器。
- adb shell 命令
使用 adb shell dumpsys meminfo [PackageName]，可以列印出指定包名的應用記憶體資訊
使用該命令可以很直觀的觀察到 Activity 的洩漏問題，是我平常分析比較常用的一種方式。除了使用命令外，AndroidStudio 也提供了下面的功能，和使用命令是一樣效果的。
如果對 adb shell 命令感興趣，更多的資訊可以看下面提供的資源：
以上就是我在做記憶體洩漏分析的時候會用到的工具，通常都是結合起來用，畢竟每個工具都有優缺點，通過使用多個工具互補分析問題可以極大的提高我們的效率和最終取得的效果。
洩漏的解決策略
聊完工具，最後來談談記憶體洩漏問題的解決策略。我把它總結為以下三點：
- 完成需求功能開發後，再去優化記憶體洩漏問題；
- 洩漏源有多處時，核心功能產生的洩漏優先處理，使用者使用頻繁的功能引起的洩漏優先處理；
- 處理洩漏避免影響原有的程式碼邏輯，優化過後最好能夠讓測試童鞋過一遍相關的功能，避免引入未知的BUG；
總結
對於如何在編碼上去解決記憶體洩漏問題，網路上有提供了很多場景及其解決方案，大家可以自行藉助搜尋引擎。通過掌握分析方法和對洩漏場景及其解決方案的積累，相信大家處理記憶體洩漏問題是遊刃有餘的。當然，也並不是所有記憶體洩漏問題我們都能夠進行處理，就例如第二章節提到的洩漏源頭是由第三方程式碼引起時，我們就顯得無能為力了。最近在排查的過程中就發現不少第三方 SDK 存在洩漏問題，遇上這種情況就得找找可替代的 SDK 進行更換了。以上就是我做記憶體洩漏分析的一些心得總結，如果有錯誤和不足，還請大家指出。
更多文章，歡迎檢視我的簡書：