6岁女儿问我：APP是如何启动的？
The following article is from 码上积木 Author 积木zz
有一天，女儿问我：“爸爸爸爸，你说我玩的这个小天才电话手表怎么这么厉害，随便点一下这个小图片，这个应用就冒出来了，就可以听儿歌了。好神奇啊。”
首先，new 一个女儿：
var mDdaughter = new 女儿("6岁"，“漂亮可爱”，“健康乖巧”，“最喜欢玩小天才电话手表和她的爸爸”)
小天才电话手表的系统就是 Android，所以这不就是面试官常考的应用启动流程嘛！
女儿也要来面试我了吗？😭好了，既然女儿问了，那就答吧。但是，对付这个小小的 0 经验面试官，我该咋说呢？
解答小小面试官
女儿，你可以把手表里面想象成一个幼儿园，里面有一个老师，一个班长，一个班干部，以及一大堆小朋友：
一个老师：Z老师（Zygote进程）。
一个班长：小 A（ActivityManagerService）。
一个班干部：小 L（Launcher 桌面应用）。
一大堆小朋友：所有应用，包括音乐小朋友，聊天小朋友，日历小朋友等等。
应用启动过程就像一个小朋友被叫醒一样，开机之后呢，Z 老师会依次叫醒班长和班干部（SystemServer#ActivityManagerService，Launcher）。
小 L 醒了之后就会去了解手表里有哪些小朋友，长什么样（icon，name），家庭信息（包名，androidmanifest）等等，然后一个个把小朋友的照片（icon）贴到自己的身上。
比如有音乐小朋友，聊天小朋友，日历小朋友，其实也就是你手表上这个桌面啦。
这时候你要点开一个音乐小朋友呢（startActivity），小 L 就会通知班长小 A（Binder）。
小 A 知道了之后，让小 L 自己休息下（Paused），然后就去找 Z 老师了。Z 老师就负责叫音乐小朋友起床了（fork 进程，启动 ActivityThread）。
音乐小朋友起来后就又找小 A 带她去洗脸刷牙（启动ApplicationThread，Activity）。
都弄完了就可以进行各种表演了，唱歌啊，跳舞啊。
女儿似懂非懂的给我点了一个赞👍，爸爸你真棒。
十五年后
mDdaughter.grow(15)
mDdaughter.study("Android")
过了十五年，女儿已经 21 岁了，正在学习 Android，考虑要不要女从父业。
这天，她一脸疑惑的来找我：“爸，这个 App 启动到底是怎么个流程啊，我看了好久还是不大明白，要不你再跟我详细讲一遍吧？” ，“好嘞，别担心，我这次详细跟你说说”！
解答 Android 程序媛
还记得我小时候跟你说过的故事吗，Android 系统就像一个幼儿园，有一个大朋友叫 Launcher，身上会贴很多其他小朋友的名片。
这个 Launcher 就是我们的桌面了，它通过 PackageManagerService 获知了系统里所有应用的信息，并展示了出来，当然它本身也是一个应用。
通过点击一个应用图标，也就是触发了点击事件，最后会执行到 startActivity 方法。这里也就和启动 Activity 步骤重合上了。
那么这个 startActivity 干了啥？是怎么通过重重关卡唤醒这个应用的？
首先，介绍下系统中那些重要的成员，他们在 App 启动流程中都担任了重要的角色。
系统成员介绍：
①init 进程，Android 系统启动后，Zygote 并不是第一个进程，而是 Linux 的根进程 init 进程，然后 init 进程才会启动 Zygote 进程。
②Zygote 进程，所有 Android 进程的父进程，当然也包括 SystemServer 进程。
③SystemServer 进程，正如名字一样，系统服务进程，负责系统中大大小小的事物，为此也是启动了三员大将：
ActivityManagerService。
PackageManagerService。
WindowManagerService 以及 binder 线程池。
④ActivityManagerService，主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作，对于一些进程的启动，都会通过 Binder 通信机制传递给 AMS，再处理给 Zygote。
⑤PackageManagerService，主要负责应用包的一些操作，比如安装，卸载，解析 AndroidManifest.xml，扫描文件信息等等。
⑥WindowManagerService，主要负责窗口相关的一些服务，比如窗口的启动，添加，删除等。
⑦Launcher，桌面应用，也是属于应用，也有自己的 Activity，一开机就会默认启动，通过设置 Intent.CATEGORY_HOME 的 Category 隐式启动。
搞清楚这些成员，就跟随我一起看看怎么过五关斩六将，最终启动了一个 App。
第一关：跨进程通信，告诉系统我的需求
首先，要告诉系统，我 Launcher 要启动一个应用了。
调用 Activity.startActivityForResult 方法，最终会转到 mInstrumentation.execStartActivity 方法。
由于 Launcher 自己处在一个单独的进程，所以它需要跨进程告诉系统服务我要启动 App 的需求。
找到要通知的 Service，名叫 ActivityTaskManagerService，然后使用 AIDL，通过 Binder 与他进行通信。
这里的简单说下 ActivityTaskManagerService（简称 ATMS）。原来这些通信工作都是属于 ActivityManagerService，现在分了一部分工作给到 ATMS，主要包括四大组件的调度工作。
也是由 SystemServer 进程直接启动的，相关源码可见 ActivityManagerService.Lifecycle.startService 方法，感兴趣朋友可以自己看看。
//Instrumentation.java
int result = ActivityTaskManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
//ActivityTaskManager.java
public static IActivityTaskManager getService() {
return IActivityTaskManagerSingleton.get();
}
private static final Singleton<IActivityTaskManager> IActivityTaskManagerSingleton =
new Singleton<IActivityTaskManager>() {
@Override
protected IActivityTaskManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE);
return IActivityTaskManager.Stub.asInterface(b);
}
};
//ActivityTaskManagerService.java
public class ActivityTaskManagerService extends IActivityTaskManager.Stub
public static final class Lifecycle extends SystemService {
private final ActivityTaskManagerService mService;
public Lifecycle(Context context) {
super(context);
mService = new ActivityTaskManagerService(context);
}
@Override
public void onStart() {
publishBinderService(Context.ACTIVITY_TASK_SERVICE, mService);
mService.start();
}
}
startActivity 我们都很熟悉，平时启动 Activity 都会使用，启动应用也是从这个方法开始的，也会同样带上 intent 信息，表示要启动的是哪个 Activity。
另外要注意的一点是，startActivity 之后有个 checkStartActivityResult 方法，这个方法是用作检查启动 Activity 的结果。
public static void checkStartActivityResult(int res, Object intent) {
switch (res) {
case ActivityManager.START_INTENT_NOT_RESOLVED:
case ActivityManager.START_CLASS_NOT_FOUND:
if (intent instanceof Intent && ((Intent)intent).getComponent() != null)
throw new ActivityNotFoundException(
"Unable to find explicit activity class "
+ ((Intent)intent).getComponent().toShortString()
+ "; have you declared this activity in your AndroidManifest.xml?");
throw new ActivityNotFoundException(
"No Activity found to handle " + intent);
case ActivityManager.START_PERMISSION_DENIED:
throw new SecurityException("Not allowed to start activity "
+ intent);
case ActivityManager.START_FORWARD_AND_REQUEST_CONFLICT:
throw new AndroidRuntimeException(
"FORWARD_RESULT_FLAG used while also requesting a result");
case ActivityManager.START_NOT_ACTIVITY:
throw new IllegalArgumentException(
"PendingIntent is not an activity");
//...
}
}
第二关：通知 Launcher 可以休息了
//ActivityStack.java
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
//...
ActivityRecord next = topRunningActivityLocked(true /* focusableOnly */);
//...
boolean pausing = getDisplay().pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
if (DEBUG_STATES) Slog.d(TAG_STATES,
"resumeTopActivityLocked: Pausing " + mResumedActivity);
pausing |= startPausingLocked(userLeaving, false, next, false);
}
//...
if (next.attachedToProcess()) {
//应用已经启动
try {
//...
transaction.setLifecycleStateRequest(
ResumeActivityItem.obtain(next.app.getReportedProcState(),
getDisplay().mDisplayContent.isNextTransitionForward()));
mService.getLifecycleManager().scheduleTransaction(transaction);
//...
} catch (Exception e) {
//...
mStackSupervisor.startSpecificActivityLocked(next, true, false);
return true;
}
//...
// From this point on, if something goes wrong there is no way
// to recover the activity.
try {
next.completeResumeLocked();
} catch (Exception e) {
// If any exception gets thrown, toss away this
// activity and try the next one.
Slog.w(TAG, "Exception thrown during resume of " + next, e);
requestFinishActivityLocked(next.appToken, Activity.RESULT_CANCELED, null,
"resume-exception", true);
return true;
}
} else {
//冷启动流程
mStackSupervisor.startSpecificActivityLocked(next, true, true);
}
}
这里有两个类没有见过：
ActivityStack，是 Activity 的栈管理，相当于我们平时项目里面自己写的 Activity 管理类，用于管理 Activity 的状态啊，如栈出栈顺序等等。
ActivityRecord，代表具体的某一个 Activity，存放了该 Activity 的各种信息。
startPausingLocked 方法就是让上一个应用，这里也就是 Launcher 进入 Paused 状态。
然后就会判断应用是否启动，如果已经启动了，就会走 ResumeActivityItem 的方法，看这个名字，结合应用已经启动的前提，是不是已经猜到了它是干吗的？
没错，这个就是用来控制 Activity 的 onResume 生命周期方法的，不仅是 onResume 还有 onStart 方法，具体可见 ActivityThread 的 handleResumeActivity 方法源码。
如果应用没启动就会接着走到 startSpecificActivityLocked方法，接着看。
第三关：是否已启动进程，否则创建进程
Launcher 进入 Paused 之后，ActivityTaskManagerService 就会判断要打开的这个应用进程是否已经启动。
如果已经启动，则直接启动 Activity 即可，这也就是应用内的启动 Activity 流程。如果进程没有启动，则需要创建进程。
这里有两个问题：
①怎么判断应用进程是否存在呢？如果一个应用已经启动了，会在 ATMS 里面保存一个 WindowProcessController 信息，这个信息包括 processName 和 uid，uid 则是应用程序的 id，可以通过 applicationInfo.uid 获取。processName 则是进程名，一般为程序包名。
所以判断是否存在应用进程，则是根据 processName 和 uid 去判断是否有对应的 WindowProcessController，并且 WindowProcessController 里面的线程不为空。
//ActivityStackSupervisor.java
void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) {
// Is this activity's application already running?
final WindowProcessController wpc =
mService.getProcessController(r.processName, r.info.applicationInfo.uid);
boolean knownToBeDead = false;
if (wpc != null && wpc.hasThread()) {
//应用进程存在
try {
realStartActivityLocked(r, wpc, andResume, checkConfig);
return;
}
}
}
//WindowProcessController.java
IApplicationThread getThread() {
return mThread;
}
boolean hasThread() {
return mThread != null;
}
//ZygoteProcess.java
private Process.ProcessStartResult attemptUsapSendArgsAndGetResult(
ZygoteState zygoteState, String msgStr)
throws ZygoteStartFailedEx, IOException {
try (LocalSocket usapSessionSocket = zygoteState.getUsapSessionSocket()) {
final BufferedWriter usapWriter =
new BufferedWriter(
new OutputStreamWriter(usapSessionSocket.getOutputStream()),
Zygote.SOCKET_BUFFER_SIZE);
final DataInputStream usapReader =
new DataInputStream(usapSessionSocket.getInputStream());
usapWriter.write(msgStr);
usapWriter.flush();
Process.ProcessStartResult result = new Process.ProcessStartResult();
result.pid = usapReader.readInt();
// USAPs can't be used to spawn processes that need wrappers.
result.usingWrapper = false;
if (result.pid >= 0) {
return result;
} else {
throw new ZygoteStartFailedEx("USAP specialization failed");
}
}
}
可以看到，这里其实是通过 socket 和 Zygote 进行通信，BufferedWriter 用于读取和接收消息。这里将要新建进程的消息传递给 Zygote，由 Zygote 进行 fork 进程，并返回新进程的 pid。
可能又会有人问了？fork 是啥？为啥这里又变成 socket 进行 IPC 通信，而不是 Bindler 了？
首先，fork() 是一个方法，是类 Unix 操作系统上创建进程的主要方法。用于创建子进程（等同于当前进程的副本）。
那为什么 fork 的时候不用 Binder 而用 socket 了呢？主要是因为 fork 不允许存在多线程，Binder 通讯偏偏就是多线程。
问题总是在不断产生，总有好奇的朋友会接着问，为什么 fork 不允许存在多线程？防止死锁。其实你想想，多线程+多进程，听起就不咋靠谱是不。
假设多线程里面线程 A 对某个锁 lock，另外一个线程 B 调用 fork 创建了子进程，但是子进程却没有了线程 A，但是锁本身却被 fork 了出来，那么这个锁没人可以打开了。
一旦子进程中另外的线程又对这个锁进行 lock，就死锁了。
第四关：ActivityThread 闪亮登场
刚才说到由 Zygote 进行 fork 进程，并返回新进程的 pid。其实这过程中也实例化 ActivityThread 对象。
//RuntimeInit.java
protected static Runnable findStaticMain(String className, String[] argv,
ClassLoader classLoader) {
Class<?> cl;
try {
cl = Class.forName(className, true, classLoader);
} catch (ClassNotFoundException ex) {
throw new RuntimeException(
"Missing class when invoking static main " + className,
ex);
}
Method m;
try {
m = cl.getMethod("main", new Class[] { String[].class });
} catch (NoSuchMethodException ex) {
throw new RuntimeException(
"Missing static main on " + className, ex);
} catch (SecurityException ex) {
throw new RuntimeException(
"Problem getting static main on " + className, ex);
}
//...
return new MethodAndArgsCaller(m, argv);
}
原来是反射！通过反射调用了 ActivityThread 的 main 方法。
ActivityThread 大家应该都很熟悉了，代表了 Android 的主线程，而 main 方法也是 App 的主入口。
public static void main(String[] args) {
//...
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq);
//...
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
//...
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
main 方法主要创建了 ActivityThread，创建了主线程的 Looper 对象，并开始 loop 循环。
除了这些，还要告诉 AMS，我醒啦，进程创建好了！也就是上述代码中的 attach 方法，最后会转到 AMSattachApplicationLocked 方法。
//ActivitymanagerService.java
private final boolean attachApplicationLocked(IApplicationThread thread,
int pid, int callingUid, long startSeq) {
//...
ProcessRecord app;
//...
thread.bindApplication(processName, appInfo, providers, null, profilerInfo,
null, null, null, testMode,
mBinderTransactionTrackingEnabled, enableTrackAllocation,
isRestrictedBackupMode || !normalMode, app.isPersistent(),
new Configuration(app.getWindowProcessController().getConfiguration()),
app.compat, getCommonServicesLocked(app.isolated),
mCoreSettingsObserver.getCoreSettingsLocked(),
buildSerial, autofillOptions, contentCaptureOptions);
//...
app.makeActive(thread, mProcessStats);
//...
// See if the top visible activity is waiting to run in this process...
if (normalMode) {
try {
didSomething = mAtmInternal.attachApplication(app.getWindowProcessController());
} catch (Exception e) {
Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
badApp = true;
}
}
//...
}
//ProcessRecord.java
public void makeActive(IApplicationThread _thread, ProcessStatsService tracker) {
//...
thread = _thread;
mWindowProcessController.setThread(thread);
}
这里主要做了三件事：
bindApplication 方法，主要用来启动 Application。
makeActive 方法，设定 WindowProcessController 里面的线程，也就是上文中说过判断进程是否存在所用到的。
attachApplication 方法，启动根 Activity。
第五关：创建 Application
接着上面看，按照我们所熟知的，应用启动后，应该就是启动 Applicaiton，启动 Activity。
//ActivityThread#ApplicationThread
public final void bindApplication(String processName, ApplicationInfo appInfo,
List<ProviderInfo> providers, ComponentName instrumentationName,
ProfilerInfo profilerInfo, Bundle instrumentationArgs,
IInstrumentationWatcher instrumentationWatcher,
IUiAutomationConnection instrumentationUiConnection, int debugMode,
boolean enableBinderTracking, boolean trackAllocation,
boolean isRestrictedBackupMode, boolean persistent, Configuration config,
CompatibilityInfo compatInfo, Map services, Bundle coreSettings,
String buildSerial, AutofillOptions autofillOptions,
ContentCaptureOptions contentCaptureOptions) {
AppBindData data = new AppBindData();
data.processName = processName;
data.appInfo = appInfo;
data.providers = providers;
data.instrumentationName = instrumentationName;
data.instrumentationArgs = instrumentationArgs;
data.instrumentationWatcher = instrumentationWatcher;
data.instrumentationUiAutomationConnection = instrumentationUiConnection;
data.debugMode = debugMode;
data.enableBinderTracking = enableBinderTracking;
data.trackAllocation = trackAllocation;
data.restrictedBackupMode = isRestrictedBackupMode;
data.persistent = persistent;
data.config = config;
data.compatInfo = compatInfo;
data.initProfilerInfo = profilerInfo;
data.buildSerial = buildSerial;
data.autofillOptions = autofillOptions;
data.contentCaptureOptions = contentCaptureOptions;
sendMessage(H.BIND_APPLICATION, data);
}
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
case BIND_APPLICATION:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
AppBindData data = (AppBindData)msg.obj;
handleBindApplication(data);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
}
}
可以看到这里有个 H，H 是主线程的一个 Handler 类，用于处理需要主线程处理的各类消息，包括 BIND_SERVICE，LOW_MEMORY，DUMP_HEAP 等等。
private void handleBindApplication(AppBindData data) {
//...
try {
final ClassLoader cl = instrContext.getClassLoader();
mInstrumentation = (Instrumentation)
cl.loadClass(data.instrumentationName.getClassName()).newInstance();
}
//...
Application app;
final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites();
final StrictMode.ThreadPolicy writesAllowedPolicy = StrictMode.getThreadPolicy();
try {
// If the app is being launched for full backup or restore, bring it up in
// a restricted environment with the base application class.
app = data.info.makeApplication(data.restrictedBackupMode, null);
mInitialApplication = app;
// don't bring up providers in restricted mode; they may depend on the
// app's custom Application class
if (!data.restrictedBackupMode) {
if (!ArrayUtils.isEmpty(data.providers)) {
installContentProviders(app, data.providers);
}
}
// Do this after providers, since instrumentation tests generally start their
// test thread at this point, and we don't want that racing.
try {
mInstrumentation.onCreate(data.instrumentationArgs);
}
//...
try {
mInstrumentation.callApplicationOnCreate(app);
} catch (Exception e) {
if (!mInstrumentation.onException(app, e)) {
throw new RuntimeException(
"Unable to create application " + app.getClass().getName()
+ ": " + e.toString(), e);
}
}
}
//...
}
这里信息量就多了，一点点的看：
首先，创建了 Instrumentation，也就是上文一开始 startActivity 的第一步。每个应用程序都有一个 Instrumentation，用于管理这个进程，比如要创建 Activity 的时候，首先就会执行到这个类里面。
makeApplication 方法，创建了 Application，终于到这一步了。最终会走到 newApplication 方法，执行 Application 的 attach 方法。
public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
Application app = getFactory(context.getPackageName())
.instantiateApplication(cl, className);
app.attach(context);
return app;
}
instrumentation.callApplicationOnCreate(app);
public void callApplicationOnCreate(Application app) {
app.onCreate();
}
也就是创建 Application→attach→onCreate 调用顺序。
installContentProviders
这里就是启动 Provider 的相关代码了，具体逻辑就不分析了。
第六关：启动 Activity
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
//...
WindowManagerGlobal.initialize();
//...
final Activity a = performLaunchActivity(r, customIntent);
//...
return a;
}
首先，初始化了 WindowManagerGlobal，这是个啥呢？没错，就是 WindowManagerService 了，也为后续窗口显示等作了准备。
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//创建ContextImpl
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
//创建Activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
}
try {
if (activity != null) {
//完成activity的一些重要数据的初始化
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback,
r.assistToken);
if (customIntent != null) {
activity.mIntent = customIntent;
}
//设置activity的主题
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
activity.setTheme(theme);
}
//调用activity的onCreate方法
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
}
}
return activity;
}
哇，终于看到 onCreate 方法了。稳住，还是一步步看看这段代码。
首先，创建了 ContextImpl 对象，ContextImpl 可能有的朋友不知道是啥，ContextImpl 继承自 Context，其实就是我们平时用的上下文。
//Activity.java
Context mBase;
@Override
public Executor getMainExecutor() {
return mBase.getMainExecutor();
}
@Override
public Context getApplicationContext() {
return mBase.getApplicationContext();
}
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}
//一层层往上找
final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, int ident,
Application application, Intent intent, ActivityInfo info,
CharSequence title, Activity parent, String id,
NonConfigurationInstances lastNonConfigurationInstances,
Configuration config, String referrer, IVoiceInteractor voiceInteractor) {
attachBaseContext(context);
mWindow = new PhoneWindow(this, window, activityConfigCallback);
mWindow.setWindowControllerCallback(this);
mWindow.setCallback(this);
mWindow.setOnWindowDismissedCallback(this);
mWindow.getLayoutInflater().setPrivateFactory(this);
if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {
mWindow.setSoftInputMode(info.softInputMode);
}
}
这不就是刚才一开始 performLaunchActivity 方法里面的 attach 吗？太巧了，所以这个 ContextImpl 就是我们平时所用的上下文。
顺便看看 attach 还干了啥？新建了 PhoneWindow，建立自己和 Window 的关联，并设置了 setSoftInputMode 等等。
ContextImpl 创建完之后，会通过类加载器创建 Activity 的对象，然后设置好 Activity 的主题，最后调用了 Activity 的 onCreate 方法。
总结
再一起捋一遍 App 的启动流程：
Launcher 被调用点击事件，转到 Instrumentation 类的 startActivity 方法。
Instrumentation 通过跨进程通信告诉 AMS 要启动应用的需求。
AMS 反馈 Launcher，让 Launcher 进入 Paused 状态。
Launcher 进入 Paused 状态，AMS 转到 ZygoteProcess 类，并通过 socket 与 Zygote 通信，告知 Zygote 需要新建进程。
Zygote fork 进程，并调用 ActivityThread 的 main 方法，也就是 App 的入口。
ActivityThread 的 main 方法新建了 ActivityThread 实例，并新建了 Looper 实例，开始 loop 循环。
同时 ActivityThread 也告知 AMS，进程创建完毕，开始创建 Application，Provider，并调用 Applicaiton 的 attach，onCreate 方法。
最后就是创建上下文，通过类加载器加载 Activity，调用 Activity 的 onCreate 方法。
至此，应用启动完毕。当然，分析源码的目的一直都不是为了学知识而学，而是理解了这些基础，我们才能更好的解决问题。
学习了 App 的启动流程，我们可以再思考下一些之前没理解透的问题，比如启动优化。
分析启动过程，其实可以优化启动速度的地方有三个地方：
Application 的 attach 方法，MultiDexApplication 会在方法里面会去执行 MultiDex 逻辑。
所以这里可以进行 MultiDex 优化，比如今日头条方案就是单独启动一个进程的 Activity 去加载 MultiDex。
Application 的 onCreate 方法，大量三方库的初始化都在这里进行，所以我们可以开启线程池，懒加载等等。把每个启动任务进行区分，哪些可以子线程运行，哪些有先后顺序。
Activity 的 onCreate 方法，同样进行线程处理，懒加载。或者预创建 Activity，提前类加载等等。
最后希望各位老铁都能有一个乖巧可爱漂亮的女儿/儿子。😊
编辑：陶家龙
出处：转载自公众号码上积木（ID：Lzjimu）
精彩文章推荐：