轉載來之
http://blog.nimbledroid.com/2016/05/23/memory-leaks-zh.html

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

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

內存泄漏場景 1 - Static Activity

2. 靜態 View
   另一種類似的情況是對經常啟動的 activity 實現一個單例模式，讓其常駐內存可以使它能夠快速恢復狀態。然而，就像前文所述，不遵循系統定義的 activity 生命周期是非常危險的，也是沒必要的，所以我們應該極力避免。
   但是如果我們有一個創建起來非常耗時的 View，在同一個 activity 不同的生命周期中都保持不變呢？所以讓我們為它實現一個單例模式，就像這段代碼。現在一旦 activity 被銷毀，那我們就應該釋放大部分的內存了。
   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(); }});

內存泄漏場景 2 - Static View

內存泄漏了！因為一旦 view 被加入到界面中，它就會持有 context 的強引用，也就是我們的 activity。由于我們通過一個靜態成員引用了這個 view，所以我們也就引用了 activity，因此 activity 就發生了泄漏。所以一定不要把加載的 view 賦值給靜態變量，如果你真的需要，那一定要確保在 activity 銷毀之前將其從 view 層級中移除。

3. 內部類
   現在讓我們在 activity 內部定義一個類，也就是內部類。這樣做的原因有很多，比如增加封裝性和可讀性。如果我們創建了一個內部類的對象，并且通過靜態變量持有了 activity 的引用，那也會發生 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(); }});

內存泄漏場景 3 - Inner Class

不幸的是，內部類能夠引用外部類的成員這一優勢，就是通過持有外部類的引用來實現的，而這正是 activity 泄漏的原因。

4. 匿名類
   類似的，匿名類同樣會持有定義它們的對象的引用。因此如果在 activity 內定義了一個匿名的 AsyncTask 對象，就有可能發生內存泄漏了。如果 activity 被銷毀之后 AsyncTask 仍然在執行，那就會組織垃圾回收器回收 activity 對象，進而導致內存泄漏，直到執行結束才能回收 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(); }});

內存內存泄漏場景 4 - AsyncTask

5. Handlers
   同樣的，定義一個匿名的 Runnable 對象并將其提交到 Handler 上也可能導致 activity 泄漏。Runnable 對象間接地引用了定義它的 activity 對象，而它會被提交到 Handler 的 MessageQueue 中，如果它在 activity 銷毀時還沒有被處理，那就會導致 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(); }});

內存泄漏場景 5 - Handler

6. Threads
   同樣的，使用 Thread 和 TimerTask 也可能導致 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(); }});

內存泄漏場景 6 - Thread

7. Timer Tasks
   只要它們是通過匿名類創建的，盡管它們在單獨的線程被執行，它們也會持有對 activity 的強引用，進而導致內存泄漏。
   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(); }});

內存泄漏場景 7 - TimerTask

8. Sensor Manager
   最后，系統服務可以通過 context.getSystemService 獲取，它們負責執行某些后臺任務，或者為硬件訪問提供接口。如果 context 對象想要在服務內部的事件發生時被通知，那就需要把自己注冊到服務的監聽器中。然而，這會讓服務持有 activity 的引用，如果程序員忘記在 activity 銷毀時取消注冊，那就會導致 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(); }});

內存泄漏場景 8 - Sensor Manager

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

SDK內存泄漏 :

今天在使用LeakCanary檢查應用的內存泄露時，報了一個這樣的錯誤，并且還給出了參考鏈接，原來這是Android輸入法的一個bug，在15<=API<=23中都存在。