activity启动之应用侧分析

前面说了activity在ams服务端的启动，现在来看一下activity在应用侧的启动。

从前面的ams分析之activity启动中，我们讲在activitystack.startspecificactivity方法中，如果需要启动的activity对应的进程没有启动起来，那么会先启动对应进程。

启动进程的操作是由zygoteconnection完成的，这是另一个话题，我们后面再讲述，现在只需要知道，它就是监听一个localsocket，请求发过来后，它调用fork系统调用创建进程，在新进程分支里面调用activitythread的main方法，这是应用侧执行的开始，也是我们分析的开始。

public static void main(String[] args) {     ...     Looper.prepareMainLooper();     ...     ActivityThread thread = new ActivityThread();     thread.attach(false);     ...     Looper.loop();     ...}

这里为什么会new一个ActivityThread呢？还记得main是一个静态函数吧，进程创建好后，直接跳转进来，所以还没有对象被创建，而后面的操作都要依赖activitythread对象的。

activitythread中有两个成员变量mAppThread和mH，都是ActivityThread内部定义类，在new ActviityThread时被初始化出来，mAppThread是binder继承，用于ams通信，mH是继承自handler，在main中被创建出来，那它的处理线程就是主线程了，具体情况就是ams通过mAppThread调用应用侧方法，在方法中通过mH给主线程发消息，然后调用ActivityThread的成员方法处理。

activitythread对象被new出来后，调用成员方法attch（false），在它里面，会调用ams的方法attchapplication，把成员变量mAppthread发送过去，这样ams就知道怎么和这个应用通信了。

在ams的attchapplication方法中，会根据应用进程号把对应的processrecord取出来，这个processrecord是在fork进程时，由ams创建的，在mpidselflocked中以进程号为键值保存，在mprocessnames中以进程名为键值保存。然后把应用侧发送过来的appthread和processrecord做绑定，再通过appthread调用应用侧的方法bindapplication，完后取出mHistory顶端的activityreacord，执行realstartactivitylocked，在它里面执行app.thread.shedulelaunchactivity，至此ams端工作完成。对于ams端执行流程不熟悉的可以看前面的ams分析之activity启动。

Ams端调用的bindapplication和shedulelaunchactivity，通过上面的分析我们知道只是通过mH往主线程消息队列中添加了两个消息BIND_APPLICATION和LAUNCH_ACTIVITY。Activitythread对BIND_APPLICATION的处理是加载应用配置文件中的applicatin类，执行其oncreate方法。对LAUNCH_ACTIVITY的处理是加载对应activity类，然后执行其生命周期函数oncreate，onresume等一些方法。