1、內(nèi)存泄漏的定義

Android是基于Java的，眾所周知Java語(yǔ)言的內(nèi)存管理是其一大特點(diǎn)，不用像C語(yǔ)言那樣處理對(duì)象的內(nèi)存分配到回收的全部過(guò)程。在Java中我們只需要簡(jiǎn)單地新建對(duì)象就可以了，Java垃圾回收器會(huì)負(fù)責(zé)回收釋放對(duì)象內(nèi)存。這么看的話，垃圾回收器會(huì)管理內(nèi)存又怎么還會(huì)發(fā)生內(nèi)存泄漏呢?

其實(shí)Java中的內(nèi)存泄漏的定義是：對(duì)象不再被程序所使用，但是由于這些對(duì)象被引用著導(dǎo)致GC(GarbageCollector)不能回收它們。

下面這張圖可以幫助我們更好地理解對(duì)象的狀態(tài)，以及內(nèi)存泄漏的情況

左邊未引用的對(duì)象是會(huì)被GC回收的，右邊被引用的對(duì)象不會(huì)被GC回收，但是未使用的對(duì)象中除了未引用的對(duì)象，還包括已被引用的一部分對(duì)象，那么內(nèi)存泄漏久發(fā)生這部分已被引用但未使用的對(duì)象。

接下來(lái)還有一個(gè)疑問(wèn)：未使用的對(duì)象被誰(shuí)引用會(huì)讓GC無(wú)法回收呢?

現(xiàn)在主流的程序語(yǔ)言的主流實(shí)現(xiàn)中，是通過(guò)可達(dá)性分析(ReachabilityAnalysis)來(lái)判斷對(duì)象是否存活的。這個(gè)算法的基本思路是：通過(guò)一系列的稱為“GCRoots”的對(duì)象作為起點(diǎn)，從這些節(jié)點(diǎn)開(kāi)始向下搜索，搜索所走過(guò)的路徑稱為引用鏈，當(dāng)一個(gè)對(duì)象到GCRoots沒(méi)有任何引用鏈時(shí)，說(shuō)明此對(duì)象不可用，可以被回收了。

可以作為GCRoots的對(duì)象包括下面幾種：

·虛擬機(jī)棧中引用的對(duì)象，一般是當(dāng)前在使用中局部變量

·方法區(qū)中類靜態(tài)屬性引用的對(duì)象，就是靜態(tài)變量對(duì)應(yīng)的對(duì)象

·方法區(qū)中常量引用的對(duì)象

·本地方法棧中JNI(即一般說(shuō)的NaTIve方法)引用的對(duì)象

MAT分析內(nèi)存泄漏的時(shí)候，也是查看對(duì)象到GCRoots的引用鏈，來(lái)定位泄漏代碼的位置。

所以未使用的對(duì)象直接或間接地被GCRoots引用時(shí)會(huì)讓GC無(wú)法回收，從而產(chǎn)生內(nèi)存泄漏。

2、Android的內(nèi)存管理

了解了Java的內(nèi)存泄漏的起因，接下來(lái)大致了解Android中的內(nèi)存管理機(jī)制。

Google在Android的官網(wǎng)上有這樣一篇文章，初步介紹了Android是如何管理應(yīng)用的進(jìn)程與內(nèi)存分配：http://developer.android.com/training/arTIcles/memory.html。Android系統(tǒng)的Dalvik虛擬機(jī)扮演了常規(guī)的內(nèi)存垃圾自動(dòng)回收的角色，Android系統(tǒng)沒(méi)有為內(nèi)存提供交換區(qū)，它使用paging與memory-mapping(mmapping)的機(jī)制來(lái)管理內(nèi)存，下面簡(jiǎn)要概述一些Android系統(tǒng)中重要的內(nèi)存管理基礎(chǔ)概念。

分配與回收內(nèi)存

每一個(gè)進(jìn)程的Dalvikheap都反映了使用內(nèi)存的占用范圍。這就是通常邏輯意義上提到的DalvikHeapSize，它可以隨著需要進(jìn)行增長(zhǎng)，但是增長(zhǎng)行為會(huì)有一個(gè)系統(tǒng)為它設(shè)定的上限。

邏輯上講的HeapSize和實(shí)際物理意義上使用的內(nèi)存大小是不對(duì)等的，ProporTIonalSetSize(PSS)記錄了應(yīng)用程序自身占用以及和其他進(jìn)程進(jìn)行共享的內(nèi)存。

Android系統(tǒng)并不會(huì)對(duì)Heap中空閑內(nèi)存區(qū)域做碎片整理。系統(tǒng)僅僅會(huì)在新的內(nèi)存分配之前判斷Heap的尾端剩余空間是否足夠，如果空間不夠會(huì)觸發(fā)gc操作，從而騰出更多空閑的內(nèi)存空間。在Android的高級(jí)系統(tǒng)版本里面針對(duì)Heap空間有一個(gè)GeneraTIonalHeapMemory的模型，最近分配的對(duì)象會(huì)存放在YoungGeneration區(qū)域，當(dāng)這個(gè)對(duì)象在這個(gè)區(qū)域停留的時(shí)間達(dá)到一定程度，它會(huì)被移動(dòng)到OldGeneration，最后累積一定時(shí)間再移動(dòng)到PermanentGeneration區(qū)域。系統(tǒng)會(huì)根據(jù)內(nèi)存中不同的內(nèi)存數(shù)據(jù)類型分別執(zhí)行不同的gc操作。例如，剛分配到Y(jié)oungGeneration區(qū)域的對(duì)象通常更容易被銷毀回收，同時(shí)在YoungGeneration區(qū)域的gc操作速度會(huì)比OldGeneration區(qū)域的gc操作速度更快。如下圖所示：

每一個(gè)Generation的內(nèi)存區(qū)域都有固定的大小，隨著新的對(duì)象陸續(xù)被分配到此區(qū)域，當(dāng)這些對(duì)象總的大小快達(dá)到這一級(jí)別內(nèi)存區(qū)域的閥值時(shí)，會(huì)觸發(fā)GC的操作，以便騰出空間來(lái)存放其他新的對(duì)象。

通常情況下，GC發(fā)生的時(shí)候，所有的線程都是會(huì)被暫停的。執(zhí)行GC所占用的時(shí)間和它發(fā)生在哪一個(gè)Generation也有關(guān)系，Young Generation中的每次GC操作時(shí)間是最短的，Old Generation其次，Permanent Generation最長(zhǎng)。執(zhí)行時(shí)間的長(zhǎng)短也和當(dāng)前Generation中的對(duì)象數(shù)量有關(guān)，遍歷樹(shù)結(jié)構(gòu)查找20000個(gè)對(duì)象比起遍歷50個(gè)對(duì)象自然是要慢很多的。

為什么通常情況下，GC發(fā)生的時(shí)候，所有的線程都會(huì)被暫停?

因?yàn)槊看蜧C的時(shí)候，需要先找到可作為GC Roots的對(duì)象，然后以此搜索引用鏈，這個(gè)過(guò)程需要在一致性的內(nèi)存快照中進(jìn)行。這個(gè)“一致性”表示在整個(gè)過(guò)程中不能出現(xiàn)對(duì)象引用關(guān)系不斷變化的情況，所以需要暫停所有的執(zhí)行線程。

限制應(yīng)用的內(nèi)存

為了整個(gè)Android系統(tǒng)的內(nèi)存控制需要，Android系統(tǒng)為每一個(gè)應(yīng)用程序都設(shè)置了一個(gè)硬性的Dalvik Heap Size最大限制閾值，這個(gè)閾值在不同的設(shè)備上會(huì)因?yàn)镽AM大小不同而各有差異。如果你的應(yīng)用占用內(nèi)存空間已經(jīng)接近這個(gè)閾值，此時(shí)再嘗試分配內(nèi)存的話，很容易引起OutOfMemoryError的錯(cuò)誤。

ActivityManager.getMemoryClass()可以用來(lái)查詢當(dāng)前應(yīng)用的Heap Size閾值，這個(gè)方法會(huì)返回一個(gè)整數(shù)，表明你的應(yīng)用的Heap Size閾值是多少M(fèi)b(megabates)。

還有一個(gè)用adb命令查詢的方法：

adb shell getprop dalvik.vm.heapgrowthlimit

3、案例

JOOX是IBG一個(gè)核心產(chǎn)品，2014年發(fā)布以來(lái)已經(jīng)成為5個(gè)國(guó)家和地區(qū)排名第一的音樂(lè)App。東南亞是JOOX的主要發(fā)行地區(qū)，實(shí)際上這些地區(qū)還是有很多的低端機(jī)型，對(duì)App的進(jìn)行內(nèi)存優(yōu)化勢(shì)在必行。

上面介紹了Android系統(tǒng)內(nèi)存分配和回收機(jī)制，同時(shí)也列舉了常見(jiàn)的內(nèi)存問(wèn)題，但是當(dāng)我們接到一個(gè)內(nèi)存優(yōu)化的任務(wù)時(shí)，我們應(yīng)該從何開(kāi)始?下面是一次內(nèi)存優(yōu)化的分享。

1. 首先是解決大部分內(nèi)存泄露。

不管目前App內(nèi)存占用怎樣，理論上不需要的東西最好回收，避免浪費(fèi)用戶內(nèi)存，減少OOM。實(shí)際上自JOOX接入LeakCanary后，每個(gè)版本都會(huì)做內(nèi)存泄露檢測(cè)，經(jīng)過(guò)幾個(gè)版本的迭代，JOOX已經(jīng)修復(fù)了幾十處內(nèi)存泄露。

2. 通過(guò)MAT查看內(nèi)存占用，優(yōu)化占用內(nèi)存較大的地方。

JOOX修復(fù)了一系列內(nèi)存泄露后，內(nèi)存占用還是居高不下，只能通過(guò)MAT查看到底是哪里占用了內(nèi)存。關(guān)于MAT的使用，網(wǎng)上教程無(wú)數(shù)，簡(jiǎn)單推薦兩篇MAT使用教程，MAT - Memory Analyzer Tool 使用進(jìn)階。

點(diǎn)擊Android Studio這里可以dump當(dāng)前的內(nèi)存快照，因?yàn)橹苯油ㄟ^(guò)Android Sutdio dump出來(lái)的hprof文件與標(biāo)準(zhǔn)hprof文件有些差異，我們需要手動(dòng)進(jìn)行轉(zhuǎn)換，利用sdk目錄/platform-tools/hprof-conv.exe可以直接進(jìn)行轉(zhuǎn)換，用法：hprof-conv 原文件.hprof 新文件.hprof。只需要輸入原文件名還有目標(biāo)文件名就可以進(jìn)行轉(zhuǎn)換，轉(zhuǎn)換完就可以直接用MAT打開(kāi)。

下面就是JOOX打開(kāi)App，手動(dòng)進(jìn)行多次gc的hprof文件。

這里我們看的是Dominator Tree(即內(nèi)存里占用內(nèi)存最多的對(duì)象列表)。

Shallo Heap：對(duì)象本身占用內(nèi)存的大小，不包含其引用的對(duì)象內(nèi)存。

Retained Heap： Retained heap值的計(jì)算方式是將retained set中的所有對(duì)象大小疊加?；蛘哒f(shuō)，由于X被釋放，導(dǎo)致其它所有被釋放對(duì)象(包括被遞歸釋放的)所占的heap大小。

第一眼看去 居然有3個(gè)8M的對(duì)象，加起來(lái)就是24M啊 這到底是什么鬼?

我們通過(guò)List objects-》with incoming references查看(這里with incoming references表示查看誰(shuí)引用了這個(gè)對(duì)象，with outgoing references表示這個(gè)對(duì)象引用了誰(shuí))

通過(guò)這個(gè)方式我們看到這三張圖分別是閃屏，App主背景，App抽屜背景。

這里其實(shí)有兩個(gè)問(wèn)題：

這幾張圖原圖實(shí)際都是1280x720，而在1080p手機(jī)上實(shí)測(cè)這幾張圖都縮放到了1920x1080

閃屏頁(yè)面，其實(shí)這張圖在閃屏顯示過(guò)后應(yīng)該可以回收，但是因?yàn)闅v史原因(和JOOX的退出機(jī)制有關(guān))，這張圖被常駐在后臺(tái)，導(dǎo)致無(wú)謂的內(nèi)存占用。

優(yōu)化方式：我們通過(guò)將這三張圖從xhdpi挪動(dòng)到xxhdpi(當(dāng)然這里需要看下圖片顯示效果有沒(méi)很大的影響)，以及在閃屏顯示過(guò)后回收閃屏圖片。

優(yōu)化結(jié)果：

從原來(lái)的8.29x3=24.87M 到 3.68x2=7.36M 優(yōu)化了17M(有沒(méi)一種萬(wàn)馬奔騰的感覺(jué)。?？赡苡袝r(shí)費(fèi)大力氣優(yōu)化很多代碼也優(yōu)化不了幾百K，所以很多情況下內(nèi)存優(yōu)化時(shí)優(yōu)化圖片還是比較立竿見(jiàn)影的)。

同樣方式我們發(fā)現(xiàn)對(duì)于一些默認(rèn)圖，實(shí)際要求的顯示要求并不高(圖片相對(duì)簡(jiǎn)單，同時(shí)大部分情況下圖片加載會(huì)成功)，比如下面這張banner的背景圖：

優(yōu)化前1.6M左右，優(yōu)化后700K左右。

同時(shí)我們也發(fā)現(xiàn)了默認(rèn)圖片一個(gè)其他問(wèn)題，因?yàn)闅v史原因，我們使用的圖片加載庫(kù)，設(shè)置默認(rèn)圖片的接口是需要一個(gè)bitmap，導(dǎo)致我們?cè)瓉?lái)幾乎每個(gè)adapter都用BitmapFactory decode了一個(gè)bitmap，對(duì)同一張默認(rèn)圖片，不但沒(méi)有復(fù)用，還保存了多份，不僅會(huì)造成內(nèi)存浪費(fèi)，而且導(dǎo)致滑動(dòng)偶爾會(huì)卡頓。這里我們也對(duì)默認(rèn)圖片使用全局的bitmap緩存池，App全局只要使用同一張bitmap，都復(fù)用了同一份。

另外對(duì)于從MAT里看到的圖片，有時(shí)候因?yàn)榭床坏皆陧?xiàng)目里面對(duì)應(yīng)的ID，會(huì)比較難確認(rèn)到底是哪一張圖，這里stackoverflow上有一種方法，直接用原始數(shù)據(jù)通過(guò)GIM還原這張圖片。

這里其實(shí)也看到JOOX比較吃虧一個(gè)地方，JOOX不少地方都是使用比較復(fù)雜的圖片，同時(shí)有些地方還需要模糊，動(dòng)畫這些都是比較耗內(nèi)存的操作，Material Design出來(lái)后，很多App都遵循MD設(shè)計(jì)進(jìn)行改版，通常默認(rèn)背景，默認(rèn)圖片一般都是純色，不僅App看起來(lái)比較明亮輕快，實(shí)際上也省了很多的內(nèi)存，對(duì)此，JOOX后面對(duì)低端機(jī)型做了對(duì)應(yīng)的優(yōu)化。

3. 我們也對(duì)Bugly上的OOM進(jìn)行了分析，發(fā)現(xiàn)其實(shí)有些OOM是可以避免的。

下面這個(gè)crash就是上面提到的在LsitView的adapter里不停創(chuàng)建bitmap，這個(gè)地方是我們的首頁(yè)banner位，理論上App一打開(kāi)就會(huì)緩存這張默認(rèn)背景圖片了，而實(shí)際在使用過(guò)一段時(shí)間后，才因?yàn)闉榱私獯a這張背景圖而OOM， 改為用全局緩存解決。

下面這個(gè)就是傳說(shuō)中的內(nèi)存抖動(dòng)

實(shí)際代碼如下，因?yàn)榇騆og而進(jìn)行了字符串拼接，一旦這個(gè)函數(shù)被比較頻繁地調(diào)用，那么就很有可能會(huì)發(fā)生內(nèi)存抖動(dòng)。這里我們新版本已經(jīng)改為使用stringbuilder進(jìn)行優(yōu)化。

還有一些比較奇怪的情況，這里是我們掃描歌曲文件頭的時(shí)候發(fā)生的，有些文件頭居然有幾百M(fèi)大，導(dǎo)致一次申請(qǐng)了過(guò)大的內(nèi)存，直接OOM，這里暫時(shí)也無(wú)法修復(fù)，直接catch住out of memory error。

4. 同時(shí)我們對(duì)一些邏輯代碼進(jìn)行調(diào)整，比如我們的App主頁(yè)的第三個(gè)tab(Live tab)進(jìn)行了數(shù)據(jù)延遲加載，和定時(shí)回收。

這里因?yàn)檫@個(gè)頁(yè)面除了有大圖還有輪播banner，實(shí)際強(qiáng)引用的圖片會(huì)有多張，如果這個(gè)時(shí)候切到其他頁(yè)面進(jìn)行聽(tīng)歌等行為，這個(gè)頁(yè)面一直在后臺(tái)緩存，實(shí)際是很浪費(fèi)耗內(nèi)存的，同時(shí)為優(yōu)化體驗(yàn)，我們又不能直接通過(guò)設(shè)置主頁(yè)的viewpager的緩存頁(yè)數(shù)，因?yàn)檫@樣經(jīng)常都會(huì)回收，導(dǎo)致影響體驗(yàn)，所以我們?cè)陧?yè)面不可見(jiàn)后過(guò)一段時(shí)間，清理掉adapter數(shù)據(jù)(只是清空adapter里的數(shù)據(jù)，實(shí)際從網(wǎng)絡(luò)加載回來(lái)的數(shù)據(jù)還在，這里只是為了去掉界面對(duì)圖片的引用)，當(dāng)頁(yè)面再次顯示時(shí)再用已經(jīng)加載的數(shù)據(jù)顯示，即減少了很多情況下圖片的引用，也不影響體驗(yàn)。

5. 最后我們也遇到一個(gè)比較奇葩的問(wèn)題，在我們的Bugly上報(bào)上有這樣一條上報(bào)

我們?cè)趕tackoverflow上看到了相關(guān)的討論，大致意思是有些情況下比如息屏，或者一些省電模式下，頻繁地調(diào)System.gc()可能會(huì)因?yàn)閮?nèi)核狀態(tài)切換超時(shí)的異常。這個(gè)問(wèn)題貌似沒(méi)有比較好的解決方法，只能是優(yōu)化內(nèi)存，盡量減少手動(dòng)調(diào)用System.gc()

優(yōu)化結(jié)果

我們通過(guò)啟動(dòng)App后，切換到我的音樂(lè)界面，停留1分鐘，多次gc后，獲取App內(nèi)存占用

優(yōu)化前：

優(yōu)化后：

多次試驗(yàn)結(jié)果都差不多，這里只截取了其中一次，有28M的優(yōu)化效果。

當(dāng)然不同的場(chǎng)景內(nèi)存占用不同，同時(shí)上面試驗(yàn)結(jié)果是通過(guò)多次手動(dòng)觸發(fā)gc穩(wěn)定后的結(jié)果。對(duì)于使用其他第三方工具不手動(dòng)gc的情況下，試驗(yàn)結(jié)果可能會(huì)差異比較大。

對(duì)于上面提到的JOOX里各種圖片背景等問(wèn)題，我們做了動(dòng)態(tài)的優(yōu)化，對(duì)不同的機(jī)型進(jìn)行優(yōu)化，對(duì)特別低端的機(jī)型設(shè)置為純色背景等方式，最終優(yōu)化效果如下：

平均內(nèi)存降低41M。

本次總結(jié)主要還是從圖片方面下手，還有一點(diǎn)邏輯優(yōu)化，已經(jīng)基本達(dá)到優(yōu)化目標(biāo)。