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

　　Android是基于Java的，眾所周知Java語言的內(nèi)存管理是其一大特點(diǎn)，不用像C語言那樣處理對(duì)象的內(nèi)存分配到回收的全部過程。在Java中我們只需要簡單地新建對(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ì)象。

　　接下來還有一個(gè)疑問：未使用的對(duì)象被誰引用會(huì)讓GC無法回收呢？

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

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

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

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

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

　　·本地方法棧中JNI（即一般說的Native方法）引用的對(duì)象

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

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

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

　　了解了Java的內(nè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)沒有為內(nèi)存提供交換區(qū)，它使用paging與memory-mapping（mmapping）的機(jī)制來管理內(nèi)存，下面簡要概述一些Android系統(tǒng)中重要的內(nèi)存管理基礎(chǔ)概念。

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

　　每一個(gè)進(jìn)程的Dalvikheap都反映了使用內(nèi)存的占用范圍。這就是通常邏輯意義上提到的DalvikHeapSize，它可以隨著需要進(jìn)行增長，但是增長行為會(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的操作，以便騰出空間來存放其他新的對(duì)象。如下圖所示：

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

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

　　因?yàn)槊看蜧C的時(shí)候，需要先找到可作為GC Roots的對(duì)象，然后以此搜索引用鏈，這個(gè)過程需要在一致性的內(nèi)存快照中進(jìn)行。這個(gè)“一致性”表示在整個(gè)過程中不能出現(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)?a href="http://www.brongaenegriffin.com/tags/ram/" target="_blank">RAM大小不同而各有差異。如果你的應(yīng)用占用內(nèi)存空間已經(jīng)接近這個(gè)閾值，此時(shí)再嘗試分配內(nèi)存的話，很容易引起OutOfMemoryError的錯(cuò)誤。

　　ActivityManager.getMemoryClass（）可以用來查詢當(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ā)布以來已經(jīng)成為5個(gè)國家和地區(qū)排名第一的音樂App。東南亞是JOOX的主要發(fā)行地區(qū)，實(shí)際上這些地區(qū)還是有很多的低端機(jī)型，對(duì)App的進(jìn)行內(nèi)存優(yōu)化勢(shì)在必行。

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

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

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

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

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

　　點(diǎn)擊Android Studio這里可以dump當(dāng)前的內(nèi)存快照，因?yàn)橹苯油ㄟ^Android Sutdio dump出來的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打開。

　　下面就是JOOX打開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，由于X被釋放，導(dǎo)致其它所有被釋放對(duì)象（包括被遞歸釋放的）所占的heap大小。

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

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

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

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

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

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

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

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

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

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

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

　　同時(shí)我們也發(fā)現(xiàn)了默認(rèn)圖片一個(gè)其他問題，因?yàn)闅v史原因，我們使用的圖片加載庫，設(shè)置默認(rèn)圖片的接口是需要一個(gè)bitmap，導(dǎo)致我們?cè)瓉韼缀趺總€(gè)adapter都用BitmapFactory decode了一個(gè)bitmap，對(duì)同一張默認(rèn)圖片，不但沒有復(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ù)通過GIM還原這張圖片。

　　這里其實(shí)也看到JOOX比較吃虧一個(gè)地方，JOOX不少地方都是使用比較復(fù)雜的圖片，同時(shí)有些地方還需要模糊，動(dòng)畫這些都是比較耗內(nèi)存的操作，Material Design出來后，很多App都遵循MD設(shè)計(jì)進(jìn)行改版，通常默認(rèn)背景，默認(rèn)圖片一般都是純色，不僅App看起來比較明亮輕快，實(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è)地方是我們的首頁banner位，理論上App一打開就會(huì)緩存這張默認(rèn)背景圖片了，而實(shí)際在使用過一段時(shí)間后，才因?yàn)闉榱私獯a這張背景圖而OOM， 改為用全局緩存解決。

　　下面這個(gè)就是傳說中的內(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)了過大的內(nèi)存，直接OOM，這里暫時(shí)也無法修復(fù)，直接catch住out of memory error。

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

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

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

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

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

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

　　優(yōu)化前：

　　優(yōu)化后：

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

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

　　對(duì)于上面提到的JOOX里各種圖片背景等問題，我們做了動(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)。