当程序启动的时候Android会自动创建一个进程和一个线程,这个线程负责界面更新,收集系统事件和用户的操作事件等并分配给对应的组件,所以这个线程非常重要 被称为主线程,因为所的和UI有关的操作都是在这个线程当中进行的所以也被称作UI线程。Android 的UI系统是非线程安全的,意思是说只有创建UI的线程(也就是主线程)才可以对UI进程操作。
一、之间的关系
1.MessageQueue与Message的关系
Message中文是消息,及线程处理的最小单元,里面带有处理的数据集,或还带有操作,及告诉目的地要做什么事情, 每个MessageQueue里包含有Message。每个Message不是直接插入到MessageQueue里的,而是通过MessageQueue.IdleHandler 与looper一起工作,把Message放到MessageQueue里,及addIdleHandler(MessageQueue.IdleHandler handler) 和removeIdleHandler(MessageQueue.IdleHandlerhandler) 方法,把MessageQueue.IdleHandler压入到MessageQueu里。
2.Thread和HandlerThread的关系
HandlerThread就是带有Looper循环的Thread
3.Looper介绍
Looper即一个循环,必须绑定到一个固定的线程里,通过getThread()方法可以获得该looper绑定的Thread对象,通过getMainLooper()获得主线程里的looper对象,myLooper()可以获得当前线程里的looper对象,通过myQueue()方法可以获得当前线程里的messageQueue对象。
4.Thread、HandlerThread、和Looper的关系的关系
一般声明一个thread是没有带looper循环的,但是可以通过Looper.prepare()方法给一个线程加上looper;Looper.loop()执行该looper绑定的线程里的messageQueue,直到该loopger结束;Loop.quit()结束该循环
二、源码分析
1.Thread的创建流程
(1)线程创建的起始点init()
// 创建Thread的公有构造函数,都调用的都是这个私有的init()方法。我们看看到底干什么了。
/**
*
* @param 线程组
* @param 就是我们平时接触最多的Runnable同学
* @param 指定线程的名称
* @param 指定线程堆栈的大小
*/
private void init(ThreadGroup g, Runnable target, String name, long stackSize) {
Thread parent = currentThread();
//先获取当前运行中的线程。这一个Native函数,暂时不用理会它怎么做到的。黑盒思想,哈哈!
if (g == null) {
g = parent.getThreadGroup();
//如果没有指定ThreadGroup,将获取父线程的TreadGroup
}
g.addUnstarted();
//将ThreadGroup中的就绪线程计数器增加一。注意,此时线程还并没有被真正加入到ThreadGroup中。
this.group = g;
//将Thread实例的group赋值。从这里开始线程就拥有ThreadGroup了。
this.target = target;
//给Thread实例设置Runnable。以后start()的时候执行的就是它了。
this.priority = parent.getPriority();
//设置线程的优先权重为父线程的权重
this.daemon = parent.isDaemon();
//根据父线程是否是守护线程来确定Thread实例是否是守护线程。
setName(name);
//设置线程的名称
init2(parent);
//纳尼?又一个初始化,参数还是父线程。不急,稍后在看。
/* Stash the specified stack size in case the VM cares */
this.stackSize = stackSize;
//设置线程的堆栈大小
tid = nextThreadID();
//线程的id。这是个静态变量,调用这个方法会自增,然后作为线程的id。
}
至此,我们的Thread就初始化完成了,Thread的几个重要成员变量都赋值了。
Thread threadDemo = new Thread(() -> {
});
threadDemo.start();
那么start()背后究竟隐藏着什么样不可告人的秘密呢?是人性的扭曲?还是道德的沦丧?让我们一起点进start()。探寻start()背后的秘密。
//如我们所见,这个方法是加了锁的。
//原因是避免开发者在其它线程调用同一个Thread实例的这个方法,从而尽量避免抛出异常。
//这个方法之所以能够执行我们传入的Runnable里的run()方法,
//是应为JVM调用了Thread实例的run()方法。
public synchronized void start() {
//检查线程状态是否为0,为0表示是一个新状态,即还没被start()过。不为0就抛出异常。
//就是说,我们一个Thread实例,我们只能调用一次start()方法。
if (threadStatus != 0)
throw new IllegalThreadStateException();
//从这里开始才真正的线程加入到ThreadGroup组里。
//再重复一次,前面只是把nUnstartedThreads这个计数器进行了增量,并没有添加线程。
//同时,当线程启动了之后,nUnstartedThreads计数器会-1。因为就绪状态的线程少了一条啊!
group.add(this);
started = false;
try {
nativeCreate(this, stackSize, daemon);
//又是个Native方法。这里交由JVM处理,会调用Thread实例的run()方法。
started = true;
} finally {
try {
if (!started) {
group.threadStartFailed(this);
//如果没有被启动成功,Thread将会被移除ThreadGroup,
//同时,nUnstartedThreads计数器又增量1了。
}
} catch (Throwable ignore) {
}
}
}
最精华的函数是native的,先当黑盒处理吧。只要知道它能够调用到Thread实例的run()方法就行了。那我们再看看run()方法到底干了什么神奇的事呢?
//没错,就是这么简单!仅仅调用了Runnable类型的成员变量target的run()方法。
//至此,我们需要执行的代码就执行起来了。
//至于这个@Overrid的存在,完全是因为Thread本身也是一个Runnable!
//就是说,我们的Thread也可以作为一个Runnable来使用。
@Override
public void run() {
if (target != null) {
target.run();
}
}
(3)案例:
public void test_1() {
Thread thread1 = new Thread(() -> {
System.out.println(Thread.currentThread().getName());
}, "Thread_1");
Thread thread2 = new Thread(thread1, "Thread_2");
thread2.start();
}
---
输出:
Thread_2
2.Looper、Handler、MessageQueue
在线程中使用Handler时(除了Android主线程)必须把它放在Looper.prepare()和Looper.loop()之间。否则会抛出RuntimeException异常。
new Thread(()->{
...
Looper.prepare();
Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
Looper.loop();
}).start()
(1)Looper.prepare()
public static void prepare() {
prepare(true);
//最终其实执行的是私有方法prepare(boolean quitAllowed)中的逻辑
}
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
//先尝试获取是否已经存在一个Looper在当前线程中,如果有就抛个异常。
//这就是为什么我们不能在一个Thread中调用两次Looper.prepare()的原因。
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
//首次调用的话,就创建一个新的Looper。
}
//Looper的私有构造函数
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
//创建新的MessageQueue,稍后在来扒它。
mThread = Thread.currentThread();
//把当前的线程赋值给mThread。
}
sThreadLocal是个静态的ThreadLocal实例(在Android中ThreadLocal的范型固定为Looper)。就是说,当前进程中的所有线程都共享这一个ThreadLocal。那么,Looper.prepare()既然是个静态方法,Looper是如何确定现在应该和哪一个线程建立绑定关系的呢?我们接着往里扒。
来看看ThreadLocal的get()、set()方法。
public T get() {
Thread t = Thread.currentThread();
//重点啊!获取到了当前运行的线程。
ThreadLocalMap map = getMap(t);
//取出当前线程的ThreadLocalMap。这个东西是个重点,前面已经提到过。
//忘了的同学在前面再看看。
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
//可以看出,每条线程的ThreadLocalMap中都有一个键值对。
//绑定关系就是通过这个键值对建立的。
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
public void set(T value) {
Thread t = Thread.currentThread();
//同样先获取到当前的线程
ThreadLocalMap map = getMap(t);
//获取线程的ThreadLocalMap
if (map != null)
map.set(this, value);
//储存键值对
else
createMap(t, value);
}
(2)创建HandlerHandler可以用来实现线程间的通行。在Android中我们在子线程作完数据处理工作时,就常常需要通过Handler来通知主线程更新UI。平时我们都使用new Handler()来在一个线程中创建Handler实例,但是它是如何知道自己应该处理那个线程的任务呢
public Handler() {
this(null, false);
}
public Handler(Callback callback, boolean async) { //可以看到,最终调用了这个方法。
if (FIND_POTENTIAL_LEAKS) {
final Class 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();
//重点啊!在这里Handler和当前Thread的Looper绑定了。
//Looper.myLooper()就是从ThreadLocale中取出当前线程的Looper。
if (mLooper == null) {
//如果子线程中new Handler()之前没有调用Looper.prepare(),那么当前线程的Looper就还没创建。
//就会抛出这个异常。
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
//赋值Looper的MessageQueue给Handler。
mCallback = callback;
mAsynchronous = async;
}
(3)Looper.loop()
Handler创建之后,还需要调用一下Looper.loop(),不然发送消息到Handler没有用!接下来,扒一扒Looper究竟有什么样的魔力,能够把消息准确的送到Handler中处理。public static void loop() {
final Looper me = myLooper();
//这个方法前面已经提到过了,就是获取到当前线程中的Looper对象。
if (me == null) {
//没有Looper.prepare()是要报错的!
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue;
//获取到Looper的MessageQueue成员变量,这是在Looper创建的时候new的。
//这是个Native方法,作用就是检测一下当前线程是否属于当前进程。并且会持续跟踪其真实的身份。
//在IPC机制中,这个方法用来清除IPCThreadState的pid和uid信息。并且返回一个身份,便于使用restoreCallingIdentity()来恢复。
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) {
//重点(敲黑板)!这里是个死循环,一直等待抽取消息、发送消息。
Message msg = queue.next();
// 从MessageQueue中抽取一条消息。至于怎么取的,我们稍后再看。
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; //取得MessageQueue的跟踪标记
if (traceTag != 0) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
//开始跟踪本线程的MessageQueue中的当前消息,是Native的方法。
}
try {
msg.target.dispatchMessage(msg);
//尝试分派消息到和Message绑定的Handler中
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
//这个和Trace.traceBegin()配套使用。
}
}
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
final long newIdent = Binder.clearCallingIdentity();
//what?又调用这个Native方法了。这里主要是为了再次验证,线程所在的进程是否发生改变。
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.loop()之后,线程就就会被一个for(;;)死循环阻塞,每次等待MessageQueue的next()方法取出一条Message才开始往下继续执行。然后通过Message获取到相应的Handler (就是target成员变量),Handler再通过dispatchMessage()方法,把Message派发到handleMessage()中处理。
这里需要注意,当线程loop起来是时,线程就一直在循环中。就是说Looper.loop()后面的代码就不能被执行了。想要执行,需要先退出loop。
Looper myLooper = Looper.myLoop();
myLooper.quit(); //普通退出方式。
myLooper.quitSafely(); //安全的退出方式。
(4)MessageQueue
MessageQueue是一个单链表而不是一个队列
Message next() {
//检查loop是否已经为退出状态。mPrt是Native层的MessageQueue的地址。
//通过这个地址可以和Native层的MessageQueue互动。
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1;
int nextPollTimeoutMillis = 0;
//时间标记,当且仅当第一次获取消息时才为0。因为它在死循环外面啊!
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
//如果不是第一次获取消息,调用Native的函数,让虚拟机刷新所有的饿Binder命令,
//确保进程在执行可能阻塞的任务之前,释放之前的对象。
}
//这是一个Native的方法。
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) { //锁住MessageQueue
//获取当前的系统时间,用于后面和msg.when进行比较。
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
//获得当前MessageQueue中的第一条消息
if (msg != null && msg.target == null) {
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
//这个判断的意义在于只有到了Message应该被发送的时刻才去发送,否则继续循环。
//计算下一条消息的时间。注意最大就是Integer.MAX_VALUE。
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else { //应该发送一条消息了。
// Got a message.
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
//转换消息标记为使用过的
return msg;
//返回一条消息给Looper。
}
} else {
// 如果取到的Message为null,将时间标记设置为-1。
nextPollTimeoutMillis = -1;
}
4
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// Run the idle handlers.
// We only ever reach this code block during the first iteration.
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
}
}
MessageQueue在取消息(调用next())时,会进入一个死循环,直到取出一条Message返回。这就是为什么Looper.loop()会在queue.next()处等待的原因。
那么,一条Message是如何添加到MessageQueue中呢?要弄明白最后的真相,我们需要调查一下mHandler.post()这个方法。
(5)Handler的post()private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
//在这里给Message的target赋值。
if (mAsynchronous) {
msg.setAsynchronous(true);
//如果是异步,就标记为异步
}
return queue.enqueueMessage(msg, uptimeMillis);
//就是这个方法把Message添加到线程的MessageQueue中的。
}
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
//没Handler调用是会抛异常的啊
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) {
//不能使用一条正在使用中的Message。
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
//锁住MessageQueue再往里添加消息。
if (mQuitting) {
//如果MessageQueue被标记为退出,就返回。
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
}
msg.markInUse();
//切换Message的使用状态为未使用。
msg.when = when;
//我们设置的延迟发送的时间。
//经过下面的逻辑,Message将会被“储存”在MessageQueue中。
//实际上,Message在MessageQueue中的储存方式,
//是使用Message.next逐个向后指向的单链表结构来储存的。
//比如:A.next = B, B.next = C...
Message p = mMessages;
//尝试获取当前Message
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// 如果为null,说明是第一条。
msg.next = p;
mMessages = msg;
//设置当前的Message为传入的Message,也就是作为第一条。
needWake = mBlocked;
} else {
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
//不满足作为第一条Message的条件时,通过下面的逐步变换,将它放在最后面。
//这样便把Message“储存”到MessageQueue中了。
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p;
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
3.主线程使用Handler
在主线程中可以直接使用Handler,而不需要Looper.prepare()和Looper.loop()。为什么可以做到这样呢?
//这个main()方法可以认为是Android应用的起点
public static void main(String[] args) {
。
。
。
Looper.prepareMainLooper();
//主要作用和我们平时调用的Looper.prepare()差不多
ActivityThread thread = new ActivityThread();
//创建本类实例
thread.attach(false);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
//重点啊!这里取得了处理主线程事物的Handler。
}
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop();
//开始循环。可以看到,主线程本质上是阻塞的!
。
。
。
}
ActivityThread并没有继承Thread,它的Handler是继承Handler的私有内部类H.class。在H.class的handleMessage()中,它接受并执行主线程中的各种生命周期状态消息。UI的16ms的绘制也是通过Handler来实现的。也就是说,主线程中的所有操作都是在Looper.prepareMainLooper()和Looper.loop()之间进行的。进一步说是在主Handler中进行的。
首先,ActivityThread从static main()函数开始,调用prepareMainLooper()为UI线程创建一个消息对列(MessageQueue)
然后,创建一个ActivityThread对象,在其初始化代码中会创建一个H(Handler)对象和一个AppplicationThread(Binder)对象
Binder负责接远程AmS的IPC调用,收到消息后,通过Handler将消息发送到消息队列,UI主线程会异步的从消息队列中取出消息并执行操作
接着,UI主线程调用Looper.loop()进入消息循环体。
当ActivityThread接收到AmS发送start某个activit后,就会创建指定的Activity对象。Activity又会创建PhoneWindow类--->DecroView类--->相应的View创建完成后,Activity需要把创建好的界面显示到屏幕上,于是调用WindowManager,他会创建一个ViewRoot对象,创建完ViewRoot后,WM调用WmS提供的远程接口完成添加一个窗口并显示到屏幕上。
转载:http://blog.csdn.net/xuxinyl/article/details/6097560
http://www.apkbus.com/blog-822715-68412.html