Activity的启动流程

总的流程图：

1. 进程A与AMS的交互过程
此处以跨进程启动Activity分析一下源码流程： 

A调用startActivity时，需要与AMS交互，此时需要需要获取到AMS的代理对象Binder也就是上图的AMP，通过ActivityManagerNative.getDefault()获得，并调用AMP的startActivity方法，然后会通过mRemote.transact方法进行Binder通信，在AMS的onTransact方法里面会获取到请求的Activity参数信息：

mRemote.transact(START_ACTIVITY_TRANSACTION,data,reply,0);
...
 
@Override
public boolean onTransact(int code, Parcel data, Parcel reply, int flags){
      switch(code){
   case START_ACTIVITY_TRANSACTION:{        startActivity(app,callingPackage,intent,...)
   }
}}

AMS里面的startActivity方法最主要会去调用startSpecificActivityLocked函数，在此函数里面会去判断目标进程是否已经存在，并且目标向AMS注册过它自己的ApplicationThread也就是上图ATP代理对象，如果这两个条件都满足会去调用realStartActivityLocked方法，这个方法我们后面再看。如果上述条件不满足时，会去调用mService.startProcessLocked(r.processName,...)方法启动进程。

2. AMS启动目标进程B

startProcessLocked方法首先调用Process.start("android.app.ActivityThread",)方法会向Zygote发送一个启动进程的请求，并告知Zygote进程启动之后，加载ActivityThread这个类的入口main函数，启动完成后返回进程的pid，并向AMS的Handler发送一个延迟消息，为的是要求目标进程启动后，10秒钟内需要向AMS报告，不然的话AMS就会清除目标进程的相关信息。

 

Process.start方法会去调用startViaZygote(processClass,)函数，这个函数主要做了两件事，一件就是打开通往Zygote的Socket，第二件事就是通过Socket发送启动进程参数。

Zygote端主要逻辑是在runOnce函数，函数内调用Zygote.forkAndSpecialize(...)创建子进程，创建完成之后就分别在父进程和子进程里面做各自的事情

1） 父进程通过hanleParentProc（pid）把子进程的pid通过Socket发送给AMS
2）子进程调用handleChildProc函数，做一些通用的初始化，比如启用Binder机制；执行应用程序的入口函数，也就是ActivityThread的Main函数

ActivityThread的main函数，里面会创建一个ActivityThread对象，并调用thread.attach(false)，为的是向AMS报到，上面第一条里面有提到。
attach方法里面，其实是一个跨进程的调用，首先通过

IActivityManager mgr = ActivityManagerNative.getDefault();

获取到AMS的Binder代理对象，然后调用

mgr.attachApplication(mAppThread);

mAppThread是应用端的一个Binder对象ApplicationThread，也就是最上面一张图的ATP，这样AMS端就可以调用应用端了。

attachApplication方法里面，最主要有两个方法，一个是通过传入的ApplicationThread对象，调用bindApplication初始化Application对象，另一个就是通过
 

mStactSupervisor.attachApplicationLoacked(app);

初始化挂起的Activity对象。

在attachApplicationLoacked函数里，会调用

ActivityRecord hr = stack.topRunningActivityLocked(null);

其中要明白AMS里面有两个栈，一个是Launch桌面栈，一个就是非桌面栈mFocusedStack,此处的stack就是mFocusedStack，它会将栈顶的ActivityRecord返回出来，我们的目标Activity早就放置在了栈顶，只是一直没有初始化。然后调用

realStartActivityLocked(hr,app,true,true);

方法，来启动Activity，如果我们不是启动另外一个进程，而是同一进程，那么这第二大部分就不会存在了，而是直接调用realStartActivityLocked方法。

3. 应用端Activity启动的几个步骤
realStartActivityLocked函数会调用app.thread.scheduleLaunchActivity(new Intent(r.intent),...);也就是通过之前注册的Binder对象ATP，调用scheduleLaunchActivity函数，在scheduleLaunchActivity函数里面：

ActivityClientRecord r = new ActivityClientRecord();
...
sendMessage(H.LAUNCH_ACTIVITY,r);

封装了一个ActivityClientRecord消息，然后丢到主线程的Handler（mH）里。

在主线程里面

final ActivityClientRecord r = （ActivityClientRecord）msg.obj ;
r.packageInfo = getPackageInfoNoCheck(...);
handleLaunchActivity(r,null);

getPackageInfoNoCheck 函数主要是用来生成一个LoadedApk对象，它用来保存我们的apk信息，因为后面我们需要一个ClassLoader去加载Apk里面的Activity类，所以这里提前准备好。

handleLaunchActivity里面分为两个部分，一个是performLaunchActivity函数，一个是handleResumeActivity函数。
1） performLaunchActivity

Activity activity = mInstrumentation.newActivity(...);
 
//返回之前创建好的
Application app = r.packageInfo.makeApplication(false,mInstrumentation);
 
//生成ContextImpl
Context appContext = createBaseContextForActivity(r,activity);
 
//给activity绑定上下文和一些初始化的工作,如createPhoneWindow
activity.attach(appContext,...);
 
mInstrumentation.callActivityOnCreate(activity,r.state); //生命周期的OnCreate
 
activity.performStart();    //生命周期的OnStart
 
return activity

2） handleResumeActivity：

-> r.activity.performResume()     
   -> mInstrumentation.callActivityOnResume(this);
     -> activity.onResume()