Android App性能評測分析－內(nèi)存篇

1、內(nèi)存了解

在Android App的性能優(yōu)化的各個部分里，內(nèi)存方面的知識較多且不易理解，內(nèi)存的問題絕對是最令人頭疼的一部分，需要對內(nèi)存基礎(chǔ)知識、內(nèi)存分配、內(nèi)存管理機制等非常熟悉，才能排查問題。

1.1 了解進程的地址空間

在32位操作系統(tǒng)中，進程的地址空間為0到4GB,這里主要說明一下Stack和Heap：
Stack空間（進棧和出棧）:

由操作系統(tǒng)控制，其中主要存儲函數(shù)地址、函數(shù)參數(shù)、局部變量等等，所以Stack空間不需要很大，一般為幾MB大小。

Heap空間:

它的使用由程序員控制，程序員可以使用malloc、new、free、delete等函數(shù)調(diào)用來操作這片地址空間。Heap為程序完成各種復(fù)雜任務(wù)提供內(nèi)存空間，所以空間比較大，一般為幾百MB到幾GB。正是因為Heap空間由程序員管理，所以容易出現(xiàn)使用不當導(dǎo)致嚴重問題。

進程地址空間-引用自CSDN.png

1.2 Android的內(nèi)存管理

Android系統(tǒng)的ART和Dalvik虛擬機扮演了常規(guī)的內(nèi)存垃圾自動回收的角色， 使用paging 和 memory-mapping來管理內(nèi)存，這意味著不管是因為創(chuàng)建對象還是使用使用內(nèi)存頁面造成的任何被修改的內(nèi)存，都會一直存在于內(nèi)存中，App唯一釋放內(nèi)存的方法就是釋放App持有的對象引用，使GC可以回收。

1.2.1 Android的應(yīng)用進程按共享/私有分類如下：

首先來了解什么是共享內(nèi)存

Android應(yīng)用的進程都是從一個叫做Zygote的進程fork出來的。Zygote進程在系統(tǒng)啟動并且載入通用的framework的代碼與資源之后開始啟動。為了啟動一個新的程序進程，系統(tǒng)會fork Zygote進程生成一個新的進程，然后在新的進程中加載并運行應(yīng)用程序的代碼。這使得大多數(shù)的RAM pages被用來分配給framework的代碼，同時使得RAM資源能夠在應(yīng)用的所有進程之間進行共享。
- 大多數(shù)static的數(shù)據(jù)被mmapped到一個進程中。這不僅僅使得同樣的數(shù)據(jù)能夠在進程間進行共享，而且使得它能夠在需要的時候被paged out。常見的static數(shù)據(jù)包括Dalvik Code，app resources，so文件等。
- 大多數(shù)情況下，Android通過顯式的分配共享內(nèi)存區(qū)域(例如ashmem或者gralloc)來實現(xiàn)動態(tài)RAM區(qū)域能夠在不同進程之間進行共享的機制。例如，Window Surface在App與Screen Compositor之間使用共享的內(nèi)存，Cursor Buffers在Content Provider與Clients之間共享內(nèi)存。


image.png

共享內(nèi)存：Dalvik虛擬機代碼、應(yīng)用框架的代碼、應(yīng)用框架的資源
應(yīng)用框架的SO庫。
私有內(nèi)存：應(yīng)用的代碼、應(yīng)用的資源、應(yīng)用的SO庫
共享/私有內(nèi)存：堆內(nèi)存，其他部分

1.2.2 android進程中內(nèi)存分類如下:

android進程中內(nèi)存分類.png

native heap：是lib層C/C++庫所占用的內(nèi)存（Native代碼分配的內(nèi)存，虛擬機和Android框架本身也會分配），不包含dalvik實例的linux進程，/system/bin/目錄下面的程序文件運行后都是以native進程形式存在的。
Dalvik heap：Dalvik虛擬機使用的內(nèi)存，包含dalvik-heap和dalvik-zygote，堆內(nèi)存，是java實例對象的空間
以上兩個heap空間完全由程序員控制，是最主要的兩塊內(nèi)存，另外還有下面3種：
Dalvik Other:類的數(shù)據(jù)結(jié)構(gòu)和索引
so mmap:Native代碼和常量
dex mmap:Java代碼和常量

1.2.3 查看內(nèi)存占用

通過命令行adb shell dumpsys meminfo packagename查看內(nèi)存詳細占用情況：

其中幾個關(guān)鍵的數(shù)據(jù)：

  • Private（Clean和Dirty的）：應(yīng)用進程單獨使用的內(nèi)存，代表著系統(tǒng)殺死你的進程后可以實際回收的內(nèi)存總量**。通常需要特別關(guān)注其中更為昂貴的dirty部分，它不僅只被你的進程使用而且會持續(xù)占用內(nèi)存而不能被從內(nèi)存中置換出存儲。申請的全部Dalvik和本地heap內(nèi)存都是Dirty的，和Zygote共享的Dalvik和本地heap內(nèi)存也都是Dirty的。
  • Dalvik Heap：Dalvik虛擬機使用的內(nèi)存，包含dalvik-heap和dalvik-zygote，堆內(nèi)存，所有的Java對象實例都放在這里。
  • Heap Alloc：累加了Dalvik和Native的heap。
  • PSS：這是加入與其他進程共享的分頁內(nèi)存后你的應(yīng)用占用的內(nèi)存量，你的進程單獨使用的全部內(nèi)存也會加入這個值里，多進程共享的內(nèi)存按照共享比例添加到PSS值中。如一個內(nèi)存分頁被兩個進程共享，每個進程的PSS值會包括此內(nèi)存分頁大小的一半在內(nèi)。
  • Dalvik Pss內(nèi)存 = 私有內(nèi)存Private Dirty + （共享內(nèi)存Shared Dirty / 共享進程數(shù)）
  • TOTAL：上面全部條目的累加值，全局的展示了你的進程占用的內(nèi)存情況。
  • ViewRootImpl：應(yīng)用進程里的活動窗口視圖個數(shù)，可以用來監(jiān)測對話框或者其他窗口的內(nèi)存泄露。
  • AppContexts及Activities：應(yīng)用進程里Context和Activity的對象個數(shù)，可以用來監(jiān)測Activity的內(nèi)存泄露。

1.3 內(nèi)存回收

在Android的高級系統(tǒng)版本里面針對Heap空間有一個Generational Heap Memory的模型，最近分配的對象會存放在Young Generation區(qū)域，當這個對象在這個區(qū)域停留的時間達到一定程度，它會被移動到Old Generation，最后累積一定時間再移動到Permanent Generation區(qū)域。系統(tǒng)會根據(jù)內(nèi)存中不同的內(nèi)存數(shù)據(jù)類型分別執(zhí)行不同的gc操作。例如，剛分配到Y(jié)oung Generation區(qū)域的對象通常更容易被銷毀回收，同時在Young Generation區(qū)域的gc操作速度會比Old Generation區(qū)域的gc操作速度更快。

2、內(nèi)存測試方法

基于上面的理論學(xué)習(xí)，可以知道內(nèi)存問題基本上就是三種：內(nèi)存抖動、內(nèi)存泄漏、內(nèi)存溢出。我們測試內(nèi)存的時候也主要關(guān)注這三個測試點。至于用什么方法進行測試，下面簡單列舉一下工具，基本上網(wǎng)上都有關(guān)于工具使用很詳細的教程，在此不再詳細述說。

2.1 檢測內(nèi)存抖動

內(nèi)存抖動：大量的對象被創(chuàng)建又在短時間內(nèi)馬上被釋放。
瞬間產(chǎn)生大量的對象會嚴重占用Young Generation的內(nèi)存區(qū)域，當達到閥值，剩余空間不夠的時候，也會觸發(fā)GC。系統(tǒng)花費在GC上的時間越多，進行界面繪制或流音頻處理的時間就越短。即使每次分配的對象占用了很少的內(nèi)存，但是他們疊加在一起會增加Heap的壓力，從而觸發(fā)更多其他類型的GC。這個操作有可能會影響到幀率，并使得用戶感知到性能問題。

  • Memory Monitor：查看整個app所占用的內(nèi)存，以及發(fā)生GC的時刻，短時間內(nèi)發(fā)生大量的GC操作是一個危險的信號（用于發(fā)現(xiàn)有沒有內(nèi)存泄漏和嚴重內(nèi)存抖動）。
    例如：存在內(nèi)存抖動.png

2.2 檢測內(nèi)存泄漏

內(nèi)存泄露可以引發(fā)很多的問題：
1.程序卡頓，響應(yīng)速度慢（內(nèi)存占用高時JVM虛擬機會頻繁觸發(fā)GC）
2.莫名消失（當你的程序所占內(nèi)存越大，它在后臺的時候就越可能被干掉。反之內(nèi)存占用越小，在后臺存在的時間就越長）
3.直接崩潰（OutOfMemoryError）
內(nèi)存泄漏無疑會嚴重影響用戶體驗，一些本應(yīng)該廢棄的資源和對象無法被釋放，導(dǎo)致手機內(nèi)存的浪費，app使用的卡頓，那么如何排查內(nèi)存泄漏呢？

一個terminal指令：

adb shelldumpsys meminfo （package name）

這條指令是用來查詢這個進程所占用的內(nèi)存的具體詳情的，通過這條指令可以看到當前app在手機中占用的具體的堆內(nèi)存大小，view的數(shù)量，activity的數(shù)量等等。

meminfo_內(nèi)存泄漏.png

其中activity數(shù)目是非常關(guān)鍵的一個信息，可以幫助我們快速地檢測出內(nèi)存泄漏。我們可以反復(fù)地進入退出需要測試的目標activity，如果在反復(fù)進入退出之后，用terminal執(zhí)行上面的語句查詢當前的內(nèi)存情況，如果發(fā)現(xiàn)activity數(shù)量一直在增長，如上圖所示，APP退出后，再進入相當界面時Views和activity數(shù)量成倍地增長，則很大可能存在內(nèi)存泄漏。

另外以下4個是用于定位的內(nèi)存抖動和內(nèi)存泄漏發(fā)生的具體位置·

  • Allocation Tracker：

使用此工具來追蹤內(nèi)存的分配.
但是事實上，通過觀察這個內(nèi)存曲線的增長來或者是觀察allocate tracker中的allocate data數(shù)值的增長來檢測是否有內(nèi)存泄漏問題，不太靠譜，因為往往內(nèi)存泄漏發(fā)生了，但是GC仍然可以通過回收其他對象的方式騰出空間，導(dǎo)致這個數(shù)據(jù)的變化基本看不出來，甚至是減小的。

  • Heap Tool：

查看當前內(nèi)存快照，便于對比分析哪些對象有可能是泄漏了的。

  • Memory monitor :

如果是Dalvik內(nèi)存泄漏，也可以使用Android Device Monitor dump出一份hprof文件（別忘了先手工Cause GC），生成hprof文件進行測試分析。用hprof分析工具，可以檢測到泄漏的activities、分析出重復(fù)定義的字符串。

memory monitor.png

這里能夠?qū)崟r地顯示應(yīng)用程序占用的內(nèi)存，很方便我們查看?？偟膩碚f，就是使用monitor memory功能監(jiān)測app主進程占用的內(nèi)存，觸發(fā)GC操作，而后觀察內(nèi)存的占用情況，如果在使用的過程中內(nèi)存不斷增加，沒有回落，很有可能發(fā)生了內(nèi)存泄漏，這時候就需要對生成的HPROF文件進行深入分析了。
hprof.png
使用HPROF文件分析工具標準步驟如下：
（1）、打開Captures窗口，雙擊你想要查看的HPROF文件，打開HPROF文件查看工具界面；
（2）、點擊Android Studio主窗口右邊欄上的Analyzer Tasks，默認HPROF文件分析工具會出現(xiàn)在HPROF文件查看工具的右邊。Analyzer Tasks列表中選擇你想分析的選項；
（3）、點擊開始分析的按鈕；
（4）、查看分析結(jié)果，點擊結(jié)果中條目可在HPROF文件分析工具中查看詳情。一般查看Retained Size占用最大的類，分析是否有內(nèi)存泄漏。

名稱 描述
Class name 類名
Total Count 該類的實例總數(shù)
Heap Count 所選擇的堆中該類的實例的數(shù)量
Sizeof 單個實例所占空間大?。ㄈ绻總€實例所占空間大小不一樣則顯示0）
Shallow Size 堆里所有實例大小總和（Heap Count * Sizeof）
Retained Size 當該對象被GC回收時，所釋放掉的內(nèi)存大小
Instance 具體的實例
Reference Tree 所選實例的引用，以及指向該引用的引用。
Depth GC根節(jié)點到所選實例的最短路徑的深度
Shallow Size 所選實例的大小
Dominating Size 所選實例所支配的內(nèi)存大小
  • MAT
    上述只是可以粗略的看出是不是有問題，而要知道問題出在哪里就需要借助MAT了。將生成的.hprof文件進行轉(zhuǎn)換，然后使用MAT打開來分析應(yīng)用的內(nèi)存使用情況。通常在使用MAT打開hprof文件后，能夠在首頁看到Top Comnsumers和 component Report等功能，我們可以快速定位一些大塊的內(nèi)存消耗。
    TOP列表.png

    但我們在分析時會發(fā)現(xiàn)系統(tǒng)資源類占據(jù)了很大一部分內(nèi)存，因此為去除這部分對分析的干擾，我們在使用AndroidSDK提供的hprof-conv轉(zhuǎn)換時需要增加一個參數(shù)：
hporf- conv [-z] <infile><outfile> -z:exclude non-app heaps,such as Zygote

如果hprof文件是已經(jīng)轉(zhuǎn)換過的，則可以使用OQL:

//在數(shù)據(jù)中尋找應(yīng)用的Application類對象，將對象地址轉(zhuǎn)換為十進制后輸入以下查詢語句:
select * from instanceof java.langObject s where s.@objectAddress> 1107296256
//(后面那串數(shù)字應(yīng)該是Application類對象的地址)

采用這兩種方法后，再使用MAT來分析就可以比較容易發(fā)現(xiàn)自身代碼的內(nèi)存問題。

附：更多具體詳細教程及其他排查經(jīng)驗請參考以下鏈接：
Android 性能優(yōu)化之內(nèi)存泄漏的檢測與修復(fù)：http://blog.csdn.net/cleverGump/article/details/52013873
這一次，我優(yōu)化了37%的內(nèi)存：
http://wetest.qq.com/lab/view/147.html

  • 小結(jié)
  • MAT 是探索 Java 堆并發(fā)現(xiàn)問題和好幫手，能夠迅速發(fā)現(xiàn)常見的圖片和大數(shù)組等問題；
  • 內(nèi)存碎片問題一般隱藏在對象的地址中；
  • 如需要測試非 Dalvik部分，有必要了解 Linux 的進程和內(nèi)存原理、內(nèi)存共享機制，熟悉常用命令行工具；
  • 內(nèi)存分配的最小單位是頁面，通常為4KB，這個限制會引發(fā)各種問題；

2.3 檢測OOM

Android系統(tǒng)的每個進程都有一個最大內(nèi)存限制（這個閾值可以是48M、24M、16M等，視機型而定），如果申請的內(nèi)存資源超過這個限制，系統(tǒng)就會拋出OOM錯誤。
PS:可以通過adb命令查看閾值

adb shell getprop | grep dalvik.vm.heapgrowthlimit
[dalvik.vm.heapgrowthlimit]: [192m]
  • Android 2.x系統(tǒng)，當dalvik allocated + external allocated + 新分配的大小 >= dalvik heap 最大值時候就會發(fā)生OOM。其中bitmap是放于external中 。
  • Android 4.x系統(tǒng)，廢除了external的計數(shù)器，類似bitmap的分配改到dalvik的java heap中申請，只要allocated + 新分配的內(nèi)存 >= dalvik heap 最大值的時候就會發(fā)生OOM（art運行環(huán)境的統(tǒng)計規(guī)則還是和dalvik保持一致）

內(nèi)存溢出是程序運行到某一階段的最終結(jié)果，直接原因是剩余的內(nèi)存不能滿足內(nèi)存的申請，但是再分析間接原因內(nèi)存為什么沒有了：

  • 內(nèi)存泄漏的存在可能導(dǎo)致可用內(nèi)存越來越少；
  • 內(nèi)存申請的峰值超過了系統(tǒng)時間點剩余的內(nèi)存；(例如：某手機單個進程可用最大內(nèi)存為192M，目前分配內(nèi)存80M，此時申請5M內(nèi)存，但是當前時間點整個系統(tǒng)可用內(nèi)存只有3M，此時沒有超出單個進程可用最大內(nèi)存，但是OOM也會發(fā)生)

2.4 常見內(nèi)存測試場景

2.4.1 按各部分內(nèi)存的用途設(shè)計場景

（1）比較操作前后或不同版本的內(nèi)存變化
（2）顯示多張圖片的前臺進程
（3）多個場景來回切換
（4）長時間運行進程的內(nèi)存增長

2.4.1 根據(jù)比較結(jié)果，確定問題方向
android進程中內(nèi)存分類.png

（1）Dalvik Heap內(nèi)存

持續(xù)增長
內(nèi)存泄露 -> LeakCanary / MAT

頻繁GC，大幅度波動
大量的分配和釋放 -> Allocation Tracker
比以前版本穩(wěn)定增長
新功能及代碼改動 -> Heap Dump / MAT
Heap Alloc不變，PSS增加
可能存在內(nèi)存碎片 -> Heap Dump / MAT

（2）非Heap內(nèi)存

Dalvik Other
類信息
載入Class數(shù)正相關(guān)
mmaps
可執(zhí)行代碼
常量

3、XX銀行性能評測-內(nèi)存測試結(jié)果分析

3.1 總覽

此次質(zhì)量開放平臺-評測中心（http://fit-stg1.jryzt.com/Hyperion-server/html/index.html）的性能測試的采集的內(nèi)存數(shù)據(jù)主要是針對場景頁面的內(nèi)存占用測試，內(nèi)存占用數(shù)據(jù)獲取原理是從memoryinfo中獲取。

從內(nèi)存占用對比看，行業(yè)競品均值為351.3M，90分位約262.6M，75分位約339.5M，中位數(shù)約426.4M，25分位約605.7M?！鹃派藼ank】內(nèi)存占用均值為246M，表現(xiàn)良好，打敗了行業(yè)90%以上的競品，請繼續(xù)保持哦。

image.png

3.2 啟動首頁加載內(nèi)存問題分析--存在內(nèi)存抖動

這里選取了啟動加載場景來進行內(nèi)存問題的分析。

實際上從上面的總覽數(shù)據(jù)分析看內(nèi)存占用不同場景對比很難發(fā)現(xiàn)內(nèi)存問題，但是同一個場景內(nèi)存占用曲線圖是可以發(fā)現(xiàn)問題的，如果曲線圖有鋸齒形的抖動且持續(xù)上升，基本上可能存在內(nèi)存問題，如下圖可得出首頁存在內(nèi)存抖動問題


首頁加載內(nèi)存抖動圖1.png

首頁加載內(nèi)存抖動圖2.png

另外還需要以日志輔助分析內(nèi)存問題：從日志上看，1秒甚至幾百ms內(nèi)就有一次GC，而且是主動GC，說明在頻繁申請內(nèi)存,總阻塞耗時約5001 ms


GC.png
GC日志.png

注釋：

  • GC Reason：GC觸發(fā)原因
  • GC_CONCURRENT：當已分配內(nèi)存達到某一值時，觸發(fā)并發(fā)GC；
  • GC_FOR_MALLOC：當嘗試在堆上分配內(nèi)存不足時觸發(fā)的GC；系統(tǒng)必須停止應(yīng)用程序并回收內(nèi)存；
    -GC_HPROF_DUMP_HEAP： 當需要創(chuàng)建HPROF文件來分析堆內(nèi)存時觸發(fā)的GC；
    -GC_EXPLICIT：當明確的調(diào)用GC時，例如調(diào)用System.gc()或者通過DDMS工具顯式地告訴系統(tǒng)進行GC操作等；
  • Amount freed GC：回收的內(nèi)存大小
  • Heap stats：堆上的空閑內(nèi)存百分比 （已用內(nèi)存）/（堆上總內(nèi)存）
  • Pause time：這次GC操作導(dǎo)致應(yīng)用程序暫停的時間。關(guān)于這個暫停的時間，在2.3之前GC操作是不能并發(fā)進行的，也就是系統(tǒng)正在進行GC，那么應(yīng)用程序就只能阻塞住等待GC結(jié)束。而自2.3之后，GC操作改成了并發(fā)的方式進行，就是說GC的過程中不會影響到應(yīng)用程序的正常運行，但是在GC操作的開始和結(jié)束的時候會短暫阻塞一段時間。

4、App端內(nèi)存問題排查思路：

（1）Service停止使用時，是否被銷毀

（2） 當界面變?yōu)椴豢梢姇r，是否釋放當前界面的資源

（3）內(nèi)存變少時，是否有釋放內(nèi)存

（4） bitmap使用完之后是否被回收

（5）是否有大量第三方庫的消耗

參考：

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容