Android ActivitiyThread的建立

原文：http://android.tgbus.com/Android/tutorial/201107/359101.shtml

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,整个系统就可以运作了。