深刻浅出，Handler机制外科手术式的剖析（ThreadLocal,Looper,MessageQueen,Message）（上）
为何会有handler机制?java
在Android中，全部的UI控件都是运行在主线程中的， 若是咱们从子线程访问UI，系统会报异常。为何不容许子线程访问UI呢？由于Android的UI控件不是线程安全的，为了防止UI控件处于不可控的状态，就禁止了。主线程是不容许作任何的网络请求的，那么请求回来的数据如何同步到UI呢。因此为了方便线程间通信，就产生了Handler机制，目的就是方便数据在线程间传递切换。而更新UI是咱们用的最多见的。算法
先来看一段代码：数组
private Handler mHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
// TODO: 9/7/17 do what you wanna
}
};
这个是典型的handler用法，咱们在使用的时候通常都在主线程初始化Handler，那么有没有可能在子线程建立handler呢?答案是能够的，可是若是直接在子线程建立Handler，会报异常：安全
RuntimeException("Can't create handler inside thread that has not called Looper.prepare()");
1
说的很清楚，须要咱们在子线程初始化Looper，经过Looper.prepare();那么这个Looper是个什么？它和handler是什么关系呢？别急，听我细细道来。网络
在说Looper以前，先说一下MessageQueen，顾名思义他是一个消息队列，遵循的是先进先出的原则，可是他的内部不是一个队列的形式，而是以单链表的数据结构来实现的，单链表的优点就不用说了吧，插入和删除的速度相对快。分别对应的是enqueueMessage和next方法。可是他不处理消息，而Looper就是负责处理消息的。数据结构
Looper能够说是handler的核心类，他是连接MessageQueen和handler的媒介，它开启后，会无限循环的去MessageQueen中获取消息，而后交给Handler处理。在初始化Handler以前，必须先初始化Looper，不然就会报上边的异常，Looper是和线程绑定的，每个线程，只有一个Looper。这一点咱们从Looper的静态初始化方法中也能够看出来：less
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));
}
if语句的判断就是判断是否有当前thread的Looper，若是有就报异常。咱们注意到，他的判断依据是sThreadLocal，这是一个ThreadLocal实例。这是一个重要的线程工具类，下边咱们详细讲一下。
ThreadLocalide
ThreadLocal是java里边一个线程数据存储类，他并非一个Thread，其实做用很是简单，就是每个使用该变量的线程，都提供一个变量值的副本，每个线程能够独立的改变本身的副本，而不和其余线程的副本冲突。当某些数据是以线程为做用域而且不一样线程有不一样的数据副本的时候，能够考虑用ThreadLocal，很明显Looper的做用域就是当前线程，因此很是适合了。经过下边的下例子，简单展现下ThreadLocal的特色和用法：工具
public static void main(String[] args){
final ThreadLocal<String> mThreadLocal = new ThreadLocal<String>();
mThreadLocal.set("main");
new Thread("Thread-1") {
public void run() {
mThreadLocal.set(Thread.currentThread().getName());
System.out.println("currentThread:"+Thread.currentThread().getName()+","+mThreadLocal.get());
};
}.start();
System.out.println("currentThread:"+Thread.currentThread().getName()+","+mThreadLocal.get());
}
首先我初始化了一个ThreadLocal的变量mThreadLocal,而后在主线程调用set方法，放入字符串”main“，而后开启一个子线程，放入子线程的名字，而后分别在子线程和主线程打印get方法获取的数据，打印结果以下：oop
currentThread:main,main
currentThread:Thread-1,Thread-1
从日志中咱们能够看出来，尽管塞数据的时候调用的都是同一个ThreadLocal，可是在不一样的线程获取到的数据是不同的。是否是很厉害，可是到底他是如何实现不一样的线程有不一样的副本的呢，咱们来看一下它的set方法的源码：
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
从set方法中咱们能够看到，经过getMap拿到一个ThreadLocalMap对象，而后经过ThreadLocalMap的set方法设置进去，若是这个ThreadLocalMap对象为null，则执行createMap方法。
从getMap的方法内容咱们能够看出，他返回的Thread内部的一个成员变量：ThreadLocal.ThreadLocalMap。那么这个ThreadLocalMap就是数据存储的关键，他是一个内部静态类，咱们看一下new ThreadLocalMap（this, firstValue）具体作了什么：
static class Entry extends WeakReference<ThreadLocal> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}
table是一个数组，Entry是ThreadLocalMap的静态内部类，继承自WeakReference并以ThreadLocal做为key，ThreadLocal的泛型实例做为value。在new ThreadLocalMap的时候，把key和value存入Entry，而后经过必定的算法(算法的具体内容不在分析，有兴趣的兄弟能够本身看看)，把Entry放入数组。接着让咱们来看下ThreadLocalMap的set(ThreadLocal,Object)方法：
private void set(ThreadLocal key, Object value) {
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal k = e.get();
if (k == key) {
e.value = value;
return;
}
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
能够看出它内部是开启一个for循环，来遍历数组table，当Entry不为null的时候，拿到Entry里边的value而后替换掉。到这里咱们算搞明白了ThreadLocal和ThreadLocalMap的关系，以及他们的建立和set方法。
接下来咱们看看ThreadLocal的get方法：
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
private T setInitialValue() {
T value = initialValue();
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
return value;
}
protected T initialValue() {
return null;
}
搞明白了刚才的内容再看这些应该很容易了，代码逻辑也是比较清晰的，经过ThreadLocalMap拿到Entry，而后拿到Entry的value。值得注意的是，initialValue()直接返回null，因此没有在相应的线程调用ThreadLocal.set的时候，那么咱们经过get拿到的就是null。
经过分析源码咱们能够得出，ThreadLocal的get和set方法依赖于ThreadLocalMap对象，而ThreadLocalMap对象依赖于Thread被建立，因此不一样的线程中访问的数据是不同的。理解了这些，咱们再去理解Looper就很是简单了。
Looper
Looper是一个轮训器，他会不断地去MessageQueen中查看是否有新消息，若是有就当即处理。Looper有如下几个原则：
1.Handler的建立依赖于对应线程的Looper；
2.一个线程只能有一个Looper，不然会出异常；
前边咱们讲了，在子线程初始化Handler，会报RunTimeException，正确的建立方式以下：
new Thread(){
@Override
public void run() {
Looper.prepare();
Handler threadHandler = new Handler();
Looper.loop();
}
}.start();
Looper.prepare()方法作了什么，下边咱们看一下源码：
// sThreadLocal.get() will return null unless you've called prepare().
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
public static void prepare() {
prepare(true);
}
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));
}
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
代码中有一个成员变量sThreadLocal，他就是一个ThreadLocal实例，里边的泛型是Looper，刚才咱们分析完ThreadLocal，因此很容易咱们就能知道，handler机制是经过这个sThreadLocal来保有当前线程的Looper的。从代码上咱们能看出来，Looper在prepare的时候，会经过sThreadLocal拿到当前线程的looper，若是不为null，就报异常，若是为null，就new一个Looper，塞到sThreadLocal中。
那么你可能会有一个疑问，为何主线程不须要执行prepare方法呢？其实，主线程也执行了初始化方法，只不过不是prepare，而是prepareMainLooper方法，这个是专门为主线程提供的建立Looper的方法。
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
从代码上能够看出，他也执行了prepare，本质上也是同样的。
prepare以后，Looper并不会去执行任何操做，只有调用了Looper.loop()方法以后，消息循环系统才算生效。loop()方法是Looper的主要方法，咱们具体来看一下：
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 traceTag = me.mTraceTag;
if (traceTag != 0) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
try {
msg.target.dispatchMessage(msg);
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
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();
}
}
代码逻辑也是比较清晰的，首先会作一个校验，检查当前线程是否有初始化Looper，而后会开启一个无条件的for循环，不断地从MessageQueen中获取消息，若是MessageQueen的next()返回null，则终止方法。message的next()方法是一个阻塞操做，当没有消息的时候，next方法会阻塞，这也就致使loop方法阻塞。若是从MessageQueen中拿到了message，那么会经过message调用target的dispatchMessage(Message)。这个target其实就是Handler，一会讲Handler的时候咱们会讲到。这样就成功的把消息切换到了指定的线程中去执行，由于dispatchMessage是在建立Handler时候所使用的Looper执行的。
Looper还提供了退出的方法：quit()和quitSafely();他们俩执行的都是同一个方法，都是MessageQueen中的quit(boolean),可是传入的参数不同。quit会直接退出looper，可是quitSafely只是设定了一个标记，而后把消息队列的消息处理完毕后才安全退出。quit以后，handler发送消息会失败，send方法会返回false。在子线程中，执行完全部的handler回调以后应该调用quit方法来终止Looper，不然这个线程会一直处于等待状态，不能被gc回收。
第一部分就先剖析到这里，还有一半放在第二篇博客讲。
- 1. 深刻浅出，Handler机制外科手术式的剖析（ThreadLocal,Looper,MessageQueen,Message）（下）
- 2. Android消息机制Looper、Handler、MessageQueen（一）
- 3. 深刻理解Message, MessageQueue, Handler和Looper
- 4. android开发笔记：Handler、Looper、MessageQueen、Message的关系
- 5. Handler 、 Looper 、Message
- 6. Android Handler 、 Looper 、Message
- 7. Handler Looper Message
- 8. 深刻浅出ThreadLocal
- 9. Android Looper，Handler，Message分析
- 10. Handler机制（Looper、Message、MessageQueue）源码追踪
- 更多相关文章...
- • TCP滑动窗口机制深度剖析 - TCP/IP教程
- • ARP协议的工作机制详解 - TCP/IP教程
- • 漫谈MySQL的锁机制
- • 互联网组织的未来：剖析GitHub员工的任性之源
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 深刻浅出，Handler机制外科手术式的剖析（ThreadLocal,Looper,MessageQueen,Message）（下）
- 2. Android消息机制Looper、Handler、MessageQueen（一）
- 3. 深刻理解Message, MessageQueue, Handler和Looper
- 4. android开发笔记：Handler、Looper、MessageQueen、Message的关系
- 5. Handler 、 Looper 、Message
- 6. Android Handler 、 Looper 、Message
- 7. Handler Looper Message
- 8. 深刻浅出ThreadLocal
- 9. Android Looper，Handler，Message分析
- 10. Handler机制（Looper、Message、MessageQueue）源码追踪