前言

Android的消息机制主要是指Handler的运行机制，对于大家来说Handler已经是轻车熟路了，可是真的掌握了Handler？本文主要通过几个问题围绕着Handler展开深入并拓展的了解。

Gityuan–Handler(Native层)

Activity 启动过程」

比如收到msg=H.LAUNCH_ACTIVITY，则调用ActivityThread.handleLaunchActivity()方法，最终会通过反射机制，创建Activity实例，然后再执行Activity.onCreate()等方法；

再比如收到msg=H.PAUSE_ACTIVITY，则调用ActivityThread.handlePauseActivity()方法，最终会执行Activity.onPause()等方法。

主线程的消息又是哪来的呢？当然是App进程中的其他线程通过Handler发送给主线程

system_server进程

system_server进程是系统进程，java framework框架的核心载体，里面运行了大量的系统服务，比如这里提供ApplicationThreadProxy（简称ATP），ActivityManagerService（简称AMS），这个两个服务都运行在system_server进程的不同线程中，由于ATP和AMS都是基于IBinder接口，都是binder线程，binder线程的创建与销毁都是由binder驱动来决定的。

App进程

App进程则是我们常说的应用程序，主线程主要负责Activity/Service等组件的生命周期以及UI相关操作都运行在这个线程； 另外，每个App进程中至少会有两个binder线程 ApplicationThread(简称AT)和ActivityManagerProxy（简称AMP），除了图中画的线程，其中还有很多线程

Binder

Binder用于不同进程之间通信，由一个进程的Binder客户端向另一个进程的服务端发送事务，比如图中线程2向线程4发送事务；而handler用于同一个进程中不同线程的通信，比如图中线程4向主线程发送消息。

结合图说说Activity生命周期，比如暂停Activity，流程如下：

1. 线程1的AMS中调用线程2的ATP；（由于同一个进程的线程间资源共享，可以相互直接调用，但需要注意多线程并发问题）

2. 线程2通过binder传输到App进程的线程4；

3. 线程4通过handler消息机制，将暂停Activity的消息发送给主线程；

4. 主线程在looper.loop()中循环遍历消息，当收到暂停Activity的消息时，便将消息分发给 
   ActivityThread.H.handleMessage()方法，再经过方法的调用， 
   最后便会调用到Activity.onPause()，当onPause()处理完后，继续循环loop下去。

补充:

ActivityThread的main方法主要就是做消息循环，一旦退出消息循环，那么你的程序也就可以退出了。

从消息队列中取消息可能会阻塞，取到消息会做出相应的处理。如果某个消息处理时间过长，就可能会影响UI线程的刷新速率，造成卡顿的现象。

最后通过《Android开发艺术探索》的一段话总结 :

ActivityThread通过ApplicationThread和AMS进行进程间通讯，AMS以进程间通信的方式完成ActivityThread的请求后会回调ApplicationThread中的Binder方法，然后ApplicationThread会向H发送消息，H收到消息后会将ApplicationThread中的逻辑切换到ActivityThread中去执行，即切换到主线程中去执行，这个过程就是。主线程的消息循环模型

另外，ActivityThread实际上并非线程，不像HandlerThread类，ActivityThread并没有真正继承Thread类

那么问题又来了，既然ActivityThread不是一个线程，那么ActivityThread中Looper绑定的是哪个Thread，也可以说它的动力是什么？

看到这个崩溃日志，是否有些疑惑，因为一般如果子线程不能更新UI控件是会报如下错误的（子线程不能更新UI） 

所以子线程不能更新Toast的原因就和Handler有关了，据我们了解，每一个Handler都要有对应的Looper对象，那么。 
满足你。

        new Thread(new Runnable() {            @Override
            public void run() {

                Looper.prepare();
                Toast.makeText(MainActivity.this, "run on thread", Toast.LENGTH_SHORT).show();
                Looper.loop();

            }
        }).start();

这样便能在子线程中Toast，不是说子线程…? 
老样子，我们追根到底看一下Toast内部执行方式。 

//Toast


    /**
     * Show the view for the specified duration.
     */
    public void show() {
        ``````

        INotificationManager service = getService();//从SMgr中获取名为notification的服务
        String pkg = mContext.getOpPackageName();
        TN tn = mTN;
        tn.mNextView = mNextView;        try {
            service.enqueueToast(pkg, tn, mDuration);//enqueue? 难不成和Handler的队列有关?
        } catch (RemoteException e) {            // Empty
        }
    }

在show方法中，我们看到Toast的show方法和普通UI 控件不太一样，并且也是通过Binder进程间通讯方法执行Toast绘制。这其中的过程就不在多讨论了，有兴趣的可以在NotificationManagerService类中分析。

现在把目光放在TN 这个类上（难道越重要的类命名就越简洁，如H类），通过TN 类，可以了解到它是Binder的本地类。在Toast的show方法中，将这个TN对象传给NotificationManagerService就是为了通讯！并且我们也在TN中发现了它的show方法。

    private static class TN extends ITransientNotification.Stub {//Binder服务端的具体实现类

        /**
         * schedule handleShow into the right thread
         */
        @Override
        public void show(IBinder windowToken) {
            mHandler.obtainMessage(0, windowToken).sendToTarget();
        }        final Handler mHandler = new Handler() {            @Override
            public void handleMessage(Message msg) {
                IBinder token = (IBinder) msg.obj;
                handleShow(token);
            }
        };

    }

看完上面代码，就知道子线程中Toast报错的原因，因为在TN中使用Handler，所以需要创建Looper对象。 
那么既然用Handler来发送消息，就可以在handleMessage中找到更新Toast的方法。 
在handleMessage看到由handleShow处理。

//Toast的TN类


        public void handleShow(IBinder windowToken) {

                ``````
                mWM = (WindowManager)context.getSystemService(Context.WINDOW_SERVICE);

                mParams.x = mX;
                mParams.y = mY;
                mParams.verticalMargin = mVerticalMargin;
                mParams.horizontalMargin = mHorizontalMargin;
                mParams.packageName = packageName;
                mParams.hideTimeoutMilliseconds = mDuration ==
                    Toast.LENGTH_LONG ? LONG_DURATION_TIMEOUT : SHORT_DURATION_TIMEOUT;
                mParams.token = windowToken;
                if (mView.getParent() != null) {
                    mWM.removeView(mView);
                }
                mWM.addView(mView, mParams);//使用WindowManager的addView方法
                trySendAccessibilityEvent();
            }
        }

看到这里就可以总结一下：

Toast本质是通过window显示和绘制的（操作的是window），而主线程不能更新UI 是因为ViewRootImpl的checkThread方法在Activity维护的View树的行为。 
Toast中TN类使用Handler是为了用队列和时间控制排队显示Toast，所以为了防止在创建TN时抛出异常，需要在子线程中使用Looper.prepare();和Looper.loop();（但是不建议这么做，因为它会使线程无法执行结束，导致内存泄露）

匿名内部类导致的泄露改为匿名静态内部类，并且对上下文或者Activity使用弱引用。

http://www.apkbus.com/blog-873057-77708.html