Android 应用程序是通过消息来驱动的，系统为每一个应用程序维护一个消息队例，应用程序的主线程不断地从这个消息队例中获取消息（Looper），然后对这些消息进行处理（Handler），这样就实现了通过消息来驱动应用程序的执行，本文将详细分析Android 应用程序的消息处理机制。 前面我们学习Android 应用程序中的Activity 启动（Android 应用程序启动过程源代码分析和Android应用程序内部启动Activity 过程（startActivity）的源代码分析）、Service 启动（Android 系统在新进程中启动自定义服务过程（startService）的原理分析和Android 应用程序绑定服务（bindService）的过程源代码分析）以及广播发送（Android 应用程序发送广播（sendBroadcast）的过程分析）时，它们都有一个共同的特点，当 ActivityManagerService 需要与应用程序进行并互时，如加载 Activity 和Service、处理广播待，会通过Binder 进程间通信机制来知会应用程序，应用程序接收到这个请求时，它不是马上就处理这个请求，而是将这个请求封装成一个消息，然后把这个消息放在应用程序的消息队列中去，然后再通过消息循环来处理这个消息。这样做的好处就是消息的发送方只要把消息发送到应用程序的消息队列中去就行了，它可以马上返回去处理别的事情，而不需要等待消息的接收方去处理完这个消息才返回，这样就可以提高系统的并发性。实质上，这就是一种异步处理机制。 这样说可能还是比较笼统，我们以 Android 应用程序启动过程源代码分析一文中所介绍的应用程序启动过程的一个片断来具体看看是如何这种消息处理机制的。在这篇文章中，要启动的应用程序称为Activity，它的默认 Activity 是MainActivity，它是由 Launcher 来负责启动的，而 Launcher 又是通过ActivityManagerService 来启动的，当 ActivityManagerService 为这个即将要启的应用程序准备好新的进程后，便通过一个Binder 进程间通信过程来通知这个新的进程来加载 MainActivity，如下图所示： 它对应Android 应用程序启动过程中的Step 30 到 Step 35，有兴趣的读者可以回过头去参考 Android应用程序启动过程源代码分析一文。这里的Step 30 中的scheduleLaunchActivity 是ActivityManagerService 通过Binder 进程间通信机制发送过来的请求，它请求应用程序中的ActivityThread执行Step 34 中的performLaunchActivity操作，即启动MainActivity的操作。这里我们就可以看到，Ste...
