导读：对于Android开发者来说，成系列的技术文章对他们的技术成长帮助最大。如下是我们向您强烈推荐的主题为Android开发的第一个系列文章。

《Android核心分析》整理如下：

17.电话系统之rilD

Rild是Init进程启动的一个本地服务，这个本地服务并没有使用Binder之类的通讯手段，而是采用了socket通讯这种方式。RIL(Radio Interface Layer)

Android给出了一个ril实现框架。由于Android开发者使用的Modem是不一样的，各种指令格式，初始化序列都可能不一样，GSM和CDMA就差别更大了，所以为了消除这些差别，Android设计者将ril做了一个抽象，使用一个虚拟电话的概念。这个虚拟电话对象就是GSMPhone（CDMAPhone),Phon对象所提供的功能协议，以及要求下层的支撑环境都有一个统一的描述，这个底层描述的实现就是靠RIL来完成适配。

Andoid将RIL层分为两个代码空间：RILD管理框架，AT相关的xxxril.so动态链接库。将ＲＩＬ独立成一个动态链接库的好处就是Ａｎｄｒｏｉｄ系统适应不同的Ｍｏｄｅｍ，不同的Mode可以有一个独立的Ril与之对应。从这个层面上看，Rild更多是一个管理框架。

而ril是具体的AT指令合成者和应答解析者。从最基本的功能来讲，ril建立了一个侦听Socket，等待客户端的连接，然后从该连接上读取RIL-Java成传递来的命令并转化成AT指令发送到Modem。并等待Modem的回应，然后将结果通过套接口传回到Ril-Java层。下图是Ril-D的基本框架：

下面的数据流传递描述图表描述了RIL-JAVA层发出一个电话指令的5 步曲。

在AT通讯的过程中有两类响应：一种是请求后给出应答，一种是通知类，即为不请自来的，例如短信通知达到，我们称该类通知为URC。在Rild中URC和一般的Response是分开处理的，概念上URC由handleUnsolicited@Atchannel.c处理，而Response由handleFinalResponse来处理。

1 Event Loop

Rild管理的真正精髓在ril.cpp,ril_event.cpp中，在研究的过程中，可以看到设计者在抽象上所下的功夫，设计得很优美。Event Loop的基本工作就是等待在事件端口（串口，Socket），一旦有数据到达就根据登记的Event回调函数进行处理。现在来看Ril设计者是如何建立一套管理框架来完成这些工作的？

1.1 Event对象

Event对象构成：（fd,index,persist,func,param）

fd 事件相关设备句柄。例如对于串口数据事件，fd就是相关串口的设备句柄

index

persist 如果是保持的，则不从watch_list中删除。

func 回调事件处理函数

param 回调时参数

为了统一管理事件，Android使用了三个队列：watch_list,timer_list,pending_list,并使用了一个设备句柄池readFDS。

readFDS：是Linux的fd_set，readFDS保存了Rild中所有的设备文件句柄，以便利用select函数统一的完成事件的侦听。

watch_list：监测时间队列。需要检测的事件都放入到该队列中。

timer_list：timer队列

pending_list:待处理事件队列，事件已经触发，需要所回调处理的事件。

事件队列队列的操作：ril_event_add,ril_event_del, ril_timer_add

在添加操作中，有两个动作：

(1) 加入到watch_list

(2) 将句柄加入到readFDS事件句柄池。

1.2 ril_event_loop()

我们知道对于Linux设备来讲，我们可以使用select函数等待在FDS上,只要FDS中记录的设备有数据到来，select就会设置相应的标志位并返回。readFDS记录了所有的事件相关设备句柄。readFDS中句柄是在在AddEvent加入的。所有的事件侦听都是建立在linux的select readFDS基础上。

ril_event_loop 利用select等待在readFDS（fd_set）上，当select设备有数据时，ril_event_loop会从select返回，在watch_list中相应的Event放置到pend_list，如果Event是持久性的则不从watch_list中删除。然后ril_event_loop遍历pengding_list处理Event事件，发起事件回调函数。

1.3 几个重要的Event

上面分析了ril-d的框架，在该框架上跑的事件有什么

（1）s_listen_event- （s_fdListen,listenCallback）

listenCallback处理函数，

接收客户端连接：s_fdCommand=accepte(..)

添加s_commands_event()

重新建立s_listen_event，等待下一次连接

（2） s_command_event(s_fdCommand,ProcessCommandsCallback)

从fdCommand Socket连接中读取StreamRecord

使用ProcessCommandBufer处理数据

s_listen_event在大的功能上处理客户端连接（Ril-JAVA层发起的connect）,并建立s_commands_event去处理Socket连接发来的Ril命令。ProcessCommandBufer实际上包含了Ril指令的下行过程。

1.4 下行命令翻译及其组织@ProcessCommandBuffer

RIL_JAVA传递的命令格式：Parcel ，由命令号，令牌，内容组成。RIL_JAVA到达RIL_C时转为构建本地RequestInfo，并将被翻译成具体的AT指令。由于每条AT命令的参数是不同的，所以对不同的AT指令，有不同的转换函数，在此Android设计在这里做了一个抽象，做了一个分发框架，通过命令号，利用sCommand数组，获得该命令的处理函数。

sComand[]={

<...>

}

sComand 存在于Ril_command.h中。

&sComand[]=

<

{RIL_REQUEST_GET_IMEI, dispatchVoid, responseString},

{RIL_REQUEST_DIAL, dispatchDial, responseVoid},

{….}

>

dispatchXxx函数一般都放在在Reference-ril.c中，Reference-ril.c这个就是我们需要根据不同的Modem来修改的文件。

1.5 send_at_command框架

send_at_command是同步的，命令发送后，send_at_command将等待在s_commandcond，直到有sp_response->finalResponse。

2 read loop@Atchannel.c

Read loop是解决的问题是：解析从Modem发过来的回应。如果遇到URC则通过handleUnsolicited上报的RIL_JAVA。如果是命令的应答，则通过handleFinalResponse通知send_at_command有应答结果。

对于URC，Rild同样使用一个抽象数组@Ril.CPP.

static UnsolResponseInfo s_unsolResponses[] = {

#include "ril_unsol_commands.h"

};

并利用RIL_onUnsolicitedResponse将URC向上层发送。

3 Ril-d的整体数据流及其控制流示意图

18.Android电话系统之RIL-Java

RIL-Java在本质上就是一个RIL代理，起到一个转发的作用，是Android Java概念空间中的电话系统的起点。在RIL-D的分析中，我们知道RILD建立了一个侦听套接口，等待RIL-Java的连接。一旦连接成功，RIL-JAVA就可发起一个请求，并等待应答，并将结构发送到目标处理对象。在RIL-Java中，这个请求称为RILRequest。为了直观起见，我还是不厌其烦的给出RIL-Java的框架图。

RIL-Java的大框架包含了四个方面：

Receiver，Sender，CommandInterface，异步通知机制

（1） Command Interface

在ril.java源代码中，我们可以看到RIL-JAVA对象提供了如下的Command Interface：

…

getlccCardStatus

getCurrrentCalls

dial

acceptCall

rejectCall

sendDTMF

sendSMS

setupDataCall

setRadioPower

…

为什么要定义这些接口呢？这函数接口不是凭空捏造出来的，这些都是电话的基本功能的描述，是对Modem AT指令的提炼抽象。大多数Modem都是根据通讯协议提供接口，我们如果不熟悉通讯协议，请参阅3GPP的相关文档，以及自己使用的Modem的SPEC说明。

V.25ter AT Commands

3GPP 07.07 AT Comamnds-General commands

3GPP 07.07 AT Comamnds-Call Control commans

3GPP 07.07 AT Comamnds-Network Service related commands

3GPP 07.07 AT Comamnds-MT control and status command

3GPP 07.07 AT Comamnds-GPRS Commands

3GPP 07.07 Mobile Termination Errors

3GPP 07.05 SMS AT Commands

（2）Receiver

Receiver连接到RILD的服务套接口，接收读取RILD传递过来的Response Parcel。Response分为两种类型，一种是URC，一种是命令应答。对于URC将会直接分发到通知注册表中的Handler。而命令应答则通过Receiver的异步通知机制传递到命令的发送者进行相应处理。

（3）Sender

Sender应该分为两部分架构，

上层函数调用Command Interface将请求消息发送到Sender的架构。

Sender接收到EVENT_SEND消息后，将请求发送到RILD的架构。

（4）异步应答框架

对于异步应答来讲，命令的发起者发送后，并不等待应答就返回，应答的回应是异步的，处理结果通过消息的方式返回。站在设计者的角度思考如何设计合适的框架来完成异步通讯的功能呢？对于异步系统我们首先应该考虑的是如何标识命令和结果，让命令和结果有一个对应关系，还有命令没有响应了，如何管理命令超时？让我们来看看Android设计者如何完成这些工作。

Android设计者利用了Result Message 和RILRequest对象来完成Request和Result的对应对于关系。在上层做调用的时候生成Result Message对象传递到ril_java，并在Modem有应答后，通过Result Message对象带回结果。如何保证该应答是该RILRequest的呢？Android设计者还提供了一个Token（令牌）的概念。在源代码中RILRequest的mSerail就用作了Token。Token用来唯一标识每次发送的请求，并且Token将被传递到RILD，RILD在组装应答是将Token写入，并传回到ril-java，ril-java根据该Token找到相应的Request对象。

（4.1）RIL命令的发送模式

协议的真正实现是在rild中，RIL-JAVA更多的是一个抽象和代理，我们在研究源代码的过程中就会体会到到RIL-JAVA中的命令函数都有一个共同的框架。

SendXxxCmd(传入参数Data，传出参数result){

组合RILRequest(请求号，result，mSerail)

Data->RR

send(RILRequest)： Message

}

1)RILRequest

请求号：

request将传递到RILD用以标识命令，request代表某个功能。例如拨叫的request号为：RIL_REQUEST_DIAL。在libs/telephony/ril_commands.h有定义。RILRequest.obtain@RILRequest根据命令请求号,传入参数Result Message，mSerail构造了一个RILRequest。Result Message将带回应答信息回到命令的发起者。

mSerail：

Android使用了一个RILRequest对象池来管理Andoird RILRequest。mSerail是一个递增的变量，用来唯一标识一个RILRequest。在发送时正是用了该变量为Token,在rild层看到的token就是该mSerail。

EVENT_END:

EVENT_END@handleMessage@RILSender@RIL.java

2)发送步骤：

第一步：

生成RILRequest，此时将生成m_Serial（请求的Token)并将请求号，数据，及其Result Message 对象填入到RILRequest中

第二步：

使用send将RILRequest打包到EVENT_SEND消息中发送到到RIL Sender Handler，

第三步：

RilSender 接收到EVENT_SEND消息，将RILRequest通过套接口发送到RILD，同时将RILRequest保存在mRequest中以便应答消息的返回。

（4.2） 接收模式

第一步：分析接收到的Parcel，根据类型不同进行处理。

第二步：根据数据中的Token（mSerail),反查mRequest,找到对应的请求信息。

第三步：将是数据转换成结果数据。

第四步：将结果放在RequestMessage中发回到请求的发起者。

4.3)详细的GSMCallTracker,RIL-Java函数对照

19.电话系统之GSMCallTacker

通话连接管理

GSMCallTracker在本质上是一个Handler。

GSMCallTracker是Android的通话管理层。GSMCallTracker建立了ConnectionList来管理现行的通话连接，并向上层提供电话调用接口。

在GSMCallTracker中维护着通话列表：connections。顺序记录了正连接上的通话，这些通话包括：ACTIVE，DIALING，ALERTING，HOLDING，INCOMING，WAITING等状态的连接。GSMCallTracker将这些连接分为了三类别进行管理：

RingingCall: INCOMING ,WAITING

ForegourndCall: ACTIVE, DIALING ,ALERTING

BackgroundCall: HOLDING

上层函数通过getRingCall()，getForegrouandCall()等来获得电话系统中特定通话连接。

为了管理电话状态，GSMCallTracker在构造时就将自己登记到了电话状态变化通知表中。RIL-Java一收到电话状态变化的通知，就会使用EVENT_CALL_STATE_CHANGE通知到GSMCallTacker

在一般的实现中，我们的通话Call Table是通过AT+CLCC查询到的，CPI可以通知到电话的改变，但是CPI在各个Modem的实现中差别比较大，所以参考设计都没有用到CPI这样的电话连接改变通知，而是使用最为传统的CLCC查询CALL TABLE。在GSMTracker中使用connections来管理Android电话系统中的通话连接。每次电话状态发生变化是GSMTracker就会使用CLCC查询来更新connections内容，如果内容有发生变化，则向上层发起电话状态改变的通知。

1 RIL-JAVA中发起电话连接列表操作

在RIL-JAVA中涉及到CurrentCallList查询的有以下几个操作：

（1）hangup

（2）dial

（3）acceptCall

（4）rejectCall

在GSMcallTracker在发起这些调用的时候都有一个共同的ResultMessage构造函数：obtainCompleteMessage()。obtainCompleteMessage()实际上是调用：

obtainCompleteMessage(EVENT_OPERATION_COMPLETE)

这就意味着在这些电话操作后，GSMCallTracker会收到EVENT_OPERATION_COMPLETE消息，于是我们将目光转移到handleMessage()@GSMCallTracker的EVENT_OPERATION_COMPLETE事件处理：operationComplete@GSMCallTracker。

operationComplete（）操作会使用cm.getCurrentCalls(lastRelevantPoll)调用，向RILD发起RIL_REQUEST_GET_CURRENT_CALLS调用，这个最终就是向Modem发起AT+CLCC，获取到真正的电话列表。

2 在RILD中，引起getCurrentCalls调用

（1）在RILD中，收到URC消息：

+CRING

RING

NO CARRIER

+CCWA

将会使用RIL_onUnsolicitedResponse( RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED)，主动向ril-java上报RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED消息。

（2） 在处理requestCurrentCalls时，使用CLCC查询通话连接（CALL TABLE）后，如何发现有call Table不为空则开启一个定时器，主动上报RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED消息，直到没有电话连接为止。

在RIL-Java层收到RIL_UNSOL_RESPONSE_CALL_STATE_CHANGED这个URC，并利用mCallStateRegistrants.notifyRegistrants(new AsyncResult(null, null, null))来通知电话状态的变化，此时GSMTracker会接收到EVENT_CALL_STATE_CHANGE消息，并使用

pollCallsWhenSafe()-> cm.getCurrentCalls(lastRelevantPoll);

来发起查询，并更新JAVA层的电话列表。

3 handlePollCalls电话列表刷新

首先我们来看看是什么引起了handlePollCalls的调用。

上面的1,2分析了，Android电话系统中所有引起电话连接列表更新的条件及其处理。他们共同的调用了cm.getCurrentCalls(lastRelevantPoll) 来完成电话列表的获取。

lastRelevantPoll = obtainMessage(EVENT_POLL_CALLS_RESULT)

我们这里就从可以看到获取到的电话列表Result使用handlePollCalls进行了处理。Result实际上是一个DriverCall列表，handlePollCalls的工作就是将当前电话列表与RIL-Java的电话列表对比，使用DriverCall列表更新CallTracker的电话列表connections,并向上传递电话状态改变的通知。

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蕴含的人文意义。

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

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

22.Android应用框架之Activity

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

23.Andoird GDI之基本原理及其总体框架

在Android中所涉及的概念和代码最多，最繁杂的就是GDI相关的代码了。但是本质从抽象上来讲，这么多的代码和框架就干了一件事情：对显示缓冲区的操作和管理。

GDI主要管理图形图像的输出,从整体方向上来看,GDI可以被认为是一个物理屏幕使用的管理器。因为在实际的产品中，我们需要在物理屏幕上输出不同的窗口，而每个窗口认为自己独占屏幕的使用，对所有窗口输出，应用程序不会关心物理屏幕是否被别的窗口占用，而只是关心自己在本窗口的输出，至于输出是否能在屏幕上看见，则需要GDI来管理。

从最上层到最底层的数据流的分析可以看到实际上GDI在上层为GUI提供一个抽象的概念,就好像操作系统中的文件系统所提供文件，目录等抽象概念一样，GDI输出抽象成了文本,画笔,位图操作等设备无关的操作,让应用程序员只需要面对逻辑的设备上下文进行输出操作,而不要涉及到具体输出设备,以及输出边界的管理。GDI负责将文本、线条、位图等概念对象映射到具体的物理设备，所以GDI的在大体方向上可以分为以下几大要素：

• 画布
• 字体
• 文本输出
• 绘画对象
• 位图输出

Android的GDI系统

Android的GDI系统所涉及到概念太多，加之使用了OpenGL使得Android的层次和代码很繁杂。但是我们对于Android的GDI系统需要了解的方面不是他的静态的代码关系，而是动态的对象关系，在逻辑运行的架构上理解GDI。我们首先还是需要从代码结构开始我们的理解。

Frameworks/Libs/Surfaceflinger

Frameworks/base/core/jni/android_view_Surface.cpp

Frameworks/base/core/java/android/view/surface.java

Frameworks/base/Graphics：绘图接口

Frameworks/Libs/Ui

External/Skia

其中External/Skia是一个C++的2D图形引擎库，Android的2D绘制系统都是建立在该基础之上.Skia完成了：文本输出，位图，点，线，图像解码等功能。

我在这里给出Android GDI的基本框架示意图。

对于上面的GDI架构图我们只是一个大概的了解，我们有太多的问题需要解决，有太多的疑问需要得到答案，我就一直在想，为什么设计者有提出如此众多的概念，这个概念的背景是什么？他要管理什么，他要抽象什么？从前面知道，Android的整个设计理念就是无边界化，他是如何穿透Linux进程这个鸿沟来达到无边界的？Surface，Canvas， Layer，LayerBase, NativeBuffer，SurfaceFlinger，SurfaceFlingerClient这些到底是一个什么东西？如何管理，传递的是什么？创建的是什么？这些都是抽象的概念，绘画的终极的缓冲区到底是如何管理的？缓冲区到底在哪里？

我们还是看看做终极的，最本质的设计概念，在从这些概念出发，来探讨这些概念的形成过程，是否有必要去生成写概念。SurfaceFlinger本质上干什么的？SurfaceFlinger的确就是这个意义：应用程序通过SurfaceFlinger将自己的“Surface”投掷到屏幕缓冲区。至于如何投掷的，我们将会在后面详细描述。