Android M应用启动流程分析

更新：
2016-10-29:更新handleBindApplication部分。

我这个版本的原则是，有话则长，无话则短.

以下分析基于6.0.1_r10版本。
先看一张大图：

1. 桌面的onClick事件(进程：桌面应用的进程)

我们暂时忽略Input处理的过程，以桌面的onClick事件被触发为起点。
这部分根据Launcher的不同而大同小异。

2. ActivityManagerService之startActivity(进程AmS)

路径：frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
桌面调用framework，最后会调到AmS的startActivity方法.
现在是多用户时代了，startActivity现在唯一做的事儿，就是通过UserHandle.getCallingUserId()去获取当前的user id，然后调用startActivityAsUser方法。

3848    @Override
3849    public final int startActivity(IApplicationThread caller, String callingPackage,
3850            Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
3851            int startFlags, ProfilerInfo profilerInfo, Bundle options) {
3852        return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
3853            resultWho, requestCode, startFlags, profilerInfo, options,
3854            UserHandle.getCallingUserId());
3855    }

3. ActivityManagerService之startActivityAsUser

这个方法如其名，还真是只处理跟user相关的工作，调用handleIncomingUser。
之后，调用ActivityStackSupervisor来去处理跟Activity状态相关真正逻辑。

3857    @Override
3858    public final int startActivityAsUser(IApplicationThread caller, String callingPackage,
3859            Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
3860            int startFlags, ProfilerInfo profilerInfo, Bundle options, int userId) {
3861        enforceNotIsolatedCaller("startActivity");
3862        userId = handleIncomingUser(Binder.getCallingPid(), Binder.getCallingUid(), userId,
3863                false, ALLOW_FULL_ONLY, "startActivity", null);
3864        // TODO: Switch to user app stacks here.
3865        return mStackSupervisor.startActivityMayWait(caller, -1, callingPackage, intent,
3866                resolvedType, null, null, resultTo, resultWho, requestCode, startFlags,
3867                profilerInfo, null, null, options, false, userId, null, null);
3868    }

4. ActivityStackSupervisor之startActivityMayWait(进程AmS)

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java
先解释一下为什么叫MayWait，因为调用startActivity是可能要等待结果的startActivityForResult，那就要挂起调用者。
首先，startActivityMayWait要读取一些信息。从4.4开始，这部分逻辑写到resolveActivity方法中，它会调用PackageManagerService的resolveIntent方法。这个方法会先调用queryIntentActivities方法出查询相关的列表，然后再调用chooseBestActivity方法去选择。为了不影响主线，这些支线内容后面再讲。
主线往下走，进入startActivityLocked。Locked意思是调用者需要保证加锁保护，不能重复调用，在startActivityMayWait中，是采用mService对象，也就是构造ActivityStackSupervisor时传进来的ActivityManagerService的对象。
调用成功了之后，如果需要wait，就让mService.wait()去等待吧。新Activity还在征途上。

925    final int startActivityMayWait(IApplicationThread caller, int callingUid,
926            String callingPackage, Intent intent, String resolvedType,
927            IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
928            IBinder resultTo, String resultWho, int requestCode, int startFlags,
929            ProfilerInfo profilerInfo, WaitResult outResult, Configuration config,
930            Bundle options, boolean ignoreTargetSecurity, int userId,
931            IActivityContainer iContainer, TaskRecord inTask) {
...
941        // Collect information about the target of the Intent.
942        ActivityInfo aInfo =
943                resolveActivity(intent, resolvedType, startFlags, profilerInfo, userId);
...
1045            int res = startActivityLocked(caller, intent, resolvedType, aInfo,
1046                    voiceSession, voiceInteractor, resultTo, resultWho,
1047                    requestCode, callingPid, callingUid, callingPackage,
1048                    realCallingPid, realCallingUid, startFlags, options, ignoreTargetSecurity,
1049                    componentSpecified, null, container, inTask);
...

5. ActivityStackSupervisor之startActivityLocked

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java

前面先做一系列检查的工作，比如权限，比如Intent防火墙检查。
准备做好之后，就new一个ActivityRecord，用于存储Activity的各种状态和历史信息。
然后，通过getFocusedStack方法获取当前获取焦点的ActivityStack。ActivityStackSupervisor中的mFocusedStack中保存了当前的前台ActivityStack。
下面就准备切换新进程了，先判断一下是否可以切换，如果处于通话中界面等无法马上切换的情况。通过ActivityManagerService的checkAppSwitchAllowedLocked方法来做检查，如果当前不允许做进程切换，就先存到PendingActivityLaunch的列表中，等待以后有机会再调用。
如果允许做切换，那么先检查一下当前是否有以前的等待任务，如果有就先执行它们，调用doPendingActivityLaunchesLocked方法去执行这个循环。
如果以上都完成了，就调用startActivityUncheckedLocked。

1399    final int startActivityLocked(IApplicationThread caller,
1400            Intent intent, String resolvedType, ActivityInfo aInfo,
1401            IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
1402            IBinder resultTo, String resultWho, int requestCode,
1403            int callingPid, int callingUid, String callingPackage,
1404            int realCallingPid, int realCallingUid, int startFlags, Bundle options,
1405            boolean ignoreTargetSecurity, boolean componentSpecified, ActivityRecord[] outActivity,
1406            ActivityContainer container, TaskRecord inTask) {
...
1675        err = startActivityUncheckedLocked(r, sourceRecord, voiceSession, voiceInteractor,
1676                startFlags, true, options, inTask);
1677
1678        if (err < 0) {
1679            // If someone asked to have the keyguard dismissed on the next
1680            // activity start, but we are not actually doing an activity
1681            // switch...  just dismiss the keyguard now, because we
1682            // probably want to see whatever is behind it.
1683            notifyActivityDrawnForKeyguard();
1684        }
1685        return err;
1686    }

6. ActivityStackSupervisor之startActivityUncheckedLocked

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java
通过一系列分析，找到了该执行的目标ActivityStack，然后调用该ActivityStack的startActivityLocked方法针对该任务做具体的操作。

1828    final int startActivityUncheckedLocked(final ActivityRecord r, ActivityRecord sourceRecord,
1829            IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor, int startFlags,
1830            boolean doResume, Bundle options, TaskRecord inTask) {
...
2457        ActivityStack.logStartActivity(EventLogTags.AM_CREATE_ACTIVITY, r, r.task);
2458        targetStack.mLastPausedActivity = null;
2459        targetStack.startActivityLocked(r, newTask, doResume, keepCurTransition, options);
2460        if (!launchTaskBehind) {
2461            // Don't set focus on an activity that's going to the back.
2462            mService.setFocusedActivityLocked(r, "startedActivity");
2463        }
2464        return ActivityManager.START_SUCCESS;
2465    }

7. ActivityStack之startActivityLocked

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStack.java
如果需要的话，这一步中会调用到WmS的setAppStartingWindow，开始准备新应用的启动窗口。
这其中，有重要一步是调用WindowManagerService的addAppToken方法去将信息共步给WmS，为下一步的显示做准备。
最后，调用ActivityStackSupervisor的resumeTopActivitiesLocked方法，将显示的Activities都resume一下。

2074    final void startActivityLocked(ActivityRecord r, boolean newTask,
2075            boolean doResume, boolean keepCurTransition, Bundle options) {
...
2232        if (doResume) {
2233            mStackSupervisor.resumeTopActivitiesLocked(this, r, options);
2234        }
2235    }

8. ActivityStackSupervisor之resumeTopActivitiesLocked

先获取当前焦点显示的ActivityStack，调其resumeTopActivityLocked。完成后，遍历所有能显示的Activity的stack。

2727    boolean resumeTopActivitiesLocked(ActivityStack targetStack, ActivityRecord target,
2728            Bundle targetOptions) {
2729        if (targetStack == null) {
2730            targetStack = mFocusedStack;
2731        }
2732        // Do targetStack first.
2733        boolean result = false;
2734        if (isFrontStack(targetStack)) {
2735            result = targetStack.resumeTopActivityLocked(target, targetOptions);
2736        }
2737
2738        for (int displayNdx = mActivityDisplays.size() - 1; displayNdx >= 0; --displayNdx) {
2739            final ArrayList<ActivityStack> stacks = mActivityDisplays.valueAt(displayNdx).mStacks;
2740            for (int stackNdx = stacks.size() - 1; stackNdx >= 0; --stackNdx) {
2741                final ActivityStack stack = stacks.get(stackNdx);
2742                if (stack == targetStack) {
2743                    // Already started above.
2744                    continue;
2745                }
2746                if (isFrontStack(stack)) {
2747                    stack.resumeTopActivityLocked(null);
2748                }
2749            }
2750        }
2751        return result;
2752    }

9. ActivityStack之resumeTopActivityLocked

调用resumeTopActivityInnerLocked

1540    final boolean resumeTopActivityLocked(ActivityRecord prev, Bundle options) {
1541        if (mStackSupervisor.inResumeTopActivity) {
1542            // Don't even start recursing.
1543            return false;
1544        }
1545
1546        boolean result = false;
1547        try {
1548            // Protect against recursion.
1549            mStackSupervisor.inResumeTopActivity = true;
1550            if (mService.mLockScreenShown == ActivityManagerService.LOCK_SCREEN_LEAVING) {
1551                mService.mLockScreenShown = ActivityManagerService.LOCK_SCREEN_HIDDEN;
1552                mService.updateSleepIfNeededLocked();
1553            }
1554            result = resumeTopActivityInnerLocked(prev, options);
1555        } finally {
1556            mStackSupervisor.inResumeTopActivity = false;
1557        }
1558        return result;
1559    }

10. ActivityStack之resumeTopActivityInnerLocked

这是第一次进入这个方法，这次我们是走pause桌面这一支，下一次我们就走到最后的startSpecificActivityLocked那一支。
调用startPausingLocked去pause。

1561    private boolean resumeTopActivityInnerLocked(ActivityRecord prev, Bundle options) {
...
1729        if (mResumedActivity != null) {
1730            if (DEBUG_STATES) Slog.d(TAG_STATES,
1731                    "resumeTopActivityLocked: Pausing " + mResumedActivity);
1732            pausing |= startPausingLocked(userLeaving, false, true, dontWaitForPause);
1733        }

11. ActivityStack之startPausingLocked

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStack.java
AmS开始发起pause桌面的操作
如果不是从桌面启动的话，就要去为上一个应用抓个用于显示在近期任务里的图。
prev.updateThumbnailLocked(screenshotActivities(prev), null);
处理完成之后，通知桌面应用去执行onPause。
prev.app.thread.schedulePauseActivity(prev.appToken, prev.finishing,userLeaving, prev.configChangeFlags, dontWait);
这个thread就是IPC的ApplicationThreadNative对象。

802    /**
803     * Start pausing the currently resumed activity.  It is an error to call this if there
804     * is already an activity being paused or there is no resumed activity.
805     *
806     * @param userLeaving True if this should result in an onUserLeaving to the current activity.
807     * @param uiSleeping True if this is happening with the user interface going to sleep (the
808     * screen turning off).
809     * @param resuming True if this is being called as part of resuming the top activity, so
810     * we shouldn't try to instigate a resume here.
811     * @param dontWait True if the caller does not want to wait for the pause to complete.  If
812     * set to true, we will immediately complete the pause here before returning.
813     * @return Returns true if an activity now is in the PAUSING state, and we are waiting for
814     * it to tell us when it is done.
815     */
816    final boolean startPausingLocked(boolean userLeaving, boolean uiSleeping, boolean resuming,
817            boolean dontWait) {
...
860        if (prev.app != null && prev.app.thread != null) {
861            if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "Enqueueing pending pause: " + prev);
862            try {
863                EventLog.writeEvent(EventLogTags.AM_PAUSE_ACTIVITY,
864                        prev.userId, System.identityHashCode(prev),
865                        prev.shortComponentName);
866                mService.updateUsageStats(prev, false);
867                prev.app.thread.schedulePauseActivity(prev.appToken, prev.finishing,
868                        userLeaving, prev.configChangeFlags, dontWait);

12. ApplicationThreadNative的schedulePauseActivity

路径：frameworks/base/core/java/android/app/ApplicationThreadNative.java
AmS要通过IPC来通知给桌面，于是通过Proxy来发送IPC操作.

718    public final void schedulePauseActivity(IBinder token, boolean finished,
719            boolean userLeaving, int configChanges, boolean dontReport) throws RemoteException {
720        Parcel data = Parcel.obtain();
721        data.writeInterfaceToken(IApplicationThread.descriptor);
722        data.writeStrongBinder(token);
723        data.writeInt(finished ? 1 : 0);
724        data.writeInt(userLeaving ? 1 :0);
725        data.writeInt(configChanges);
726        data.writeInt(dontReport ? 1 : 0);
727        mRemote.transact(SCHEDULE_PAUSE_ACTIVITY_TRANSACTION, data, null,
728                IBinder.FLAG_ONEWAY);
729        data.recycle();
730    }

13. ActivityThread之schedulePauseActivity (桌面进程)

路径：frameworks/base/core/java/android/app/ActivityThread.java
通过IPC，运行桌面应用的ActivityThread的schedulePauseActivity。此处ActivityThread会将这个请求放入队列中，等待运行。

588        public final void schedulePauseActivity(IBinder token, boolean finished,
589                boolean userLeaving, int configChanges, boolean dontReport) {
590            sendMessage(
591                    finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY,
592                    token,
593                    (userLeaving ? 1 : 0) | (dontReport ? 2 : 0),
594                    configChanges);
595        }

在这段期间，WmS也没闲着，类似于之前我们在startActivityLocked时做的addWindow之类的操作一直在干活。

14. ActivityThread之handlePauseActivity (桌面进程)

终于从队列中轮到出场了，开始执行桌面的onPause吧。

不过先别急，执行onPause之前，先执行performUserLeavingActivity，最后会调到Activity的performUserLeaving。
这个方法做两步：

final void performUserLeaving() {
    onUserInteraction();
    onUserLeaveHint();
}

这些都做完了，调用performPauseActivity。

3305    private void handlePauseActivity(IBinder token, boolean finished,
3306            boolean userLeaving, int configChanges, boolean dontReport) {
...
3310            if (userLeaving) {
3311                performUserLeavingActivity(r);
3312            }
...
3315            performPauseActivity(token, finished, r.isPreHoneycomb());
...
3325                    ActivityManagerNative.getDefault().activityPaused(token);
...
}

15. ActivityThread之performPauseActivity

首先判断一下状态，如果已经pause了，那就需要先resume之。当然，如果pause了之后正在finishing中，就算了，不是的话，抛个RuntimeException，问问调用者不先resume是为哪般。
没有异常的话，先调用callCallActivityOnSaveInstanceState，这个会通过Instrumentation的callActivityOnSaveInstanceState去调用Activity的performSaveInstanceState, 然后会调到Activity的onSaveInstanceState。还会将对话框的信息做保存操作。
保存完状态之后，再调用Instrumentation的callActivityOnPause。然后调用Activity的performPause。
Activity在onPause之前，先通知各个Fragment去onPause，再调用Activity的onPause.
performPauseActivity结束后，回到launchPauseActivity，下面通知AMS，调IPC来做activityPaused。

16. ActivityManagerNative 之activityPaused

路径：frameworks/base/core/java/android/app/ActivityManagerNative.java
桌面的onPause执行完了，通过IPC通知AmS，可以启动新应用了。

17. ActivityManagerService之activityPaused

路径：services/core/java/com/android/server/am/ActivityManagerService.java
AmS收到activityPaused的消息，然后找到对应的ActivityStack的activityPausedLocked。

18. ActivityStack之activityPausedLocked

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStack.java
然后调用completePausedLocked。

19. ActivityStack之completePauseLocked

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStack.java
到此，桌面的onPause正式告一段落。
结束之后，再次调用前面我们已经遇到过的ActivityStackSupervisor的resumeTopActivitiesLocked，前一次我们走了一半就调pause过程去了，这次我们将走到最后。

20. ActivityStackSupervisor之resumeTopActivitiesLocked

还跟上次一样，调相应的ActivityStack的resumeTopActivityLocked。

21. ActivityStack之resumeTopActivityLocked

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStack.java
这个方法只是一个十几行的wrapper，除了设了个flag和处理锁屏之外，直接调用resumeTopActivityInnerLocked方法。

22. ActivityStack之resumeTopActivityInnerLocked

这个大方法走到最后，执行ActivityStackSupervisor的startSpecificActivityLocked。
（注：这个方法是5.0之后分出来的，4.4上还在resumeTopActivityLocked里面）

23. ActivityStackSupervisor之startSpecificActivityLocked (AmS进程)

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java
从这里，又从ActivityStackSupervisor调回ActivityManagerService，调用startProcessLocked。

24. ActivityManagerService 之startProcessLocked

路径：frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
通过调用android.os.Process的start去启动新进程。

25. Process.start

路径：frameworks/base/ core/java/android/os/Process.java
其实就是startViaZygote的一个简单封装。

481    public static final ProcessStartResult start(final String processClass,
482                                  final String niceName,
483                                  int uid, int gid, int[] gids,
484                                  int debugFlags, int mountExternal,
485                                  int targetSdkVersion,
486                                  String seInfo,
487                                  String abi,
488                                  String instructionSet,
489                                  String appDataDir,
490                                  String[] zygoteArgs) {
491        try {
492            return startViaZygote(processClass, niceName, uid, gid, gids,
493                    debugFlags, mountExternal, targetSdkVersion, seInfo,
494                    abi, instructionSet, appDataDir, zygoteArgs);
495        } catch (ZygoteStartFailedEx ex) {
496            Log.e(LOG_TAG,
497                    "Starting VM process through Zygote failed");
498            throw new RuntimeException(
499                    "Starting VM process through Zygote failed", ex);
500        }
501    }

26. Process.startViaZygote

路径：frameworks/base/core/java/android/os/Process.java
主要是处理参数，然后调用zygoteSendArgsAndGetResult去通过socket通信去通知zygote。

27. Process.zygoteSendArgsAndGetResult

路径：frameworks/base/core/java/android/os/Process.java
通过socket通知Zygote进程去fork新进程。接收方是ZygoteConnection。

28. ZygoteConnection.runOnce

路径：frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java
从socket中读取命令并执行。
这个可以往下再分为4步：

• readArgumentList
• apply security policies
• apply security policies
• preForkAndSpecialize

29. Zygote之forkAndSpecialize

路径：/frameworks/base/core/java/com/android/internal/os/Zygote.java
这步分为三个子步骤：

• preFork
• nativeForkAndSpecialize
• postForkCommon

29-1. ZygoteHooks.PreFork

路径：/libcore/dalvik/src/main/java/dalvik/system/ ZygoteHooks.java
这步离开了frameworks/base，进入了libcore。这里面要注意，不能调用Android的API，打个log什么的都要注意。

• Daemons.stop()
  停掉GC，停掉finalizer等，fork进程时不需要这些
• waitUntilAllThreadsStopped()
  确保fork之前只有一个线程在运行
• nativePreFork()
  给虚拟机一个机会去在fork之前做点处理

29-2. com_android_internal_os_Zygote_nativeForkAndSpecialize

路径：/frameworks/base/core/jni/com_android_internal_os_Zygote.cpp
这是我们第一次进入C++层。真正做事的函数是ForkAndSpecializeCommon。

真正开始fork新进程

• SetSigChldHandler
• Fork and detach（新进程从这一步开始诞生）
• child process setup

这一步是值得大书特书的一步，因为从这一步开始，更具体地说是从Fork and detach开始，新应用的进程终于fork出来了。从此zygote老进程的事情我们不再关心，我们来看新进程号就好了。

Child process setup之后，有一个重要的函数会被执行到，这就是ZygoteHooks_nativePostForkChild。
在这个函数中，我们熟悉的AOC版本号的log会输出出来。
这个函数的AOC版本路径在：/aliyunos/aoc/vm/native/dalvik_system_ZygoteHooks.cc中。

#if defined(AOC_VERSION)
LOG(INFO) << "==========================";
LOG(INFO) << "+ AOC version " << Runtime::GetVersionString() << " +";
LOG(INFO) << "==========================";
#endif

对应的ART版本在：/art/runtime/native/dalvik_system_ZygoteHooks.cc中。

29-3. postForkCommon

路径：/libcore/dalvik/src/main/java/dalvik/system/ZygoteHooks.java
只干一件事，把preFork里面stop的monitor们重新打开。这一步要注意，原来的Zygote里面的不要去管了，只看新进程的就好。

30. RuntimeInit.zygoteInit

路径：frameworks/base/core/java/com/android/internal/os/RuntimeInit.java

31. RuntimeInit.invokeStaticMain

路径：frameworks/base/core/java/com/android/internal/os/RuntimeInit.java
初始化完成，通过反射来调用ActivityThread的main方法

32. ActivityThread main

路径：frameworks/base/ core/java/android/app/ActivityThread.java
执行ActivityThread的main方法，新的应用正式上路

33. Proxy:attachApplication

路径：frameworks/base/
新的Activity建好了，要通知AmS，走IPC。

34. ActivityManagerService之attachApplication

路径: frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
AmS收到attach的通知，一切准备就绪。

35. AMS:attachApplicationLocked

路径:frameworks/base/ services/core/java/com/android/server/am/ActivityManagerService.java
其它部分都是线性的，这部分我们不得不分成两个部分各表一支了。这两部分分别走IPC，最后在ActivityThread的队列中汇合。
首先是bindApplication。

36. ApplicationThreadProxy之bindApplication

IPC调用
路径：frameworks/base/core/java/android/app/ApplicationThreadNative.java

37. ActivityThread之bindApplication

路径：frameworks/base/core/java/android/app/ActivityThread.java
主要包括两部分的操作，虽然这个方法不叫做scheduleXXX，但是实际上两步的操作都是放到队列中。
到这一步的时候，其实我们只是启动了一个空进程而己，跟实际的apk还一点关系也没有。
首先，如果services不为空的话，先初始化一下services cache。
ServiceManager.initServiceCache(services);
然后，schedule第一个任务，setCoreSettings(coreSettings);
这个最终会走到handleSetCoreSettings。
下面，PM才出场去读真正的package的信息。读好之后，再去将BIND_APPLICATION消息放到队列里去，这时候可能正在执行setCoreSettings。

38. ActivityThread之handleBindApplication

真正启动Activity之前，还得做一些准备工作。比如install provider就是在这时候做的。

38-1 LoadedApk之makeApplication

我们都知道，在Activity之外，对于每个应用，还对应一个Application类。这个Application就是在LoadApk的makeApplication方法时构造的。

554    public Application makeApplication(boolean forceDefaultAppClass,
555            Instrumentation instrumentation) {
556        if (mApplication != null) {
557            return mApplication;
558        }
559
560        Application app = null;
561
562        String appClass = mApplicationInfo.className;
563        if (forceDefaultAppClass || (appClass == null)) {
564            appClass = "android.app.Application";
565        }

下面调用ClassLoader，并且生成ApplicationContext.

567        try {
568            java.lang.ClassLoader cl = getClassLoader();
569            if (!mPackageName.equals("android")) {
570                initializeJavaContextClassLoader();
571            }
572            ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);

下面将通过Intrumentation的newApplication方法去真正创建Application

573            app = mActivityThread.mInstrumentation.newApplication(
574                    cl, appClass, appContext);
575            appContext.setOuterContext(app);
576        } catch (Exception e) {
577            if (!mActivityThread.mInstrumentation.onException(app, e)) {
578                throw new RuntimeException(
579                    "Unable to instantiate application " + appClass
580                    + ": " + e.toString(), e);
581            }
582        }
583        mActivityThread.mAllApplications.add(app);
584        mApplication = app;

38-2 Application之newApplication

通过反射构造对象，然后调用Application的attach方法。

993    static public Application newApplication(Class<?> clazz, Context context)
994            throws InstantiationException, IllegalAccessException,
995            ClassNotFoundException {
996        Application app = (Application)clazz.newInstance();
997        app.attach(context);
998        return app;
999    }

38-3 Application之attach

attach再调用attachBaseContext。

183    /**
184     * @hide
185     */
186    /* package */ final void attach(Context context) {
187        attachBaseContext(context);
188        mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
189    }
```

### 38-4 ContextThemeWrapper之attachBaseContext

50 @Override
51 protected void attachBaseContext(Context newBase) {
52 super.attachBaseContext(newBase);
53 }

### 38-5 ContextWrapper的attachBaseContext

65 protected void attachBaseContext(Context base) {
66 if (mBase != null) {
67 throw new IllegalStateException("Base context already set");
68 }
69 mBase = base;
70 }

Application构造好之后，将调用Application的onCreate方法。

586 if (instrumentation != null) {
587 try {
588 instrumentation.callApplicationOnCreate(app);
589 } catch (Exception e) {
590 if (!instrumentation.onException(app, e)) {
591 throw new RuntimeException(
592 "Unable to create application " + app.getClass().getName()
593 + ": " + e.toString(), e);
594 }
595 }
596 }

最后更新所有R常量的值

598 // Rewrite the R 'constants' for all library apks.
599 SparseArray packageIdentifiers = getAssets(mActivityThread)
600 .getAssignedPackageIdentifiers();
601 final int N = packageIdentifiers.size();
602 for (int i = 0; i < N; i++) {
603 final int id = packageIdentifiers.keyAt(i);
604 if (id == 0x01 || id == 0x7f) {
605 continue;
606 }
607
608 rewriteRValues(getClassLoader(), packageIdentifiers.valueAt(i), id);
609 }
610
611 return app;
612 }

下面花开两朵说另一枝，回到attachApplicationLocked方法，它将会调用到realStartActivityLocked。

### 39.    ActivityStackSupervisor之realStartActivityLocked(AmS进程)

路径：frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java
这时算是真正启动，通过Activity，可以执行onCreate了。

### 40.    ApplicationThreadNative之scheduleLaunchActivity

路径：frameworks/base/core/java/android/app/ApplicationThreadNative.java
IPC通道，通知本地进程

### 41.    ActivityThread之scheduleLaunchActivity

路径：frameworks/base/ core/java/android/app/ActivityThread.java
ActivityThread收到，将命令放入队列。

### 42.    ActivityThread之handleLaunchActivity

路径：frameworks/base/ core/java/android/app/ActivityThread.java
正式开始Activity的启动流程。

### 43.    ActivityThread之performLaunchActivity

路径：frameworks/base/ core/java/android/app/ActivityThread.java
负责new出Activity的实例，makeApplication，然后调用Activity.attach向系统注册。
最后，通过callActivityOnCreate来调用应用的onCreate方法。

### 44.    ActivityThread之handleResumeActivity

路径：frameworks/base/ core/java/android/app/ActivityThread.java
首先，通过performResumeActivity方法调用应用的onResume方法。
如大家所熟知的，执行完onResume之后，真正的绘制工作就才真正开始。
ActivityThread通过ViewManager对象调用其addView方法，开始正式通知WmS要添加窗口了。实际上，获取的这个ViewManager，是其子接口WindowManager的实现类WindowManagerImpl的方法。这个WindowManagerImpl的对象是通过
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE)调用从系统服务获取到的。

### 45.    WindowManagerImpl之addView

路径：frameworks/base/core/java/android/view/WindowManagerImpl.java
ViewManager只是一个接口，用于定义功能，本身并不与WmS打交道。它通过单例对象WindowManagerGlobal去访问ViewRootImpl，再由ViewRootImpl去跟WmS通信。

### 46.    WindowManagerGlobal之addView

路径：frameworks/base/core/java/android/view/WindowManagerGlobal.java
WindowManagerGlobal也只是个二传手，最终调用ViewRootImpl类的setView来真正与WmS交互。

### 47.    ViewRootImpl之setView

路径：frameworks/base/core/java/android/view/ViewRootImpl.java
ViewRootImpl被构造出来后，会通过WindowManagerGlobal的getWindowSession方法去创建一个与WmS之间的连接。构造中会调到这一句：

mWindowSession = WindowManagerGlobal.getWindowSession();

在正式添加到WmS之前，首先要保证这个View树可以正常接收事件，于是先发起一次requestLayout。

### 48.    ViewRootImpl之requestLayout

这个方法本身是WmS最简单的方法之一，先检查一下是不是UI线程，如果是，就scheduleTraversals，申请做一次遍历。
准备好了之后，setView就会通过mWindowSession去IPC通知WmS去添加一个窗口。

### 49.    Session之addToDisplay

路径：frameworks/base/services/core/java/com/android/server/wm/Session.java
IPC调用WmS的addWindow方法。

### 50.    WindowManagerService之addWindow

路径：frameworks/base/services/core/java/com/android/server/wm/WindowManagerService.java
第一步先检查权限，比如部分系统窗口就不是应用可以添加的。
第二步去检查是不是重复添加了。

if (mWindowMap.containsKey(client.asBinder())) {

Slog.w(TAG, "Window " + client + " is already added");
return WindowManagerGlobal.ADD_DUPLICATE_ADD;

}

第三步，如果是子窗口，就寻找父窗口。
第四步，检查窗口的有效性。
第五步，用WindowState对象来管理窗口的状态。

win = new WindowState(this, session, client, token,attachedWindow, appOp0, seq, attrs, viewVisibility, displayContent);

第六步，调整Window属性
第七步，将token加入到mTokenMap中。
第八步，将client.asBinder()加到mWindowMap中。
第九步，将Window们按顺序排列，调用addWindowToListInOrderLocked方法。
这些做完，addView就算完成了，剩下的事情就看遍历的了。

### 51.    ViewRootImpl之scheduleTraversals

准备好了之后，放入队列等待被遍历。

### 52.    ViewRootImpl之doTraversal

遍历操作，实际逻辑都在performTraversals中。

### 53.    ViewRootImpl之performTraversals

遍历的核心逻辑，主要有三个步骤：measure, layout和draw。
如果是第一次调用，所有的子对象还没有attach到窗口上，需要首先dispatchAttachedToWindow。Attach到哪里呢，PhoneWindow的DecorView。
这个方法没有被DecorView重载，直接调用的是ViewGroup的dispatchAttachedToWindow。

### 54.    ViewGroup之dispatchAttachedToWindow

根元素被attach到Window上之后，开始递归它的子节点，使每个子节点都attach到父节点上。
执行结束后，通过回调onAttachedToWindow来通知节点已经被attach到Window上了。
在被attach到Window之前，View实际上是没有大小的，因为还不知道被用到哪里呢，无法去做测量。
然后，回到performTraversals中，在执行三大操作之前，先去看看队列里还有什么未执行的任务没有，有的话就先执行之。

getRunQueue().executeActions(mAttachInfo.mHandler);

由于是第一次画，所以mLayoutRequested为true，我们还不知道窗口大小是多大，于是来一次测量，调用measureHierarchy.

windowSizeMayChange |= measureHierarchy(host, lp, res,desiredWindowWidth, desiredWindowHeight);

测量完成之后，就可以开始布局了，调用relayoutWindow.

### 55.    ViewRootImpl之relayoutWindow

relayoutWindow当然不是本地能搞得定的，于是通过IPC调，mWindowSession的relayout去通知WmS去干这事儿。

### 56.    Session之relayout

IPC调用，调用WmS的relayoutWindow。

### 57.    WindowManagerService之relayoutWindow

WmS准备第一次画之前，先来个进场动画吧。

winAnimator.applyEnterAnimationLocked();

然后创建个新的Surface吧。

SurfaceControl surfaceControl = winAnimator.createSurfaceLocked();

最后调用performLayoutAndPlaceSurfacesLocked方法

### 58.    WindowManagerService之performLayoutAndPlaceSurfacesLocked

这里边还要走一个最多6次的循环，每次都调用performLayoutAndPlaceSurfacesLockedLoop。

### 59.    WindowManagerService之performLayoutAndPlaceSurfacesLockedLoop

调用performLayoutAndPlaceSurfacesLockedInner

### 60.    WindowManagerService之performLayoutAndPlaceSurfacesLockedInner

真正执行layout的逻辑。
Measure和layout完成了，最后终于可以画了。回到performTraversals中，调用performDraw。

### 61.    ViewRootImpl之performDraw

先调用draw去通知绘制线程开始画。
然后把所有的动画全停掉。

### 62.    ViewRootImpl之draw

如果支持硬件加速，就调用HardwareRenderer抽象类的draw方法去画。

### 63.    ThreadedRenderer之draw

路径:frameworks/base/core/java/android/view/ThreadedRenderer.java

### 64.    ThreadedRenderer之nSyncAndDrawFrame

这是个native方法，真正实现调用GPU去绘制。调用的是android_view_ThreadedRender_syncAndDrawFrame函数。

### 65.    android_view_ThreadedRenderer_syncAndDrawFrame函数

路径：frameworks/base/core/jni/android_view_ThreadedRenderer.cpp
再调用RenderProxy的syncAndDrawFrame。

### 66.    RenderProxy::syncAndDrawFrame

路径：frameworks/base/libs/hwui/renderthread/RenderProxy.cpp
调用DrawFrameTask的drawFrame函数。

### 67.    DrawFrameTask::drawFrame

路径：frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp
调用postAndWait。

### 68.    DrawFrameTask::postAndWait

放到队列里，等着VSYNC信号来了就调用吧。

void DrawFrameTask::postAndWait() {
AutoMutex _lock(mLock);
mRenderThread->queue(this);
mSignal.wait(mLock);
}