轉(zhuǎn)載來之
http://blog.nimbledroid.com/2016/05/23/memory-leaks-zh.html

像 Java 這樣具有垃圾回收功能的語言的好處之一，就是程序員無需手動(dòng)管理內(nèi)存分配。這減少了段錯(cuò)誤（segmentation fault）導(dǎo)致的閃退，也減少了內(nèi)存泄漏導(dǎo)致的堆空間膨脹，讓編寫的代碼更加安全。然而，Java 中依然有可能發(fā)生內(nèi)存泄漏。所以你的安卓 APP 依然有可能浪費(fèi)了大量的內(nèi)存，甚至由于內(nèi)存耗盡（OOM）導(dǎo)致閃退。
傳統(tǒng)的內(nèi)存泄漏是由忘記釋放分配的內(nèi)存導(dǎo)致的，而邏輯上的內(nèi)存泄漏則是由于忘記在對(duì)象不再被使用的時(shí)候釋放對(duì)其的引用導(dǎo)致的。如果一個(gè)對(duì)象仍然存在強(qiáng)引用，垃圾回收器就無法對(duì)其進(jìn)行垃圾回收。在安卓平臺(tái)，泄漏 Context 對(duì)象問題尤其嚴(yán)重。這是因?yàn)橄?Activity 這樣的 Context 對(duì)象會(huì)引用大量很占用內(nèi)存的對(duì)象，例如 View 層級(jí)，以及其他的資源。如果 Context 對(duì)象發(fā)生了內(nèi)存泄漏，那它引用的所有對(duì)象都被泄漏了。安卓設(shè)備大多內(nèi)存有限，如果發(fā)生了大量這樣的內(nèi)存泄漏，那內(nèi)存將很快耗盡。
如果一個(gè)對(duì)象的合理生命周期沒有清晰的定義，那判斷邏輯上的內(nèi)存泄漏將是一個(gè)見仁見智的問題。幸運(yùn)的是，activity 有清晰的生命周期定義，使得我們可以很明確地判斷 activity 對(duì)象是否被內(nèi)存泄漏。onDestroy() 函數(shù)將在 activity 被銷毀時(shí)調(diào)用，無論是程序員主動(dòng)銷毀 activity，還是系統(tǒng)為了回收內(nèi)存而將其銷毀。如果 onDestroy 執(zhí)行完畢之后，activity 對(duì)象仍被 heap root 強(qiáng)引用，那垃圾回收器就無法將其回收。所以我們可以把生命周期結(jié)束之后仍被引用的 activity 定義為被泄漏的 activity。
Activity 是非常重量級(jí)的對(duì)象，所以我們應(yīng)該極力避免妨礙系統(tǒng)對(duì)其進(jìn)行回收。然而有多種方式會(huì)讓我們無意間就泄露了 activity 對(duì)象。我們把可能導(dǎo)致 activity 泄漏的情況分為兩類，一類是使用了進(jìn)程全局（process-global）的靜態(tài)變量，無論 APP 處于什么狀態(tài)，都會(huì)一直存在，它們持有了對(duì) activity 的強(qiáng)引用進(jìn)而導(dǎo)致內(nèi)存泄漏，另一類是生命周期長于 activity 的線程，它們忘記釋放對(duì) activity 的強(qiáng)引用進(jìn)而導(dǎo)致內(nèi)存泄漏。下面我們就來詳細(xì)分析一下這些可能導(dǎo)致 activity 泄漏的情況。

1. 靜態(tài) Activity
   泄漏 activity 最簡單的方法就是在 activity 類中定義一個(gè) static 變量，并且將其指向一個(gè)運(yùn)行中的 activity 實(shí)例。如果在 activity 的生命周期結(jié)束之前，沒有清除這個(gè)引用，那它就會(huì)泄漏了。這是因?yàn)?activity（例如 MainActivity） 的類對(duì)象是靜態(tài)的，一旦加載，就會(huì)在 APP 運(yùn)行時(shí)一直常駐內(nèi)存，因此如果類對(duì)象不卸載，其靜態(tài)成員就不會(huì)被垃圾回收。
   void setStaticActivity() { activity = this;}View saButton = findViewById(R.id.sa_button);saButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { setStaticActivity(); nextActivity(); }});

內(nèi)存泄漏場(chǎng)景 1 - Static Activity

2. 靜態(tài) View
   另一種類似的情況是對(duì)經(jīng)常啟動(dòng)的 activity 實(shí)現(xiàn)一個(gè)單例模式，讓其常駐內(nèi)存可以使它能夠快速恢復(fù)狀態(tài)。然而，就像前文所述，不遵循系統(tǒng)定義的 activity 生命周期是非常危險(xiǎn)的，也是沒必要的，所以我們應(yīng)該極力避免。
   但是如果我們有一個(gè)創(chuàng)建起來非常耗時(shí)的 View，在同一個(gè) activity 不同的生命周期中都保持不變呢？所以讓我們?yōu)樗鼘?shí)現(xiàn)一個(gè)單例模式，就像這段代碼?，F(xiàn)在一旦 activity 被銷毀，那我們就應(yīng)該釋放大部分的內(nèi)存了。
   void setStaticView() { view = findViewById(R.id.sv_button);}View svButton = findViewById(R.id.sv_button);svButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { setStaticView(); nextActivity(); }});

內(nèi)存泄漏場(chǎng)景 2 - Static View

內(nèi)存泄漏了！因?yàn)橐坏?view 被加入到界面中，它就會(huì)持有 context 的強(qiáng)引用，也就是我們的 activity。由于我們通過一個(gè)靜態(tài)成員引用了這個(gè) view，所以我們也就引用了 activity，因此 activity 就發(fā)生了泄漏。所以一定不要把加載的 view 賦值給靜態(tài)變量，如果你真的需要，那一定要確保在 activity 銷毀之前將其從 view 層級(jí)中移除。

3. 內(nèi)部類
   現(xiàn)在讓我們?cè)?activity 內(nèi)部定義一個(gè)類，也就是內(nèi)部類。這樣做的原因有很多，比如增加封裝性和可讀性。如果我們創(chuàng)建了一個(gè)內(nèi)部類的對(duì)象，并且通過靜態(tài)變量持有了 activity 的引用，那也會(huì)發(fā)生 activity 泄漏。
   void createInnerClass() { class InnerClass { } inner = new InnerClass();}View icButton = findViewById(R.id.ic_button);icButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { createInnerClass(); nextActivity(); }});

內(nèi)存泄漏場(chǎng)景 3 - Inner Class

不幸的是，內(nèi)部類能夠引用外部類的成員這一優(yōu)勢(shì)，就是通過持有外部類的引用來實(shí)現(xiàn)的，而這正是 activity 泄漏的原因。

4. 匿名類
   類似的，匿名類同樣會(huì)持有定義它們的對(duì)象的引用。因此如果在 activity 內(nèi)定義了一個(gè)匿名的 AsyncTask 對(duì)象，就有可能發(fā)生內(nèi)存泄漏了。如果 activity 被銷毀之后 AsyncTask 仍然在執(zhí)行，那就會(huì)組織垃圾回收器回收 activity 對(duì)象，進(jìn)而導(dǎo)致內(nèi)存泄漏，直到執(zhí)行結(jié)束才能回收 activity。
   void startAsyncTask() { new AsyncTask<Void, Void, Void>() { @Override protected Void doInBackground(Void... params) { while(true); } }.execute();}super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);View aicButton = findViewById(R.id.at_button);aicButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { startAsyncTask(); nextActivity(); }});

內(nèi)存內(nèi)存泄漏場(chǎng)景 4 - AsyncTask

5. Handlers
   同樣的，定義一個(gè)匿名的 Runnable 對(duì)象并將其提交到 Handler 上也可能導(dǎo)致 activity 泄漏。Runnable 對(duì)象間接地引用了定義它的 activity 對(duì)象，而它會(huì)被提交到 Handler 的 MessageQueue 中，如果它在 activity 銷毀時(shí)還沒有被處理，那就會(huì)導(dǎo)致 activity 泄漏了。
   void createHandler() { new Handler() { @Override public void handleMessage(Message message) { super.handleMessage(message); } }.postDelayed(new Runnable() { @Override public void run() { while(true); } }, Long.MAX_VALUE >> 1);}View hButton = findViewById(R.id.h_button);hButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { createHandler(); nextActivity(); }});

內(nèi)存泄漏場(chǎng)景 5 - Handler

6. Threads
   同樣的，使用 Thread 和 TimerTask 也可能導(dǎo)致 activity 泄漏。
   void spawnThread() { new Thread() { @Override public void run() { while(true); } }.start();}View tButton = findViewById(R.id.t_button);tButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { spawnThread(); nextActivity(); }});

內(nèi)存泄漏場(chǎng)景 6 - Thread

7. Timer Tasks
   只要它們是通過匿名類創(chuàng)建的，盡管它們?cè)趩为?dú)的線程被執(zhí)行，它們也會(huì)持有對(duì) activity 的強(qiáng)引用，進(jìn)而導(dǎo)致內(nèi)存泄漏。
   void scheduleTimer() { new Timer().schedule(new TimerTask() { @Override public void run() { while(true); } }, Long.MAX_VALUE >> 1);}View ttButton = findViewById(R.id.tt_button);ttButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { scheduleTimer(); nextActivity(); }});

內(nèi)存泄漏場(chǎng)景 7 - TimerTask

8. Sensor Manager
   最后，系統(tǒng)服務(wù)可以通過 context.getSystemService 獲取，它們負(fù)責(zé)執(zhí)行某些后臺(tái)任務(wù)，或者為硬件訪問提供接口。如果 context 對(duì)象想要在服務(wù)內(nèi)部的事件發(fā)生時(shí)被通知，那就需要把自己注冊(cè)到服務(wù)的監(jiān)聽器中。然而，這會(huì)讓服務(wù)持有 activity 的引用，如果程序員忘記在 activity 銷毀時(shí)取消注冊(cè)，那就會(huì)導(dǎo)致 activity 泄漏了。
   void registerListener() { SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE); Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL); sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);}View smButton = findViewById(R.id.sm_button);smButton.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { registerListener(); nextActivity(); }});

內(nèi)存泄漏場(chǎng)景 8 - Sensor Manager

現(xiàn)在，我們展示了八種很容易不經(jīng)意間就泄漏大量內(nèi)存的情景。請(qǐng)記住，最壞的情況下，你的 APP 可能會(huì)由于大量的內(nèi)存泄漏而內(nèi)存耗盡，進(jìn)而閃退，但它并不總是這樣。相反，內(nèi)存泄漏會(huì)消耗大量的內(nèi)存，但卻不至于內(nèi)存耗盡，這時(shí)，APP 會(huì)由于內(nèi)存不夠分配而頻繁進(jìn)行垃圾回收。垃圾回收是非常耗時(shí)的操作，會(huì)導(dǎo)致嚴(yán)重的卡頓。在 activity 內(nèi)部創(chuàng)建對(duì)象時(shí)，一定要格外小心，并且要經(jīng)常測(cè)試是否存在內(nèi)存泄漏。

SDK內(nèi)存泄漏 :

今天在使用LeakCanary檢查應(yīng)用的內(nèi)存泄露時(shí)，報(bào)了一個(gè)這樣的錯(cuò)誤，并且還給出了參考鏈接，原來這是Android輸入法的一個(gè)bug，在15<=API<=23中都存在。