1、內(nèi)存了解
在Android App的性能優(yōu)化的各個(gè)部分里，內(nèi)存方面的知識(shí)較多且不易理解，內(nèi)存的問(wèn)題絕對(duì)是最令人頭疼的一部分，需要對(duì)內(nèi)存基礎(chǔ)知識(shí)、內(nèi)存分配、內(nèi)存管理機(jī)制等非常熟悉，才能排查問(wèn)題。
1.1 了解進(jìn)程的地址空間
在32位操作系統(tǒng)中，進(jìn)程的地址空間為0到4GB,這里主要說(shuō)明一下Stack和Heap：
Stack空間（進(jìn)棧和出棧）:
由操作系統(tǒng)控制，其中主要存儲(chǔ)函數(shù)地址、函數(shù)參數(shù)、局部變量等等，所以Stack空間不需要很大，一般為幾MB大小。
Heap空間:
它的使用由程序員控制，程序員可以使用malloc、new、free、delete等函數(shù)調(diào)用來(lái)操作這片地址空間。Heap為程序完成各種復(fù)雜任務(wù)提供內(nèi)存空間，所以空間比較大，一般為幾百M(fèi)B到幾GB。正是因?yàn)镠eap空間由程序員管理，所以容易出現(xiàn)使用不當(dāng)導(dǎo)致嚴(yán)重問(wèn)題。
1.2 Android的內(nèi)存管理
Android系統(tǒng)的ART和Dalvik虛擬機(jī)扮演了常規(guī)的內(nèi)存垃圾自動(dòng)回收的角色， 使用paging 和 memory-mapping來(lái)管理內(nèi)存，這意味著不管是因?yàn)閯?chuàng)建對(duì)象還是使用使用內(nèi)存頁(yè)面造成的任何被修改的內(nèi)存，都會(huì)一直存在于內(nèi)存中，App唯一釋放內(nèi)存的方法就是釋放App持有的對(duì)象引用，使GC可以回收。
1.2.1 Android的應(yīng)用進(jìn)程按共享/私有分類(lèi)如下：
首先來(lái)了解什么是共享內(nèi)存
Android應(yīng)用的進(jìn)程都是從一個(gè)叫做Zygote的進(jìn)程fork出來(lái)的。Zygote進(jìn)程在系統(tǒng)啟動(dòng)并且載入通用的framework的代碼與資源之后開(kāi)始啟動(dòng)。為了啟動(dòng)一個(gè)新的程序進(jìn)程，系統(tǒng)會(huì)fork Zygote進(jìn)程生成一個(gè)新的進(jìn)程，然后在新的進(jìn)程中加載并運(yùn)行應(yīng)用程序的代碼。這使得大多數(shù)的RAM pages被用來(lái)分配給framework的代碼，同時(shí)使得RAM資源能夠在應(yīng)用的所有進(jìn)程之間進(jìn)行共享。
- 大多數(shù)static的數(shù)據(jù)被mmapped到一個(gè)進(jìn)程中。這不僅僅使得同樣的數(shù)據(jù)能夠在進(jìn)程間進(jìn)行共享，而且使得它能夠在需要的時(shí)候被paged out。常見(jiàn)的static數(shù)據(jù)包括Dalvik Code，app resources，so文件等。
- 大多數(shù)情況下，Android通過(guò)顯式的分配共享內(nèi)存區(qū)域(例如ashmem或者gralloc)來(lái)實(shí)現(xiàn)動(dòng)態(tài)RAM區(qū)域能夠在不同進(jìn)程之間進(jìn)行共享的機(jī)制。例如，Window Surface在App與Screen Compositor之間使用共享的內(nèi)存，Cursor Buffers在Content Provider與Clients之間共享內(nèi)存。
image.png
共享內(nèi)存：Dalvik虛擬機(jī)代碼、應(yīng)用框架的代碼、應(yīng)用框架的資源
應(yīng)用框架的SO庫(kù)。
私有內(nèi)存：應(yīng)用的代碼、應(yīng)用的資源、應(yīng)用的SO庫(kù)
共享/私有內(nèi)存：堆內(nèi)存，其他部分
1.2.2 android進(jìn)程中內(nèi)存分類(lèi)如下:
native heap：是lib層C/C++庫(kù)所占用的內(nèi)存（Native代碼分配的內(nèi)存，虛擬機(jī)和Android框架本身也會(huì)分配），不包含dalvik實(shí)例的linux進(jìn)程，/system/bin/目錄下面的程序文件運(yùn)行后都是以native進(jìn)程形式存在的。
Dalvik heap：Dalvik虛擬機(jī)使用的內(nèi)存，包含dalvik-heap和dalvik-zygote，堆內(nèi)存，是java實(shí)例對(duì)象的空間
以上兩個(gè)heap空間完全由程序員控制，是最主要的兩塊內(nèi)存，另外還有下面3種：
Dalvik Other:類(lèi)的數(shù)據(jù)結(jié)構(gòu)和索引
so mmap:Native代碼和常量
dex mmap:Java代碼和常量
1.2.3 查看內(nèi)存占用
通過(guò)命令行adb shell dumpsys meminfo packagename查看內(nèi)存詳細(xì)占用情況：
其中幾個(gè)關(guān)鍵的數(shù)據(jù)：
- Private（Clean和Dirty的）：應(yīng)用進(jìn)程單獨(dú)使用的內(nèi)存，代表著系統(tǒng)殺死你的進(jìn)程后可以實(shí)際回收的內(nèi)存總量**。通常需要特別關(guān)注其中更為昂貴的dirty部分，它不僅只被你的進(jìn)程使用而且會(huì)持續(xù)占用內(nèi)存而不能被從內(nèi)存中置換出存儲(chǔ)。申請(qǐng)的全部Dalvik和本地heap內(nèi)存都是Dirty的，和Zygote共享的Dalvik和本地heap內(nèi)存也都是Dirty的。
- Dalvik Heap：Dalvik虛擬機(jī)使用的內(nèi)存，包含dalvik-heap和dalvik-zygote，堆內(nèi)存，所有的Java對(duì)象實(shí)例都放在這里。
- Heap Alloc：累加了Dalvik和Native的heap。
- PSS：這是加入與其他進(jìn)程共享的分頁(yè)內(nèi)存后你的應(yīng)用占用的內(nèi)存量，你的進(jìn)程單獨(dú)使用的全部?jī)?nèi)存也會(huì)加入這個(gè)值里，多進(jìn)程共享的內(nèi)存按照共享比例添加到PSS值中。如一個(gè)內(nèi)存分頁(yè)被兩個(gè)進(jìn)程共享，每個(gè)進(jìn)程的PSS值會(huì)包括此內(nèi)存分頁(yè)大小的一半在內(nèi)。
- Dalvik Pss內(nèi)存 = 私有內(nèi)存Private Dirty + （共享內(nèi)存Shared Dirty / 共享進(jìn)程數(shù)）
- TOTAL：上面全部條目的累加值，全局的展示了你的進(jìn)程占用的內(nèi)存情況。
- ViewRootImpl：應(yīng)用進(jìn)程里的活動(dòng)窗口視圖個(gè)數(shù)，可以用來(lái)監(jiān)測(cè)對(duì)話(huà)框或者其他窗口的內(nèi)存泄露。
- AppContexts及Activities：應(yīng)用進(jìn)程里Context和Activity的對(duì)象個(gè)數(shù)，可以用來(lái)監(jiān)測(cè)Activity的內(nèi)存泄露。
1.3 內(nèi)存回收
在Android的高級(jí)系統(tǒng)版本里面針對(duì)Heap空間有一個(gè)Generational Heap Memory的模型，最近分配的對(duì)象會(huì)存放在Young Generation區(qū)域，當(dāng)這個(gè)對(duì)象在這個(gè)區(qū)域停留的時(shí)間達(dá)到一定程度，它會(huì)被移動(dòng)到Old Generation，最后累積一定時(shí)間再移動(dòng)到Permanent Generation區(qū)域。系統(tǒng)會(huì)根據(jù)內(nèi)存中不同的內(nèi)存數(shù)據(jù)類(lèi)型分別執(zhí)行不同的gc操作。例如，剛分配到Y(jié)oung Generation區(qū)域的對(duì)象通常更容易被銷(xiāo)毀回收，同時(shí)在Young Generation區(qū)域的gc操作速度會(huì)比Old Generation區(qū)域的gc操作速度更快。
2、內(nèi)存測(cè)試方法
基于上面的理論學(xué)習(xí)，可以知道內(nèi)存問(wèn)題基本上就是三種：內(nèi)存抖動(dòng)、內(nèi)存泄漏、內(nèi)存溢出。我們測(cè)試內(nèi)存的時(shí)候也主要關(guān)注這三個(gè)測(cè)試點(diǎn)。至于用什么方法進(jìn)行測(cè)試，下面簡(jiǎn)單列舉一下工具，基本上網(wǎng)上都有關(guān)于工具使用很詳細(xì)的教程，在此不再詳細(xì)述說(shuō)。
2.1 檢測(cè)內(nèi)存抖動(dòng)
內(nèi)存抖動(dòng)：大量的對(duì)象被創(chuàng)建又在短時(shí)間內(nèi)馬上被釋放。
瞬間產(chǎn)生大量的對(duì)象會(huì)嚴(yán)重占用Young Generation的內(nèi)存區(qū)域，當(dāng)達(dá)到閥值，剩余空間不夠的時(shí)候，也會(huì)觸發(fā)GC。系統(tǒng)花費(fèi)在GC上的時(shí)間越多，進(jìn)行界面繪制或流音頻處理的時(shí)間就越短。即使每次分配的對(duì)象占用了很少的內(nèi)存，但是他們疊加在一起會(huì)增加Heap的壓力，從而觸發(fā)更多其他類(lèi)型的GC。這個(gè)操作有可能會(huì)影響到幀率，并使得用戶(hù)感知到性能問(wèn)題。
- Memory Monitor：查看整個(gè)app所占用的內(nèi)存，以及發(fā)生GC的時(shí)刻，短時(shí)間內(nèi)發(fā)生大量的GC操作是一個(gè)危險(xiǎn)的信號(hào)（用于發(fā)現(xiàn)有沒(méi)有內(nèi)存泄漏和嚴(yán)重內(nèi)存抖動(dòng)）。
例如：存在內(nèi)存抖動(dòng).png
2.2 檢測(cè)內(nèi)存泄漏
內(nèi)存泄露可以引發(fā)很多的問(wèn)題：
1.程序卡頓，響應(yīng)速度慢（內(nèi)存占用高時(shí)JVM虛擬機(jī)會(huì)頻繁觸發(fā)GC）
2.莫名消失（當(dāng)你的程序所占內(nèi)存越大，它在后臺(tái)的時(shí)候就越可能被干掉。反之內(nèi)存占用越小，在后臺(tái)存在的時(shí)間就越長(zhǎng)）
3.直接崩潰（OutOfMemoryError）
內(nèi)存泄漏無(wú)疑會(huì)嚴(yán)重影響用戶(hù)體驗(yàn)，一些本應(yīng)該廢棄的資源和對(duì)象無(wú)法被釋放，導(dǎo)致手機(jī)內(nèi)存的浪費(fèi)，app使用的卡頓，那么如何排查內(nèi)存泄漏呢？
一個(gè)terminal指令：
adb shelldumpsys meminfo （package name）
這條指令是用來(lái)查詢(xún)這個(gè)進(jìn)程所占用的內(nèi)存的具體詳情的，通過(guò)這條指令可以看到當(dāng)前app在手機(jī)中占用的具體的堆內(nèi)存大小，view的數(shù)量，activity的數(shù)量等等。
其中activity數(shù)目是非常關(guān)鍵的一個(gè)信息，可以幫助我們快速地檢測(cè)出內(nèi)存泄漏。我們可以反復(fù)地進(jìn)入退出需要測(cè)試的目標(biāo)activity，如果在反復(fù)進(jìn)入退出之后，用terminal執(zhí)行上面的語(yǔ)句查詢(xún)當(dāng)前的內(nèi)存情況，如果發(fā)現(xiàn)activity數(shù)量一直在增長(zhǎng)，如上圖所示，APP退出后，再進(jìn)入相當(dāng)界面時(shí)Views和activity數(shù)量成倍地增長(zhǎng)，則很大可能存在內(nèi)存泄漏。
另外以下4個(gè)是用于定位的內(nèi)存抖動(dòng)和內(nèi)存泄漏發(fā)生的具體位置·
- Allocation Tracker：
使用此工具來(lái)追蹤內(nèi)存的分配.
但是事實(shí)上，通過(guò)觀察這個(gè)內(nèi)存曲線(xiàn)的增長(zhǎng)來(lái)或者是觀察allocate tracker中的allocate data數(shù)值的增長(zhǎng)來(lái)檢測(cè)是否有內(nèi)存泄漏問(wèn)題，不太靠譜，因?yàn)橥鶅?nèi)存泄漏發(fā)生了，但是GC仍然可以通過(guò)回收其他對(duì)象的方式騰出空間，導(dǎo)致這個(gè)數(shù)據(jù)的變化基本看不出來(lái)，甚至是減小的。
- Heap Tool：
查看當(dāng)前內(nèi)存快照，便于對(duì)比分析哪些對(duì)象有可能是泄漏了的。
- Memory monitor :
如果是Dalvik內(nèi)存泄漏，也可以使用Android Device Monitor dump出一份hprof文件（別忘了先手工Cause GC），生成hprof文件進(jìn)行測(cè)試分析。用hprof分析工具，可以檢測(cè)到泄漏的activities、分析出重復(fù)定義的字符串。
這里能夠?qū)崟r(shí)地顯示應(yīng)用程序占用的內(nèi)存，很方便我們查看。總的來(lái)說(shuō)，就是使用monitor memory功能監(jiān)測(cè)app主進(jìn)程占用的內(nèi)存，觸發(fā)GC操作，而后觀察內(nèi)存的占用情況，如果在使用的過(guò)程中內(nèi)存不斷增加，沒(méi)有回落，很有可能發(fā)生了內(nèi)存泄漏，這時(shí)候就需要對(duì)生成的HPROF文件進(jìn)行深入分析了。
（1）、打開(kāi)Captures窗口，雙擊你想要查看的HPROF文件，打開(kāi)HPROF文件查看工具界面；
（2）、點(diǎn)擊Android Studio主窗口右邊欄上的Analyzer Tasks，默認(rèn)HPROF文件分析工具會(huì)出現(xiàn)在HPROF文件查看工具的右邊。Analyzer Tasks列表中選擇你想分析的選項(xiàng)；
（3）、點(diǎn)擊開(kāi)始分析的按鈕；
（4）、查看分析結(jié)果，點(diǎn)擊結(jié)果中條目可在HPROF文件分析工具中查看詳情。一般查看Retained Size占用最大的類(lèi)，分析是否有內(nèi)存泄漏。
| 名稱(chēng) | 描述 |
|---|---|
| Class name | 類(lèi)名 |
| Total Count | 該類(lèi)的實(shí)例總數(shù) |
| Heap Count | 所選擇的堆中該類(lèi)的實(shí)例的數(shù)量 |
| Sizeof | 單個(gè)實(shí)例所占空間大小（如果每個(gè)實(shí)例所占空間大小不一樣則顯示0） |
| Shallow Size | 堆里所有實(shí)例大小總和（Heap Count * Sizeof） |
| Retained Size | 當(dāng)該對(duì)象被GC回收時(shí)，所釋放掉的內(nèi)存大小 |
| Instance | 具體的實(shí)例 |
| Reference Tree | 所選實(shí)例的引用，以及指向該引用的引用。 |
| Depth | GC根節(jié)點(diǎn)到所選實(shí)例的最短路徑的深度 |
| Shallow Size | 所選實(shí)例的大小 |
| Dominating Size | 所選實(shí)例所支配的內(nèi)存大小 |
-
MAT
上述只是可以粗略的看出是不是有問(wèn)題，而要知道問(wèn)題出在哪里就需要借助MAT了。將生成的.hprof文件進(jìn)行轉(zhuǎn)換，然后使用MAT打開(kāi)來(lái)分析應(yīng)用的內(nèi)存使用情況。通常在使用MAT打開(kāi)hprof文件后，能夠在首頁(yè)看到Top Comnsumers和 component Report等功能，我們可以快速定位一些大塊的內(nèi)存消耗。
TOP列表.png
但我們?cè)诜治鰰r(shí)會(huì)發(fā)現(xiàn)系統(tǒng)資源類(lèi)占據(jù)了很大一部分內(nèi)存，因此為去除這部分對(duì)分析的干擾，我們?cè)谑褂肁ndroidSDK提供的hprof-conv轉(zhuǎn)換時(shí)需要增加一個(gè)參數(shù)：
hporf- conv [-z] <infile><outfile> -z:exclude non-app heaps,such as Zygote
如果hprof文件是已經(jīng)轉(zhuǎn)換過(guò)的，則可以使用OQL:
//在數(shù)據(jù)中尋找應(yīng)用的Application類(lèi)對(duì)象，將對(duì)象地址轉(zhuǎn)換為十進(jìn)制后輸入以下查詢(xún)語(yǔ)句:
select * from instanceof java.langObject s where s.@objectAddress> 1107296256
//(后面那串?dāng)?shù)字應(yīng)該是Application類(lèi)對(duì)象的地址)
采用這兩種方法后，再使用MAT來(lái)分析就可以比較容易發(fā)現(xiàn)自身代碼的內(nèi)存問(wèn)題。
附：更多具體詳細(xì)教程及其他排查經(jīng)驗(yàn)請(qǐng)參考以下鏈接：
Android 性能優(yōu)化之內(nèi)存泄漏的檢測(cè)與修復(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)問(wèn)題和好幫手，能夠迅速發(fā)現(xiàn)常見(jiàn)的圖片和大數(shù)組等問(wèn)題；
- 內(nèi)存碎片問(wèn)題一般隱藏在對(duì)象的地址中；
- 如需要測(cè)試非 Dalvik部分，有必要了解 Linux 的進(jìn)程和內(nèi)存原理、內(nèi)存共享機(jī)制，熟悉常用命令行工具；
- 內(nèi)存分配的最小單位是頁(yè)面，通常為4KB，這個(gè)限制會(huì)引發(fā)各種問(wèn)題；
2.3 檢測(cè)OOM
Android系統(tǒng)的每個(gè)進(jìn)程都有一個(gè)最大內(nèi)存限制（這個(gè)閾值可以是48M、24M、16M等，視機(jī)型而定），如果申請(qǐng)的內(nèi)存資源超過(guò)這個(gè)限制，系統(tǒng)就會(huì)拋出OOM錯(cuò)誤。
PS:可以通過(guò)adb命令查看閾值
adb shell getprop | grep dalvik.vm.heapgrowthlimit
[dalvik.vm.heapgrowthlimit]: [192m]
- Android 2.x系統(tǒng)，當(dāng)dalvik allocated + external allocated + 新分配的大小 >= dalvik heap 最大值時(shí)候就會(huì)發(fā)生OOM。其中bitmap是放于external中 。
- Android 4.x系統(tǒng)，廢除了external的計(jì)數(shù)器，類(lèi)似bitmap的分配改到dalvik的java heap中申請(qǐng)，只要allocated + 新分配的內(nèi)存 >= dalvik heap 最大值的時(shí)候就會(huì)發(fā)生OOM（art運(yùn)行環(huán)境的統(tǒng)計(jì)規(guī)則還是和dalvik保持一致）
內(nèi)存溢出是程序運(yùn)行到某一階段的最終結(jié)果，直接原因是剩余的內(nèi)存不能滿(mǎn)足內(nèi)存的申請(qǐng)，但是再分析間接原因內(nèi)存為什么沒(méi)有了：
- 內(nèi)存泄漏的存在可能導(dǎo)致可用內(nèi)存越來(lái)越少；
- 內(nèi)存申請(qǐng)的峰值超過(guò)了系統(tǒng)時(shí)間點(diǎn)剩余的內(nèi)存；(例如：某手機(jī)單個(gè)進(jìn)程可用最大內(nèi)存為192M，目前分配內(nèi)存80M，此時(shí)申請(qǐng)5M內(nèi)存，但是當(dāng)前時(shí)間點(diǎn)整個(gè)系統(tǒng)可用內(nèi)存只有3M，此時(shí)沒(méi)有超出單個(gè)進(jìn)程可用最大內(nèi)存，但是OOM也會(huì)發(fā)生)
2.4 常見(jiàn)內(nèi)存測(cè)試場(chǎng)景
2.4.1 按各部分內(nèi)存的用途設(shè)計(jì)場(chǎng)景
（1）比較操作前后或不同版本的內(nèi)存變化
（2）顯示多張圖片的前臺(tái)進(jìn)程
（3）多個(gè)場(chǎng)景來(lái)回切換
（4）長(zhǎng)時(shí)間運(yùn)行進(jìn)程的內(nèi)存增長(zhǎng)
2.4.1 根據(jù)比較結(jié)果，確定問(wèn)題方向
（1）Dalvik Heap內(nèi)存
持續(xù)增長(zhǎng)
內(nèi)存泄露 -> LeakCanary / MAT
頻繁GC，大幅度波動(dòng)
大量的分配和釋放 -> Allocation Tracker
比以前版本穩(wěn)定增長(zhǎng)
新功能及代碼改動(dòng) -> Heap Dump / MAT
Heap Alloc不變，PSS增加
可能存在內(nèi)存碎片 -> Heap Dump / MAT
（2）非Heap內(nèi)存
Dalvik Other
類(lèi)信息
載入Class數(shù)正相關(guān)
mmaps
可執(zhí)行代碼
常量
3、XX銀行性能評(píng)測(cè)-內(nèi)存測(cè)試結(jié)果分析
3.1 總覽
此次質(zhì)量開(kāi)放平臺(tái)-評(píng)測(cè)中心（http://fit-stg1.jryzt.com/Hyperion-server/html/index.html）的性能測(cè)試的采集的內(nèi)存數(shù)據(jù)主要是針對(duì)場(chǎng)景頁(yè)面的內(nèi)存占用測(cè)試，內(nèi)存占用數(shù)據(jù)獲取原理是從memoryinfo中獲取。
從內(nèi)存占用對(duì)比看，行業(yè)競(jìng)品均值為351.3M，90分位約262.6M，75分位約339.5M，中位數(shù)約426.4M，25分位約605.7M。【榕商Bank】?jī)?nèi)存占用均值為246M，表現(xiàn)良好，打敗了行業(yè)90%以上的競(jìng)品，請(qǐng)繼續(xù)保持哦。
3.2 啟動(dòng)首頁(yè)加載內(nèi)存問(wèn)題分析--存在內(nèi)存抖動(dòng)
這里選取了啟動(dòng)加載場(chǎng)景來(lái)進(jìn)行內(nèi)存問(wèn)題的分析。
實(shí)際上從上面的總覽數(shù)據(jù)分析看內(nèi)存占用不同場(chǎng)景對(duì)比很難發(fā)現(xiàn)內(nèi)存問(wèn)題，但是同一個(gè)場(chǎng)景內(nèi)存占用曲線(xiàn)圖是可以發(fā)現(xiàn)問(wèn)題的，如果曲線(xiàn)圖有鋸齒形的抖動(dòng)且持續(xù)上升，基本上可能存在內(nèi)存問(wèn)題，如下圖可得出首頁(yè)存在內(nèi)存抖動(dòng)問(wèn)題
另外還需要以日志輔助分析內(nèi)存問(wèn)題：從日志上看，1秒甚至幾百ms內(nèi)就有一次GC，而且是主動(dòng)GC，說(shuō)明在頻繁申請(qǐng)內(nèi)存,總阻塞耗時(shí)約5001 ms
注釋?zhuān)?/p>
- GC Reason：GC觸發(fā)原因
- GC_CONCURRENT：當(dāng)已分配內(nèi)存達(dá)到某一值時(shí)，觸發(fā)并發(fā)GC；
- GC_FOR_MALLOC：當(dāng)嘗試在堆上分配內(nèi)存不足時(shí)觸發(fā)的GC；系統(tǒng)必須停止應(yīng)用程序并回收內(nèi)存；
-GC_HPROF_DUMP_HEAP： 當(dāng)需要?jiǎng)?chuàng)建HPROF文件來(lái)分析堆內(nèi)存時(shí)觸發(fā)的GC；
-GC_EXPLICIT：當(dāng)明確的調(diào)用GC時(shí)，例如調(diào)用System.gc()或者通過(guò)DDMS工具顯式地告訴系統(tǒng)進(jìn)行GC操作等；- Amount freed GC：回收的內(nèi)存大小
- Heap stats：堆上的空閑內(nèi)存百分比 （已用內(nèi)存）/（堆上總內(nèi)存）
- Pause time：這次GC操作導(dǎo)致應(yīng)用程序暫停的時(shí)間。關(guān)于這個(gè)暫停的時(shí)間，在2.3之前GC操作是不能并發(fā)進(jìn)行的，也就是系統(tǒng)正在進(jìn)行GC，那么應(yīng)用程序就只能阻塞住等待GC結(jié)束。而自2.3之后，GC操作改成了并發(fā)的方式進(jìn)行，就是說(shuō)GC的過(guò)程中不會(huì)影響到應(yīng)用程序的正常運(yùn)行，但是在GC操作的開(kāi)始和結(jié)束的時(shí)候會(huì)短暫阻塞一段時(shí)間。
4、App端內(nèi)存問(wèn)題排查思路：
（1）Service停止使用時(shí)，是否被銷(xiāo)毀
（2） 當(dāng)界面變?yōu)椴豢梢?jiàn)時(shí)，是否釋放當(dāng)前界面的資源
（3）內(nèi)存變少時(shí)，是否有釋放內(nèi)存
（4） bitmap使用完之后是否被回收
（5）是否有大量第三方庫(kù)的消耗
參考：
- 《深入理解Java虛擬機(jī)》
- Overview of Android Memory Management
- Investigating Your RAM Usage
- Android內(nèi)存優(yōu)化之OOM
- Managing Your App's Memory
http://developer.android.com/intl/zh-cn/training/articles/memory.html - Investigating Your RAM Usager
http://developer.android.com/intl/zh-cn/tools/debugging/debugging-memory.html - Performance Tips
http://developer.android.com/intl/zh-cn/training/articles/perf-tips.html
