Android应用程序框架

   Android的应用框架的外特性空间的描述在SDK文档（http://androidappdocs.appspot.com/guide/topics/fundamentals.html#acttask）有十分清楚的描述，Android应用的基本概念，组件生命周期等等有详细的描述。在外特性空间中，Android提供了Activity,Service,Broadcast receivers，Content Provider,Intent，task等概念，我在这里不讨论这些概念定义，因为SDK文档已经讲得够详细。

在阅读SDK文档和研究Activity这个概念时，我感觉到了在Android中若隐若现的Android自由无边界这个设计意图。Android的应用只是一个虚的概念，并没有实际的入口，这个不像Window平台上的应用程序的概念，Android更多的是提供组件（Components）的概念。为什么要虚化应用的概念？我想这个虚化就是自由无边界设计意图的直接体现。突出请求和服务，突出组件个体，弱化边界，系统的各个组件可以自由的无边界的交流，服务请求者直接发出请求，不论这个对象在何处和属于谁的，组件是自由独立的个体，一个应用程序可以直接请求使用其他的应用的的组件，这个是Android应用框架设计的核心理念，其他的一切都是在为这个核心理念服务。

    让程序员忽略应用的概念，甚至彻底的抛弃进程这样的概念，程序员看到的就是一个一个的组件，应用程序员利用这些组件来架构成一个所谓的应用，那么设计者首先要考虑的是什么呢？我想应该是一个抽象的应用模型，在这个模型下产生概念和接口。

    我们知道MicroSoft提出了Application，Windows的概念，有前景应用（Foreground Application）概念，MicroSoft的应用模型中用户交互则完全交给了Window，各种界面的呈现都是属于这个应用的是孤立的，应用程序之间的各个构成对象不能相互访问，最多提供一个进程间通讯机制，那个也是应用程序层面的。虽然Microsoft后来也提出了组件，分布式组件等概念，但是这些不是根植在Windows系统中，而Android则是彻底的组件化思想构建，一开始的应用程序概念就是Activity，Service,Broadcast receivers，Content Provider,Intent，Task。这些概念体现了一个人机交互的模型本质：

界面呈现

发起请求,响应请求

内容交互

消息接收处理

 

Activity是Android应用的核心概念，简而言之Activity为用户交互管理者，有一个可视界面呈现，而Service跟Activity的区别是他在后台运行，没有界面呈现。而Intent的意义是意图，他在Android的概念空间中，代表消息，这个消息代表了请求的意图。

    Activity可以到处存在，提供服务，消除空间差别，Activity是一个独立的个体，更能表现面向对象的实质。这个个体需要接受另外的个体的消息，可以随时发起对另外一个个体的请求。个体是自由的，Android中你可以开始一个Activity，但是没有权利消灭一个Activity，这是个体权利的体现，个体的消灭是由系统决定的，这个就是Android中Activity蕴含的人文意义。

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"这个定义。

    <="" font="">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用已经描述的很清楚到了。

  默认状态下，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,整个系统就可以运作了。

为了更为系统的了解应用程序的建立时序及其涉及到数据操作，我给出了应用进程的建立过程示意图：

3.1 外特性空间的Activity

    我们先来看看，Android应用开发人员接触的外特性空间中的Activity，对于AMS来讲，这个Activity就是客服端的Activity。应用程序员在建立Android应用时，构建Activity的子类就是Andoid外特性空间展现的接口。我们可以从下面的简单的例子描述看看Activity，到底如何建立的。

DemoActivity extend Activity

{

     onCreate

    onResume

    onPause

    onStop

}

    在Android的外特性空间(SDK)中，Android应用程序员根本不知道进程是什么时候起来的，系统消息是如何传递过来的。这个DemoActivity是如何实例化的呢？并且该Activity是托管在哪个进程的呢？本节的分析将给出答案。

我们从ActivityThread中可以看到在应用进程中的Activity都被放置在mActivities中。

这些ActivityRecord记录了应用进程中，程序员建立的Activity子类的实例，我们称之为外特性空间的Activity。这些Activity类实例是放在应用程序端进行实际交互的Activity，而为了管理这些Activity，AMS内核中还有一个影子Activity，被称为HistoryRecord。

3.2 Activity与HistoryRecord的关系

     在整个系统中，Activity实际上有两个实体。一个在应用进程中跟应用程序员打交道的Activity，一个是在AMS的中具有管理功能的History Record。应用进程中的Activity都登记ActivityThread实例中的mActivity数组中，而在AM端，HistroytRecord实例放置在mHistroy栈中。mHistory栈是Android管理Activity的场所，放置在栈顶的就是User看到的处于活动状态的Activity。

Activity与HistrotyRecord的关系图可以表示如下：

Activity的内核实体是依靠在ProcessRecord的成员变量中，通过ProcessRecord我们可以访问到所有的属于该Process的Activity。而在ProcessRecord记录了与应用进程之间的联系：IActivtityThread接口。通过该接口，可以访问到所对应的Activity的方法。在Launch Activity时，AMS将对应的HistoryRecord作为token传递到客服端和客服端的Activity建立联系。在AMS中Activity状态变化时，将通过该联系找到客服端的Activity，从而将消息或者动作传递应用程序面对的接口：xxxActivity。

3.3 Actvity的Launch过程

1)发起请求startActivity(intent)

2）Activity Service Manager接收到请求执行StartActivity函数。

      建立：HistoryRecord实例r.

      将r 加入到mHistory顶。

（3）通过app.thread.scheduleLaunchActvity(app,r)@ActivityThread.java

（4）在App应用中建立新的ActivityRecord。

（5）建立新的Activity对象并放入到ActivityRecord中。

（6）将ActivityRecord加入到mActivites@ActivityThread

(7)发起Activity.onCreate(..),,该onCreate就是在你的应用程序XXXActivity中的onCreate。

3.4 Activity的Resume

（1）Activity什么时候被Resume

（2）Rusume的过程

    通过该过程的研究我们会进一步的了解到AMS与应用进程的交互过程。

在AMS端，满足resume条件都会调用： Resume的核心函数：

resumeTopActivityLocked@ActivityManagerService

XXX当前栈顶的HistroyRecord

1）窗口切换：隐藏前一个Activity的窗口，

2）更新LRUList，（LRUList是淘汰应用程序的依据之一）

3) XXX.app.thread.scheduleResumeActivity(XXX,

                        isNextTransitionForward());

4)completeResumeLocked

     setFocusedActivityLocked

        mFocusActivity=xxx  //此时焦点Actvitiy切换了。

       WM.setFocusedApp(xxx,

       mWindowManager.executeAppTransition();

       mNoAnimActivities.clear();

在应用程序端：

（5）scheduleResumeActivity

handleResumeActivity(IBinder token, boolean clearHide, boolean isForward) {

ActivityRecord r = performResumeActivity(token, clearHide);

     ActivityRecord r = mActivities.get(token);

     r.activity.performResume()

              performResume

整个Resume的过程如下：