Android ActivitiyThread的建立

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

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

       應用進程名稱

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

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

java代碼：
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" >

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

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

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

        ActivityThread運行框架

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

java代碼：
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對象。

       ActivitiyThread的建立

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

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

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

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

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

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

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