Android開發經常會用到handler，但是我們發現每次使用Handler都會出現：This Handler class should be static or leaks might occur（null）這樣的提示。Android lint就是為了提示我們，這樣使用Handler會容易造成記憶體洩漏。但是你會發現其實改成static並沒有什麼用。因為這並沒有解決這個問題的根本。

　　首先，我們得確認，為什麼會有記憶體洩漏？因為Handler是基於訊息的。每次new 出Handler，都會建立一個訊息佇列用於處理你使用handler傳送的訊息，形如：handler.send***Message。由於訊息的傳送總是會有先來後到的區別（如果只是這樣都還好，畢竟再慢也不會太久，總歸可以跑完，可能會延遲個幾秒），但是如果你使用的是sendMessageDelayed(Message msg, long delayMillis)或postDelayed(Runnable r, long delayMillis)等傳送延遲訊息的時候，那基本記憶體洩漏發生的概率已經在90%以上了。

     我舉個通常的例子，就是我們在Activity中使用handler來更新UI控制元件，這是比較常見的。

 1 public class DemoActivity extends Activity {
 2 
 3     private Handler mHandler; 
 4 
 5     protected void onCreate(Bundle savedInstanceState) {
 6         mHandler = new Handler();
 7 
 8 　　　　　mHandler.postDelayed(new Runnable() {
 9 　　　　　　　Log.i("wytings","-----------postDelayed-------");
 
10             view.setVisibility(View.GONE);
11         }, 50000);
12         ...
13     }
14 　　

      如果我們瘋狂的對這個Activity進行橫屏和豎屏切換的話，那麼Activity就會不斷的被銷燬和重建。理論上被關閉的Activity應該會再特定時候被回收，也就是我們的記憶體會在一定的範圍內上下起伏，但是實際上，會發現消耗的記憶體會隨著切換橫屏的次數一直慢慢增加。這其實已經說明我們的記憶體洩漏了，如果你會檢視記憶體，你會發現裡面有成堆的DemoActivity例項沒辦法回收。

　　這是因為view中使用的Context就是當前的Activity，而這個runnable一旦被post，就會一直存在於佇列裡面，直到時間到了，被執行。意思是這個時間段內Activity即使已經被destroy了但是這個物件還是沒辦法回收，你會發現50秒好，會有一堆"-----------postDelayed-------"的log打印出來，雖然你已經被這個應用關閉了並且你以為即使列印也應該只打印一次……

　　那怎麼樣才可以避免這中問題呢，如果你網上一搜你會看到很多關於弱引用的文章。這確實是一個解決的辦法。其原理就是讓所有在handler裡面使用的物件都變成弱引用，目的就是為了可以在Android回收記憶體的時候，可以直接回收掉。我真覺得如果只是寫這種辦法的人，絕對是屬於拷貝黨，因為這完全是就事論事。你想想就明白，我們寫這個Handler是因為我們要使用它。怎麼可以通過這種弱引用的辦法去處理這類問題呢？讓JVM想回收就回收？！如果這樣，那我們還需要在使用Bitmap的時候，recycle()幹嘛，還不如直接弄成軟引用得了。

這裡需要再插播一下關於Java裡面引用的知識：

      如果你運氣好，你會碰到一些除了寫弱引用這個方法後，還有一個就是handler.removeCallbacksAndMessages(null);，就是移除所有的訊息和回撥，簡單一句話就是清空了訊息佇列。注意，不要以為你post的是個Runnable或者只是sendEmptyMessage。你可以看一下原始碼，在handler裡面都是會把這些轉成正統的Message，放入訊息佇列裡面，所以清空佇列就意味著這個Handler直接被打成原型了，當然也就可以回收了。

　　所以，我覺得最好的辦法就是你在使用Handler的時候，在外面的Activity或者Fragment中的關閉方法中，如onDestroy中呼叫一下handler.removeCallbacksAndMessages(null);就可以了，不應該改成軟引用。

轉自：http://www.cnblogs.com/wytings/p/5225278.html