android要怎么進(jìn)行內(nèi)存管理？詳解android管理內(nèi)存方法分享！

對(duì)于在開(kāi)發(fā)中內(nèi)存的管理是尤為重要的，尤其是在軟件的設(shè)計(jì)中，今天我們就來(lái)講講有關(guān)于：“android要怎么進(jìn)行內(nèi)存管理？”這個(gè)問(wèn)題的解決方法和相關(guān)的解決思路分享！ 

前言

很高興遇見(jiàn)你~

內(nèi)存優(yōu)化一直是 Android 開(kāi)發(fā)中的一個(gè)非常重要的話題，他直接影響著我們 app 的性能表現(xiàn)。但這個(gè)話題涉及到的內(nèi)容很廣且都偏向底層，讓很多開(kāi)發(fā)者望而卻步。同時(shí)，內(nèi)存優(yōu)化更加偏向于“經(jīng)驗(yàn)知識(shí)”，需要在實(shí)際項(xiàng)目中去應(yīng)用來(lái)學(xué)習(xí)。

因而本文并不想深入到底層去講內(nèi)存優(yōu)化的原理，而是著眼于宏觀，聊聊 android 是如何分配和管理內(nèi)存、在內(nèi)存不足的時(shí)候系統(tǒng)會(huì)如何處理以及會(huì)對(duì)用戶造成什么樣的影響。

Android 應(yīng)用基于 JVM 語(yǔ)言進(jìn)行開(kāi)發(fā)，雖然 google 根據(jù)移動(dòng)設(shè)備特點(diǎn)開(kāi)發(fā)了自家的虛擬機(jī)如 Dalvik、ART，但依舊是基于 JVM 模型，在堆區(qū)分配對(duì)象內(nèi)存。因此 Java heap（java 堆）是android應(yīng)用內(nèi)存分配和回收的重點(diǎn)。其次，移動(dòng)設(shè)備的 RAM 非常有限，如何為進(jìn)程分配以及管理內(nèi)存也是重中之重。

文章的主要內(nèi)容是分析 Java heap、RAM 的內(nèi)存管理，以及當(dāng)內(nèi)存不夠時(shí) android 會(huì)如何處理。

那么，我們開(kāi)始吧。

Java Heap

Java Heap，也就是 JVM 中的堆區(qū)。簡(jiǎn)單回顧一下 JVM 中運(yùn)行時(shí)數(shù)據(jù)區(qū)域的劃分：

• 橙色區(qū)域的方法棧以及程序計(jì)數(shù)器屬于線程私有，主要存儲(chǔ)方法中的局部數(shù)據(jù)。
• 方法區(qū)主要存儲(chǔ)常量以及類(lèi)信息，線程共享。
• 堆區(qū)主要負(fù)責(zé)存儲(chǔ)創(chuàng)建的對(duì)象，幾乎一切對(duì)象的內(nèi)存都在堆區(qū)中分配，同時(shí)也是線程共享。
  

我們?cè)?android 程序中使用如 Object o = new Object() 代碼創(chuàng)建的對(duì)象都會(huì)在堆區(qū)中分配一塊內(nèi)存進(jìn)行存儲(chǔ)，具體如何分配由虛擬機(jī)解決而不需要我們開(kāi)發(fā)者干預(yù)。當(dāng)一個(gè)對(duì)象不再使用時(shí)， JVM 中具有垃圾回收機(jī)制（GC），會(huì)自動(dòng)釋放堆區(qū)中無(wú)用的對(duì)象，重新利用內(nèi)存。當(dāng)我們請(qǐng)求分配的內(nèi)存已經(jīng)超過(guò)堆區(qū)的內(nèi)存大小，則會(huì)拋出 OOM 異常。

在 android 中，堆區(qū)是一個(gè)由 JVM 邏輯劃分的區(qū)域，他并不是真正的物理區(qū)域。堆區(qū)并不會(huì)直接全部映射和他等量大小的物理內(nèi)存，而是到了需要使用時(shí)，才會(huì)去建立邏輯地址和物理地址的映射：

這樣可以給應(yīng)用分配足夠的邏輯內(nèi)存大小，同時(shí)也不必在啟動(dòng)時(shí)一次性分配一大塊的物理內(nèi)存。在相同大小的內(nèi)存中，可以運(yùn)行更多的程序。

當(dāng)堆區(qū)進(jìn)程 GC 之后，釋放出來(lái)多余的空閑內(nèi)存，會(huì)返還給系統(tǒng)，減少物理內(nèi)存的占用。但這個(gè)過(guò)程涉及到比較復(fù)雜的系統(tǒng)調(diào)用，若釋放的內(nèi)存較為少量，可能得不償失，則無(wú)需返還給系統(tǒng)，在堆區(qū)中繼續(xù)使用即可。

在 GC 過(guò)程中，如果一個(gè)對(duì)象不再使用，但是其所占用的內(nèi)存無(wú)法被釋放，導(dǎo)致資源浪費(fèi)，這種現(xiàn)象稱(chēng)為內(nèi)存泄漏。內(nèi)存泄露會(huì)導(dǎo)致堆區(qū)中的對(duì)象越來(lái)越多，內(nèi)存的壓力越來(lái)越大，甚至出現(xiàn) OOM 。因此，內(nèi)存泄露是我們必須要盡量避免的現(xiàn)象。

進(jìn)程內(nèi)存分配

堆區(qū)的內(nèi)存分配，屬于進(jìn)程內(nèi)的內(nèi)存分配，由進(jìn)程自己管理。下面講一個(gè)應(yīng)用，系統(tǒng)是如何為其分配內(nèi)存的。

系統(tǒng)的運(yùn)行內(nèi)存，即為我們常說(shuō)的 RAM ，是應(yīng)用的運(yùn)行空間。每個(gè)應(yīng)用必須裝入內(nèi)存中才可以被執(zhí)行：

• 我們安裝的應(yīng)用進(jìn)程都位于硬盤(pán)中
• 當(dāng)一個(gè)應(yīng)用被執(zhí)行時(shí)，需要裝入到 RAM 中才能被執(zhí)行（zRAM 是為了壓縮數(shù)據(jù)節(jié)省空間而設(shè)計(jì)，后續(xù)會(huì)講到）
• CPU 與 RAM 交互，讀取指令、數(shù)據(jù)、寫(xiě)入數(shù)據(jù)等
  

RAM 的大小為設(shè)備的硬件內(nèi)存大小，是非常寶貴的資源?，F(xiàn)代手機(jī)常見(jiàn)的運(yùn)存是6G、8G或者12G，一些專(zhuān)為游戲研發(fā)的手機(jī)甚至有18G，但同時(shí)價(jià)格也會(huì)跟上去。

Android 采用分頁(yè)存儲(chǔ)的方式把一個(gè)進(jìn)程存儲(chǔ)到 RAM 中。分頁(yè)存儲(chǔ)，簡(jiǎn)單來(lái)說(shuō)就是把內(nèi)存分割成很多個(gè)小塊，每個(gè)應(yīng)用占用不同的小塊，這些小塊也可以稱(chēng)為頁(yè)：

前面講到，進(jìn)程的堆區(qū)并不是一次性分配，當(dāng)需要分配內(nèi)存時(shí)，系統(tǒng)會(huì)為其分配空閑的頁(yè)；當(dāng)這些頁(yè)被回收，那么有可能被返還到系統(tǒng)中。

這里的頁(yè)、塊概念涉及到操作系統(tǒng)的分頁(yè)存儲(chǔ)，這里并不打算展開(kāi)詳細(xì)講解，有興趣的讀者可以自行了解：分頁(yè)存儲(chǔ)-維基百科。本文中的“頁(yè)”與“塊”可以不嚴(yán)謹(jǐn)?shù)乩斫鉃橥瑐€(gè)概念，為了幫助理解這里不進(jìn)行詳細(xì)地區(qū)分。

分配給進(jìn)程的頁(yè)可以分為兩種類(lèi)型：干凈頁(yè)、臟頁(yè)：

• 干凈頁(yè)：進(jìn)程從硬盤(pán)中讀取數(shù)據(jù)或申請(qǐng)內(nèi)存之后未進(jìn)行修改。這種類(lèi)型的頁(yè)面在內(nèi)存不足的時(shí)候可以被回收，因?yàn)轫?yè)中存儲(chǔ)的數(shù)據(jù)可通過(guò)其他的途徑復(fù)原。
• 臟頁(yè)：進(jìn)程對(duì)頁(yè)中的數(shù)據(jù)進(jìn)行了修改或數(shù)據(jù)存儲(chǔ)。這類(lèi)頁(yè)面不能被直接回收，否則會(huì)造成數(shù)據(jù)丟失，必須先進(jìn)行數(shù)據(jù)存儲(chǔ)。
  

zRAM，是作為 RAM 中的一個(gè)分區(qū)，當(dāng)內(nèi)存不足時(shí)，可以把一些類(lèi)型的頁(yè)壓縮之后存儲(chǔ)在zRAM中，當(dāng)需要使用的時(shí)候再?gòu)膠RAM中調(diào)出。通過(guò)壓縮來(lái)節(jié)省應(yīng)用的空間占用，同時(shí)不需要與硬盤(pán)進(jìn)行調(diào)度，提高了速度。

這里需要理解的一個(gè)點(diǎn)是：內(nèi)存中的操作速度要遠(yuǎn)遠(yuǎn)比硬盤(pán)操作快。即使與zRAM的調(diào)入和調(diào)出需要壓縮和解壓，其速度也是比與硬盤(pán)交互快得多。

內(nèi)存不足管理

前面我們一直強(qiáng)調(diào)，移動(dòng)設(shè)備的內(nèi)存容量是非常有限的，需要我們非常謹(jǐn)慎地去使用它。幸運(yùn)的是，JVM 和 android 系統(tǒng)早就幫我們想到了這一點(diǎn)。

面對(duì)不同的內(nèi)存壓力，android 會(huì)有不同的應(yīng)對(duì)策略。從低到高依次是 GC、內(nèi)核交換守護(hù)進(jìn)程釋放內(nèi)存、低內(nèi)存終止守護(hù)進(jìn)程殺死進(jìn)程釋放內(nèi)存；他們的代價(jià)也是逐步上升。下面我們依個(gè)來(lái)介紹一下。

GC 垃圾回收

GC 屬于 JVM 內(nèi)部的內(nèi)存管理機(jī)制，他管理的內(nèi)存區(qū)域是堆區(qū)。當(dāng)我們創(chuàng)建的對(duì)象越來(lái)多，堆區(qū)的壓力越來(lái)越大時(shí)，GC 機(jī)制就會(huì)啟動(dòng)，開(kāi)始回收堆區(qū)中的垃圾對(duì)象。

辨別一個(gè)對(duì)象是否是垃圾，虛擬機(jī)采用的是可達(dá)性分析法。即從一些確定活躍有用的對(duì)象出發(fā)，向下分析他的引用鏈；如果一個(gè)對(duì)象直接或者間接這些對(duì)象所引用，那么他就不是垃圾，否則就是垃圾。這些確定活躍有用的對(duì)象稱(chēng)為 GC Roots：

如上圖，其中綠色的對(duì)象被 GC Roots 直接或間接引用，則不會(huì)被回收；灰色的對(duì)象沒(méi)有被引用則被標(biāo)記為垃圾
GC Roots對(duì)象的類(lèi)型比較常見(jiàn)的是靜態(tài)變量以及棧中的引用。靜態(tài)變量比較好理解，他在整個(gè)進(jìn)程的執(zhí)行期間不會(huì)被回收，因此他肯定是有用的。棧，這里指的是 JVM 運(yùn)行數(shù)據(jù)區(qū)域中的方法棧，也就是局部變量引用，在方法執(zhí)行期間肯定是活躍的。由于方法棧屬于線程私有，因此這里等于活躍線程持有的對(duì)象不會(huì)被回收。

因此，如果一個(gè)對(duì)象對(duì)于我們的程序不再使用，則必須解除 GC Roots 對(duì)其的引用，否則會(huì)造成內(nèi)存泄露。例如，不要把 activity 賦值給一個(gè)靜態(tài)變量，這樣會(huì)導(dǎo)致界面退出時(shí)activity無(wú)法被回收。

GC 也并不是直接對(duì)整個(gè)堆區(qū)進(jìn)行回收，而是將堆區(qū)中的對(duì)象分成兩個(gè)部分：新生代、老年代。

剛創(chuàng)建的對(duì)象大都會(huì)被回收，而在多次回收中存活的對(duì)象則后續(xù)也很少被回收。新生代中存儲(chǔ)的對(duì)象主要是剛被創(chuàng)建不久的對(duì)象，而老年代則存儲(chǔ)著那些在多次 GC 中存活的對(duì)象。那么我們可以針對(duì)這些不同特性的對(duì)象，執(zhí)行不同的回收算法來(lái)提高GC性能：

• 對(duì)于新創(chuàng)建的對(duì)象，我們需要更加頻繁地對(duì)他們進(jìn)行GC來(lái)釋放內(nèi)存，且每次只需要記錄需要留下來(lái)的對(duì)象即可，而不必要去標(biāo)記其他大量需要被回收的對(duì)象，提高性能。
• 對(duì)于熬過(guò)很多次GC的對(duì)象，則可以以更低的頻率對(duì)他門(mén)進(jìn)行GC，且每次只需要關(guān)注少量需要被回收的對(duì)象即可。

具體的垃圾回收算法就不繼續(xù)展開(kāi)了，了解到這里就可以。感興趣的讀者可以閱讀相關(guān)書(shū)籍。

單次的垃圾回收速度是很快的，甚至我們都無(wú)法感知到。但當(dāng)內(nèi)存壓力越來(lái)越大，垃圾回收的速度跟不上內(nèi)存分配的速度，此時(shí)就會(huì)出現(xiàn)內(nèi)存分配等待 GC 的情況，也就是發(fā)生了卡頓。同時(shí)，我們無(wú)法控制 GC 的時(shí)機(jī)，JVM 有一套完整的算法來(lái)決定什么時(shí)候進(jìn)行 GC。假如在我們滑動(dòng)界面的時(shí)候觸發(fā) GC ，那么展示出來(lái)的就是出現(xiàn)了掉幀情況。因此，做好內(nèi)存優(yōu)化，對(duì)于 app 的性能表現(xiàn)非常重要。

內(nèi)核交換守護(hù)進(jìn)程

GC 是針對(duì)于 Java 程序內(nèi)部進(jìn)行的優(yōu)化。對(duì)于移動(dòng)設(shè)備來(lái)說(shuō)，RAM 非常寶貴，如何在有限的 RAM 資源上進(jìn)行分配內(nèi)存，也是一個(gè)非常重要的話題。

我們的應(yīng)用程序都運(yùn)行在 RAM 中，當(dāng)進(jìn)程不斷申請(qǐng)內(nèi)存分配，RAM 的剩余內(nèi)存達(dá)到一定的閾值時(shí)，會(huì)啟動(dòng)內(nèi)核交換守護(hù)進(jìn)程來(lái)釋放內(nèi)存以滿足資源的分配。

內(nèi)核交換守護(hù)進(jìn)程，是運(yùn)行在系統(tǒng)內(nèi)核的一個(gè)進(jìn)程，他主要的工作時(shí)回收干凈頁(yè)、壓縮頁(yè)等操作來(lái)釋放內(nèi)存。前面講到，android 是基于分頁(yè)存儲(chǔ)的操作系統(tǒng)，每個(gè)進(jìn)程都會(huì)被存儲(chǔ)到一些頁(yè)中。分頁(yè)的類(lèi)型有兩種：干凈頁(yè)、臟頁(yè)：

• 當(dāng)內(nèi)核交換守護(hù)進(jìn)程啟動(dòng)時(shí)，他會(huì)把干凈頁(yè)回收以釋放內(nèi)存。當(dāng)進(jìn)程再次訪問(wèn)干凈頁(yè)時(shí)，則需要去硬盤(pán)中再次讀取。
• 對(duì)于臟頁(yè)，內(nèi)核交換守護(hù)進(jìn)程會(huì)把他們壓縮后放入 zRAM 中。當(dāng)進(jìn)程訪問(wèn)臟頁(yè)時(shí)，則需要從zRAM中解壓出來(lái)。

通過(guò)不斷回收和壓縮分頁(yè)的方式來(lái)釋放內(nèi)存，以滿足新的內(nèi)存請(qǐng)求。使用此方式釋放的內(nèi)存也無(wú)法滿足新的內(nèi)存請(qǐng)求時(shí)，android 會(huì)啟動(dòng)低內(nèi)存終止守護(hù)進(jìn)程，來(lái)終止一些低優(yōu)先級(jí)的進(jìn)程。

低內(nèi)存終止守護(hù)進(jìn)程

當(dāng) RAM 的被占用內(nèi)存達(dá)到一定的閾值，android 會(huì)根據(jù)進(jìn)程的優(yōu)先級(jí)，終止部分進(jìn)程來(lái)釋放內(nèi)存。當(dāng)?shù)蛢?nèi)存終止守護(hù)進(jìn)程啟動(dòng)時(shí)，說(shuō)明系統(tǒng)的內(nèi)存壓力已經(jīng)非常大了，這在一些性能較差的設(shè)備中經(jīng)常出現(xiàn)。

進(jìn)程的優(yōu)先級(jí)從高到低排序如下，優(yōu)先級(jí)更高的進(jìn)程會(huì)優(yōu)先被終止：

圖片來(lái)源：developer.android.google.cn/topic/perfo…

從上到下依次是：

• 后臺(tái)應(yīng)用：使用過(guò)的 app 會(huì)被緩存在后臺(tái)，下一次打開(kāi)可以更加快速地進(jìn)行切換。當(dāng)內(nèi)存不足時(shí)，此類(lèi)應(yīng)用會(huì)最快被殺死。
• 上一個(gè)應(yīng)用：例如從微信跳轉(zhuǎn)到瀏覽器，此時(shí)微信就是上一個(gè)應(yīng)用。
• 主屏幕應(yīng)用：這是啟動(dòng)器應(yīng)用，也就是我們的桌面。如果這個(gè)進(jìn)程被kill了，那么返回桌面時(shí)會(huì)暫時(shí)黑屏。
• 服務(wù)：同步服務(wù)、上傳服務(wù)等等
• 可覺(jué)察的應(yīng)用：例如正在播放的音樂(lè)軟件，他可以被我們感知到，但是不在前臺(tái)。
• 前臺(tái)應(yīng)用：當(dāng)前正在使用的應(yīng)用，如果這個(gè)應(yīng)用被kill了，需要向用戶報(bào)崩潰異常，此時(shí)的體驗(yàn)是極差的。
• 持久性（服務(wù)）：這些是設(shè)備的核心服務(wù)，例如電話和 WLAN。
• 系統(tǒng)：系統(tǒng)進(jìn)程。這些進(jìn)程被終止后，手機(jī)可能即將重新啟動(dòng)，就像手機(jī)突然卡死重啟。
• 原生：系統(tǒng)使用的極低級(jí)別的進(jìn)程，例如我們的內(nèi)核交換守護(hù)進(jìn)程。
  

當(dāng)內(nèi)存不足，會(huì)按照上面的規(guī)則，從上到下來(lái)終止進(jìn)程，獲得內(nèi)存資源。這也就是為什么在 android 中我們的后臺(tái)應(yīng)用一直被殺死。為了避免我們的應(yīng)用被優(yōu)化，內(nèi)存優(yōu)化就顯得非常重要了。

最后再來(lái)回顧一下：

圖片來(lái)源：www.youtube.com/watch?v=w7K…

• 在0-1階段，系統(tǒng)的內(nèi)存資源足夠，程序請(qǐng)求內(nèi)存分配，系統(tǒng)會(huì)不斷地使用空閑頁(yè)來(lái)滿足應(yīng)用的內(nèi)存請(qǐng)求
• 在1-2階段，系統(tǒng)的可利用內(nèi)存下降到一個(gè)閾值，程序繼續(xù)請(qǐng)求內(nèi)存分配，內(nèi)核交換守護(hù)進(jìn)程啟動(dòng)，開(kāi)始釋放緩存來(lái)滿足內(nèi)存請(qǐng)求
• 在2-3階段，系統(tǒng)的被利用內(nèi)存達(dá)到一個(gè)閾值，系統(tǒng)將啟動(dòng)低內(nèi)存終止守護(hù)進(jìn)程來(lái)殺死進(jìn)程釋放內(nèi)存
  

最后

我們文章分析了 android 是如何對(duì)內(nèi)存進(jìn)行分配以及低內(nèi)存時(shí)如何釋放內(nèi)存來(lái)滿足內(nèi)存請(qǐng)求。可以很明顯看到，當(dāng)內(nèi)存不足時(shí)，會(huì)嚴(yán)重影響我們 app 的體驗(yàn)甚至整個(gè)用戶手機(jī)的體驗(yàn)：

• 當(dāng)內(nèi)存不足會(huì)造成頻繁GC、回收干凈頁(yè)、回寫(xiě)緩存，導(dǎo)致應(yīng)用緩慢、卡頓
• 如果設(shè)備內(nèi)存一直不夠，那么會(huì)一直殺死進(jìn)程影響用戶體驗(yàn)，特別是這些進(jìn)程是用戶非常在意的如游戲、微信
• 內(nèi)存占用過(guò)高會(huì)讓app在后臺(tái)被殺死、或者讓用戶的其他app被殺死、甚至整個(gè)系統(tǒng)無(wú)法運(yùn)行而直接崩潰重啟,
• 不是所有的設(shè)備都有著高內(nèi)存，有著設(shè)備只有很少的內(nèi)存，在一些性能較差的設(shè)備上甚至?xí)o(wú)法運(yùn)行，這樣我們就失去了這些設(shè)備的市場(chǎng)
  

反觀現(xiàn)在國(guó)內(nèi)的很多 app，有如扣扣、t寶、iqy，在我這個(gè)三年前的機(jī)器上運(yùn)行會(huì)發(fā)生嚴(yán)重卡頓，偶爾還有ANR崩潰的出現(xiàn)；而當(dāng)我去測(cè)試了youto、tele、Twit等 app ，發(fā)現(xiàn)基本不會(huì)發(fā)生卡頓，甚至在 youto 這樣有大量圖片視頻加載的 app 界面切換也盡享絲滑。這兩種 app 的體驗(yàn)是有著天壤之別的。

本文沒(méi)有講如何進(jìn)行內(nèi)存優(yōu)化，是因?yàn)檫@一塊的內(nèi)容設(shè)計(jì)到的太廣太深，無(wú)法在這篇文章中一并介紹。文章的目的只是為了幫助讀者了解android是如何管理內(nèi)存以及內(nèi)存不足可能造成的后果，對(duì)內(nèi)存的重要性能有一個(gè)感性的認(rèn)知。

在文中小編詳細(xì)的講解了有關(guān)于“android要怎么進(jìn)行內(nèi)存管理？”這個(gè)問(wèn)題的解決方法，更多有關(guān)于android這方面的相關(guān)內(nèi)容我們都可以在W3Cschool進(jìn)行學(xué)習(xí)和了解！