一般內存泄漏(traditional memory leak)的原因是： 由忘記釋放分配的內存導致的。（如Cursor忘記關閉等） 邏輯內存泄漏(logical memory leak)的原因是： 當應用不再需要這個對象，當仍未釋放該對象的所有引用。 **如果持有對象的強引用，垃圾回收器是無法在內存中回收這個對象。** 在Android中，導致潛在內存泄漏的陷阱不外乎兩種： > 1）全局進程(process-global)的static變量。這個無視應用的狀態，持有Activity的強引用的怪物。 > 2）活在Activity生命周期之外的線程。沒有清空對Activity的強引用。 具體有以下幾種： #### 1.Static Activities **在類中定義了靜態Activity變量，把當前運行的Activity實例賦值于這個靜態變量。** 如果這個靜態變量在Activity生命周期結束后沒有清空，就導致內存泄漏。**因為static變量是貫穿這個應用的生命周期的，所以被泄漏的Activity就會一直存在于應用的進程中，不會被垃圾回收器回收**。 #### 2.Static Views View在內存中也是比較耗資源的，如果把View定義為static，加載到視圖樹上(View Hierachy)，也會造成內存泄漏。 #### 3.Inner Classes 內部類的優勢之一就是可以訪問外部類，不幸的是，導致內存泄漏的原因，就是內部類持有外部類實例的強引用。 #### 4.Anonymous Classes 相似地，匿名類也維護了外部類的引用。所以內存泄漏很容易發生，當你在Activity中定義了匿名的AsyncTsk。當異步任務在后臺執行耗時任務期間，Activity不幸被銷毀了（譯者注：用戶退出，系統回收），這個被AsyncTask持有的Activity實例就不會被垃圾回收器回收，直到異步任務結束。 #### 5.Handler 同樣道理，定義匿名的Runnable，用匿名類Handler執行。Runnable內部類會持有外部類的隱式引用，被傳遞到Handler的消息隊列MessageQueue中，在Message消息沒有被處理之前，Activity實例不會被銷毀了，于是導致內存泄漏。 #### 6.Threads #### 7.TimerTask 只要是匿名類的實例，不管是不是在工作線程，都會持有Activity的引用，導致內存泄漏。 #### 8.Sensor Manager 最后，通過Context.getSystemService(int name)可以獲取系統服務。這些服務工作在各自的進程中，幫助應用處理后臺任務，處理硬件交互。如果需要使用這些服務，可以注冊監聽器**，這會導致服務持有了Context的引用，如果在Activity銷毀的時候沒有注銷這些監聽器，會導致內存泄漏。**