Android核心分析（21）—-Android應用程式框架之AndroidApplication

Android Application

    Android提供給開發程式員的概念空間中Application只是一個鬆散的表徵概念，沒有多少實質上的表徵。在Android實際空間中看不到實際意義上的應用程式的概念,即使有一個叫Application的類，這個也就是個應用程式上下文狀態，是一個極度弱化的概念。Application只是一個空間範疇的概念，Application就是Activity，Service之類的組件上下文描述。Application並不是Android的核心概念，而Activity才是Android的核心概念。

    從Android的SDK文檔中，我們知道一般情況Android應用程式是由以下四種組件構造而成的：Activity，Broadcast Intent Receiver，服務（Service），內容提供器（Content Provider）。我們可以使用下面的圖來表示一下Android的概念空間。這些組件依附於應用程式中，應用程式並不會一開始就建立起來，而是在這些組件建立起來後，需要運行時，才開始建立應用程式物件。

2.1應用進程名稱

    為什麼要從應用進程名稱開始？作為核心研究，我們還是回到問題的最本質處：不管Activity，Service等組件如何設計和運行，它要提供服務，就必須要依附在Linux的進程上，建立訊息迴圈，組件才能夠真正的運作。Activity執行個體是如何Hosting在Linux進程上的？這個是我們首先想要弄明白的。

我們在的項目中看到android:process="string"這個定義。

allowClearUserData=["true" | "false"]
android:allowTaskReparenting=["true" | "false"]
android:backupAgent="string"
…

android:label="string resource"
android:manageSpaceActivity="string"
android:name="string"
android:permission="string"
android:persistent=["true" | "false"]
android:process="string"
android:restoreAnyVersion=["true" | "false"]
android:taskAffinity="string"
android:theme="resource or theme" >
    . . .

在SDK用已經描述的很清楚到了。

android:process

The name of a process where all components of the application should run. Each component can override this default by setting its own process attribute.

By default, Android creates a process for an application when the first of its components needs to run. All components then run in that process. The name of the default process matches the package name set by the element.

By setting this attribute to a process name that's shared with another application, you can arrange for components of both applications to run in the same process — but only if the two applications also share a user ID and be signed with the same certificate.

為什麼要提出這麼一個定義？android:process名稱。

    預設狀態下，Activity Manager Service在應用程式的第一個組件需要運行時將會為應用程式建立一個進程，而這個進程的名字就是android:process=”string”所指定，預設的是應用程式套件組合的名字。該進程一旦建立，後面的該應用的組件都將運行在該進程中，他們綁定的根據就是這個Android：Process指定的名稱，因為在他們都在同一個應用程式套件組合裡，也就具有了同樣的進程名字，於是他們都託管在了同一進程中。組件將通過ClassLoader從Package中擷取到應用程式的資訊。

    在建立Actvitiy時，如果在應用進程端沒有應用對象，系統在該過程中利用makeApplication建立一個Application對象，執行個體化"android.app.Application"，建立一個應用程式上下文完成例如資源，package等資訊管理。

2.2  ActivityThread運行架構

    在分析中，我們可以看到真正對應應用進程的不是Application而是ActivityThread。我們從實際的應用堆棧可以看到：

NaiveStart.main()

        ZygoteInit.main

           ZygoteInit$MethodAndArgsCall.run

              Method.Invoke

                                       method.invokeNative

                     ActivityThread.main()

                         Looper.loop()

                                                                 ....

    每個應用程式都以ActivityThread.main()為入口進入到訊息迴圈處理。對於一個進程來講，我們需要這個閉合的處理架構。

    ActivitiyThread是應用程式概念空間的重要概念，他建立了應用進程啟動並執行架構，並提供了一個IActivityThread介面作為與Activity Manager Service的通訊介面.通過該介面AMS可以將Activity的狀態變化傳遞到用戶端的Activity對象。

2．3 ActivitiyThread的建立

為了敘述的方便我將Actvitiy Manager Service簡寫成AMS。

    在AMS中關於應用程式的概念是ProcessRecord，請求都是從Activity，Service…等開始的，在Activity需要Resume時，此時如果與Activity相關的應用進程沒有起來，AM則啟動應用進程。

AMS與應用進程的綁定分為兩個部分，第一部分就是AM建立應用進程，第二部分就是應用進程Attach到AM，與AM建立通訊通道。

1）建立建立進程：startProcessLocked(processName,Appinfo.uid)。該函數在StartSecificActivityLocked等調用。

（1）建立ProcessRecord對象app,並將該對象添加到mProcessNames中。應用對象在mProcessNames中使用應用程式名稱字和uid來標識自己。如果在同一個Package中的Activity,如果都使用預設設定，那麼這些Activity都會託管在同一個進程中，這是因為他們在帶的ApplicationInfo中的ProcessName都是一樣的。

 

mPidsSelfLocked數組記錄了PID，這個將會在應用進程跑起來後，將自己Attach到AM時，根據pid找到自己的前世：ProcessRecord.

2）android.app.ActivityThread進程啟動

     Android.app.ActivityThread進程建立後，將跳入到ActivityThread的main函數開始運行，進入訊息迴圈。

    應用進程使用thread.attach()發起AMS的AttachApplicationLocked調用，並傳遞 ActvitiyThread對象和CallingPid。AttachApplicationLocked將根據CallingPid在mPidsSelfLocked找到對應的ProcessRecord執行個體app,將ActvitiyThread放置app.thread中。這樣應用進程和AMS建立起來雙向串連。AM可以使用AIDL介面，通過app.thread可以訪問應用進程的對象。

    應用程式通過ActivityThread提供的架構，建立訊息迴圈Looper和Handler。從前面的相關章節我們知道有Looper和Handler,整個系統就可以運作了。

為了更為系統的瞭解應用程式的建立時序及其涉及到資料操作，我給出了應用進程的建立過程：