Android子线程更新UI大全及源码解析

首先子线程真的不可以更新UI吗？可以看看文章 

Android子线程真的不可以更新UI吗？？？http://blog.csdn.net/qq_36523667/article/details/79232336

事实上 大部分情况是不可以的 小部分的情况请看上面的文章 如果不明白这个小部分情况 那可谓本末倒置了

new Thread(new Runnable() {
    @Override
    public void run() {
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        tv.setText("888");
    }
}).start();

自然会报错

一般我们采用Handler来切换到主线程进行一个UI的更新

给Activity声明一个成员变量Handler

private Handler mHandler = new Handler();

mHandler.post(new Runnable() {
    @Override
    public void run() {
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        tv.setText("8888888");
    }
});

这样就可以了，但是这里不也是Runnable吗？？为啥就可以了？

所以得追溯源码，猜测一下，应该是obtain一个message，然后把这个runnable赋给message的callback字段。然后就把runnable里的代码在主线程中执行了。原因在于Handler在初始化的时候，会根据当前进程获取一个Looper，也就获取了Looper的消息队列。而这里的Handler是Activity的成员变量，所以内部维护的这个消息队列的消息自然是运行在主线程中的。

追溯源码

public final boolean post(Runnable r)
{
   return  sendMessageDelayed(getPostMessage(r), 0);
}

分两部分看待，一个是send，一个是getPostMessage。

先看getPostMessage

private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

验证了上面的猜测

再看看构造方法

public Handler(Callback callback, boolean async) {
    if (FIND_POTENTIAL_LEAKS) {
        final Class<? extends Handler> klass = getClass();
        if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                (klass.getModifiers() & Modifier.STATIC) == 0) {
            Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                klass.getCanonicalName());
        }
    }

    mLooper = Looper.myLooper();
    if (mLooper == null) {
        throw new RuntimeException(
            "Can't create handler inside thread that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

myLooper内部就是获取当前线程的looper

也验证了上面的猜测

再看一看send方法

public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    if (queue == null) {
        RuntimeException e = new RuntimeException(
                this + " sendMessageAtTime() called with no mQueue");
        Log.w("Looper", e.getMessage(), e);
        return false;
    }
    return enqueueMessage(queue, msg, uptimeMillis);
}

把维护的消息队列 在这里设置

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

这里还把这个Handler给了msg的target字段。最后调用了MessageQueue的enqueueMessage方法。这样就完成了消息的入队列。

那消息又是怎么执行的呢？

就得关注Looper这个类了。

Looper的使用，其实应该是Looper.prepare和Looper.loop。但是activity中是不用的。因为他是UI线程。所以他会隐式地Looper.prepare。然后再监听到消息队列中入队列的 操作，执行Looper.loop(这一点是我猜测的，没有具体看过源码)。

Looper.prepare源码，存储在了ThreadLocal里，其实就相当于一个成员变量，如果想了解更多ThreadLocal，可以看http://blog.csdn.net/qq_36523667/article/details/78877176

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));
}

Looper.loop就开始无限循环去取了

public static void loop() {
    final Looper me = myLooper();
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    final MessageQueue queue = me.mQueue;

    // Make sure the identity of this thread is that of the local process,
    // and keep track of what that identity token actually is.
    Binder.clearCallingIdentity();
    final long ident = Binder.clearCallingIdentity();

    for (;;) {
        Message msg = queue.next(); // might block
        if (msg == null) {
            // No message indicates that the message queue is quitting.
            return;
        }

        // This must be in a local variable, in case a UI event sets the logger
        final Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }

        final long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;

        final long traceTag = me.mTraceTag;
        if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
            Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
        }
        final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
        final long end;
        try {
            msg.target.dispatchMessage(msg);
            end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
        } finally {
            if (traceTag != 0) {
                Trace.traceEnd(traceTag);
            }
        }
        if (slowDispatchThresholdMs > 0) {
            final long time = end - start;
            if (time > slowDispatchThresholdMs) {
                Slog.w(TAG, "Dispatch took " + time + "ms on "
                        + Thread.currentThread().getName() + ", h=" +
                        msg.target + " cb=" + msg.callback + " msg=" + msg.what);
            }
        }

        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }

        // Make sure that during the course of dispatching the
        // identity of the thread wasn't corrupted.
        final long newIdent = Binder.clearCallingIdentity();
        if (ident != newIdent) {
            Log.wtf(TAG, "Thread identity changed from 0x"
                    + Long.toHexString(ident) + " to 0x"
                    + Long.toHexString(newIdent) + " while dispatching to "
                    + msg.target.getClass().getName() + " "
                    + msg.callback + " what=" + msg.what);
        }

        msg.recycleUnchecked();
    }
}

看一看msg.target.dispatchMessage(msg);

target就是Handler。所以调用的是Handler中的dispatchMessage方法

dispatchMessage

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

可以清楚的看到，有3层式的筛选，也决定了我们子线程更新UI的不同姿势

post是哪一种情况呢？

看看我们之前看过的代码

private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

是第一种

if (msg.callback != null) {
        handleCallback(msg);
    } 

private static void handleCallback(Message message) {
    message.callback.run();
}

相当于runnable.run。不过这一次是在主线程中执行的这个方法。

再看除了post之外的另一种处理方式

mHandler.sendMessage(mHandler.obtainMessage(1, "2"));
}

private Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        if (msg.what == 1) {
            tv.setText("66666");
        }
    }
};

这种方式是把回调写在handleMessage里的。属于dispatchMessage里的第三种方式

handleMessage(msg);

public void handleMessage(Message msg) {
}

进去一看是一个空方法。这就是我们需要重写的方法了。

那第二种情况呢？

if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }

这样操作

mHandler.sendMessage(mHandler.obtainMessage(1, "6666"));
}

private Handler mHandler = new Handler(new Handler.Callback() {
    @Override
    public boolean handleMessage(Message msg) {
        if (msg.what == 1) {
            tv.setText(msg.obj + "");
        }
        return true;
    }
});

源码证明如下

public Handler(Callback callback) {
    this(callback, false);
}

之前的那个构造函数里

mCallback = callback;

关于Handler的3种方法，算是齐活了。

不过这样写会更优雅。

mHandler.obtainMessage(1,"666").sendToTarget();
}

private Handler mHandler = new Handler(){
    @Override
    public void handleMessage(Message msg) {
        if (msg.what == 1) {
            tv.setText(msg.obj + "");
        }
    }
};

这里的源码可以自行查阅咯。

不过具体代码是写在runnable里还是像这里一样写在Handler里，都可以。我个人更喜欢写在Handler里，看其来显眼，改起来方便。

Handler是第一种方式，讲了半天终于讲完第一种了。

view.post。view自己封装有一套异步处理机制

new Thread(new Runnable() {
    @Override
    public void run() {
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        tv.post(new Runnable() {
            @Override
            public void run() {
                tv.setText("6666");
            }
        });
    }
}).start();

本想也分析下他的源码，但是发现view的异步处理机制用的很少，所以就不分析了。

还有runUiThread

new Thread(new Runnable() {
    @Override
    public void run() {
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        runOnUiThread(new Runnable() {
            @Override
            public void run() {
                tv.setText("6666");
            }
        });
    }
}).start();

戳进去一看

@Override
public final void runOnUiThread(Runnable action) {
    if (Thread.currentThread() != mUiThread) {
        mHandler.post(action);
    } else {
        action.run();
    }
}

也是mHandler.post

看来，只需要掌握一个Handler就可一通百通了。view的异步机制底层应该也是这个。Handler的消息机制应该是安卓用途十分广的东西了，得学，得透透的学。