Android - Activity 啟動過程

概述

從點選桌面應用圖示到應用顯示的過程我們再熟悉不過了，下面我們來分析下這個過程都做了什麼。

本文主要對以下問題分析：

• ActivityThread 是什麼，它是一個執行緒嗎，如何被啟動的？
• ActivityClientRecord 與 ActivityRecord 是什麼？
• Context 是什麼，ContextImpl，ContextWapper 是什麼？
• Instrumentation 是什麼？
• Application 是什麼，什麼時候建立的，每個應用程式有幾個 Application？
• 點選 Launcher 啟動 Activity 和應用內部啟動 Activity 的區別？
• Activity 啟動過程，onCreate()，onResume() 回撥時機及具體作用？

Launcher

如不瞭解 Android 是如何從開機到 Launcher 啟動的過程，請先閱讀Android - 系統啟動過程。

我們知道 Android 系統啟動後已經啟動了 Zygote，ServiceManager，SystemServer 等系統程序；ServiceManager 程序中完成了 Binder 初始化；SystemServer 程序中 ActivityManagerService，WindowManagerService，PackageManagerService 等系統服務在 ServiceManager 中已經註冊；最後啟動了 Launcher 桌面應用。

其實 Launcher 本身就是一個應用程式，執行在自己的程序中，我們看到的桌面就是 Launcher 中的一個 Activity。

應用安裝的時候，通過 PackageManagerService 解析 apk 的 AndroidManifest.xml 檔案，提取出這個 apk 的資訊寫入到 packages.xml 檔案中，這些資訊包括：許可權、應用包名、icon、apk 的安裝位置、版本、userID 等等。packages.xml 檔案位於系統目錄下/data/system/packages.xml。

同時桌面 Launcher 會為安裝過的應用生成不同的應用入口，對應桌面上的應用圖示，下面分析點選應用圖示的到應用啟動的過程。

點選 Launcher 中應用圖示

點選 Launcher 中應用圖示將會執行以下方法

Launcher.startActivitySafely()
Launcher.startActivity()
//以上兩個方法主要是檢查將要開啟的 Activity 是否存在

Activity.startActivity()
//這段程式碼大家已經很熟悉，經常開啟 Activity 用的就是這個方法

Activity.startActivityForResult()
//預設 requestCode = -1，也可通過呼叫 startActivityForResult() 傳入 requestCode。 
//然後通過 MainThread 獲取到 ApplicationThread 傳入下面方法。

Instrumentation.execStartActivity()
//通過 ActivityManagerNative.getDefault() 獲取到 ActivityManagerService 的代理為程序通訊作準備。

ActivityManagerNative.getDefault().startActivity()
ActivityManagerProxy.startActivity()
//呼叫代理物件的 startActivity() 方法，傳送 START_ACTIVITY_TRANSACTION 命令。

在 system_server 程序中的服務端 ActivityManagerService 收到 START_ACTIVITY_TRANSACTION 命令後進行處理，呼叫 startActivity() 方法。

ActivityManagerService.startActivity() -> startActivityAsUser(intent, requestCode, userId)
//通過 UserHandle.getCallingUserId() 獲取到 userId 並呼叫 startActivityAsUser() 方法。

ActivityStackSupervisor.startActivityMayWait() -> resolveActivity()
//通過 intent 建立新的 intent 物件，即使之前 intent 被修改也不受影響。 然後呼叫 resolveActivity()。
//然後通過層層呼叫獲取到 ApplicationPackageManager 物件。

PackageManagerService.resolveIntent() -> queryIntentActivities()
//獲取 intent 所指向的 Activity 資訊，並儲存到 Intent 物件。

PackageManagerService.chooseBestActivity()
//當存在多個滿足條件的 Activity 則會彈框讓使用者來選擇。

ActivityStackSupervisor.startActivityLocked()
//獲取到呼叫者的程序資訊。 通過 Intent.FLAG_ACTIVITY_FORWARD_RESULT 判斷是否需要進行 startActivityForResult 處理。 
//檢查呼叫者是否有許可權來呼叫指定的 Activity。 
//建立 ActivityRecord 物件，並檢查是否執行 App 切換。

ActivityStackSupervisor.startActivityUncheckedLocked() -> startActivityLocked()
//進行對 launchMode 的處理[可參考 Activity 啟動模式]，建立 Task 等操作。
//啟動 Activity 所在程序，已存在則直接 onResume()，不存在則建立 Activity 並處理是否觸發 onNewIntent()。

ActivityStack.resumeTopActivityInnerLocked()
//找到 resume 狀態的 Activity，執行 startPausingLocked() 暫停該 Activity，同時暫停所有處於後臺棧的 Activity，找不到 resume 狀態的 Activity 則回桌面。
//如果需要啟動的 Activity 程序已存在，直接設定 Activity 狀態為 resumed。 呼叫下面方法。

ActivityStackSupervisor.startSpecificActivityLocked()
//程序存在呼叫 realStartActivityLocked() 啟動 Activity，程序不存在則呼叫下面方法。

fork 新程序

從 Launcher 點選圖示，如果應用沒有啟動過，則會 fork 一個新程序。建立新程序的時候，ActivityManagerService 會儲存一個 ProcessRecord 資訊，Activity 應用程式中的AndroidManifest.xml 配置檔案中，我們沒有指定 Application 標籤的 process 屬性，系統就會預設使用 package 的名稱。每一個應用程式都有自己的 uid，因此，這裡 uid + process 的組合就可以為每一個應用程式建立一個 ProcessRecord。每次在新建新程序前的時候會先判斷這個 ProcessRecord 是否已存在，如果已經存在就不會新建程序了，這就屬於應用內開啟 Activity 的過程了。

ActivityManagerService.startProcessLocked()
//程序不存在請求 Zygote 建立新程序。 建立成功後切換到新程序。

程序建立成功切換至 App 程序，進入 app 程序後將 ActivityThread 類載入到新程序，並呼叫 ActivityThread.main() 方法

ActivityThread.main()
//建立主執行緒的 Looper 物件，建立 ActivityThread 物件，ActivityThread.attach() 建立 Binder 通道，開啟 Looper.loop() 訊息迴圈。

ActivityThread.attach()
//開啟虛擬機器各項功能，建立 ActivityManagerProxy 物件，呼叫基於 IActivityManager 介面的 Binder 通道 ActivityManagerProxy.attachApplication()。

ActivityManagerProxy.attachApplication()
//傳送 ATTACH_APPLICATION_TRANSACTION 命令

此時只建立了應用程式的 ActivityThread 和 ApplicationThread，和開啟了 Handler 訊息迴圈機制，其他的都還未建立， ActivityThread.attach(false) 又會最終到 ActivityMangerService 的 attachApplication，這個工程其實是將本地的 ApplicationThread 傳遞到 ActivityMangerService。然後 ActivityMangerService 就可以通過 ApplicationThread 的代理 ApplicationThreadProxy 來呼叫應用程式 ApplicationThread.bindApplication，通知應用程式的 ApplicationThread 已和 ActivityMangerService 繫結，可以不借助其他程序幫助直接通訊了。此時 Launcher 的任務也算是完成了。

在 system_server 程序中的服務端 ActivityManagerService 收到 ATTACH_APPLICATION_TRANSACTION 命令後進行處理，呼叫 attachApplication()。

ActivityMangerService.attachApplication() -> attachApplicationLocked()
//首先會獲取到程序資訊 ProcessRecord。 繫結死亡通知，移除程序啟動超時訊息。 獲取到應用 ApplicationInfo 並繫結應用 IApplicationThread.bindApplication(appInfo)。
//然後檢查 App 所需元件。

• Activity: 檢查最頂層可見的 Activity 是否等待在該程序中執行，呼叫 ActivityStackSupervisor.attachApplicationLocked()。
• Service：尋找所有需要在該程序中執行的服務，呼叫 ActiveServices.attachApplicationLocked()。
• Broadcast：檢查是否在這個程序中有下一個廣播接收者，呼叫 sendPendingBroadcastsLocked()。

此處討論 Activity 的啟動過程，只討論 ActivityStackSupervisor.attachApplicationLocked() 方法。

ActivityStackSupervisor.attachApplicationLocked() -> realStartActivityLocked()
//將該程序設定為前臺程序 PROCESS_STATE_TOP，呼叫 ApplicationThreadProxy.scheduleLaunchActivity()。

ApplicationThreadProxy.scheduleLaunchActivity()
//傳送 SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION 命令

傳送送完 SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION 命令，還會發送 BIND_APPLICATION_TRANSACTION 命令來建立 Application。

ApplicationThreadProxy.bindApplication()
//傳送 BIND_APPLICATION_TRANSACTION 命令

App 程序初始化

在 app 程序中，收到 BIND_APPLICATION_TRANSACTION 命令後呼叫 ActivityThread.bindApplication()。

ActivityThread.bindApplication()
//快取 Service，初始化 AppBindData，傳送訊息 H.BIND_APPLICATION。

ApplicationThreadProxy.bindApplication(…) 會傳來這個應用的一些資訊，如ApplicationInfo，Configuration 等，在 ApplicationThread.bindApplication 裡會待資訊封裝成A ppBindData，通過

sendMessage(H.BIND_APPLICATION, data)

將資訊放到應用裡的訊息佇列裡，通過 Handler 訊息機制，在 ActivityThread.handleMeaasge 裡處理 H.BIND_APPLICATION 的資訊，呼叫 AplicationThread.handleBindApplication。

handleBindApplication(AppBindData data) {
    Process.setArgV0(data.processName);//設定程序名
    ...
    //初始化 mInstrumentation
    if(data.mInstrumentation!=null) {
        mInstrumentation = (Instrumentation) cl.loadClass(data.instrumentationName.getClassName()).newInstance();
    } else {
        mInstrumentation = new Instrumentation();
    }
    //建立Application，data.info 是個 LoadedApk 物件。
    Application app = data.info.makeApplication(data.restrictedBackupMode, null);
    mInitialApplication = app;
    //呼叫 Application 的 onCreate()方法。
    mInstrumentation.callApplicationOnCreate(app);
}

public Application makeApplication(boolean forceDefaultAppClass,Instrumentation instrumentation) {

    if (mApplication != null) {   
       return mApplication;
    }

    String appClass = mApplicationInfo.className;
    java.lang.ClassLoader cl = getClassLoader();

    //此時新建一個 Application 的 ContextImpl 物件，
    ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);

    //通過在 handleBindApplication 建立的 mInstrumentation 物件新建一個 Application 物件，同時進行 attach。
    app = mActivityThread.mInstrumentation.newApplication(cl, appClass, appContext);
    appContext.setOuterContext(app);
}

//設定程序名，獲取 LoadedApk 物件，建立 ContextImpl 上下文
//LoadedApk.makeApplication() 建立 Application 物件，呼叫 Application.onCreate() 方法。

Instrumentation：

public Application newApplication(ClassLoader cl, String className, Context context) {    
    return newApplication(cl.loadClass(className), context);
}
Instrumentation類：
static public Application newApplication(Class<?> clazz, Context context)  {
    //例項化 Application
    Application app = (Application)clazz.newInstance();     

    // Application 和 context繫結
    app.attach(context);    
    return app;
}
//attach 就是將新建的 ContextImpl 賦值到 mBase，這個 ContextImpl 物件就是所有Application 內 Context 的具體實現，同時賦值一些其他的資訊如 mLoadedApk。
final void attach(Context context) {    
    mBase = base;  
    mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
}

這時 Application 就建立好了，這點很重要，很多資料裡說 Application 是在performLaunchActivity() 裡建立的，因為 performLaunchActivity() 也有mInstrumentation.newApplication 這個呼叫，newApplication() 函式中可看出會先判斷是否以及建立了 Application，如果之前已經建立，就返回已建立的 Application 物件。

Activity 啟動

上面 fork 程序時會發送 SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION 命令，在 app 程序中，收到 SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION 命令後呼叫 ApplicationThread.scheduleLaunchActivity()。

ApplicationThread.scheduleLaunchActivity()
//傳送訊息 H.LAUNCH_ACTIVITY。

sendMessage(H.LAUNCH_ACTIVITY, r);

ActivityThread.handleLaunchActivity()
//最終回撥目標 Activity 的 onConfigurationChanged()，初始化 WindowManagerService。
//呼叫 ActivityThread.performLaunchActivity()

ActivityThread.performLaunchActivity() {
    //類似 Application 的建立過程，通過 classLoader 載入到 activity.
    activity = mInstrumentation.newActivity(classLoader, 
               component.getClassName(), r.intent);
    //因為 Activity 有介面，所以其 Context 是 ContextThemeWrapper 型別，但實現類仍是ContextImpl.
    Context appContext = createBaseContextForActivity(r, activity);
    activity.attach(context,mInstrumentation,application,...);
    //與 Window 進行關聯

    //attach 後呼叫 activity 的 onCreate()方法。
    mInstrumentation.callActivityOnCreate(activity,...)

}
//在ActivityThread.handleLaunchActivity裡，接著呼叫

Activity.performCreate() -> onCreate()
//最終回撥目標 Activity 的 onCreate()。

Activity.setContentView()
//設定 layout 佈局

ActivityThread.performResumeActivity()
//最終回撥目標 Activity 的 onResume()。

總結

Activity 的整體啟動流程如圖所示：

• ActivityThread 是什麼，它是一個執行緒嗎，如何被啟動的？

它不是一個執行緒，它是執行在 App 程序中的主執行緒中的一個方法中。當 App 程序建立時會執行 ActivityThread.main()，ActivityThread.main() 首先會建立 Looper 執行 Looper.prepareMainLooper()；然後建立 ActivityThread 並呼叫 ActivityThread.attach() 方法告訴 ActivityManagerService 我們建立了一個應用 並將 ApplicationThread 傳給 ActivityManagerService；最後呼叫 Looper.loop()。

• ActivityClientRecord 與 ActivityRecord 是什麼？

記錄 Activity 相關資訊，比如：Window，configuration，ActivityInfo 等。
ActivityClientRecord 是客戶端的，ActivityRecord 是 ActivityManagerService 服務端的。

• Context 是什麼，ContextImpl，ContextWapper 是什麼？

Context 定義了 App 程序的相關環境，Context 是一個介面，ContextImpl 是子類，ContextWapper 是具體實現。

應用資源是在 Application 初始化的時候，也就是建立 Application，ContextImpl 的時候，ContextImpl 就包含這個路徑，主要就是對就是 ResourcesManager 這個單例的引用。

可以看出每次建立 Application 和 Acitvity 以及 Service 時就會有一個 ContextImpl 例項，ContentProvider 和B roadcastReceiver 的 Context 是其他地方傳入的。

所以 Context 數量 = Application 數量 + Activity 數量 + Service 數量，單程序情況下 Application 數量就是 1。

• Instrumentation 是什麼？

管理著元件Application,Activity，Service等的建立，生命週期呼叫。

• Application 是什麼，什麼時候建立的，每個應用程式有幾個 Application？

Application 是在 ActivityThread.handleBindApplication() 中建立的，一個程序只會建立一個 Application，但是一個應用如果有多個程序就會建立多個 Application 物件。

• 點選 Launcher 啟動 Activity 和應用內部啟動 Activity 的區別？

點選 Launcher 時會建立一個新程序來開啟 Activity，而應用內開啟 Activity，如果 Activity 不指定新程序，將在原來程序開啟，是否開啟新程序實在 ActivityManagerService 進行控制的，上面分析得到，每次開啟新程序時會儲存程序資訊，預設為 應用包名 + 應用UID，開啟 Activity 時會檢查請求方的資訊來判斷是否需要新開程序。Launcher 開啟 Activity 預設 ACTIVITY_NEW_TASK，新開一個 Activity 棧來儲存 Activity 的資訊。

• Activity 啟動過程，onCreate()，onResume() 回撥時機及具體作用？

Activity.onCreate() 完成了 App 程序，Application，Activity 的建立，呼叫 setContentView() 給 Activity 設定了 layout 佈局。

Activity.onResume() 完成了 Activity 中 Window 與 WindowManager 的關聯，並對所有子 View 進行渲染並顯示。

參考資料

更多文章