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

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

成都創(chuàng)新互聯(lián)是一家專業(yè)提供淳安企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、H5場景定制、小程序制作等業(yè)務(wù)。10年已為淳安眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進(jìn)行中。

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

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

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

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

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

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

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

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

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

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

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

這個結(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)存尚未真正使用，就不計入PrivateDirty和PSS。例如圖1-8，Heap Size/Alloc很多，但大部分是共享，實際使用的較少。所以反映到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)行一段時間后，開始GC，有些對象被回收了，有些會一直存在。

4)在GC時，有可能會進(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后，大部分對象被釋放，少部分留下來。

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

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

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

在MAT中列出所有對象實例：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)計，取每個對象的地址的高位(&0xfffff000)，結(jié)果相同的對象處在同一頁面中。最后再按每個頁面所有對象的大小分類統(tǒng)計，做出直方圖如圖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ù)量比較多的前幾個類的自然嫌疑比較大，可以先對前幾個類的相關(guān)代碼進(jìn)行分析。也可以對這些代碼進(jìn)行針對性的內(nèi)存測試，觀察內(nèi)存情況。

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

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

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

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

下圖是造成這個問題的類似代碼，執(zhí)行這段代碼將會在內(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ù)組中每個成員的內(nèi)存地址都是不連續(xù)的，并且相隔很遠(yuǎn)。這種情況下就會消耗很多個物理內(nèi)存頁面，增加Heap Free，造成例子中的問題。

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

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

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

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

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

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

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

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

網(wǎng)站名稱：App的待機(jī)內(nèi)存增長的原因是什么
本文來源：http://bm7419.com/article2/gegcoc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、建站公司、App設(shè)計、全網(wǎng)營銷推廣、網(wǎng)站設(shè)計公司、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

外貿(mào)網(wǎng)站制作