上篇博客我們寫(xiě)到了 Java/Android 內(nèi)存的分配以及相關(guān) GC 的詳細(xì)分析媒咳，這篇博客我們會(huì)繼續(xù)分析 Android 中內(nèi)存泄漏的檢測(cè)以及相關(guān)案例英染，和 Android 的內(nèi)存優(yōu)化相關(guān)內(nèi)容貌亭。
　　上篇：Android 性能優(yōu)化之內(nèi)存泄漏檢測(cè)以及內(nèi)存優(yōu)化（上）。
　　中篇：Android 性能優(yōu)化之內(nèi)存泄漏檢測(cè)以及內(nèi)存優(yōu)化（中）许赃。
　　下篇：Android 性能優(yōu)化之內(nèi)存泄漏檢測(cè)以及內(nèi)存優(yōu)化（下）跟压。
　　轉(zhuǎn)載請(qǐng)注明出處：http://blog.csdn.net/self_study/article/details/66969064
　　對(duì)技術(shù)感興趣的同鞋加群544645972一起交流。

Android 內(nèi)存泄漏檢測(cè)

?通過(guò)上篇博客我們了解了 Android JVM/ART 內(nèi)存的相關(guān)知識(shí)和泄漏的原因塞茅，再來(lái)歸類一下內(nèi)存泄漏的源頭亩码，這里我們簡(jiǎn)單將其歸為一下三類：<ul><li>自身編碼引起</li>由項(xiàng)目開(kāi)發(fā)人員自身的編碼造成；<li>第三方代碼引起</li>這里的第三方代碼包含兩類野瘦，第三方非開(kāi)源的 SDK 和開(kāi)源的第三方框架描沟；<li>系統(tǒng)原因</li>由 Android 系統(tǒng)自身造成的泄漏，如像 WebView鞭光、InputMethodManager 等引起的問(wèn)題吏廉，還有某些第三方 ROM 存在的問(wèn)題。</ul>

Android 內(nèi)存泄漏的定位惰许，檢測(cè)與修復(fù)

?內(nèi)存泄漏不像閃退的 BUG席覆，排查起來(lái)相對(duì)要困難一些，比較極端的情況是當(dāng)你的應(yīng)用 OOM 才發(fā)現(xiàn)存在內(nèi)存泄漏問(wèn)題汹买，到了這種情況才去排查處理問(wèn)題的話佩伤，對(duì)用戶的影響就太大了，為此我們應(yīng)該在編碼階段盡早地發(fā)現(xiàn)問(wèn)題卦睹，而不是拖到上線之后去影響用戶體驗(yàn)畦戒，下面總結(jié)一下常用內(nèi)存泄漏的定位和檢測(cè)工具：

Lint

Lint 是 Android studio 自帶的靜態(tài)代碼分析工具，使用起來(lái)也很方便结序，選中需要掃描的 module障斋，然后點(diǎn)擊頂部菜單欄 Analyze -> Inspect Code ，選擇需要掃描的地方即可：

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

最后在 Performance 里面有一項(xiàng)是 Handler reference leaks徐鹤，里面列出來(lái)了可能由于內(nèi)部 Handler 對(duì)象持有外部 Activity 引用導(dǎo)致內(nèi)存泄漏的地方垃环，這些地方都可以根據(jù)實(shí)際的使用場(chǎng)景去排查一下，因?yàn)楫吘共皇敲總€(gè)內(nèi)部 Handler 對(duì)象都會(huì)導(dǎo)致內(nèi)存泄漏返敬。Lint 還可以自定義掃描規(guī)則遂庄，使用姿勢(shì)很多很強(qiáng)大，感興趣的可以去了解一下劲赠，除了 Lint 之外涛目，還有像 FindBugs秸谢、Checkstyle 等靜態(tài)代碼分析工具也是很不錯(cuò)的。

StrictMode

StrictMode 是 Android 系統(tǒng)提供的 API霹肝，在開(kāi)發(fā)環(huán)境下引入可以更早的暴露發(fā)現(xiàn)問(wèn)題給開(kāi)發(fā)者估蹄，于開(kāi)發(fā)階段解決它，StrictMode 最常被使用來(lái)檢測(cè)在主線程中進(jìn)行讀寫(xiě)磁盤(pán)或者網(wǎng)絡(luò)操作等耗時(shí)任務(wù)沫换，把這些耗時(shí)任務(wù)放置于主線程會(huì)造成主線程阻塞卡頓甚至可能出現(xiàn) ANR 臭蚁，官方例子：

 public void onCreate() {
     if (DEVELOPER_MODE) {
         StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                 .detectDiskReads()
                 .detectDiskWrites()
                 .detectNetwork()   // or .detectAll() for all detectable problems
                 .penaltyLog()
                 .build());
         StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                 .detectLeakedSqlLiteObjects()
                 .detectLeakedClosableObjects()
                 .penaltyLog()
                 .penaltyDeath()
                 .build());
     }
     super.onCreate();
 }

把上面這段代碼放在早期初始化的 Application、Activity 或者其他應(yīng)用組件的 onCreate 函數(shù)里面來(lái)啟用 StrictMode 功能讯赏，一般 StrictMode 只是在測(cè)試環(huán)境下啟用垮兑，到了線上環(huán)境就不要開(kāi)啟這個(gè)功能。啟用 StrictMode 之后漱挎，在 logcat 過(guò)濾日志的地方加上 StrictMode 的過(guò)濾 tag系枪，如果發(fā)現(xiàn)一堆紅色告警的 log，說(shuō)明可能就出現(xiàn)了內(nèi)存泄漏或者其他的相關(guān)問(wèn)題了：

這里寫(xiě)圖片描述

比如上面這個(gè)就是因?yàn)檎{(diào)用 registerReceiver 之后忘記調(diào)用 unRegisterReceiver 導(dǎo)致的 activity 泄漏识樱，根據(jù)錯(cuò)誤信息便可以定位和修復(fù)問(wèn)題嗤无。

LeakCanary

? LeakCanary 是一個(gè) Android 內(nèi)存泄漏檢測(cè)的神器，正確使用可以大大減少內(nèi)存泄漏和 OOM 問(wèn)題怜庸，地址：

https://github.com/square/leakcanary

集成 LeakCanary 也很簡(jiǎn)單当犯，在 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 類中添加下面代碼：

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...
  }
}

上面兩步做完之后就算是集成了 LeakCanary 了，非常簡(jiǎn)單方便割疾，如果程序出現(xiàn)了內(nèi)存泄漏會(huì)彈出 notification嚎卫，點(diǎn)擊這個(gè) notification 就會(huì)進(jìn)入到下面這個(gè)界面，或者集成 LeakCanary 之后在桌面會(huì)有一個(gè) LeakCanary 的圖標(biāo)宏榕，點(diǎn)擊進(jìn)去是所有的內(nèi)存泄漏列表拓诸，點(diǎn)擊其中一項(xiàng)同樣是進(jìn)入到下面界面：

這里寫(xiě)圖片描述

Android Memory Monitor

?Memory Monitor 是 Android Studio 自帶的一個(gè)監(jiān)控內(nèi)存使用狀態(tài)的工具载弄，入口如下所示：

這里寫(xiě)圖片描述

在 Android Monitor 點(diǎn)開(kāi)之后 logcat 的右側(cè)就是 Monitor 工具耘拇，其中可以檢測(cè)內(nèi)存、CPU侦锯、網(wǎng)絡(luò)等內(nèi)容驼鞭，我們這里只用到了 Memory Monitor 功能，點(diǎn)擊紅色箭頭所指的區(qū)域尺碰，就會(huì) dump 此時(shí)此刻的 Memory 信息，并且生成一個(gè) .hprof 文件译隘，dump 完成之后會(huì)自動(dòng)打開(kāi)這個(gè)文件的顯示界面亲桥，如果沒(méi)有打開(kāi)，可以通過(guò)點(diǎn)擊最左側(cè)的 Capture 界面或者 Tool Window 里面的 Capture 進(jìn)入 dump 的 .hprof 文件列表：

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

首先左上角的下拉框固耘，可以選擇 App Heap题篷、Image Heap 和 Zygote Heap，對(duì)應(yīng)的就是上篇博客講到的 Allocation Space厅目，Image Space 和 Zygote Space番枚，我們這里選擇 Allocation Space，然后第二個(gè)選擇 PackageTreeView 這一項(xiàng)损敷，展開(kāi)之后就能看見(jiàn)一個(gè)樹(shù)形結(jié)構(gòu)了筹麸，然后繼續(xù)展開(kāi)我們應(yīng)用包名的對(duì)應(yīng)對(duì)象汽畴，就可以很清晰的看到有多少個(gè) Activity 對(duì)象了，上面那兩欄展示的信息按照從左到右的順序，定義如下所示：

然后可以點(diǎn)擊展開(kāi)右側(cè)的 Analyzer Tasks 項(xiàng)淑掌，勾選上需要檢測(cè)的任務(wù)，然后系統(tǒng)就會(huì)給你分析出結(jié)果：

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

MAT

MAT（Memory Analyzer Tools）是一個(gè) Eclipse 插件催蝗，它是一個(gè)快速切威、功能豐富的 JAVA heap 分析工具，它可以幫助我們查找內(nèi)存泄漏和減少內(nèi)存消耗丙号，MAT 插件的下載地址：Eclipse Memory Analyzer Open Source Project先朦，上面通過(guò) Android studio 生成的 .hprof 文件因?yàn)楦袷缴杂胁煌衷孕枰?jīng)過(guò)一個(gè)簡(jiǎn)單的轉(zhuǎn)換，然后就可以通過(guò) MAT 去打開(kāi)了：

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

adb shell && Memory Usage

可以通過(guò)命令 adb shell dumpsys meminfo [package name] 來(lái)將指定 package name 的內(nèi)存信息打印出來(lái)魂务，這種模式可以非常直觀地看到 Activity 未釋放導(dǎo)致的內(nèi)存泄漏：

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

Allocation Tracker

Android studio 還自帶一個(gè) Allocation Tracker 工具，功能和 DDMS 中的基本差不多粘姜，這個(gè)工具可以監(jiān)控一段時(shí)間之內(nèi)的內(nèi)存分配：

這里寫(xiě)圖片描述

這里寫(xiě)圖片描述

常見(jiàn)的內(nèi)存泄漏案例

?我們來(lái)看看常見(jiàn)的導(dǎo)致內(nèi)存泄漏的案例：

靜態(tài)變量造成的內(nèi)存泄漏

?由于靜態(tài)變量的生命周期和應(yīng)用一樣長(zhǎng)臭猜，所以如果靜態(tài)變量持有 Activity 或者 Activity 中 View 對(duì)象的應(yīng)用躺酒，就會(huì)導(dǎo)致該靜態(tài)變量一直直接或者間接持有 Activity 的引用，導(dǎo)致該 Activity 無(wú)法釋放蔑歌，從而引發(fā)內(nèi)存泄漏羹应，不過(guò)需要注意的是在大多數(shù)這種情況下由于靜態(tài)變量只是持有了一個(gè) Activity 的引用，所以導(dǎo)致的結(jié)果只是一個(gè) Activity 對(duì)象未能在退出之后釋放次屠，這種問(wèn)題一般不會(huì)導(dǎo)致 OOM 問(wèn)題园匹，只能通過(guò)上面介紹過(guò)的幾種工具在開(kāi)發(fā)中去觀察發(fā)現(xiàn)。
　　這種問(wèn)題的解決思路很簡(jiǎn)單劫灶，就是不讓靜態(tài)變量直接或者間接持有 Activity 的強(qiáng)引用偎肃，可以將其修改為 soft reference 或者 weak reference 等等之類的，或者如果可以的話將 Activity Context 更換為 Application Context浑此，這樣就能保證生命周期一致不會(huì)導(dǎo)致內(nèi)存泄漏的問(wèn)題了。

內(nèi)部類持有外部類引用

我們上面的 demo 中模擬的就是內(nèi)部類對(duì)象持有外部類對(duì)象的引用導(dǎo)致外部類對(duì)象無(wú)法釋放的問(wèn)題滞详，在 Java 中非靜態(tài)內(nèi)部類和匿名內(nèi)部類會(huì)持有他們所屬外部類對(duì)象的引用凛俱，如果這個(gè)非靜態(tài)內(nèi)部類對(duì)象或者匿名內(nèi)部類對(duì)象被一個(gè)耗時(shí)的線程（或者其他 GC Root）直接或者間接的引用，甚至這些內(nèi)部類對(duì)象本身就在做一些耗時(shí)操作料饥，這樣就會(huì)導(dǎo)致這個(gè)內(nèi)部類對(duì)象直接或者間接無(wú)法釋放蒲犬，內(nèi)部類對(duì)象無(wú)法釋放，外部類的對(duì)象也就無(wú)法釋放造成內(nèi)存泄漏岸啡，而且如果無(wú)法釋放的對(duì)象積累起來(lái)就會(huì)造成 OOM原叮，示例代碼如下所示：

public class SecondActivity extends AppCompatActivity{
    private Handler handler;
    private Bitmap bitmap;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);
        bitmap = BitmapFactory.decodeResource(getResources(), R.mipmap.pic);//decode 一個(gè)大圖來(lái)模擬內(nèi)存無(wú)法釋放導(dǎo)致的崩潰
        findViewById(R.id.btn_second).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                finish();
            }
        });

        handler = new Handler() {
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);

            }
        };
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(1000000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                handler.sendEmptyMessage(0);
            }
        }).start();
    }
}

這個(gè)問(wèn)題的解決方法可以根據(jù)實(shí)際情況進(jìn)行選擇：<ul><li>將非靜態(tài)內(nèi)部類或者匿名內(nèi)部類修改為靜態(tài)內(nèi)部類，比如 Handler 修改為靜態(tài)內(nèi)部類巡蘸，然后讓 Handler 持有外部 Activity 的一個(gè) Weak Reference 或者 Soft Reference奋隶；</li><li>在 Activity 頁(yè)面銷毀的時(shí)候?qū)⒑臅r(shí)任務(wù)停止，這樣就能保證 GC Root 不會(huì)間接持有 Activity 的引用悦荒，也就不會(huì)導(dǎo)致內(nèi)存泄漏唯欣；</li></ul>

錯(cuò)誤使用 Activity Context

這個(gè)很好理解，在一個(gè)錯(cuò)誤的地方使用 Activity Context搬味，造成 Activity Context 被靜態(tài)變量長(zhǎng)時(shí)間引用導(dǎo)致無(wú)法釋放而引發(fā)的內(nèi)存泄漏境氢，這個(gè)問(wèn)題的處理方式也很簡(jiǎn)單，如果可以的話修改為 Application Context 或者將強(qiáng)引用變成其他引用碰纬。

資源對(duì)象沒(méi)關(guān)閉造成的內(nèi)存泄漏

資源性對(duì)象比如（Cursor萍聊，F(xiàn)ile 文件等）往往都用了一些緩沖，我們?cè)诓皇褂玫臅r(shí)候應(yīng)該及時(shí)關(guān)閉它們悦析，以便它們的緩沖對(duì)象被及時(shí)回收寿桨，這些緩沖不僅存在于 java 虛擬機(jī)內(nèi)，還存在于 java 虛擬機(jī)外她按，如果我們僅僅是把它的引用設(shè)置為 null 而不關(guān)閉它們牛隅，往往會(huì)造成內(nèi)存泄漏炕柔。但是有些資源性對(duì)象，比如 SQLiteCursor（在析構(gòu)函數(shù) finalize()媒佣，如果我們沒(méi)有關(guān)閉它匕累，它自己會(huì)調(diào) close() 關(guān)閉），如果我們沒(méi)有關(guān)閉它系統(tǒng)在回收它時(shí)也會(huì)關(guān)閉它默伍，但是這樣的效率太低了欢嘿。因此對(duì)于資源性對(duì)象在不使用的時(shí)候，應(yīng)該調(diào)用它的 close() 函數(shù)也糊，將其關(guān)閉掉炼蹦，然后再置為 null，在我們的程序退出時(shí)一定要確保我們的資源性對(duì)象已經(jīng)關(guān)閉狸剃。
　　程序中經(jīng)常會(huì)進(jìn)行查詢數(shù)據(jù)庫(kù)的操作掐隐，但是經(jīng)常會(huì)有使用完畢 Cursor 后沒(méi)有關(guān)閉的情況，如果我們的查詢結(jié)果集比較小钞馁，對(duì)內(nèi)存的消耗不容易被發(fā)現(xiàn)虑省，只有在常時(shí)間大量操作的情況下才會(huì)出現(xiàn)內(nèi)存問(wèn)題，這樣就會(huì)給以后的測(cè)試和問(wèn)題排查帶來(lái)困難和風(fēng)險(xiǎn)僧凰，示例代碼：

Cursor cursor = getContentResolver().query(uri...); 
if (cursor.moveToNext()) { 
... ... 
} 

更正代碼：

Cursor cursor = null;
try {
    cursor = getContentResolver().query(uri...);
    if (cursor != null && cursor.moveToNext()) {
        ... ...
    }
} finally {
    if (cursor != null) {
        try {
            cursor.close();
        } catch (Exception e) {
            //ignore this
        }
    }
}

集合中對(duì)象沒(méi)清理造成的內(nèi)存泄漏

在實(shí)際開(kāi)發(fā)過(guò)程中難免會(huì)有把對(duì)象添加到集合容器（比如 ArrayList）中的需求探颈，如果在一個(gè)對(duì)象使用結(jié)束之后未將該對(duì)象從該容器中移除掉，就會(huì)造成該對(duì)象不能被正確回收训措，從而造成內(nèi)存泄漏伪节，解決辦法當(dāng)然就是在使用完之后將該對(duì)象從容器中移除。

WebView造成的內(nèi)存泄露

具體的可以看看我的這篇博客：android WebView詳解绩鸣，常見(jiàn)漏洞詳解和安全源碼（下）怀大。

未取消注冊(cè)導(dǎo)致的內(nèi)存泄漏

一些 Android 程序可能引用我們的 Android 程序的對(duì)象（比如注冊(cè)機(jī)制），即使我們的 Android 程序已經(jīng)結(jié)束了全闷，但是別的應(yīng)用程序仍然還持有對(duì)我們 Android 程序某個(gè)對(duì)象的引用叉寂，這樣也會(huì)造成內(nèi)存不能被回收，比如調(diào)用 registerReceiver 后未調(diào)用unregisterReceiver总珠。假設(shè)我們希望在鎖屏界面（LockScreen）中屏鳍，監(jiān)聽(tīng)系統(tǒng)中的電話服務(wù)以獲取一些信息，則可以在 LockScreen 中定義一個(gè) PhoneStateListener 的對(duì)象局服，同時(shí)將它注冊(cè)到 TelephonyManager 服務(wù)中钓瞭，對(duì)于 LockScreen 對(duì)象，當(dāng)需要顯示鎖屏界面的時(shí)候就會(huì)創(chuàng)建一個(gè) LockScreen 對(duì)象淫奔，而當(dāng)鎖屏界面消失的時(shí)候 LockScreen 對(duì)象就會(huì)被釋放掉山涡，但是如果在釋放 LockScreen 對(duì)象的時(shí)候忘記取消我們之前注冊(cè)的 PhoneStateListener 對(duì)象，則會(huì)間接導(dǎo)致 LockScreen 無(wú)法被回收，如果不斷的使鎖屏界面顯示和消失鸭丛，則最終會(huì)由于大量的 LockScreen 對(duì)象沒(méi)有辦法被回收而引起 OOM竞穷，雖然有些系統(tǒng)程序本身好像是可以自動(dòng)取消注冊(cè)的（當(dāng)然不及時(shí)），但是我們還是應(yīng)該在程序結(jié)束時(shí)明確的取消注冊(cè)鳞溉。

因?yàn)閮?nèi)存碎片導(dǎo)致分配內(nèi)存不足

還有一種情況是因?yàn)轭l繁的內(nèi)存分配和釋放瘾带，導(dǎo)致內(nèi)存區(qū)域里面存在很多碎片，當(dāng)這些碎片足夠多熟菲，new 一個(gè)大對(duì)象的時(shí)候看政，所有的碎片中沒(méi)有一個(gè)碎片足夠大以分配給這個(gè)對(duì)象，但是所有的碎片空間加起來(lái)又是足夠的時(shí)候抄罕，就會(huì)出現(xiàn) OOM允蚣，而且這種 OOM 從某種意義上講，是完全能夠避免的呆贿。
　　由于產(chǎn)生內(nèi)存碎片的場(chǎng)景很多嚷兔，從 Memory Monitor 來(lái)看，下面場(chǎng)景的內(nèi)存抖動(dòng)是很容易產(chǎn)生內(nèi)存碎片的：

這里寫(xiě)圖片描述

最常見(jiàn)產(chǎn)生內(nèi)存抖動(dòng)的例子就是在 ListView 的 getView 方法中未復(fù)用 convertView 導(dǎo)致 View 的頻繁創(chuàng)建和釋放做入，針對(duì)這個(gè)問(wèn)題的處理方式那當(dāng)然就是復(fù)用 convertView谴垫；或者是 String 拼接創(chuàng)建大量小的對(duì)象（比如在一些頻繁調(diào)用的地方打字符串拼接的 log 的時(shí)候）；如果是其他的問(wèn)題母蛛，就需要通過(guò) Memory Monitor 去觀察內(nèi)存的實(shí)時(shí)分配釋放情況，找到內(nèi)存抖動(dòng)的地方修復(fù)它乳怎，或者如果當(dāng)出現(xiàn)下面這種情況下的 OOM 時(shí)彩郊，也是由于內(nèi)存碎片導(dǎo)致無(wú)法分配內(nèi)存：

這里寫(xiě)圖片描述

Android 內(nèi)存優(yōu)化

內(nèi)存優(yōu)化請(qǐng)看下篇：Android 性能優(yōu)化之內(nèi)存泄漏檢測(cè)以及內(nèi)存優(yōu)化（下）蚪缀。

引用

http://blog.csdn.net/luoshengyang/article/details/42555483
http://blog.csdn.net/luoshengyang/article/details/41688319
http://blog.csdn.net/luoshengyang/article/details/42492621
http://blog.csdn.net/luoshengyang/article/details/41338251
http://blog.csdn.net/luoshengyang/article/details/41581063
https://mp.weixin.qq.com/s?__biz=MzA4MzEwOTkyMQ==&mid=2667377215&idx=1&sn=26e3e9ec5f4cf3e7ed1e90a0790cc071&chksm=84f32371b384aa67166a3ff60e3f8ffdfbeed17b4c8b46b538d5a3eec524c9d0bcac33951a1a&scene=0&key=c2240201df732cf062d22d3cf95164740442d817864520af90bb0e71fa51102f2e91475a4f597ec20653c59d305c8a3e518d3f575d419dfcf8fb63a776e0d9fa6d3a9a6a52e84fedf3f467fe4af1ba8b&ascene=0&uin=Mjg5MDI3NjQ2Mg%3D%3D&devicetype=iMac+MacBookPro11%2C4+OSX+OSX+10.12.3+build(16D32)&version=12010310&nettype=WIFI&fontScale=100&pass_ticket=Upl17Ws6QQsmZSia%2F%2B0xkZs9DYxAJBQicqh8rcaxYUjcu3ztlJUPxYrQKML%2BUtuf
http://geek.csdn.net/news/detail/127226
http://www.reibang.com/p/216b03c22bb8
https://zhuanlan.zhihu.com/p/25213586
https://joyrun.github.io/2016/08/08/AndroidMemoryLeak/
http://www.cnblogs.com/larack/p/6071209.html
https://source.android.com/devices/tech/dalvik/gc-debug.html
http://blog.csdn.net/high2011/article/details/53138202
http://gityuan.com/2015/10/03/Android-GC/
http://www.ayqy.net/blog/android-gc-log%E8%A7%A3%E8%AF%BB/
https://developer.android.com/studio/profile/investigate-ram.html
https://zhuanlan.zhihu.com/p/26043999