App的待機(jī)內(nèi)存增長的原因是什么

這篇文章給大家介紹App的待機(jī)內(nèi)存增長的原因是什么，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

1.新問題的進(jìn)一步挖掘

在上一節(jié)里，我們介紹了內(nèi)存測試的基本流程，講述了如何發(fā)現(xiàn)并處理簡單的內(nèi)存問題。對于Dalvik Heap部分總結(jié)出了一些常見的問題模式，以及如何使用工具識(shí)別和處理這些常見的內(nèi)存問題。

當(dāng)簡單問題不再是問題的時(shí)候，我們就會(huì)開始遇上一些奇怪問題了，類似于下面這些：

“我們這個(gè)版本引入了一個(gè)挺簡單的庫，內(nèi)存就漲了2M” “這些代碼只是初始化了幾個(gè)對象，還沒有開始用呢” “我只是改了一行代碼，沒有創(chuàng)建新對象” “我一行代碼都沒改，怎么會(huì)漲呢”

這次出現(xiàn)的問題就是這樣這一類問題，新版本的Dalvik Heap Pss內(nèi)存出現(xiàn)了2M左右的增長。但Dalvik Heap Alloc只增長了273K的情況下。而從Dalvik Heap Free也能看出大部分增長的內(nèi)存是空閑狀態(tài)的。

經(jīng)過一段時(shí)間對問題的觀察，我們有以下幾點(diǎn)發(fā)現(xiàn)：

• 經(jīng)過較長時(shí)間待機(jī)后也沒有被釋放回系統(tǒng)。

• 有幾處代碼會(huì)導(dǎo)致內(nèi)存增長，只要將這些代碼屏蔽掉，內(nèi)存情況就下降到正常水品。

• 這些代碼分配的內(nèi)存并不多，甚至有些地方是不需要分配內(nèi)存的。

• 有些代碼并不是這個(gè)版本新加入的，已經(jīng)存在較長時(shí)間了。

• 使用裁剪功能的方法編譯并分析內(nèi)存后，基本可以確定是新加入代碼消耗了內(nèi)存，但并沒有內(nèi)存泄漏，代碼經(jīng)過review也沒有發(fā)現(xiàn)問題。

這個(gè)結(jié)果讓我們陷入了困惑，常用的方法找不出問題，說明有更深層次的原因。接下來要從更底層的Dalvik虛擬機(jī)尋找問題。

1.1 Dalvik Heap內(nèi)部機(jī)制

為了弄清楚為什么DVM占著內(nèi)存不釋放，我們閱讀了DVM分配內(nèi)存部分的代碼。位置在Android源碼的dalvik/vm/alloc下，約255K。分析出的主要流程如下：

1) DVM使用mmap系統(tǒng)調(diào)用從系統(tǒng)分配大塊內(nèi)存作為Java Heap。根據(jù)系統(tǒng)機(jī)制，如果分類的內(nèi)存尚未真正使用，就不計(jì)入PrivateDirty和PSS。例如圖1-8，Heap Size/Alloc很多，但大部分是共享，實(shí)際使用的較少。所以反映到PrivateDirty/PSS里的內(nèi)存并不多。

圖1-8 共享內(nèi)存較多的進(jìn)程

2) New對象之后，由于要向?qū)?yīng)的地址寫入數(shù)據(jù)，內(nèi)核開始真正分配該地址對應(yīng)的4K物理內(nèi)存頁面。

Alloc.cpp, 176行起：

3) 運(yùn)行一段時(shí)間后，開始GC，有些對象被回收了，有些會(huì)一直存在。

4) 在GC時(shí)，有可能會(huì)進(jìn)行trim。即將空閑的物理頁面釋放回系統(tǒng)，表現(xiàn)為PrivateDirty/PSS下降。

HeapSource.cpp, 431行：

1.2 問題所在

在了解DVM分配釋放內(nèi)存的機(jī)制后，根據(jù)dumpsys觀察到的現(xiàn)象，猜測可能出現(xiàn)了頁利用率問題（頁內(nèi)碎片）。如圖1-13所示，第一行：在開始階段，內(nèi)存分配的較滿。第二行：經(jīng)過GC后，大部分對象被釋放，少部分留下來。

這種情況下可能會(huì)產(chǎn)生的問題是，整頁的4K內(nèi)存中可能只有一個(gè)小對象，但統(tǒng)計(jì)PrivateDirty/PSS時(shí)還是按4K計(jì)算。

在通常的jvm虛擬機(jī)中，有Compacting GC機(jī)制，整理內(nèi)存對象，將散布的內(nèi)存移動(dòng)到一起。但根據(jù)DVM的代碼，DVM的Mark-Sweep算法不能移動(dòng)對象，即沒有內(nèi)存整理功能，這種情況下就會(huì)形成內(nèi)存空洞。

在猜測了可能的問題后，需要驗(yàn)證是否如猜測原因所致，由于MAT的對象實(shí)例數(shù)據(jù)中有地址和大小信息，我們先從MAT中導(dǎo)出數(shù)據(jù)。

在MAT中列出所有對象實(shí)例：list_objects java.*,然后選中所有數(shù)據(jù)導(dǎo)出為CSV格式，如下所示：

Class Name,Shallow Heap,Retained Heap,
class java.lang.Class @ 0x41fdd1e8,16,56,
class test.bxi$3 @ 0x432501c8,0,0,
class test.aaw$c$1 @ 0x4324fef8,0,0,
class test.ds @ 0x4324fc88,8,48,
class test.bxh @ 0x4324f438,8,248,
class test.bxg @ 0x4324f248,0,0,
class test.bxd$1 @ 0x4324f028,0,0,

處理導(dǎo)出的csv文件，按頁面進(jìn)行統(tǒng)計(jì)，取每個(gè)對象的地址的高位(&0xfffff000)，結(jié)果相同的對象處在同一頁面中。最后再按每個(gè)頁面所有對象的大小分類統(tǒng)計(jì)，做出直方圖如圖1-14所示。

這張圖就是被測應(yīng)用的頁面利用率分布圖，左邊是利用率低的頁面，右邊是利用率高的頁面。如果發(fā)現(xiàn)利用率低的頁面數(shù)目增加，說明小對象碎片的數(shù)量增加了。

1.3 優(yōu)化Dalvik內(nèi)存碎片

為了能夠找出有問題的代碼，我們將上一步得到的數(shù)據(jù)繼續(xù)處理。取出所有使用不滿2K的頁面的內(nèi)存塊地址，再使用OQL將地址導(dǎo)入到MAT中，分析地址對應(yīng)的對象是什么。如圖1-15所示就是將地址重新導(dǎo)入到MAT中得到的對象列表了：

在這里基本就能看出來是哪些對象造成了內(nèi)存的碎片化，數(shù)量比較多的前幾個(gè)類的自然嫌疑比較大，可以先對前幾個(gè)類的相關(guān)代碼進(jìn)行分析。也可以對這些代碼進(jìn)行針對性的內(nèi)存測試，觀察內(nèi)存情況。

通過對生成這些對象的代碼分析和模擬實(shí)驗(yàn)，我們還原出問題的基本過程：

• 生成對象過程需要較多的臨時(shí)變量。

• 批量生成過程中，由于還有空閑內(nèi)存，虛擬機(jī)沒有做GC。

• 完成后才進(jìn)行GC，清除了所有的零時(shí)變量，留下碎片化的內(nèi)存。

下圖是造成這個(gè)問題的類似代碼，執(zhí)行這段代碼將會(huì)在內(nèi)存中形成很多碎片，造成很高的PSS占用。

private Object result[] = new Object[100];
void foo() {
  for(int i = 0; i < 100; ++i) {
    byte[] tmp = new byte[2000];
    result[i] = new byte[4];
  }
}

顯示了類似情況下數(shù)組的分配范圍，可見數(shù)組中每個(gè)成員的內(nèi)存地址都是不連續(xù)的，并且相隔很遠(yuǎn)。這種情況下就會(huì)消耗很多個(gè)物理內(nèi)存頁面，增加Heap Free，造成例子中的問題。

根據(jù)上述的流程，我們搞清楚了造成問題的原因，并且找到了問題代碼。那么應(yīng)當(dāng)總結(jié)一些經(jīng)驗(yàn)，以供借鑒。對于測試人員來說，有以下兩個(gè)經(jīng)驗(yàn)：

• MAT是探索Java堆并發(fā)現(xiàn)問題的好幫手，能夠迅速發(fā)現(xiàn)常見的圖片和大數(shù)組等問題。但僅靠MAT提供的功能也不是萬能的，比如這個(gè)問題的數(shù)據(jù)就隱藏在對象的地址中。

• 對Android測試經(jīng)驗(yàn)來說，可能容易找到的是應(yīng)用代碼及框架的各種測試經(jīng)驗(yàn)和指導(dǎo)，底層以及涉及性能的測試經(jīng)驗(yàn)并不太多。這方面可以借鑒Linux系統(tǒng)的測試經(jīng)驗(yàn)，了解內(nèi)核及進(jìn)程相關(guān)的知識(shí)，熟悉常用工具。

• 內(nèi)存分配的最小單位是頁面，通常為4K。

對于開發(fā)人員，以下兩個(gè)經(jīng)驗(yàn)也許能有幫助：

• 盡量不要在循環(huán)中創(chuàng)建很多臨時(shí)變量。

• 可以將大型的循環(huán)拆散，分段或者按需執(zhí)行。

關(guān)于App的待機(jī)內(nèi)存增長的原因是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。