摘要：如果這個靜態變量在生命周期結束后沒有清空，就導致內存泄漏。因此造成內存泄露。注冊沒取消造成的內存泄露這種的內存泄露比純的內存泄漏還要嚴重，因為其他一些程序可能引用系統的程序的對象比如注冊機制。

內存空間使用完畢之后未回收, 會導致內存泄漏。有人會問：Java不是有垃圾自動回收機制么？不幸的是，在Java中仍存在很多容易導致內存泄漏的邏輯(logical leak)。雖然垃圾回收器會幫我們干掉大部分無用的內存空間，但是對于還保持著引用，但邏輯上已經不會再用到的對象，垃圾回收器不會回收它們。

例如

忘記釋放分配的內存的。（Cursor忘記關閉等）。

應用不再需要這個對象，未釋放該對象的所有引用。

強引用持有的對象，垃圾回收器是無法在內存中回收這個對象。

持有對象生命周期過長，導致無法回收。

Android內存回收管理策略圖：

圖中的每個圓節點代表對象的內存資源，箭頭代表可達路徑。當圓節點與 GC Roots 存在可達路徑時，表示當前資源正被引用，虛擬機是無法對其進行回收的（如圖中的黃色節點）。反過來，如果圓節點與 GC Roots 不存在可達路徑，則意味著這塊對象的內存資源不再被程序引用，系統虛擬機可以在 GC 過程中將其回收掉。

從定義上講，Android（Java）平臺的內存泄漏是指沒有用的對象資源任與GC-Root保持可達路徑，導致系統無法進行回收。

用戶對單次的內存泄漏并沒有什么感知，但當泄漏積累到內存都被消耗完，就會導致卡頓，崩潰。

內存泄露是內存溢出OOM的重要原因之一，會導致Crash

比如Activity的Context，就包含大量的內存引用，一旦泄漏了Context，也意味泄漏它指向的所有對象。

造成Activity泄漏的常見原因：

Static Activities

在類中定義了靜態Activity變量，把當前運行的Activity實例賦值于這個靜態變量。
如果這個靜態變量在Activity生命周期結束后沒有清空，就導致內存泄漏。
因為static變量是貫穿這個應用的生命周期的，所以被泄漏的Activity就會一直存在于應用的進程中，不會被垃圾回收器回收。

static Activity activity; //這種代碼要避免

單例中保存Activity

在單例模式中，如果Activity經常被用到，那么在內存中保存一個Activity實例是很實用的。但是由于單例的生命周期是應用程序的生命周期，這樣會強制延長Activity的生命周期，這是相當危險而且不必要的，無論如何都不能在單例子中保存類似Activity的對象。
舉例：

public class Singleton {
    private static Singleton instance;
    private Context mContext;
    private Singleton(Context context){
        this.mContext = context;
    }

    public static Singleton getInstance(Context context){
        if (instance == null){
            synchronized (Singleton.class){
                if (instance == null){
                    instance = new Singleton(context);
                }
            }
        }
        return instance;
    }
}

在調用Singleton的getInstance()方法時傳入了Activity。那么當instance沒有釋放時，這個Activity會一直存在。因此造成內存泄露。
解決方法:

可以將new Singleton(context)改為new Singleton(context.getApplicationContext())即可，這樣便和傳入的Activity沒關系了。

Static Views

同理，靜態的View也是不建議的

Inner Classes

內部類的優勢可以提高可讀性和封裝性，而且可以訪問外部類，不幸的是，導致內存泄漏的原因，就是內部類持有外部類實例的強引用。 例如在內部類中持有Activity對象

解決方法：

1.將內部類變成靜態內部類;
2.如果有強引用Activity中的屬性，則將該屬性的引用方式改為弱引用;
3.在業務允許的情況下，當Activity執行onDestory時，結束這些耗時任務;

例如：
發生內存泄漏的代碼：

public class LeakAct extends Activity {  
     @Override
     protected void onCreate(Bundle savedInstanceState) {    
         super.onCreate(savedInstanceState);
         setContentView(R.layout.aty_leak);
         test();
     } 
     //這兒發生泄漏    
     public void test() {    
         new Thread(new Runnable() {      
             @Override
             public void run() {        
                 while (true) {          
                     try {
                         Thread.sleep(1000);
                     } catch (InterruptedException e) {
                         e.printStackTrace();
                     }
                 }
             }
         }).start();
     }
 }

解決方法：

public class LeakAct extends Activity {  
     @Override
     protected void onCreate(Bundle savedInstanceState) {    
         super.onCreate(savedInstanceState);
         setContentView(R.layout.aty_leak);
         test();
     }  
     //加上static，變成靜態匿名內部類
     public static void test() {    
         new Thread(new Runnable() {     
             @Override
             public void run() {        
                 while (true) {          
                     try {
                         Thread.sleep(1000);
                     } catch (InterruptedException e) {
                         e.printStackTrace();
                     }
                 }
             }
         }).start();
     }
 }

Anonymous Classes

匿名類也維護了外部類的引用。當你在匿名類中執行耗時任務，如果用戶退出，會導致匿名類持有的Activity實例就不會被垃圾回收器回收，直到異步任務結束。

Handler

handler中，Runnable內部類會持有外部類的隱式引用，被傳遞到Handler的消息隊列MessageQueue中，在Message消息沒有被處理之前，Activity實例不會被銷毀了，于是導致內存泄漏。
解決方法：

1.可以把Handler類放在多帶帶的類文件中，或者使用靜態內部類便可以避免泄露;
2.如果想在Handler內部去調用所在的Activity,那么可以在handler內部使用弱引用的方式去指向所在Activity.使用Static + WeakReference的方式來達到斷開Handler與Activity之間存在引用關系的目的.
3.在界面銷毀是，釋放handler資源

@Override
 protected void doOnDestroy() {        
     super.doOnDestroy();        
     if (mHandler != null) {
         mHandler.removeCallbacksAndMessages(null);
     }
     mHandler = null;
     mRenderCallback = null;
 }

同樣還有其他匿名類實例，如TimerTask、Threads等，執行耗時任務持有Activity的引用，都可能導致內存泄漏。

線程產生內存泄露的主要原因在于線程生命周期的不可控。如果我們的線程是Activity的內部類，所以MyThread中保存了Activity的一個引用，當MyThread的run函數沒有結束時，MyThread是不會被銷毀的，因此它所引用的老的Activity也不會被銷毀，因此就出現了內存泄露的問題。

傳入Application 的 Context，因為 Application 的生命周期就是整個應用的生命周期，所以這將沒有任何問題。

如果此時傳入的是 Activity 的 Context，當這個 Context 所對應的 Activity 退出時，主動結束執行的任務，并釋放Activity資源。

將線程的內部類，改為靜態內部類。

因為非靜態內部類會自動持有一個所屬類的實例，如果所屬類的實例已經結束生命周期，但內部類的方法仍在執行，就會hold其主體（引用）。也就使主體不能被釋放，亦即內存泄露。靜態類編譯后和非內部類是一樣的，有自己獨立的類名。不會悄悄引用所屬類的實例，所以就不容易泄露。

如果需要引用Acitivity，使用弱引用。

謹慎對context使用static關鍵字。

Bitmap對象在不使用時,我們應該先調用recycle()釋放內存，然后才設置為null.

我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，并沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。
解決方案：

在Activity退出之前，將集合里的東西clear，然后置為null，再退出程序。

這種Android的內存泄露比純Java的內存泄漏還要嚴重，因為其他一些Android程序可能引用系統的Android程序的對象（比如注冊機制）。即使Android程序已經結束了，但是別的應用程序仍然還有對Android程序的某個對象的引用，泄漏的內存依然不能被垃圾回收。
解決方案：

1.使用ApplicationContext代替ActivityContext;
2.在Activity執行onDestory時，調用反注冊;

資源性對象比如（Cursor，File文件等）往往都用了一些緩沖，我們在不使用的時候，應該及時關閉它們，以便它們的緩沖及時回收內存。而不是等待GC來處理。

因為Bitmap占用的內存實在是太多了，特別是分辨率大的圖片，如果要顯示多張那問題就更顯著了。Android分配給Bitmap的大小只有8M.
解決方法：

1.等比例縮小圖片

BitmapFactory.Options options = new BitmapFactory.Options(); 
options.inSampleSize = 2;//圖片寬高都為原來的二分之一，即圖片為原來的四分之一 

2.對圖片采用軟引用，及時地進行recycle()操作

//軟引用
 SoftReference bitmap = new SoftReference(pBitmap); 
//回收操作
 if(bitmap != null) {  
       if(bitmap.get() != null && !bitmap.get().isRecycled()){ 
           bitmap.get().recycle(); 
           bitmap = null;  
       } 
} 

解決方案:

用新的進程起含有WebView的Activity,并且在該Activity 的onDestory() 最后加上 System.exit(0); 殺死當前進程。

1.使用 靜態代碼分析工具-Lint 檢查內存泄漏

Lint 是 Android Studio 自帶的工具，使用姿勢很簡單 Analyze -> Inspect Code 然后選擇想要掃面的區域即可

對可能引起泄漏的編碼，Lint 都會進行溫馨提示：

2.LeakCanary 工具

Square 公司出品的內存分析工具，官方地址如下：https://github.com/square/lea...
LeakCanary 需要在項目代碼中集成，不過代碼也非常簡單，如下的官方示例：

在你的 build.gradle:

dependencies {
 debugImplementation "com.squareup.leakcanary:leakcanary-android:1.6.3"
 releaseImplementation "com.squareup.leakcanary:leakcanary-android-no-op:1.6.3"
 // Optional, if you use support library fragments:
 debugImplementation "com.squareup.leakcanary:leakcanary-support-fragment:1.6.3"
}

在 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 會彈窗提示并生成對應的堆存儲信息記錄

-3.Android Monitor

開Android Studio，編譯代碼，在模擬器或者真機上運行App，然后點擊

，在Android Monitor下點擊Monitor對應的Tab，進入如下界面

在Memory一欄中，可以觀察不同時間App內存的動態使用情況，點擊

可以手動觸發GC，點擊

可以進入HPROF Viewer界面，查看Java的Heap，如下圖

Reference Tree代表指向該實例的引用，可以從這里面查看內存泄漏的原因，Shallow Size指的是該對象本身占用內存的大小，Retained Size代表該對象被釋放后，垃圾回收器能回收的內存總和。

強引用(StrongReference)：JVM 寧可拋出 OOM ，也不會讓 GC 回收具有強引用的對象；

軟引用(SoftReference)：只有在內存空間不足時，才會被回的對象；

弱引用(WeakReference)：在 GC 時，一旦發現了只具有弱引用的對象，不管當前內存空間足夠與否，都會回收它的內存；

虛引用(PhantomReference)：任何時候都可以被GC回收，當垃圾回收器準備回收一個對象時，如果發現它還有虛引用，就會在回收對象的內存之前，把這個虛引用加入到與之關聯的引用隊列中。程序可以通過判斷引用隊列中是否存在該對象的虛引用，來了解這個對象是否將要被回收。可以用來作為GC回收Object的標志。