解答Android程序媛
第四关：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等等。接着看handleBindApplication：
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; }
attach方法有了，onCreate方法又是何时调用的呢？马上来了：
instrumentation.callApplicationOnCreate(app); public void callApplicationOnCreate(Application app) { app.onCreate(); }
也就是创建Application->attach->onCreate调用顺序。
等等，在onCreate之前还有一句重要的代码：
installContentProviders
这里就是启动Provider的相关代码了，具体逻辑就不分析了。
第六关：启动Activity
说完bindApplication，该说说后续了，上文第五关说到，bindApplication方法之后执行的是attachApplication方法，最终会执行到ActivityThread的handleLaunchActivity方法：
public Activity handleLaunchActivity(ActivityClientRecord r, PendingTransactionActions pendingActions, Intent customIntent) { //... WindowManagerGlobal.initialize(); //... final Activity a = performLaunchActivity(r, customIntent); //... return a; }
首先，初始化了WindowManagerGlobal，这是个啥呢？没错，就是WindowManagerService了，也为后续窗口显示等作了准备。
继续看performLaunchActivity：
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,其实就是我们平时用的上下文。有的同学可能表示，这不对啊，获取上下文明明获取的是Context对象。来一起跟随源码看看。
//Activity.java Context mBase; @Override public Executor getMainExecutor() { return mBase.getMainExecutor(); } @Override public Context getApplicationContext() { return mBase.getApplicationContext(); }
这里可以看到，我们平时用的上下文就是这个mBase，那么找到这个mBase是啥就行了：
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需要新建进程。Zygotefork进程，并调用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，提前类加载等等。
最后希望各位老铁都能有一个乖巧可爱漂亮的女儿/儿子。😊
附件
fork使用多线程
今日头条启动优化
app启动流程分析
谢谢你的阅读，如果你觉得写的还行，就点个赞支持下吧！感谢！
你的一个👍，就是我分享的动力❤️。
