Handler常见疑问

首先是来一段写了一万遍的代码，Handler的基本使用

public class MainActivity extends AppCompatActivity {

    private TextView textView;

    private Handler handler = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            textView.setText("二二三四");
            return false;
        }
    });

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

        textView = findViewById(R.id.textView);
        textView.setText("一二三四");

        handlerTest();
    }

    private void handlerTest() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                Message message = handler.obtainMessage();
                handler.sendMessage(message);
            }
        }).start();
    }
}

毫无疑问textView直接被改成了“二二三四”，那第一个问题问题来了：

一、可不可以在子线程里直接修改textView内容，这样的代码：

public class MainActivity extends AppCompatActivity {

    ...

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        handlerTest();
    }

    private void handlerTest() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                textView.setText("二二三四");
            }
        }).start();
    }
}

先不要着急否定，运行一下试试：


子线程中修改textView为“二二三四”

再加一句代码：

public class MainActivity extends AppCompatActivity {

    ...

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        handlerTest();
    }

    private void handlerTest() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                //添加一秒延迟
                SystemClock.sleep(1000);
                textView.setText("二二三四");
            }
        }).start();
    }
}

在setText()之前加了一秒延迟，在运行一下，没图，直接炸了，错误信息：

android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
  at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:7286)
  at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1155)

Only the original thread that created a view hierarchy can touch its views.这一句说的很明显，但是为什么不加延迟就可以，直接去看下源码找原因，setText()方法点进去一步步跟踪：

    private void setText(CharSequence text, BufferType type,
                         boolean notifyBefore, int oldlen) {
        ...
        if (mLayout != null) {
            checkForRelayout();
        }

        ...
    }

这里的checkForRelayout()再点进去：

    private void checkForRelayout() {
        ...

        if (...)
            ...
            requestLayout();
            invalidate();
        } else {
            ...
            requestLayout();
            invalidate();
        }
    }

发现这里无论如何都会走requestLayout();和invalidate();，requestLayout()再继续跟：

    public void requestLayout() {
       ...

        if (...) {
            ...
            ViewRootImpl viewRoot = getViewRootImpl();
            ...
        }

        if (mParent != null && !mParent.isLayoutRequested()) {
            mParent.requestLayout();
        }
        ...
    }

这里就发现了跟错误信息有些对上了，错误信息的定位是这样的：

at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:7286)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1155)

但是我们跟踪到的是mParent.requestLayout();虽然上面有个ViewRootImpl，这个mParent是ViewParent类型，点ViewParent会发现这是个接口，而ViewRootImpl正实现了这个接口，所以我们直接可以去ViewRootImpl里找错误信息里的requestLayout()方法，这里显特别注意一点，一会要用，就是如果mParent != null，才会继续进行下面的requestLayout()：

    @Override
    public void requestLayout() {
        if (...) {
            checkThread();
            ...
        }
    }

这里也发现了错误信息里的下一层方法checkThread()，再跟进去：

    void checkThread() {
        if (mThread != Thread.currentThread()) {
            throw new CalledFromWrongThreadException(
                    "Only the original thread that created a view hierarchy can touch its views.");
        }
    }

这里就是导致崩溃的CalledFromWrongThreadException，只要mThread != Thread.currentThread()成立就会报错，这里报错其实是可以理解的，因为我们是在子线程里调用setText()，所以Thread.currentThread()获取到的一定是子线程，并不是主线程mThread，mThread是ViewRootImpl初始化是存储的赋值的，所以直接抛出异常。那为什么不延迟的情况下不报错呢？上面提到过特别注意的那一点就是如果mParent != null，才会继续进行下面的requestLayout()，那这个mParent也就是ViewRootImpl是在ActivityThread的handleResumeActivity(..)中创建的，是在主线程中，所以如果setText的子线程如果在ViewRootImpl创建之前执行了，那么requestLayout();并不会报出异常，会继续执行invalidate();，控件也就被刷行了。

二、Handler内存泄漏测试

还是一段常见的代码：

public class MainActivity extends AppCompatActivity {

    private Handler handler = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            startActivity(new Intent(MainActivity.this, AnotherActivity.class));
            return false;
        }
    });

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

        findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                startAnotherActivity();
            }
        });
    }
    
    private void startAnotherActivity(){
        new Thread(new Runnable() {
            @Override
            public void run() {
                SystemClock.sleep(3000);
                Message message = handler.obtainMessage();
                message.what = 666;
                handler.sendMessage(message);
            }
        }).start();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.e(TAG, "onDestroy: ");
    }
}

点击发送消息，收到消息跳转。一般在线程都会进行一个耗时操作，这里用个3秒延迟模拟下，点击跳转然后再3秒延迟之内关闭Activity，结果就是3秒过后还是跳转了，而且第一个Activity的onDestroy()也执行了。这里就是发生了内存泄漏，运行效果：


Activity还是打开了

这种泄漏怎么处理，先看这种方式：

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.e(TAG, "onDestroy: ");
        handler.removeMessages(666);
    }

这种方式是不行的，解决不了问题，因为在onDestroy()执行的时候，延迟还没有结束，所以message并没有在消息队列中，这样移除的话，必须要发送的时候同时改变才可以：

        new Thread(new Runnable() {
            @Override
            public void run() {
                Message message = handler.obtainMessage();
                message.what = 666;
                handler.sendMessageDelayed(message, 3000);
            }
        }).start();

这样会直接把message放入消息队列，三秒后执行，所以这样再removeMessages()是会起作用的。但是这样很难用，一般我的做的耗时操作，比如网络请求，并不能知道时长，我们需要的就是再耗时执行完成后发动消息，也就是说如果一定要用SystemClock.sleep(3000)，怎么解决内存泄漏？很简单：

public class MainActivity extends AppCompatActivity {

   ...
    private void startAnotherActivity(){
        new Thread(new Runnable() {
            @Override
            public void run() {
                SystemClock.sleep(3000);
                if (handler != null){
                    Message message = handler.obtainMessage();
                    message.what = 666;
                    handler.sendMessage(message);
                }
            }
        }).start();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.e(TAG, "onDestroy: ");
        if (handler != null) {
            handler.removeCallbacksAndMessages(null);
            handler = null;
        }
    }
}

三、Handler的另一种写法

可能有时候看到有的Handler不是这样写的，两种写法比较一下：

    private Handler handler = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            return false;
        }
    });

    private Handler handler2 = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    };

这两种都可以实现消息接受，去源码里看看有什么区别，关于Loop、MessageQueue、Message这里不再展开，直接这里从ActivityThread里看Handler是如何接收消息的，在ActivityThread的main函数里：

    public static void main(String[] args) {
        ...
        Looper.loop();
        ...
    }

然后点这个loop()继续跟：

    public static void loop() {
        ...
        for (;;) {
            Message msg = queue.next();
            ...

            msg.target.dispatchMessage(msg);
            ...
        }
    }

这里是一个无限的循环，不停的去消息队列里取下一条，然后调用了msg.target.dispatchMessage(msg)，这个target是什么？他其实就是handler，可以去Message源码里看一下是这样的：

public final class Message implements Parcelable {
    ...
    Handler target;
    ...
}

那直接可以去Handler源码中找dispatchMessage()方法：

    public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

而这里的mCallback就是第一种Handler创建时候传递过来的Callback，那么这里一目了然，最外层的if中msg.callback我们这里不用关心，直接进去else中，如果mCallback有值，优先执行mCallback.handleMessage(msg)，执行完之后直接return，不会再执行Handler的handleMessage(msg)，所以两种Handler的写法都能实现消息传递，但是第二种写法也就是没有Callback的那种，是有黄色警告的，所以推荐使用第一种Callback的写法。
这里还有个问题，就是mCallback.handleMessage(msg)的返回值，看上面这段代码的意思，如果返回true直接return了还好，如果返回false还是会执行Handler的handleMessage(msg);，也就是说既传递了Callback又重写了Handler的handleMessage(msg)会有什么效果？比如这样的代码：

    private Handler handler = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            Log.e(TAG, "Callback的handleMessage");
            return false;
        }
    }){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            Log.e(TAG, "Handler的handleMessage");
        }
    };

这样写的话，第一个handleMessage()的返回值直接影响第二个handleMessage()是否被调用，如果不重写第二个handleMessage()，也就是Handler中的handleMessage()的方法，那第一个里的返回值就没什么意义了，因为Handler源码中的handleMessage()是一个空的方法。

四、为什么不能在子线程中new Handler() ?

public class MainActivity extends AppCompatActivity {

    ...
    private void startAnotherActivity(){
        new Thread(new Runnable() {
            @Override
            public void run() {
                new Handler();
            }
        }).start();
    }
    ...
}

运行一下直接炸：

    java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
        at android.os.Handler.<init>(Handler.java:203)
        at android.os.Handler.<init>(Handler.java:117)
        at com.yu.handlertest.MainActivity$4.run(MainActivity.java:58)
        at java.lang.Thread.run(Thread.java:764)

这个点进去Handler源码就能看到原因：

    public Handler(Callback callback, boolean async) {
        ...

        mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread " + Thread.currentThread()
                        + " that has not called Looper.prepare()");
        }
        ...
    }

    ...

    /**
     * Return the Looper object associated with the current thread.  Returns
     * null if the calling thread is not associated with a Looper.
     */
    public static @Nullable Looper myLooper() {
        return sThreadLocal.get();
    }

这个myLooper ()方法的注释写的也很清楚，获取当前线程的Looper对象很显然这个线程里我没没有Looper对象，那问题来了，主线程里我们也没创建，为什么没问题？
这个还是看ActivityThread类的源码可以找到原因，ActivityThread是在程序一打开就会被创建的，ActivityThread的main函数有调用这一个方法：

    public static void main(String[] args) {
        ...

        Looper.prepareMainLooper();
        ...
    }

到Looper类中跟一下这个方法：

    public static void prepareMainLooper() {
        prepare(false);
        ...
    }

    private static void prepare(boolean quitAllowed) {
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        sThreadLocal.set(new Looper(quitAllowed));
    }

这里就证明ActivityThread的mian函数里会进行sThreadLocal.set()操作，所以在在主线程中创建Handler的时候，获取主线程的Loop对象时sThreadLocal.get()是有值的。这了可能有个疑问，同样是调用sThreadLocal.get()，并没有传递参数过去，是怎么区分线程的？继续看下一个问题：

五、ThreadLocal是什么？

打开ThreadLocal看他的get()方法：

    /**
     * Returns the value in the current thread's copy of this
     * thread-local variable.  If the variable has no value for the
     * current thread, it is first initialized to the value returned
     * by an invocation of the {@link #initialValue} method.
     *
     * @return the current thread's value of this thread-local
     */
    public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }

这里就会发现，调用get的时候，他会以当前线程作为key去取值，取不到就会调用setInitialValue ()方法，直接撸一段代码看效果，上面Handler里的ThreadLocal中存的是Looper对象，这里用String做演示：

    ThreadLocal<String> threadLocal = new ThreadLocal<String>(){
        @Nullable
        @Override
        protected String initialValue() {
            return "默认值";
        }
    };

    private void testThreadLocal() {
        // 获取主线程中的值，这里应该输出默认值
        Log.e(TAG, "主线程修改前: " + threadLocal.get());
        // 在主线程修改threadLocal的值为："A"
        threadLocal.set("A");
        // 获取主线程中的值，因为修改过，所以这里应该输出："A
        Log.e(TAG, "主线程修改后: " + threadLocal.get());

        //Thread1
        new Thread(new Runnable() {
            @Override
            public void run() {
                //子线程中获取threadLocal的值，主线程中已经进行修改，看子线程中是什么值
                Log.e(TAG, "Thread1修改前: " + threadLocal.get());
                threadLocal.set("B");
                //子线程中获取threadLocal的值，子线程中已经进行修改，看子线程中是什么值
                Log.e(TAG, "Thread1修改后: " + threadLocal.get());
            }
        }).start();

        //Thread2
        new Thread(new Runnable() {
            @Override
            public void run() {
                //子线程中获取threadLocal的值，主线程中和另一个子线程中都已经进行修改，看子线程中是什么值
                Log.e(TAG, "Thread2修改前: " + threadLocal.get());
            }
        }).start();
    }

运行这个方法输出为：

E/MainActivity: 主线程修改前: 默认值
E/MainActivity: 主线程修改后: A
E/MainActivity: Thread1修改前: 默认值
E/MainActivity: Thread1修改后: B
E/MainActivity: Thread2修改前: 默认值

这样就很明白了，同一个ThreadLocal对象在不同线程中的set()和get()是互不相关的，set()方法只会影响当前线程的get()值，当然不重写initialValue()的话默认值是null

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 158,847评论 4赞 362
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,208评论 1赞 292
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 108,587评论 0赞 243
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 43,942评论 0赞 205
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,332评论 3赞 287
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,587评论 1赞 218
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,853评论 2赞 312
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,568评论 0赞 198
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,273评论 1赞 242
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,542评论 2赞 246
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,033评论 1赞 260
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,373评论 2赞 253
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,031评论 3赞 236
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,073评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,830评论 0赞 195
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,628评论 2赞 274
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,537评论 2赞 269