[[199971]]

 序

OOM(Out of Memory)是 Android 開發(fā)繞不過去的坎，一定會遇到。但是很多時(shí)候，報(bào)錯(cuò)的地方都并不是發(fā)生問題的原因，只是壓死駱駝的***一根稻草。

解決 OOM ，涉及到的東西太多了，從原理、分析工具、解決辦法很多個(gè)方向，所以準(zhǔn)備做一個(gè)專門解決 OOM 需要用到的知識，集合成一個(gè)系列來發(fā)布。

就叫它《吊打 OOM》吧，準(zhǔn)備慢慢寫好好寫，希望完結(jié)之后，不懼 OOM。

一、前言

OOM(Out of Memory) 大部分原因來自內(nèi)存泄露，如果有內(nèi)存泄露導(dǎo)致系統(tǒng) GC 無法將無用資源回收，就可能導(dǎo)致下次申請內(nèi)存空間的時(shí)候，出現(xiàn) OOM 的錯(cuò)誤。

其實(shí) Android Studio(以下簡稱 AS)已經(jīng)自帶了一些內(nèi)存泄露的檢查。但是它的功能有限，暫時(shí)只能對 Activity 發(fā)生的內(nèi)存泄露進(jìn)行檢查。

下面來了解如何使用 AS 分析 Activity 的內(nèi)存泄露。

二、Android Monitor

一般用來做內(nèi)存泄露的檢測，會推薦使用 LeakCannary ，它是 Square 提供的一個(gè)檢測內(nèi)存泄露的開源庫，集成也非常的簡單。

有興趣的可以去 Github 上看它的文檔集成使用。

https://github.com/square/leakcanary

不過大多數(shù)情況下，我們可能不會去使用 LeakCanary ，畢竟它還是需要集成在項(xiàng)目中。而如果只是為了檢測一下是否有 Activity 的內(nèi)存泄露情況，其實(shí) AS 中已經(jīng)提供了檢測的工具。

AS 本身也為我們提供了非常方便的 Android Monitor 工具，來幫我們監(jiān)聽當(dāng)前 Debug 情況下，App 運(yùn)行的情況，其中就包括 Memory 的監(jiān)控。

Memory 窗口可以完全監(jiān)聽當(dāng)前正在 Debug 的 App 的內(nèi)存使用情況。如果在正常操作的時(shí)候，看到此處的內(nèi)存一直在飆高，卻沒有降低的跡象，你的 App 就可能存在內(nèi)存泄露的問題。

先來簡單介紹一下 Memory 面板，如圖中標(biāo)記的區(qū)域。

1、當(dāng)前監(jiān)控的終端設(shè)備和進(jìn)程。

2、被檢測的設(shè)備的內(nèi)存分配情況。

Allocated：已經(jīng)被使用的空間。

Free : 當(dāng)前剩余的空間。

3、Memroy 分析的工具欄，包含一些內(nèi)存分析相關(guān)的操作。

分析內(nèi)存的工具欄，從左到右依次的作用是：

1. Enable：終止檢測。
2. Initiate GC ：手動觸發(fā) GC。
3. Jump java heap：獲取 hprof 分析文件。
4. Start Allocation Tracking： 開始分配追蹤。
5. Memory monitor help：查看幫助文檔。

特別提一下，內(nèi)存分配情況只是標(biāo)識當(dāng)前的內(nèi)存使用情況，如果還需要繼續(xù)使用內(nèi)存，是可以繼續(xù)申請的，直到超過了 Dalvik Heap 分配的***內(nèi)存數(shù)，就會觸發(fā) OOM。

今天介紹的方法，主要會使用到『獲取 hprof 分析文件的方法』，去獲取一個(gè) hprof 文件進(jìn)行分析，AS 使用這種方式生成的 hprof 文件，并非標(biāo)準(zhǔn)的 hprof 文件，是專門為 AS 分析使用的，所以如果想要交給 MAT 進(jìn)行分析，還需要使用 hprof-conv 命令進(jìn)行轉(zhuǎn)換一下。這不是本文的重點(diǎn)，本文介紹的方式只需要使用 AS 進(jìn)行分析即可。

點(diǎn)擊『Jump java heap』按鈕之后，會自動生成當(dāng)前設(shè)備當(dāng)前進(jìn)行的內(nèi)存使用報(bào)告，我們就在此基礎(chǔ)上進(jìn)行分析。

生成的時(shí)間完全視情況而定，可能受當(dāng)前使用的內(nèi)存大小和當(dāng)前使用的設(shè)備配置決定。最終會生成一個(gè) .hprof 的文件，文件的命名摻雜了包名和日期時(shí)間，能幫我們很好的區(qū)分它們。

生成的 .hprof 文件，會自動將其保存在項(xiàng)目的 captures 目錄下，同時(shí)也可以使用Captures 窗口查看。

在 hprof 的文件分析窗口中，右邊會有一個(gè) Analyzer Tasks 子窗口，它就是本文的主角，用來分析 Activity 內(nèi)存泄露的。

默認(rèn)情況如上圖，點(diǎn)擊右上角的『Perform Analysis』按鈕，即可開始分析。

它主要是用來檢測泄露的 Activity 和 重復(fù)的 Strings 字符串。重復(fù)的 String 檢測，基本上處于無用的狀態(tài)，沒什么實(shí)際用處，新建一個(gè) App ，運(yùn)行起來，它就是會有很多重復(fù)的 String ，占用的空間也不大，基本上也無需我們太過關(guān)心。

點(diǎn)擊『Perform Analysis』按鈕，開始嘗試檢測。

這里主要是使用 Detect Leaked Activitys 的功能，但是我們這是一個(gè)空項(xiàng)目，所以也沒有什么關(guān)于 Activity 內(nèi)存泄露的問題。

三、Detect Leaked Activitys

既然沒有內(nèi)存泄露的情況，那我們就手動的造一個(gè) Activity 的內(nèi)存泄露的情況。

我們知道，對于 Activity 而言，如果有內(nèi)部類，可能會引發(fā)內(nèi)存泄露，下面就是這樣一個(gè)會引發(fā)內(nèi)存泄露的的例子。

上面創(chuàng)建了一個(gè)內(nèi)部類，并且在 Activity 中，使用一個(gè) static 的 變量去持有它，它不會在 Activity onFinish() 的時(shí)候被回收掉，而是一直處于內(nèi)存中，就會引發(fā)內(nèi)存泄露。

現(xiàn)在，我們打開 ChildActivity 然后關(guān)閉它，點(diǎn)擊 『Jump Java Heap』按鈕生成內(nèi)存的 hprof 文件。

再繼續(xù)使用『Perform Analysis』進(jìn)行 Activitys 的泄露檢測。

可以看到，這里已經(jīng)能檢測出來 ChildActivity 存在內(nèi)存泄露的問題了。

再進(jìn)行點(diǎn)擊可以查看到更信息的情況，來看個(gè)完整的效果。

在 Referebce Tree 中，就可以清晰的看到，是 MemoryLeak 對象，造成的內(nèi)存泄露。

檢測到 Activity 的內(nèi)存泄露問題，我們只需要修復(fù)它就可以了。一些常規(guī)的編碼習(xí)慣(Activity 中的內(nèi)部類，推薦 static 化)，確實(shí)是可以避免掉這些問題。

【本文為51CTO專欄作者“張旸”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號聯(lián)系作者獲取授權(quán)】

戳這里，看該作者更多好文