当程序启动的时候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的几个重要成员变量都赋值了。
（2）启动线程 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）创建Handler
Handler可以用来实现线程间的通行。在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中进行的。 APK程序的运行过程 首先，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
