Framework源码面试之activity启动流程
引言
Framework源码面试：activity启动流程
1.1面试连环炮之说说 Android 的四种启动模式
1.2.面试连环炮之说说 Intent标签起什么作用呢？ 简单说一说
1.2.Android 的启动原理，他的流程是什么样的
1.2.1.进程A与AMS的交互过程
引言今天在电脑上翻出了很久之前整理笔记Framework源码面试,Flutter,以及一部分面试专题。拿出来温习一下。
今天先讲Framework源码篇：
1.Framework源码面试：Activity启动流程
2.Framework源码面试：Binder面试
3.Framework源码面试：Handler面试
4.Framework源码面试：事件分发机制
5.Framework源码面试：onMeasure测量原理
6.Framework源码面试：Android屏幕刷新机制
面试的时候，面试官经常同你随便侃侃Activity的启动模式，但Activity启动牵扯的知识点其实很多，并非能单单用四个启动模式就能概括的，
默认的启动模式的表现会随着Intent Flag的设置而改变，因此侃Activity启动模式大多走流程装逼，最多结合项目遇到的问题，随便刁难一下面试者，并不太容易把控，也许最后，面试官跟面试者的答案都是错了，
比如在Service中必须通过设置FLAG_ACTIVITY_NEW_TASK才能启动Activity，这个时候启动Activit会有什么样的表现呢？就这一个问题，答案就要分好几个场景：
Activity的taskAffinity属性的Task栈是否存在
如果存在，要看Activity是否存已经存在于该Task
如果已经存在于该taskAffinity的Task，要看其是不是其rootActivity
如果是其rootActivity，还要看启动该Activity的Intent是否跟当前intent相等
不同场景，所表现的行为都会有所不同，再比如singleInstance属性，如果设置了，大家都知道只有一个实例，将来再启动会复用，但是如果使用Intent.FLAG_ACTIVITY_CLEAR_TASK来启动，仍然会重建，并非完全遵守singleInstance的说明，还有不同Flag在叠加使用时候也会有不同的表现，单一而论Activity启动模式其实是很难的。本文也仅仅是涉及部分启动模式及Flag，更多组合跟场景要自己看源码或者实验来解决了。
standard
这是 Activity 的默认启动模式，每次激活 Activity 的时候都会创建一个新的 Activity 实例，并放入任务栈中。
使用场景：基本绝大多数地方都可以用。
singleTop
这可能也是非常常用的 launchMode 了。如果在任务的栈顶正好存有该 Activity 的实例，则会通过调用 onNewIntent() 方法进行重用，否则就会同 standard 模式一样，创建新的实例并放入栈顶。即便栈中已经存在了该 Activity 的实例，也会创建新的实例，即：A -> B ->A，此时栈内为 A -> B -> A，但 A -> B ->B ，此时栈内为 A -> B。一句话概述就是：当且仅当启动的 Activity 和上一个 Activity 一致的时候才会通过调用 onNewIntent() 方法重用 Activity。
使用场景：资讯阅读类 APP 的内容界面。
singleTask
这个 launchMode专门用于解决上面 singleTop 的另外一种情况，只要栈中已经存在了该 Activity 的实例，就会直接调用 onNewIntent() 方法来实现重用实例。重用时，直接让该 Activity 的实例回到栈顶，并且移除之前它上面的所有 Activity 实例。如果栈中不存在这样的实例，则和 standard 模式相同。即： A ->B -> C -> D -> B，此时栈内变成了 A -> B。而 A -> B -> C，栈内还是 A -> B -> C。
使用场景：浏览器的主页面，或者大部分 APP 的主页面。
singleInstance
在一个新栈中创建该 Activity 的实例，并让多个应用共享该栈中的该 Activity 实例。一旦该模式的 Activity 实例已经存在于某个栈中，任何应用再激活该 Activity 时都会重用该栈中的实例，是的，依然是调用 onNewIntent() 方法。其效果相当于多个应用共享一个应用，不管是谁激活，该 Activity 都会进入同一个应用中。但值得引起注意的是：singleInstance 不要用于中间页面，如果用户中间页面，跳转会出现很难受的问题。 这个在实际开发中我暂未遇到过，不过 Android 系统的来电页面，多次来电均是使用的同一个 Activity 。
四种模式的背书式理解记忆讲完了，你认为这样就结束了吗？
对，我也一度是这样认为的。
1.2.面试连环炮之说说 Intent标签起什么作用呢？ 简单说一说我们除了需要知道在 AndroidManifest.xml 里面设置 android:launchMode 属性，我们还需要了解下面这几个Intent标签的用法。
在 Android 中，我们除了在清单文件 AndroidManifest.xml 中配置 launchMode，当然可以用 Intent 标签说事儿。启动 Activity ，我们需要传递一个 Intent，完全可以通过设置 Intent.setFlags(int flags) 来设置启动的 Activity 的启动模式。
需要注意的是：通过代码来设置 Activity 的启动模式的方式，优先级比清单文件设置更高。
FLAG_ACTIVITY_NEW_TASK 这个标识会使新启动的 Activity 独立创建一个 Task。
FLAG_ACTIVITY_CLEAR_TOP 这个标识会使新启动的 Activity 检查是否存在于 Task 中，如果存在则清除其之上的 Activity，使它获得焦点，并不重新实例化一个 Activity，一般结合 FLAG_ACTIVITY_NEW_TASK 一起使用。
FLAG_ACTIVITY_SINGLE_TOP 等同于在 launcherMode 属性设置为 singleTop。
总的流程图：
此处以跨进程启动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,...)方法启动进程。
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(...)创建子进程，创建完成之后就分别在父进程和子进程里面做各自的事情.
父进程通过hanleParentProc（pid）把子进程的pid通过Socket发送给AMS
子进程调用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早就放置在了栈顶，只是一直没有初始化。然后调用方法，来启动Activity
如果我们不是启动另外一个进程，而是同一进程，那么这第二大部分就不会存在了，而是直接调用realStartActivityLocked方法。
realStartActivityLocked(hr,app,true,true);
写到这里是不是有很多码牛的小伙伴们已经坚持不下去了。还剩最后几个步骤
① 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函数。
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
④ handleResumeActivity：
-> r.activity.performResume()
-> mInstrumentation.callActivityOnResume(this);
-> activity.onResume()
以上就是Framework源码面试之activity启动流程的详细内容，更多关于Framework activity启动流程的资料请关注软件开发网其它相关文章！
