Android核心分析

分享到

Android核心分析

发布于2011-09-30

Android核心分析（20)----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核心分析（21）----Android应用框架之AndroidApplication

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

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

Android核心分析（22）-----Android应用框架之Activity

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的过程如下：