一、前言

我們在開發過程中，經常使用 Handler，而使用 Handler 很容易造成內存泄漏，Android Studio 也會提示我們：This Handler class should be static or leaks might occur (anonymous android.os.Handler) ，如下圖所示：

Handler 內存泄漏.png

二、什么是內存泄漏？

內存泄漏，即Memory Leak，指程序中不再使用到的對象因某種原因而無法被GC正常回收，發生內存泄漏會對我們的應用造成如下影響：

• 導致一些不再使用到的對象沒有及時釋放，這些對象占據著寶貴的內存空間，很容易導致后續分配內存的時候，內存空間不足而出現OOM（內存溢出）。
• 無用對象占據的空間越多，那么可用的空閑空間也就越少，GC就會更容易被觸發，GC進行時會停止其他線程的工作，因此有可能造成卡頓等情況。

三、出現內存泄漏的原因分析

在上面的例子中，Android Studio 提示我們：This Handler class should be static or leaks might occur (anonymous android.os.Handler) 。這里說這個 Handler 類應用使用靜態的，否則可能會出現內存泄漏。

注意看，這里用了 might，也就是說這樣寫不一定會出現內存泄漏，那么什么情況下一定會出現內存泄漏呢，請看下面一個列子：

public class ExampleActivity extends AppCompatActivity {

    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            // Do Something
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_example);
        new ExampleThread().start();
        finish();
    }

    class ExampleThread extends Thread {
        @Override
        public void run() {
            mHandler.sendEmptyMessageDelayed(0, 10000);
        }
    }
}

這里我們在主線程定義了一個 Handler 對象，然后在子線程中使用 Handler 對象的 sendEmptyMessageDelayed() 方法發送一個延時 10000ms 的消息，接著使用 finish()，這就一定會發生內存泄漏了。

下面我們來分析一下，為什么這種情況一定會發生內存泄漏。首先我們先給出結論：

Handler 對象持有 Activity 的引用，主線程 Looper 又持有 Handler 對象的引用。當 Activity 的生命周期結束時，主線程 Looper 還持有 Handler 對象的引用。所以這個 Activity 無法被垃圾回收，內存泄漏就發生了。

大家可能會疑惑：為什么 Handler 對象會持有 Activity 的引用呢？為什么主線程 Looper 會持有 Handler 對象的引用呢？

1.Handler 為什么會持有 Activity 的引用？

要解答這個問題，我們需要掌握一些關于非靜態內部類的儲備知識：

• 編譯器自動為內部類添加一個成員變量， 這個成員變量的類型和外部類的類型相同， 這個成員變量就是指向外部類對象(this)的引用。
• 編譯器自動為內部類的構造方法添加一個參數， 參數的類型是外部類的類型， 在構造方法內部使用這個參數為內部類中添加的成員變量賦值。
• 在調用內部類的構造函數初始化內部類對象時，會默認傳入外部類的引用。

了解了非靜態內部類的知識，那么我們就清楚了：

我們這里的 Handler 為匿名類（非靜態內部類），內部類和外部類雖然寫在同一個java文件中，但是編譯完成后，它們還是會生成各自的 class 文件，內部類通過 this 訪問外部類的成員。所以非靜態內部類（handler）會隱式調用外部類對象（this，也就是Activity）。

2.主線程 Looper 為什么會持有 Handler 對象的引用？

我們在調用 Handler 對象的 sendMessage() 或者 post() 系列方法去發送消息時（無論 Handler 是在哪個線程創建的），最終都調用了 Handler 的 enqueueMessage() 方法，代碼如下：

    private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
        msg.target = this;
        if (mAsynchronous) {
            msg.setAsynchronous(true);
        }
        return queue.enqueueMessage(msg, uptimeMillis);
    }

其中 this 就是我們創建的 Handler 對象，然后 msg 引用了 Handler 對象并進入了消息隊列中，而 Looper 持有 MessageQueue 的引用。所以我們的 Handler 對象就一直被 Looper 引用著，直到 Looper 取出這個 Message。

現在我們就清楚 Handler 發生內存泄漏的原因了：Handler 對象持有 Activity 的引用，主線程 Looper 又持有 Handler 對象的引用。當 Activity 的生命周期結束時，主線程 Looper 還持有 Handler 對象的引用。所以這個 Activity 無法被垃圾回收，內存泄漏就發生了。

四、解決方案

現在我們知道了 Handler 出現內存泄漏的原因其中之一，就是 Handler 這個非靜態內部類隱式引用了 Activity，那么針對這點，我們可以想出兩個解決方法：

• 將 Handler 獨立出去，單獨一個 java 文件
• 使用 靜態內部類+弱引用 來實現 Handler

第一個解決方法比較簡單，我們就主要來介紹一下第二個方法。通常我們會使用 靜態內部類+弱引用 的方法來解決 Handler 的內存泄漏問題。

示例代碼如下：

public class StaticHandlerActivity extends AppCompatActivity {
    private TextView mStateTv; //UI控件
    private MyHandler mHandler = new MyHandler(this); //創建handler對象時傳入當前Activity

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_static_handler);

        initView();
    }

    private void initView() {
        mStateTv = findViewById(R.id.tv_state);
    }

    private static class MyHandler extends Handler {
        private final WeakReference<StaticHandlerActivity> mActivity;

        public MyHandler(StaticHandlerActivity activity) {
            mActivity = new WeakReference<StaticHandlerActivity>(activity); //獲取弱引用Activity對象
        }

        @Override
        public void handleMessage(@NonNull Message msg) {
            if (mActivity.get() != null) {
                //TODO
                //利用弱引用來獲取UI控件，不會對回收造成影響
                mActivity.get().mStateTv.setText("state change");
                
                //如果直接new Activity（）來獲取Activity屬于強引用，依然會造成內存泄漏
                //new StaticHandlerActivity().mStateTv.setText("state change"); 
            }
        }
    }
}

如上代碼，使用靜態內部類，解決了 Handler 持有 Activity 的隱式引用的問題；采用弱引用的方式，來獲取 Activity 的引用，以此來更新 UI。

關于 java.lang.ref.WeakReference<T>，下面是 Android 官方給出的介紹

Weak reference objects, which do not prevent their referents from being made finalizable, finalized, and then reclaimed. Weak references are most often used to implement canonicalizing mappings.

Suppose that the garbage collector determines at a certain point in time that an object is weakly reachable. At that time it will atomically clear all weak references to that object and all weak references to any other weakly-reachable objects from which that object is reachable through a chain of strong and soft references. At the same time it will declare all of the formerly weakly-reachable objects to be finalizable. At the same time or at some later time it will enqueue those newly-cleared weak references that are registered with reference queues.

弱引用對象，這些對象不會阻止對其引用對象進行終結，終結和回收。弱引用最常用于實現規范化映射。

假設垃圾收集器在某個時間點確定對象是弱可訪問的。到那時，它將自動清除對該對象的所有弱引用，以及對所有其他弱可達對象的弱引用，這些對象都可以通過一系列強引用和軟引用從該對象到達。同時，它將聲明所有以前難以到達的對象都是可終結的。同時或在以后的某個時間，它將排隊那些已在參考隊列中注冊的新清除的弱引用。

通俗的講，一個對象如果只有被弱引用，那么它就會被回收。所以在使用弱引用的對象時，需要判斷當前對象是否已經被回收了。

if (mActivity.get() != null) {
    //TODO       
}

到這里，我們的 Handler 已經不會出現內存泄漏的情況了，不過為了保險起見和代碼的邏輯完整性，我們可以在 Activity 的 onDestroy() 中將消息隊列中的消息全部移除，代碼如下：

    @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
    }

五、總結

讓我們來回顧一下關于 Handler 內存泄漏出現的原因：

• Handler 對象持有 Activity 的引用，主線程 Looper 又持有 Handler 對象的引用。當 Activity 的生命周期結束時，主線程 Looper 還持有 Handler 對象的引用。所以這個 Activity 無法被垃圾回收，內存泄漏就發生了。

我們可以通過以下兩種方式來解決:

• 將 Handler 獨立出去，單獨一個 java 文件
• 使用 靜態內部類+弱引用 來實現 Handler

同時配合 Activity 的 onDestroy() 方法中使用 Handler.removeCallbacksAndMessages(null) 來移除未處理的消息。

不過還記得我們在文章最開始說過的嗎？并不是每個 Handler 都會產生內存泄漏，如果你清楚你的 Activity 在結束時，消息隊列中已經沒有未處理的消息了，那你也不必加一堆代碼來防止內存泄漏了。

    @SuppressLint("HandlerLeak")
    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            // Do Something
        }
    };

強迫癥患者可以直加上 @SuppressLint("HandlerLeak") 不讓 Android Studio 提示你那一串英文了。

那么 Handler 內存泄漏分析的文章到這里也結束了，雖然很多時候也不用加上一堆代碼來防止內存泄漏，但是出于技術的完整性，以及在使用 Handler 心里有個底，了解其背后的原理還是有必要的。