好文推薦——系列文:
1.? 背景:Android App優(yōu)化, 要怎么做?
3.? Android App優(yōu)化之提升你的App啟動速度之理論基礎
4.? Android App優(yōu)化之提升你的App啟動速度之實例挑戰(zhàn)
5.? Android App優(yōu)化之Layout怎么擺
8.? Android App優(yōu)化之內存優(yōu)化
10.??Android App優(yōu)化之如何高效網(wǎng)絡請求
1 簡介
1.1 官方工具
??? 一般來說, 學習一門新的技術, 最應該做的就是閱讀其官方文檔, 那是最權威的威沫。Android本身給我們提供了很多App性能測試和分析工具, 而且大部分都集成到Android Studio或DDMS中, 非常方便使用京腥。
1.1.1 StrictMode
· 說明
????????顧名思義, "嚴格模式", 主要用來限制應用做一些不符合性能規(guī)范的事情. 一般用來檢測主線程中的耗?? 時操作和阻塞. 開啟StrictMode后, 如果線程中做一些諸如讀寫文件, 網(wǎng)絡訪問等操作, 將會在Log console輸出一些警告, 警告信息包含Stack Trace來顯示哪個地方出了問題.
· 文檔
????o?https://developer.android.com/reference/android/os/StrictMode.html
· 作用
????o 主要用來做主線程優(yōu)化分析
1.1.2 Systrace
· 說明
? ????Systrace是一個收集和檢測時間信息的工具,它能顯示CPU和時間被消耗在哪兒了,每個進程和線程都在其CPU時間片內做了什么事兒.而且會指示哪個地方出了問題,以及給出Fix建議.
? ????其以trace文件(html)的方式記錄.可以直接用Chrome瀏覽器打開查看.界面如下:
· 文檔
????o?https://developer.android.com/studio/profile/systrace.html
????o?https://developer.android.com/studio/profile/systrace-walkthru.html
????o?https://developer.android.com/studio/profile/systrace-commandline.html?hl=fy
· 作用
????o 作用很多,個人主要用來分析UI的繪制時間,結合Hierarchy Viewer來提升UI性能.
????o 也可以用來發(fā)現(xiàn)耗時操作.
1.1.3 HierarchyViewer
· 說明
? ????Hierarchy Viewer提供了一個可視化的界面來觀測布局的層級,讓我們可以優(yōu)化布局層級,刪除多余的不必要的View層級,提升布局速度.
????????有必要說明下的是:
????????上圖紅框標出的三個點是關鍵分析數(shù)據(jù). 左起依次代表View的Measure, Layout和Draw的性能. 另外顏色表示該View的該項時間指數(shù), 分為:
????* 綠色, 表示該View的此項性能比該View Tree中超過50%的View都要快.
????* 黃色, 表示該View的此項性能比該View Tree中超過50%的View都要慢.
????* 紅色, 表示該View的此項性能是View Tree中最慢的.
· 文檔
????o?https://developer.android.com/studio/profile/hierarchy-viewer.html
????o?https://developer.android.com/studio/profile/hierarchy-viewer-walkthru.html
????o?https://developer.android.com/studio/profile/hierarchy-viewer-setup.html
????o?https://developer.android.com/studio/profile/optimize-ui.html#HierarchyViewer
· 作用
????o 用來做View層級分析,可以分析出View Tree中的性能阻塞點,以便對癥下藥,提升布局性能.
??? ????Hierarchy Viewer需要Root的機器(產(chǎn)品機沒有開啟ViewServer)才可以執(zhí)行∪渌眩可以使用第三方的開源的ViewServer來協(xié)助我們在未Root的機器上使用Hierarchy Viewer分析.
1.1.4 TraceView——方法耗時分析
· 文檔
????o?https://developer.android.com/studio/profile/traceview.html
????o?https://developer.android.com/studio/profile/traceview-walkthru.html
· 作用
????o 分析方法調用棧以及其執(zhí)行時間,優(yōu)化方法執(zhí)行.
1.1.5 MemoryMonitor——內存監(jiān)控
· 說明
? ????內存使用檢測器轮蜕，可以實時檢測當前Application的內存使用和釋放等信息,并以圖形化界面展示昨悼。
· 文檔
????o?https://developer.android.com/studio/profile/am-memory.html
????o?https://developer.android.com/studio/profile/heap-viewer-walkthru.html
????o?https://developer.android.com/studio/profile/allocation-tracker-walkthru.html
· 作用
????o 用來做內存分析,內存泄露排查的不二之選.可以結合heap viewer, allocation tracker來分析.
????o 可以導出hprof文件結合第三方的MAT工具分析泄露點.
1.1.6 OtherMonitor
· 說明
? ????Android Studio的Monitor還提供了其他三個Motinor --- CPU, GPU,Network.
· 文檔
????o?https://developer.android.com/studio/profile/am-cpu.html
????o?https://developer.android.com/studio/profile/am-gpu.html
????o?https://developer.android.com/studio/profile/am-network.html
· 作用
????o 分別用來跟蹤監(jiān)測CPU,GPU和Network的使用極其變化,可以作為網(wǎng)絡優(yōu)化,流量優(yōu)化和渲染優(yōu)化等的一個指導. (個人并不常用到~)
1.1.7 其他
??? Android的開發(fā)者模式中也提供了較多的用來監(jiān)測性能的選項, 可以用下:
1.2 第三方工具
???? 以下工具全部開源
1.2.1 Google的Battery Historian
· 說明
? ????Google出品, 通過Android系統(tǒng)的bug report文件來做電量使用分析的工具.
·? 文檔
????o?https://github.com/google/battery-historian
· 作用
????o 用來做電量使用分析.
1.2.2 網(wǎng)易的Emmagee
· 說明
????????針對Android App的CPU, 內存, 網(wǎng)絡, 電量等多項綜合的測試分析.
· 文檔
????o?https://github.com/NetEase/Emmagee
· 作用
????o 比官方工具更適合國人使用來做App的整體性能分析.
1.2.3 Square的leakcanary
· 說明
? ????Square出品, 必屬精品.類似于App探針的內存泄露監(jiān)測工具.
· 文檔
????o?https://github.com/square/leakcanary
· 作用
????o 集成到App中,用來做內存問題預防最好不過了.
1.2.4 AndroidDevMetrics
· 說明
????????一個library, 用來檢測Activity生命周期執(zhí)行性能, Dagger2注入性能以及幀率性能的工具.
· 文檔
????o?https://github.com/frogermcs/AndroidDevMetrics
· 作用
????o 如果你的應用使用的Dagger2,這個就比較必要了.
2 MemoryMonitor
（轉自）Android Studio Memory Monitor
http://blog.csdn.net/flyworkspace/article/details/54019812
2.1 使用方法
2.1.1 內存鏡像
????????生成內存鏡像，當從圖中發(fā)現(xiàn)內存使用較高時肠虽，點擊小卡車圖標幔戏，可以主動觸發(fā)GC。當應用內存使用很高税课，并且存在很嚴重的內存泄露時闲延，點擊該按鈕后的效果并不明顯，內存并沒有降低或者降低的很少韩玩。點擊"Dump Java Heap"圖標稍等片刻垒玲，會生成該應用的內存快照。如圖
????? Total Count：內存中該類對象個數(shù)找颓。
????? Heap Count：堆內存中該類對象個數(shù)合愈。
????? Sizeof：每個對象的大小（如果為0，則大小不固定）佛析。
????? Shallow size：對象本身占有內存大小益老。
????? Retained Size：釋放該對象后，節(jié)省的內存大小寸莫。
????????其中捺萌，Retained Size之所以比Shallowsize大的原因是，該對象釋放后膘茎，會引起其他對象的回收桃纯。 例如，某個對象被回收后： 該對象引用的其他對象也會被回收披坏， 該對象A被另一對象B強引用后态坦，之前對象B因為強引用該對象A而沒有被回收，現(xiàn)在該對象A被回收后棒拂，若對象B強引用的其他對象都已被回收伞梯，則對象B也會被回收。
????優(yōu)化內存：
????????點擊Class Name中的類名着茸，查看其所有實例（Instance）壮锻，分析實例中參數(shù)所占用的內存琐旁。根據(jù)Retaine Size排序涮阔，查找Instance中Depth較小的實例或者參數(shù)，在代碼中找到相應的位置灰殴，查看內存占用是否合理敬特。
????判斷內存泄露的步驟：
????????從Total Count入手。該類的對象數(shù)量不對牺陶。
????? 很多對象只可能存在1個伟阔，若存在多個，則可能存在泄露掰伸。例如MainActivity的數(shù)量為2皱炉。又或者由于單例的使用不規(guī)范而導致創(chuàng)建多個“單例”對象。
????? 某個對象已經(jīng)不再使用狮鸭，而其還在內存中顯示合搅。例如LoginActivity已經(jīng)退出了，其數(shù)量為1歧蕉。
????????Memory Monitor只提供了內存信息灾部，如需詳細信息，可以通過android studio的Captures（View—–Tool window—–Captures）欄惯退，右鍵點擊快照文件赌髓，Export to standard .hprof將堆快照（Heap Snapshot）轉換成通用的hprof文件，之后可以通過其他內存分析工具打開，例如MAT锁蠕。
2.1.2 跟蹤內存分配（Allocation tracker）
????????點擊“Start Allocation Tracking”開始監(jiān)聽內存的分配情況夷野，再次點擊，監(jiān)聽完成荣倾，生成報告扫责。該報告顯示這段時間內，內存的分配情況逃呼。
2.1.3 小結
????????2.1是從內存的靜態(tài)信息中分析鳖孤，是某一個點的內存使用情況。2.2是跟蹤某一段時間內內存的分配情況抡笼，是個過程跟蹤苏揣。分析內存可以相結合，例如推姻，再進行某個操作前平匈，執(zhí)行2.1導出靜態(tài)內存信息，在開啟2.2開始跟蹤內存的分配藏古。當執(zhí)行完操作的時候增炭，關閉內存分配的跟蹤，再次執(zhí)行2.1的拧晕，導出操作某個流程后的靜態(tài)信息隙姿。將2.1的兩個靜態(tài)表結合2.2的內存分配動態(tài)過程一起分析。
2.2 分析樣例
2.2.1 占用內存分析樣例
????????打開某應用后厂捞，切換幾個頁面输玷，內存飛速上漲。這只是一個極端例子靡馁，有很多app欲鹏，隨著用的時間越長，內存也是一直在升高臭墨。
????????根據(jù)2.1的方法赔嚎，生成內存鏡像。
????????查找可疑的對象胧弛，這個過程是逐個分析的過程尤误，例如byte[]其實是其他對象的某個參數(shù)，很多本質上都是byte[]叶圃，例如Bitmap中mBuffer也是byte[]袄膏，當內存中有很多Bitmap的時候，byte[]也會很高掺冠。所以byte[]不是我們重點關注對象沉馆，如果真的是因為Bitmap（或者其他類）多而造成的byte[]高码党，那么下面肯定會有該類也會占用很高內存斥黑。
????????繼續(xù)分析下一個HashMap$HashMapEntry揖盘。點擊它后，在Instance欄中锌奴，看到其實例很多兽狭，先從占用大的實例入手。
????????例如99=這個鹿蜀，點擊它后ReferenceTree顯示如下：
????????得知這個HashMap是ReuseThumbnail…類中ReuseThumbnailManager的REUSE_BITMAPS箕慧。在代碼中查看其大小是否合理。本例中REUSE_BITMAPS參數(shù)是static參數(shù)茴恰，其類型是HashMap颠焦，查看邏輯，看其是否正常往枣。
????????再看其他參數(shù)伐庭，逐個分析其內存占用是否正常。
????????分析內存是個逐步的過程分冈，一個問題解決后圾另，再次循環(huán)這些步驟。有時候雖然列表中顯示很多對象占用內存很高雕沉，有可能是同一個參數(shù)導致的集乔，所以一個問題解決后，有可能有一系列參數(shù)占用高的情況會消失蘑秽。就比如如果高內存bitmap的優(yōu)化后饺著，byte[]也很降低很多，其他參數(shù)也有可能會降低很多肠牲。
2.2.2 跟蹤內存分配分析樣例
????????3.1是從靜態(tài)內存信息中分析內存的使用，現(xiàn)在按照2.2從動態(tài)過程中跟蹤內存的分配靴跛。
????????生成報告如下：
????????查看Size最大的一個Thread.
????????可以看到調用過程缀雳，從NewDisplayRunnale（執(zhí)行了636次）調用了BitmapDecoder的decode方法（執(zhí)行了135次），從代碼中分析過程是否合理梢睛。
2.2.3 內存泄露分析樣例
????????對于android的內存泄露肥印，一般監(jiān)測Activity的泄露居多，例如LeakCanary默認也是監(jiān)測Activity是否泄露绝葡。
????????現(xiàn)寫一個demo深碱，故意造成內存泄露作為分析樣例。
public class MyActivity extends Activity{
???@Override
???public void onCreate(Bundle savedInstanceState) {
??????? super.onCreate(savedInstanceState);
??????? setContentView(R.layout.main);
??????? new TestThread().start();
???}
???class TestThread extends Thread{
??????? @Override
??????? public voidrun() {
???????????super.run();
??????????? try{
??????????????? Thread.sleep(10 * 60 * 1000);
??????????? }catch(InterruptedException e) {
??????????????? e.printStackTrace();
??????????? }
??????? }
???}
}
????????當進入MyActivity點擊回退藏畅，重復多次敷硅。按照2.1方法獲取內存鏡像。
????????看到MyActivity的實例數(shù)量為17個。在右邊的Analyzer Tasks欄中：
????????一般引起Activity泄露是由于其Context被強引用導致的绞蹦。
????????MyActivity的context參數(shù)被TestThread引用了力奋。所以在activity的銷毀的時候，由于TestThread還引用著MyActivity幽七，所以阻止了MyActivity被釋放景殷，因而導致內存泄露。
2.3 性能數(shù)據(jù)采集
3 DDMS
http://www.cnblogs.com/gaobig/p/5029381.html
????????Android Studio開發(fā)工具中猿挚，打開DDMS，具體的方式如圖：
??? 打開之后的窗口如圖：
??? 查看進程中的線程：
??? 查看內存信息：
3.1? Traceview
Android學習之Android studio TraceView和lint工具的使用詳解
http://blog.csdn.net/qq_16131393/article/details/51172488
3.1.1 使用方法
??? 打開AndroidDevice Monitor驶鹉，這個大家都知道：
????1. 選擇你要調試的進程亭饵。
????2. 點擊start mothod profiling，待圖標變黑梁厉。
????3. 選擇sample base profiling
????這里需要解釋一下：
????Trace base profiling
????????整體監(jiān)聽辜羊，項目中所有方法都會監(jiān)聽，資源消耗比較大词顾。
????sample base profiling
????????抽樣監(jiān)聽八秃，以指定的頻率進行抽樣調查，一般不要超過5s肉盹，需要較長時間獲取準確的樣本數(shù)據(jù)昔驱。
????再次點擊start mothod profiling，就會生成檢測樣本上忍。
????效果如下：
????????上部分為時間軸骤肛，x軸表示時間，黑色區(qū)域可放大窍蓝，每個區(qū)域代表每個方法的執(zhí)行時間腋颠。y軸表示每一個獨立線程。
????????下部分Name為你所選擇的顏色區(qū)塊所代表的性能分析吓笙。不同的顏色淑玫，代表不同的方法，顏色長度代表占用時間面睛。
????????屬性介紹：
????Incl cpu time：某方法占用cpu時間（父+子）
????Excl cpu time：某方法本身占用cpu時間（父）
????Incl Real time：某方法真正執(zhí)行時間（父+子）
????Excl Real time：某方法自身執(zhí)行時間（父）
????????當然還有相應所占百分比絮蒿，不過多介紹。
????????還有Calls+RecurCall調用次數(shù)+遞歸調用次數(shù)
????????還有比較重要的：
????cpu time/call：平均每次調用占用cpu時間叁鉴。
????real time/call：平均每次調用所執(zhí)行的時間土涝。
????我覺得這個參數(shù)很具有參考性。
????????打開每個方法幌墓，會顯示Paents和children(即父方法和子方法)但壮，以及分別所占用時間冀泻。
· 說明
? ????一個圖形化的工具,用來展示和分析方法的執(zhí)行時間.
3.1.2 數(shù)據(jù)采集
3.2 Heap Viewer
3.2.1 HeapViewer面板
??? ????按上圖的標記順序按下，我們就能看到內存的具體數(shù)據(jù)茵肃，右邊面板中數(shù)值會在每次GC時發(fā)生改變腔长，包括App自動觸發(fā)或者你來手動觸發(fā)。
3.2.2 詳情
??? 下面是每一個對象都有的列名含義：
??? ????當我們點擊某一行時验残，可以看到如下的柱狀圖：
????????橫坐標是對象的內存大小捞附，這些值隨著不同對象是不同的，縱坐標是在某個內存大小上的對象的數(shù)量您没。
3.2.3 HeapViewer的使用
??? ????我們說HeapViewer適合發(fā)現(xiàn)內存泄漏的問題鸟召，那你知道何為內存泄漏么？
????內存泄漏
????英文名：Memory Leaks
????標準解釋：無用的單純氨鹏，但是還是沒GC ROOT引用的內存
????通俗解釋：該死不死的內存
????檢測
????????那么如何檢測呢欧募？Heap Viewer中的數(shù)值會自動在每次發(fā)生GC時會自動更新，那么我們是等著他自己GC么仆抵？小弟不才跟继，剛開始我就是這么一直等啊等，由于GC的時機是系統(tǒng)把握的镣丑，所以很不好把握舔糖，既然我們是來看內存泄漏，那么我們在需要檢測內存泄漏的用例執(zhí)行過后莺匠，手動GC下金吗，然后觀察data object一欄的total size(也可以觀察HeapSize/Allocated內存的情況)，看看內存是不是會回到一個穩(wěn)定值趣竣，多次操作后摇庙，只要內存是穩(wěn)定在某個值，那么說明沒有內存溢出的遥缕，如果發(fā)現(xiàn)內存在每次GC后卫袒，都在增長，不管是慢增長還是快速增長通砍，都說明有內存泄漏的可能性玛臂。
????實例
????先來看3個圖：
????1.剛打開首頁,手動GC一下:
????????2.首頁到詳情頁10遍，最后回到首頁封孙，手動GC一下,直到數(shù)值不再變化：
????????3.首頁到詳情頁10遍，最后回到首頁讽营，手動GC一下：
????????從data object一欄看到該類型的數(shù)值會在不斷增長虎忌，可能發(fā)生了內存泄漏，而我們也可以從上面三個圖的標紅部分來看橱鹏，Allocated分別增加了2.418M和1.084M膜蠢，而且你繼續(xù)這么操作下去堪藐，內存依然是增長的趨勢。
3.2.4 數(shù)據(jù)采集
4 Emmagee
4.1 使用說明
????1挑围、Emmagee是網(wǎng)易杭州研究院QA團隊開發(fā)的一個簡單易上手的Android性能監(jiān)測小工具礁竞，主要用于監(jiān)控單個App的CPU，內存杉辙，流量模捂，啟動耗時，電量蜘矢，電流等性能狀態(tài)的變化狂男，且用戶可自定義配置監(jiān)控的頻率以及性能的實時顯示，并最終生成一份性能統(tǒng)計文件品腹。
????2岖食、操作完成后，從系統(tǒng)任務列表中選擇Emmagee舞吭，并停止測試泡垃，在”storage\sdcard0”下找到命名類似”Emmagee_TestResult_20140403210532.csv”的文件，打卡即為監(jiān)控的得到的數(shù)據(jù)羡鸥。
????3蔑穴、將csv數(shù)據(jù)拷貝到excel中生成圖表，即可清晰看到整個操作過程中cpu兄春、內存等關鍵數(shù)據(jù)的變化澎剥。
Android性能測試小工具Emmagee - 敵測漏師
http://blog.csdn.net/anlegor/article/details/22895993
APP性能測試工具Emmagee的使用總結
http://blog.csdn.net/chenrushui/article/details/51589995
http://www.cnblogs.com/jytian/p/6516170.html
4.2 性能數(shù)據(jù)采集
5 leakcanary
· 說明
? ????Square出品, 必屬精品，類似于App探針的內存泄露監(jiān)測工具.
· 文檔
????o?https://github.com/square/leakcanary
· 作用
????o 集成到App中,用來做內存問題預防最好不過了.
5.1 使用說明
LeakCanary使用指南(1)
http://blog.csdn.net/hmh0512/article/details/57053265?utm_source=tuicool&utm_medium=referral
????快速集成
????????第一步：在build.gradle中添加如下依賴：
dependencies {
????debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
????releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
????testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
}
????????第二步：在自己的Application(假設名為ExampleApplication)中添加如下代碼：
public class? ExampleApplication extends?Application {
????@Override?
? ??public void?onCreate()? {
? ??????super.onCreate();
? ??????if? (LeakCanary.isInAnalyzerProcess(this)) {
????????????// This process is dedicated to LeakCanary for heap analysis.
????????????// You should not init your app in this process.
? ??????????return;
????????}
????????LeakCanary.install(this);
????????// Normal app init code...
????}
}
????????到這里其實可以檢測到Activity的內存泄露了赶舆，原理后面再說哑姚。以Debug模式運行你的App，你可以看到芜茵，你App的圖標后面跟著一個Leaks圖標叙量，如下圖;而如果你以Release模式運行，則沒有這個圖標九串。
????測試使用
????????假裝你是測試人員绞佩，你開始各種點擊App，進行測試猪钮。然后你有幸看到這樣一個彈框品山，如下圖。
????????你很好奇烤低，然后點擊了彈框中間那個圖標肘交，于是手機屏幕的左上角出現(xiàn)了你App的圖標，再下拉點擊那個圖標扑馁，或者從桌面上LeakCanary圖標(跟在你App的圖標屁股后面那個)點進去涯呻，你看到下圖迈倍。點擊+號可以展開佩研，點擊-號收起郭计。
????????內存泄露往往發(fā)生在趟紊，生命周期較長的對象，直接或間接持有了生命周期較短的對象的強引用效诅，導致了生命周期較短的對象不能及時釋放胀滚。
????????上圖已經(jīng)夠傻瓜式了，第一行表示生命周期較長的那個對象填帽，圖中是AliPayModel這個類;第二行表示生命周期長的那個持有了一個什么樣的引用蛛淋，圖中是mActivity;第三行表示生命周期較短的那個對象，圖中是SelectPayTypeActivity篡腌。
????????回去查看源碼褐荷，發(fā)現(xiàn)AliPayModel是個單例，在SelectPayTypeActivity中以AliPayModel.getInstance(this).XXX()的方式調用單例中的XXX()方法嘹悼。于是AliPayModel通過mActivity持有了SelectPayTypeActivity.this的引用叛甫。SelectPayTypeActivity本來應該在用戶退出這個頁面和進入其他Activity(尤其是其他Activity層級較深時)時釋放掉，但是單例的生命周期貫穿整個App杨伙，AliPayModel一直引用著SelectPayTypeActivity其监，導致SelectPayTypeActivity不能及時釋放，引發(fā)內存泄露限匣。
public class? AliPayModel extends?BasePayModel {
? ??private?Activity? mActivity;
? ??private?AliPayModel() {}
? ??private static? AliPayModel instance = new?AliPayModel();
? ??public static?AliPayModel? getInstance(Activity tag) {
????????instance.mActivity = tag;
? ??????return?instance;
????}
}
????????找到了原因抖苦，解決方法也呼之欲出。要么AliPayModel這個業(yè)務類不要定義成單例米死，要么mActivity由強引用改成軟引用或者弱引用锌历。Java的強、軟峦筒、弱究西、虛四種引用的區(qū)別不在本文的討論范圍。
????發(fā)現(xiàn)開源組件中的內存泄露
????????用上述方法物喷，可以檢測出各種各樣的內存泄露卤材，包括：WebView導致的內存泄露、資源未關閉導致的內存泄露峦失、非靜態(tài)匿名內部類導致的內存泄露扇丛、Handler導致的內存泄露等等。
????????請看下圖尉辑，每次選擇圖片晕拆、上傳頭像時都會引發(fā)0.96M的內存泄露!
????????再按圖索驥，發(fā)現(xiàn)罪魁禍首是將一個Activity定義為static材蹬。表示不是很能理解這種神代碼实幕。最讓人心中萬馬奔騰的是，它竟然有2600多個star!在這個項目的Issues中很多人反映內存占用大堤器、容易OOM昆庇、卡頓等，但是沒有人從技術層面去查找和分析原因闸溃，更遑論去閱讀源碼整吆，都是直接拿來就用!
6 參考鏈接
Android App優(yōu)化之性能分析工具
http://www.reibang.com/p/da2a4bfcba68
Android開發(fā)調試必備-使用DDMS
http://blog.csdn.net/stzy00/article/details/46554529
Android內存分析工具（二）：DDMS
http://blog.csdn.net/berber78/article/details/47784007
http://blog.csdn.net/itfootball/article/details/48734553
正確使用Android性能分析工具——TraceView
http://android.jobbole.com/78995/
http://blog.csdn.net/itfootball/article/details/48712595
Android性能優(yōu)化第（二）篇---Memory Monitor檢測內存泄露
http://www.cnblogs.com/ldq2016/p/6628311.html
Android內存與性能
http://blog.kamidox.com/android-memory-guide.html
http://blog.csdn.net/innost/article/details/9008691/
Android開發(fā)——Android多進程以及使用場景介紹
http://blog.csdn.net/seu_calvin/article/details/53932171
理解Android進程創(chuàng)建流程
http://gityuan.com/2016/03/26/app-process-create/
LeakCanary使用指南(1)
http://blog.csdn.net/hmh0512/article/details/57053265?utm_source=tuicool&utm_medium=referral
利用LeakCanary來檢查Android內存泄漏
http://www.reibang.com/p/0049e9b344b0
LeakCanary中文使用說明
