Android一个新应用程序启动与AMS交互过程——对ApplicationThread深入理解
明白binder通信的原理，清楚BpXXXService或者XXXserviceProxy是BpBinder的代理类，均有对应的BnXXXService或XXXServiceNative.Stub。bpbinder和binder内核通信，是通过IPCThreadProcess实现，在服务端有一个单独的线程（也是IPCThreadProcess实现），监听发给自己的binder的消息，处理后，通过binder内核reply给client。binder机制实现了client端像本地调用一样，跨进程调用服务的方法。这部分知识有些绕，提醒自己多温习。
深入理解android IPCBinder机制可参考[老罗的android之旅] 这上下4篇文章
在laucher里面启动一个新的app时，流程参考老罗文章：
整个应用程序的启动过程要执行很多步骤，但是整体来看，主要分为以下五个阶段：
一. Step1 - Step 11：Launcher通过Binder进程间通信机制通知ActivityManagerService，它要启动一个Activity； 二. Step 12 - Step 16：ActivityManagerService通过Binder进程间通信机制通知Launcher进入Paused状态； 三. Step 17 - Step 24：Launcher通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就创建一个新的进程，用来启动一个ActivityThread实例，即将要启动的Activity就是在这个ActivityThread实例中运行； 四. Step 25 - Step 27：ActivityThread通过Binder进程间通信机制将一个ApplicationThread类型的Binder对象传递给ActivityManagerService，以便以后ActivityManagerService能够通过这个Binder对象和它进行通信； 五. Step 28 - Step 35：ActivityManagerService通过Binder进程间通信机制通知ActivityThread，现在一切备就绪，它可以真正执行Activity的启动
分析本人在理解这个过程中最大的疑点和解释
launcher启动新的app时（假设创建新的process），会调用AMS获取它的服务，告诉它我要启动一个新的activity，这时launcher通过调用activitymanagerproxy.startactivity();最终通过binder机制调用AMS的方法，创建activityrecord、新的task等操作后，AMS通过binder机制，通知launcher进入paused状态，大感不解，在我看来，launcher是应用程序，也就是client，怎么能像server一样，接受binder消息呢。那岂不成了服务了嘛，况且，就算成了服务，app也没有像server一样向sercicemanager注册啊
分析：
Android应用程序框架层创建的应用程序进程天然支持Binder进程间通信机制，这是怎么理解[老罗这篇]
考虑到每一个app启动创建新的进程时，都是ams调用process.start(),这里调用了通过socket的方式向zygote请求创建新的进程，viazygote，fork子进程，并
调用onZygoteInit(),可以监听和操作binder驱动了。
加载用户定义的activity类，即ActivityThread。并执行其main方法
通过1可以知道，这个app具有binder通信能力，但是其他应用若想能够给它发消息，必须知道它的binderproxy。哈哈，到了点子上了，每个app有一个activityThread成员mmainthread，activity有个成员，mappthread，它就是一个Binder对象！！！每次创建一个app，执行activitythread.main的时候，都要把mappthread(ApplicationThread类型)，attach给ams，以后ams向和activity通信时只要通过这个binder就可以了。不需要像server一样，通过servicemanager获取binder的handle。
ams向activity发消息是必须的，比如通过applicationthread向activity的handler发消息，控制其生命周期。
我描述的很笼统，不对地方请指正。
<p>版权声明：本文为博主原创文章，未经博主允许不得转载。</p>