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,整個系統就可以運作了。

為了更為系統的了解應用程序的建立時序及其涉及到數據操作，我給出了應用進程的建立過程示意圖：