安卓應(yīng)用內(nèi)存泄漏的定位、分析與解決策略

 什么是內(nèi)存泄漏

對(duì)于不同的語(yǔ)言平臺(tái)來(lái)說(shuō)，進(jìn)行標(biāo)記回收內(nèi)存的算法是不一樣的，像Android(Java)則采用GC-Root的標(biāo)記回收算法。下面這張圖就展示了Android內(nèi)存的回收管理策略(圖來(lái)自Google 2011的IO大會(huì))

圖中的每個(gè)圓節(jié)點(diǎn)代表對(duì)象的內(nèi)存資源，箭頭代表可達(dá)路徑。當(dāng)圓節(jié)點(diǎn)與GC Roots存在可達(dá)路徑時(shí)，表示當(dāng)前資源正被引用，虛擬機(jī)是無(wú)法對(duì)其進(jìn)行回收的(如圖中的黃色節(jié)點(diǎn))。反過(guò)來(lái)，如果圓節(jié)點(diǎn)與GC Roots不存在可達(dá)路徑，則意味著這塊對(duì)象的內(nèi)存資源不再被程序引用，系統(tǒng)虛擬機(jī)可以在GC過(guò)程中將其回收掉。

有了上面的內(nèi)存回收的栗子，那么接下來(lái)就可以說(shuō)說(shuō)什么是內(nèi)存泄漏了。從定義上講，Android(Java)平臺(tái)的內(nèi)存泄漏是指沒(méi)有用的對(duì)象資源任與GC-Root保持可達(dá)路徑，導(dǎo)致系統(tǒng)無(wú)法進(jìn)行回收。舉一個(gè)最簡(jiǎn)單的栗子，我們?cè)贏ctivity的onCreate函數(shù)中注冊(cè)一個(gè)廣播接收者，但是在onDestory函數(shù)中并沒(méi)有執(zhí)行反注冊(cè)，當(dāng)Activity被finish掉時(shí)，Activity對(duì)象已經(jīng)走完了自身的生命周期，應(yīng)該被資源回收釋放掉，但由于沒(méi)有反注冊(cè)，此時(shí)Activity和GC-Root間任然有可達(dá)路徑存在，導(dǎo)致Activity雖然被銷(xiāo)毀，但是所占用的內(nèi)存資源卻無(wú)法被回收掉。類(lèi)似的栗子其實(shí)有很多，不一一例舉了。

泄漏的源頭了解完內(nèi)存泄漏的理論知識(shí)后，再來(lái)歸類(lèi)一下內(nèi)存泄漏的源頭。這里我將其歸位以下三類(lèi)：

自身編碼引起

由項(xiàng)目開(kāi)發(fā)人員自身的編碼造成。

第三方代碼引起

這里的第三方代碼包含兩類(lèi)：第三方非開(kāi)源的SDK和開(kāi)源的第三方框架。

系統(tǒng)原因

由Android系統(tǒng)自身造成的泄漏，如像WebView、InputMethodManager等引起的問(wèn)題，還有某些第三方ROM存在的問(wèn)題。

泄漏的定位

內(nèi)存泄漏不像閃退的BUG，排查起來(lái)相對(duì)要比較困難些，比較極端的情況是當(dāng)你的應(yīng)用OOM了才發(fā)現(xiàn)存在內(nèi)存泄漏問(wèn)題，到了這種情況才去排查處理問(wèn)題的話，對(duì)用戶(hù)的影響就太大了。為此，我們能夠在編碼中盡早發(fā)現(xiàn)到問(wèn)題就不要拖到上線之后才去填坑，下面介紹一些我比較常用排查內(nèi)存泄漏的工具。

靜態(tài)代碼分析工具——Lint

Lint是Android Studio自帶的工具，使用姿勢(shì)很簡(jiǎn)單Analyze -> Inspect Code然后選擇想要掃面的區(qū)域即可

對(duì)可能引起泄漏的編碼，Lint都會(huì)進(jìn)行溫馨提示。

這里只是拋磚引玉的介紹Lint，實(shí)際上玩法還有很多，大家可以自行拓展學(xué)習(xí)。除了Lint外，還有像FindBugs、Checkstyle等靜態(tài)代碼分析工具也是很不錯(cuò)的。

嚴(yán)苛模式——StrictMode

StrictMode是Android系統(tǒng)提供的API，在開(kāi)發(fā)環(huán)境下引入可以更早的暴露發(fā)現(xiàn)問(wèn)題。官方文檔鏈接在下面(需要科學(xué)上網(wǎng))：

https://developer.android.com/reference/android/os/StrictMode.html

以官網(wǎng)的示例代碼為栗子，一般StrictMode只在測(cè)試環(huán)境下啟用，到了生產(chǎn)環(huán)境就會(huì)進(jìn)行關(guān)閉，通常我們都會(huì)借助BuildConfig.DEBUG來(lái)實(shí)現(xiàn)。

啟用StrictMode后，在過(guò)濾日志的地方加上StrictMode的過(guò)濾Tag，如果手機(jī)連接著電腦進(jìn)行開(kāi)發(fā)，定期觀察一下StrictMode這個(gè)Tag下的日志，一般你看到一大堆紅色告警的Log，就需要好好排查一下是否跟內(nèi)存泄漏有關(guān)了。

LeakCanary

Square公司出品的內(nèi)存分析工具，官方地址如下：

https://github.com/square/leakcanary/

LeakCanary和StrictMode一樣，需要在項(xiàng)目代碼中集成，不過(guò)代碼也非常簡(jiǎn)單，如下的官方示例。

build.gradle引入，Application中加入兩三行代碼，即可搞定。以上只是簡(jiǎn)單的引入，還有更多使用姿勢(shì)建議詳細(xì)閱讀它的Wiki下FAQ：

https://github.com/square/leakcanary/wiki/FAQ

我對(duì)使用LeakCanary有以下兩點(diǎn)感受：

當(dāng)內(nèi)存泄漏發(fā)生時(shí)，LeakCanary會(huì)彈窗提示并生成對(duì)應(yīng)的堆存儲(chǔ)信息記錄，這讓我們對(duì)隱蔽的內(nèi)存泄漏問(wèn)題有了更加直觀的感覺(jué)，但從實(shí)際使用來(lái)看，LeakCanary的每個(gè)提示也并非是真正存在內(nèi)存泄漏問(wèn)題，要想確定是否存在問(wèn)題我們還需要借助MAT來(lái)進(jìn)行最后的確定。

Android系統(tǒng)本身就存在一些問(wèn)題導(dǎo)致應(yīng)用內(nèi)存泄漏，LeakCanary的 AndroidExcludedRefs 類(lèi)幫助我們處理了不少這類(lèi)問(wèn)題。

Android Memory Monitor

AndroidStudio提供的工具，用于監(jiān)控應(yīng)用的內(nèi)存使用狀態(tài)，在開(kāi)發(fā)中也是非常實(shí)用的工具，可以用來(lái)打印出內(nèi)存的狀態(tài)信息。

打印獲得的內(nèi)存信息如下，可以通過(guò)右上角的綠色三角形按鈕去分析泄漏的Activity和一些重復(fù)的字符串，目前只支持這兩個(gè)，希望Google后面能夠加入更多可選分析規(guī)則

同樣，這里也只是拋磚引玉的簡(jiǎn)單介紹，關(guān)于它的使用在官方文檔已經(jīng)說(shuō)得很詳細(xì)了，需要的童鞋自行查看下方鏈接(需科學(xué)上網(wǎng))：

https://developer.android.com/studio/profile/am-hprof.html

Memory Analyzer (MAT)

老牌子分析工具，可以從 http://www.eclipse.org/mat/ 下載獲得，網(wǎng)上關(guān)于MAT使用的文章好多，大家可以自行查找。上面的Android Memory Monitor生成的對(duì)儲(chǔ)存信息文件可以配置MAT一起來(lái)分析使用，由于Android Memory Monitor生成的hprof文件不是標(biāo)準(zhǔn)格式，所以需要做一下轉(zhuǎn)換，然后導(dǎo)入MAT

然后通過(guò)OQL先定位出泄漏的對(duì)象

通過(guò)排除除了強(qiáng)引用之外的其他引用鏈，最后分析到GC Root的位置

MAT使用起來(lái)相對(duì)繁瑣，但不失為定位根源問(wèn)題的利器。

adb shell命令

使用adb shell dumpsys meminfo [PackageName]，可以打印出指定包名的應(yīng)用內(nèi)存信息

使用該命令可以很直觀的觀察到Activity的泄漏問(wèn)題，是我平常分析比較常用的一種方式。除了使用命令外，AndroidStudio也提供了下面的功能，和使用命令是一樣效果的。

如果對(duì)adb shell命令感興趣，更多的信息可以看下面提供的資源：

http://adbshell.com/

https://github.com/mzlogin/awesome-adb

以上就是我在做內(nèi)存泄漏分析的時(shí)候會(huì)用到的工具，通常都是結(jié)合起來(lái)用，畢竟每個(gè)工具都有優(yōu)缺點(diǎn)，通過(guò)使用多個(gè)工具互補(bǔ)分析問(wèn)題可以極大的提高我們的效率和最終取得的效果。

泄漏的解決策

略聊完工具，最后來(lái)談?wù)剝?nèi)存泄漏問(wèn)題的解決策略。我把它總結(jié)為以下三點(diǎn)：

完成需求功能開(kāi)發(fā)后，再去優(yōu)化內(nèi)存泄漏問(wèn)題;

泄漏源有多處時(shí)，核心功能產(chǎn)生的泄漏優(yōu)先處理，用戶(hù)使用頻繁的功能引起的泄漏優(yōu)先處理;

處理泄漏避免影響原有的代碼邏輯，優(yōu)化過(guò)后最好能夠讓測(cè)試童鞋過(guò)一遍相關(guān)的功能，避免引入未知的BUG;

總結(jié)

對(duì)于如何在編碼上去解決內(nèi)存泄漏問(wèn)題，網(wǎng)絡(luò)上有提供了很多場(chǎng)景及其解決方案，大家可以自行借助搜索引擎。通過(guò)掌握分析方法和對(duì)泄漏場(chǎng)景及其解決方案的積累，相信大家處理內(nèi)存泄漏問(wèn)題是游刃有余的。當(dāng)然，也并不是所有內(nèi)存泄漏問(wèn)題我們都能夠進(jìn)行處理，就例如第二章節(jié)提到的泄漏源頭是由第三方代碼引起時(shí)，我們就顯得無(wú)能為力了。最近在排查的過(guò)程中就發(fā)現(xiàn)不少第三方SDK存在泄漏問(wèn)題，遇上這種情況就得找找可替代的SDK進(jìn)行更換了。以上就是我做內(nèi)存泄漏分析的一些心得總結(jié)，如果有錯(cuò)誤和不足，還請(qǐng)大家指出。