Android性能優(yōu)化之Java內(nèi)存

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

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

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

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

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

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

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

　　可以作為GCRoots的對象包括下面幾種：

　　·虛擬機棧中引用的對象，一般是當前在使用中局部變量

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

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

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

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

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

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

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

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

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

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

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

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

　　每一個Generation的內(nèi)存區(qū)域都有固定的大小，隨著新的對象陸續(xù)被分配到此區(qū)域，當這些對象總的大小快達到這一級別內(nèi)存區(qū)域的閥值時，會觸發(fā)GC的操作，以便騰出空間來存放其他新的對象。如下圖所示：

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

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

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

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

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

　　ActivityManager.getMemoryClass（）可以用來查詢當前應用的Heap Size閾值，這個方法會返回一個整數(shù)，表明你的應用的Heap Size閾值是多少Mb（megabates）。

　　還有一個用adb命令查詢的方法：

　　adb shell getprop dalvik.vm.heapgrowthlimit

　　3、案例

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

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

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

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

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

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

　　點擊Android Studio這里可以dump當前的內(nèi)存快照，因為直接通過Android Sutdio dump出來的hprof文件與標準hprof文件有些差異，我們需要手動進行轉(zhuǎn)換，利用sdk目錄/platform-tools/hprof-conv.exe可以直接進行轉(zhuǎn)換，用法：hprof-conv 原文件.hprof 新文件.hprof。只需要輸入原文件名還有目標文件名就可以進行轉(zhuǎn)換，轉(zhuǎn)換完就可以直接用MAT打開。

　　下面就是JOOX打開App，手動進行多次gc的hprof文件。

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

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

　　Retained Heap： Retained heap值的計算方式是將retained set中的所有對象大小疊加。或者說，由于X被釋放，導致其它所有被釋放對象（包括被遞歸釋放的）所占的heap大小。

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

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

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

　　這里其實有兩個問題：

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

　　閃屏頁面，其實這張圖在閃屏顯示過后應該可以回收，但是因為歷史原因（和JOOX的退出機制有關(guān)），這張圖被常駐在后臺，導致無謂的內(nèi)存占用。

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

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

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

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

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

　　同時我們也發(fā)現(xiàn)了默認圖片一個其他問題，因為歷史原因，我們使用的圖片加載庫，設置默認圖片的接口是需要一個bitmap，導致我們原來幾乎每個adapter都用BitmapFactory decode了一個bitmap，對同一張默認圖片，不但沒有復用，還保存了多份，不僅會造成內(nèi)存浪費，而且導致滑動偶爾會卡頓。這里我們也對默認圖片使用全局的bitmap緩存池，App全局只要使用同一張bitmap，都復用了同一份。

　　另外對于從MAT里看到的圖片，有時候因為看不到在項目里面對應的ID，會比較難確認到底是哪一張圖，這里stackoverflow上有一種方法，直接用原始數(shù)據(jù)通過GIM還原這張圖片。

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

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

　　下面這個crash就是上面提到的在LsitView的adapter里不停創(chuàng)建bitmap，這個地方是我們的首頁banner位，理論上App一打開就會緩存這張默認背景圖片了，而實際在使用過一段時間后，才因為為了解碼這張背景圖而OOM， 改為用全局緩存解決。

　　下面這個就是傳說中的內(nèi)存抖動

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

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

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

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

　　5. 最后我們也遇到一個比較奇葩的問題，在我們的Bugly上報上有這樣一條上報

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

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

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

　　優(yōu)化前：

　　優(yōu)化后：

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

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

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

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

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