面試必備：Android（9.0）Activity啓動流程(二)

時間  2021-08-14
標籤 html java android git markdown app async ide oop 源碼分析 欄目 快樂工作 简体版
原文   原文鏈接

注：下列源碼均基於9.0，可經過下列方式下載本文相關源碼到本地：html

參考博客：如何下載和閱讀Android源碼java

前言

在上一篇文章Android之9.0Actvitiy啓動流程（一）中咱們已經分析了根Activity啓動時所需的應用進程是如何建立的，而且當前應用進程已經啓動了ActivityThread的main方法，因此這篇文章主要圍繞下列內容展開來說解：android

  • 應用進程綁定到AMS
  • AMS發送啓動Activity的請求
  • ActivityThread的Handler處理啓動Activity的請求

1、應用進程綁定到AMS

1. 時序圖

\[外鏈圖片轉存失敗(img-DlmoMg47-1566527233633)(F:\md\開發藝術探索\images\啓動流程\應用進程綁定到AMS.png)\]

2. 詳細過程

在前面一篇咱們知道當Zygote進程孵化出應用進程後會執行ActivityThread的main方法，因此咱們先看看main方法裏的代碼。git

frameworks/base/core/java/android/app/ActivityThread.javamarkdown

public static void main(String[] args) {
        ....
		//建立主線程的Looper以及MessageQueue
        Looper.prepareMainLooper();
        ...
        //AMS綁定ApplicationThread對象,即應用進程綁定到AMS
        thread.attach(false, startSeq);
		//開啓主線程的消息循環
        Looper.loop();
        ...
    }
複製代碼

在這裏咱們就再也不詳細分析prepareMainLooper和loop方法，其主要功能就是準備好主線程的Looper以及消息隊列，最後再開啓主線程的消息循環。若是不懂的能夠看看前面的博客Handler機制中對這兩個方法的分析，在這裏咱們將重點分析attach這個方法。app

frameworks/base/core/java/android/app/ActivityThread.javaasync

private void attach(boolean system, long startSeq) {
        sCurrentActivityThread = this;
        mSystemThread = system;
        if (!system) {
            android.ddm.DdmHandleAppName.setAppName("<pre-initialized>",
                                                    UserHandle.myUserId());
            RuntimeInit.setApplicationObject(mAppThread.asBinder());
            final IActivityManager mgr = ActivityManager.getService();
            try {
				//AMS綁定ApplicationThread對象
                mgr.attachApplication(mAppThread, startSeq);
            } catch (RemoteException ex) {
                throw ex.rethrowFromSystemServer();
            }
            //垃圾回收觀察者
            BinderInternal.addGcWatcher(new Runnable() {
                @Override public void run() {
                    if (!mSomeActivitiesChanged) {
                        return;
                    }
                    Runtime runtime = Runtime.getRuntime();
                    long dalvikMax = runtime.maxMemory();
                    long dalvikUsed = runtime.totalMemory() - runtime.freeMemory();
                    if (dalvikUsed > ((3*dalvikMax)/4)) {
                        if (DEBUG_MEMORY_TRIM) Slog.d(TAG, "Dalvik max=" + (dalvikMax/1024)
                                + " total=" + (runtime.totalMemory()/1024)
                                + " used=" + (dalvikUsed/1024));
                        mSomeActivitiesChanged = false;
                        try {
                            mgr.releaseSomeActivities(mAppThread);
                        } catch (RemoteException e) {
                            throw e.rethrowFromSystemServer();
                        }
                    }
                }
            });
        } 
        ...
    }
複製代碼

能夠看到因爲在ActivityThread的attach中咱們傳入的是false，故在attach方法中將執行!system裏的代碼，經過調用AMS的attachApplication來將ActivityThread中的內部類ApplicationThread對象綁定至AMS，這樣AMS就能夠經過這個代理對象 來控制應用進程。接着爲這個進程添加垃圾回收觀察者，每當系統觸發垃圾回收的時候就在run方法中計算應用使用了多大的內存，若是超過總量的3/4就嘗試釋放內存。ide

frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.javaoop

public final void attachApplication(IApplicationThread thread, long startSeq) {
        synchronized (this) {
            int callingPid = Binder.getCallingPid();
            final int callingUid = Binder.getCallingUid();
            final long origId = Binder.clearCallingIdentity();
            attachApplicationLocked(thread, callingPid, callingUid, startSeq);
            Binder.restoreCallingIdentity(origId);
        }
    }


    private final boolean attachApplicationLocked(IApplicationThread thread, int pid, int callingUid, long startSeq) {
			....
			    //將應用進程的ApplicationThread對象綁定到AMS，即AMS得到ApplicationThread的代理對象
                thread.bindApplication(processName, appInfo, providers,
                        app.instr.mClass,
                        profilerInfo, app.instr.mArguments,
                        app.instr.mWatcher,
                        app.instr.mUiAutomationConnection, testMode,
                        mBinderTransactionTrackingEnabled, enableTrackAllocation,
                        isRestrictedBackupMode || !normalMode, app.persistent,
                        new Configuration(getGlobalConfiguration()), app.compat,
                        getCommonServicesLocked(app.isolated),
                        mCoreSettingsObserver.getCoreSettingsLocked(),
                        buildSerial, isAutofillCompatEnabled);
          

        boolean badApp = false;
        boolean didSomething = false;
        // See if the top visible activity is waiting to run in this process...
        if (normalMode) {
            try {
				//啓動Activity
                if (mStackSupervisor.attachApplicationLocked(app)) {
                    didSomething = true;
                }
            } catch (Exception e) {
                Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
                badApp = true;
            }
        }
        .....
    }

複製代碼

在AMS的attachApplication方法中調用了attachApplicationLocked進行綁定，從上面代碼能夠發現attachApplicationLocked中有兩個重要的方法：thread.bindApplication和mStackSupervisor.attachApplicationLocked(app)。thread.bindApplication中的thread其實就是ActivityThread裏ApplicationThread對象在AMS的代理對象，故此方法將最終調用ApplicationThread的bindApplication方法。而mStackSupervisor.attachApplicationLocked(app)主要是AMS啓動Activity的做用（在下列AMS發送啓動Activity的請求會分析到）。在這裏咱們先看看ApplicationThread的bindApplication方法。源碼分析

frameworks/base/core/java/android/app/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, boolean autofillCompatibilityEnabled) {

          	....
			//向H發送綁定ApplicationThread對象的消息
            sendMessage(H.BIND_APPLICATION, data);
        }

    void sendMessage(int what, Object obj) {
        sendMessage(what, obj, 0, 0, false);
    }

    private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
        ...
        Message msg = Message.obtain();
        msg.what = what;
        msg.obj = obj;
        msg.arg1 = arg1;
        msg.arg2 = arg2;
        if (async) {
            msg.setAsynchronous(true);
        }
        mH.sendMessage(msg);
    }

複製代碼

能夠發現上面其實就是Handler機制的應用，mH其實就是H類型的，因此bindApplication主要就是向ActivityThread的Handler,即H發送綁定的消息。

frameworks/base/core/java/android/app/ActivityThread.H

//線程所須要的Handler，內部定義了一組消息類型，主要包括四大組件的啓動和中止過程
    class H extends Handler {
        public static final int BIND_APPLICATION        = 110;
        ...
        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其實就是當前線程，也能夠說是主線程ActivityThread的Handler，內部定義了一組消息類型，包括了四大組件的啓動和中止過程。經過Handler機制咱們知道在H的handleMessage中會處理髮送給H的消息，在這裏將調用handleBindApplication方法。

frameworks/base/core/java/android/app/ActivityThread

@UnsupportedAppUsage
    private void handleBindApplication(AppBindData data) {

        ....
        final InstrumentationInfo ii;
        if (data.instrumentationName != null) {
            try {
                ii = new ApplicationPackageManager(null, getPackageManager())
                        .getInstrumentationInfo(data.instrumentationName, 0);
            } 
            ...
        } else {
            ii = null;
        }
        ....
        // Continue loading instrumentation.
        if (ii != null) {
            .....
        } else {
            mInstrumentation = new Instrumentation();
            mInstrumentation.basicInit(this);
        }
        ....
        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;
            try {
                //調用Application的onCreate的方法
                //故Application的onCreate比ActivityThread的main方法慢執行
                //可是會比全部該應用Activity的生命週期先調用，由於此時的Activity還沒啓動
                mInstrumentation.callApplicationOnCreate(app);
            }
            ...
        } 
    }
複製代碼

2、AMS發送啓動Activity的請求

應用進程綁定後，隨之就得啓動Activity，那麼得向誰發送啓動Activity獲得請求呢？顯而易見，固然是向主線程即ActivityThread發送啓動Activity的請求。下面就讓咱們一探究竟！

1. 時序圖

\[外鏈圖片轉存失敗(img-UaWral2q-1566527233635)(F:\md\開發藝術探索\images\啓動流程\AMS發送啓動Activity的請求.png)\]

2. 詳細過程

如今當前進程已經綁定到了AMS，綁定後呢？回憶一下，上面對AMS的attachApplicationLocked方法分析時，重點提到了兩個方法，其中ApplicationThread的bindApplication方法咱們分析應用進程是如何綁定到AMS的，沒錯！另一個方法mStackSupervisor.attachApplicationLocked(app)就是用來啓動Activity的，如今讓咱們來看看。

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

boolean attachApplicationLocked(ProcessRecord app) throws RemoteException {
        final String processName = app.processName;
        boolean didSomething = false;
        for (int displayNdx = mActivityDisplays.size() - 1; displayNdx >= 0; --displayNdx) {
            ...
            for (int stackNdx = display.getChildCount() - 1; stackNdx >= 0; --stackNdx) {
                ....
                for (int i = 0; i < size; i++) {
                    final ActivityRecord activity = mTmpActivityList.get(i);
                    if (activity.app == null && app.uid == activity.info.applicationInfo.uid
                            && processName.equals(activity.processName)) {
                        try {
						    //真正啓動Activity，也是普通Activity的啓動過程
                            if (realStartActivityLocked(activity, app,
                                    top == activity /* andResume */, true /* checkConfig */)) {
                                didSomething = true;
                            }
                        } catch (RemoteException e) {
                             ...
                        }
                    }
                }
            }
        }
        return didSomething;
    }
複製代碼

attachApplicationLocked會調用realStartActivityLocked方法，以下。

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

final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app, boolean andResume, boolean checkConfig) throws RemoteException {
                .....
                final ClientTransaction clientTransaction = ClientTransaction.obtain(app.thread,
                        r.appToken);
			    //添加callback，首先會執行callback中的方法
                 //此時的ActivityLifecycleItem爲LaunchActivityItem
                clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
                        System.identityHashCode(r), r.info,
                        // TODO: Have this take the merged configuration instead of separate global
                        // and override configs.
                        mergedConfiguration.getGlobalConfiguration(),
                        mergedConfiguration.getOverrideConfiguration(), r.compat,
                        r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
                        r.persistentState, results, newIntents, mService.isNextTransitionForward(),
                        profilerInfo));

                //判斷此時的生命週期是resume仍是pause
                final ActivityLifecycleItem lifecycleItem;
                if (andResume) {
                    lifecycleItem = ResumeActivityItem.obtain(mService.isNextTransitionForward());
                } else {
                    lifecycleItem = PauseActivityItem.obtain();
                }
                //設置當前的生命週期
                clientTransaction.setLifecycleStateRequest(lifecycleItem);

                // mService爲AMS對象,getLifecycleManager獲得ClientLifecycleManager
                mService.getLifecycleManager().scheduleTransaction(clientTransaction);
        	    ......
            } 
			....
        return true;
    }
複製代碼

在realStartActivityLocked方法中爲ClientTransaction對象添加LaunchActivityItem的callback，而後設置當前的生命週期狀態，因爲咱們是根Activity的啓動，很顯然這裏的生命週期爲ResumeActivityItem，最後調用ClientLifecycleManager.scheduleTransaction方法執行。咱們繼續追蹤下去!

frameworks/base/services/core/java/com/android/server/am/ClientLifecycleManager.java

void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
        final IApplicationThread client = transaction.getClient();
        transaction.schedule();
        if (!(client instanceof Binder)) {
            transaction.recycle();
        }
    }
複製代碼

從上面代碼中能夠看出，因爲transaction爲ClientTransaction類型，故接下去將執行ClientTransaction的schedule方法

frameworks\base\core\java\android\app\servertransaction\ClientTransaction.java

public void schedule() throws RemoteException {
        //1.mClient是IApplicationThread類型，
        //2.ActivityThread的內部類ApplicationThread派生這個接口類並實現了對應的方法
        //3.ActivityThread實際調用的是他父類ClientTransactionHandler的scheduleTransaction方法。
        mClient.scheduleTransaction(this);
    }
複製代碼

mClient是IApplicationThread類型，經過名字和閱讀源碼咱們能夠知道ApplicationThread會實現該類型，因此這裏調用的應該是ApplicationThread的scheduleTransaction方法，咱們知道ApplicationThread是ActivityThread的內部類，因此經過閱讀ActivityThread源碼你會發如今這個類中並無實現scheduleTransaction這個方法，難道分析錯了？？？？

聰明的你應該想到了，既然在當前類找不到這個方法，只能去找父類尋求幫助了，果真姜仍是老的辣，在ActivityThread的父類ClientTransactionHandler中咱們找到了這個scheduleTransaction方法。以下

frameworks\base\core\java\android\app\ClientTransactionHandler.java

void scheduleTransaction(ClientTransaction transaction) {
        transaction.preExecute(this);
        sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
    }
    abstract void sendMessage(int what, Object obj);
複製代碼

看到這是否是忽然以爲很熟悉，不急，咱們一步一步來分析！在這個方法中會調用sendMessage方法，而在ClientTransactionHandler類中該sendMessage方法爲抽象方法，其具體實如今子類ActivityThread中，以下

frameworks/base/services/core/java/com/android/server/am/ActivityThread.java

void sendMessage(int what, Object obj) {
        sendMessage(what, obj, 0, 0, false);
    }

    private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
        if (DEBUG_MESSAGES) Slog.v(
            TAG, "SCHEDULE " + what + " " + mH.codeToString(what)
            + ": " + arg1 + " / " + obj);
        Message msg = Message.obtain();
        msg.what = what;
        msg.obj = obj;
        msg.arg1 = arg1;
        msg.arg2 = arg2;
        if (async) {
            msg.setAsynchronous(true);
        }
        mH.sendMessage(msg);
    }
複製代碼

上面的代碼很容易理解，在ActivityThread的sendMessage中會把啓動Activity的消息發送給mH,而mH爲H類型，其實就是ActivityThread的Handler。到這裏AMS就將啓動Activity的請求發送給了ActivityThread的Handler。

3、ActivityThread的Handler處理啓動Activity的請求

1. 時序圖

\[外鏈圖片轉存失敗(img-Ohks0kHI-1566527233637)(F:\md\開發藝術探索\images\啓動流程\ActivityThread的Handler處理啓動Activity的請求.png)\]

2. 詳細過程

既然發送了啓動Activity的消息，那麼就得ActivityThread固然得處理這個消息，咱們知道Handler機制，若是是經過sendMessage的方法發送消息的話，應該是在Handler的handleMessage處理消息，在這裏也一樣如此，ActivityThread的Handler就是H，讓咱們來看看H的handleMessage,看看是否能找到EXECUTE_TRANSACTION消息的處理.

frameworks/base/core/java/android/app/ActivityThread.H

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;
                ......
				//處理事務，處理活動的啓動，生命週期的轉化等 
                case EXECUTE_TRANSACTION:
                    final ClientTransaction transaction = (ClientTransaction) msg.obj;
					//切換Activity的狀態
                    mTransactionExecutor.execute(transaction);
                    if (isSystem()) {
                        // Client transactions inside system process are recycled on the client side
                        // instead of ClientLifecycleManager to avoid being cleared before this
                        // message is handled.
                        transaction.recycle();
                    }
                    // TODO(lifecycler): Recycle locally scheduled transactions.
                    break;
                ....
            }
            ...
        }
複製代碼

果然如此，咱們H接受到AMS發來的EXECUTE_TRANSACTION消息後，將調用TransactionExecutor.execute方法來切換Activity狀態。

frameworks\base\core\java\android\app\servertransaction\TransactionExecutor.java

public void execute(ClientTransaction transaction) {
        final IBinder token = transaction.getActivityToken();
        log("Start resolving transaction for client: " + mTransactionHandler + ", token: " + token);
        //先執行callbacks，當根活動首次啓動時會有callback，callback會執行onCreate方法
        //其它活動切換狀態時沒有callback
        executeCallbacks(transaction);
        //改變活動的生命週期狀態
        executeLifecycleState(transaction);
        mPendingActions.clear();
        log("End resolving transaction");
    }
複製代碼

在execute方法中重點關注兩個方法：executeCallbacks，因爲咱們如今分析的是根Activity的啓動流程，從上面也能夠知道此時的callback是不爲null的，因此會執行executeCallbacks，最終會執行Activity的onCreate方法.此時根Activity就已經啓動成功了。executeLifecycleState方法是用來改變活動的生命週期狀態的，若是是根Activity的啓動，最終將會執行onStart和onResume方法。下面來分析這兩個方法

2.1 執行onCreate方法

來看看executeCallbacks這個方法。

frameworks\base\core\java\android\app\servertransaction\TransactionExecutor.java

@VisibleForTesting
    public void executeCallbacks(ClientTransaction transaction) {
        final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
        if (callbacks == null) {
            // No callbacks to execute, return early.
            return;
        }
        ......
        final int size = callbacks.size();
        for (int i = 0; i < size; ++i) {
            //此時item爲LaunchActivityItem
            final ClientTransactionItem item = callbacks.get(i);
            ......
            item.execute(mTransactionHandler, token, mPendingActions);
            item.postExecute(mTransactionHandler, token, mPendingActions);
            ......
        }
    }
複製代碼

從上面的分析咱們知道根Activity啓動時這個callback的ClientTransactionItem爲LaunchActivityItem，因此會執行LaunchActivityItem的execute方法。

frameworks\base\core\java\android\app\servertransaction\LaunchActivityItem.java

@Override
    public void execute(ClientTransactionHandler client, IBinder token, PendingTransactionActions pendingActions) {
        Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
        ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
                mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
                mPendingResults, mPendingNewIntents, mIsForward,
                mProfilerInfo, client);
		//此client爲ActivityThread
        client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
        Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
    }
複製代碼

上面的client爲ActivityThread，因此會繼續調用ActivityThread的handleLaunchActivity方法，以下。

public Activity handleLaunchActivity(ActivityClientRecord r, PendingTransactionActions pendingActions, Intent customIntent) {
        mSomeActivitiesChanged = true;
        //啓動Activity
        final Activity a = performLaunchActivity(r, customIntent);

        if (a != null) {
            .....
        } else {
            //若是出現錯誤就通知AMS中止活動
            try {
				//中止Activity
                ActivityManager.getService()
                        .finishActivity(r.token, Activity.RESULT_CANCELED, null,
                                Activity.DONT_FINISH_TASK_WITH_ACTIVITY);
            } catch (RemoteException ex) {
                throw ex.rethrowFromSystemServer();
            }
        }

        return a;
    }
複製代碼

在上述方法中將調用performLaunchActivity來啓動活動，以下

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
        //ActivityInfo用於存儲代碼和AndroidManifes設置的Activity和receiver節點信息，
        //好比Activity的theme和launchMode
        ActivityInfo aInfo = r.activityInfo;
        if (r.packageInfo == null) {
			//獲取APK文件的描述類LoadedApk
            r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo,
                    Context.CONTEXT_INCLUDE_CODE);
        }
		//獲取要啓動的Activity的ComponentName類，ComponentName類中保存了該Activity的包名和類名
        ComponentName component = r.intent.getComponent();
        if (component == null) {
            component = r.intent.resolveActivity(
                mInitialApplication.getPackageManager());
            r.intent.setComponent(component);
        }

        if (r.activityInfo.targetActivity != null) {
            component = new ComponentName(r.activityInfo.packageName,
                    r.activityInfo.targetActivity);
        }

		
        //建立要啓動Activity的上下文環境
        ContextImpl appContext = createBaseContextForActivity(r);
        Activity activity = null;
        try {
            java.lang.ClassLoader cl = appContext.getClassLoader();

		    //用類加載器來建立該Activity的實例
            activity = mInstrumentation.newActivity(
                    cl, component.getClassName(), r.intent);
            StrictMode.incrementExpectedActivityCount(activity.getClass());
            r.intent.setExtrasClassLoader(cl);
            r.intent.prepareToEnterProcess();
            if (r.state != null) {
                r.state.setClassLoader(cl);
            }
        }
        ...

        try {
			//建立Application,makeApplication會調用Application的onCreate方法
            Application app = r.packageInfo.makeApplication(false, mInstrumentation);
            ...
            if (activity != null) {
                ....
                //初始化Activity，建立Window對象（PhoneWindow）並實現Activity和Window相關聯
                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);

                ....
                //設置主題 
                int theme = r.activityInfo.getThemeResource();
                if (theme != 0) {
                    activity.setTheme(theme);
                }

                activity.mCalled = false;
                //啓動活動
                if (r.isPersistable()) {
                    mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
                } else {
                    mInstrumentation.callActivityOnCreate(activity, r.state);
                }
                ....
            }

			//設置生命週期爲onCreate
            r.setState(ON_CREATE);
        } 
        ...
        return activity;
    }
複製代碼

該方法代碼不少，要乾的事情也挺多的，而且都很重要，經過註釋應該能夠知道這個方法的任務，當幹完全部過後得將當前的生命週期設置爲ON_CREATE。咱們重點關注啓動活動的代碼mInstrumentation.callActivityOnCreate，能夠知道在這裏將會調用Instrumentation的callActivityOnCreate來啓動活動。

frameworks\base\core\java\android\app\Instrumentation.java

public void callActivityOnCreate(Activity activity, Bundle icicle) {
        prePerformCreate(activity);
        activity.performCreate(icicle);
        postPerformCreate(activity);
    }
複製代碼

而callActivityOnCreate將調用Activity的performCreate，以下

frameworks\base\core\java\android\app\Activity.java

final void performCreate(Bundle icicle) {
        performCreate(icicle, null);
    }

    @UnsupportedAppUsage
    final void performCreate(Bundle icicle, PersistableBundle persistentState) {
        ....
		//調用Activity的onCreate，根Activity啓動成功
        if (persistentState != null) {
            onCreate(icicle, persistentState);
        } else {
            onCreate(icicle);
        }
        ...
    }
複製代碼

看獲得這眼淚是否嘩啦啦啦的流下了，終於看到熟悉的東西了，在Activity的performCreate中將執行onCreate，也就是咱們在開發中所熟悉的onCreate,「終於等到你，還好咱們沒放棄」，講到這，根Activity就已經啓動了，咱們的萬里長征也應該結束了，可是身爲萬里長征的首席指揮官，總不能一結束就撒手無論吧。因此讓咱們繼續來看看結束後的維護工做。

2.2 執行onStart方法

從上面分析中咱們知道onCreate已經被調用，且生命週期的狀態是ON_CREATE，故executeCallbacks已經執行完畢，因此開始執行executeLifecycleState方法。以下

frameworks/base/core/java/android/app/servertransaction/TransactionExecutor.java

private void executeLifecycleState(ClientTransaction transaction) {
        final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
        if (lifecycleItem == null) {
            // No lifecycle request, return early.
            return;
        }
        ....
        // 執行當前生命週期狀態以前的狀態
        cycleToPath(r, lifecycleItem.getTargetState(), true /* excludeLastState */);

        //切換狀態
        lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
        lifecycleItem.postExecute(mTransactionHandler, token, mPendingActions);
    }
複製代碼

在executeLifecycleState方法中，會先執行cycleToPath，從上面的分析咱們已經知道當根Activity啓動時，此時的lifecycleItem爲ResumeActivityItem，故調用lifecycleItem.getTargetState時將獲得ON_RESUME狀態，讓咱們來瞧瞧cycleToPath方法。

private void cycleToPath(ActivityClientRecord r, int finish, boolean excludeLastState) {
        final int start = r.getLifecycleState();
        log("Cycle from: " + start + " to: " + finish + " excludeLastState:" + excludeLastState);
        final IntArray path = mHelper.getLifecyclePath(start, finish, excludeLastState);
        performLifecycleSequence(r, path);
    }
複製代碼

因爲onCreate方法已經執行，因此start爲ON_CREATE,而finish爲上面傳遞的ON_RESUME,excludeLastState是否移除最後的狀態爲true。讓咱們來看看getLifecyclePath這個方法

frameworks/base/core/java/android/app/servertransaction/TransactionExecutorHelper.java

public IntArray getLifecyclePath(int start, int finish, boolean excludeLastState) {
        ...
        if (finish >= start) {
            // 添加start到finish之間的週期狀態
            for (int i = start + 1; i <= finish; i++) {
                mLifecycleSequence.add(i);
            }
        } 
        ...
        // 根據需求移除最後的狀態
        if (excludeLastState && mLifecycleSequence.size() != 0) {
            mLifecycleSequence.remove(mLifecycleSequence.size() - 1);
        }

        return mLifecycleSequence;
    }

public abstract class ActivityLifecycleItem extends ClientTransactionItem {
    .....
    public static final int UNDEFINED = -1;
    public static final int PRE_ON_CREATE = 0;
    public static final int ON_CREATE = 1;
    public static final int ON_START = 2;
    public static final int ON_RESUME = 3;
    public static final int ON_PAUSE = 4;
    public static final int ON_STOP = 5;
    public static final int ON_DESTROY = 6;
    public static final int ON_RESTART = 7;
    ...
}

複製代碼

在getLifecyclePath這個方法咱們知道start爲ON_CREATE,finish爲ON_RESUME,那麼如何知道start和finish的大小關係呢？在ActivityLifecycleItem中咱們能夠發現這些狀態的定義，從定義中能夠發現finish>=start，因此咱們只關注這部分的邏輯處理，能夠發現ON_CREATE和ON_RESUME中間還有ON_START這個狀態，因此mLifecycleSequence將添加ON_START和ON_RESUME狀態，可是又由於excludeLastState爲true，因此最後會移除掉ON_RESUME狀態，故返回的類型只包含ON_START狀態。故cycleToPath方法中的path中將只包含ON_START狀態，而後繼續執行performLifecycleSequence方法。

private void performLifecycleSequence(ActivityClientRecord r, IntArray path) {
        final int size = path.size();
        for (int i = 0, state; i < size; i++) {
            state = path.get(i);
            log("Transitioning to state: " + state);
            switch (state) {
                .....
                case ON_START:
                    mTransactionHandler.handleStartActivity(r, mPendingActions);
                    break;
                 ......
            }
        }
    }
複製代碼

由於path只包含ON_START狀態，因此只執行ActivityThread的handleStartActivity方法。

frameworks/base/core/java/android/app/ActivityThread.java

public void handleStartActivity(ActivityClientRecord r, PendingTransactionActions pendingActions) {
        ...
        // Start
        activity.performStart("handleStartActivity");
        r.setState(ON_START);
        ...
    }
複製代碼

frameworks/base/core/java/android/app/Activity.java

final void performStart(String reason) {
    ...
     mInstrumentation.callActivityOnStart(this);
    ...
}
複製代碼

frameworks/base/core/java/android/app/Instrumentation.java

public void callActivityOnStart(Activity activity) {
        activity.onStart();
    }
複製代碼

從上面能夠發現ActivityThread.handleStartActivity通過屢次跳轉最終會執行activity.onStart方法，至此cycleToPath方法執行完畢。

2.3 執行onResume方法

讓咱們回到executeLifecycleState這個方法，執行完cycleToPath方法後將執行lifecycleItem.execute，即ResumeActivityItem的execute方法。

frameworks/base/core/java/android/app/servertransaction/ResumeActivityItem.java

@Override
    public void execute(ClientTransactionHandler client, IBinder token, PendingTransactionActions pendingActions) {
        Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityResume");
        //此client爲ActivityThread
        client.handleResumeActivity(token, true /* finalStateRequest */, mIsForward,
                "RESUME_ACTIVITY");
        Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
    }
複製代碼

frameworks/base/core/java/android/app/ActivityThread.java

@Override
    public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward, String reason) {
        ...
        // TODO Push resumeArgs into the activity for consideration
        final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
        ...
        Looper.myQueue().addIdleHandler(new Idler());
        ...
    }

    public ActivityClientRecord performResumeActivity(IBinder token, boolean finalStateRequest, String reason) {
        ...
        try {
            ...
            r.activity.performResume(r.startsNotResumed, reason);
            r.state = null;
            r.persistentState = null;
            //設置當前狀態爲ON_RESUME
            r.setState(ON_RESUME);
        } 
        ...
        return r;
    }
複製代碼

frameworks/base/core/java/android/app/Activity.java

final void performResume(boolean followedByPause, String reason) {
        performRestart(true /* start */, reason);
        ...
        // mResumed is set by the instrumentation
        mInstrumentation.callActivityOnResume(this);
        ...
    }
複製代碼

frameworks/base/core/java/android/app/Instrumentation.java

public void callActivityOnResume(Activity activity) {
        activity.mResumed = true;
        activity.onResume();
        ...
    }
複製代碼

能夠發現其實執行onCreate，onStart,onResume的流程大體上是相似的，經過屢次調用最終將會調用Activity的onResume方法，至此Activity真正啓動完畢！

總結

理解根Activity的啓動流程相當重要，在這次分析根Activity的啓動流程中對Activity的生命週期也有了更深的瞭解，因爲在分析過程當中是基於Android9.0的，與以前的版本有些改動，有時候會陷入源碼的沼澤中，越掙扎陷的越深。因此我以爲咱們應該藉助源碼來把握總體流程，但又不能糾結於讀懂源碼中的任何代碼，這是不太現實的。

兩篇文章結合起來，咱們能夠得知Activity的啓動的總體流程：

1. Launcher進程請求AMS

2. AMS發送建立應用進程請求

3. Zygote進程接受請求並孵化應用進程

4. 應用進程啓動ActivityThread

5. 應用進程綁定到AMS

6. AMS發送啓動Activity的請求

7. ActivityThread的Handler處理啓動Activity的請求

參考博客：

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程