《Android平台机制深入分析 有米分享费下载.docx》由会员分享，可在线阅读，更多相关《Android平台机制深入分析 有米分享费下载.docx（99页珍藏版）》请在课桌文档上搜索。
1、Android平台机制深入分析目录Android核心分析之一分析方法论探讨之设计意图1Android核心分析之二方法论探讨之概念空间篇3Android是什么之三之硬件形态5Android核心分析之四一的软件形态6Android核心分析之五根本空间划分7Android核心分析之六IPC框架分析Binder,Service,Servicemanager.11Android核心分析之七Service深入分析21Android核心分析之八Android启动过程详解31Android核心分析之九ZygoteService36Android核心分析之十AndroidGWES之根本原理篇40Android核
2、心分析之H-,AndroidGWES之消息系统43Android核心分析(12)-AndroidGEWS窗口管理之根本架构原理48Android核心分析(13)-AndroidGWES之Android窗口管理50Android核心分析(14)AndroidGWES之输入系统57Android核心分析(15)Android输入系统之输入路径详解59Android核心分析(16)Android系统-概述篇66AndrOid核心分析(17)系统之rilD69Android核心分析(18)Android系统之RIL-JaVa76Android核心分析(19)-系统之GSMCaHTaCker.84And
3、roid核心分析(20)-Android应用程序框架之无边界设计意图87Android核心分析(21)-Android应用框架之AndroidAPPIiCation88Android核心分析(22)Android应用框架之ACtiVity93Android核心分析(24)AndroidGDI之显示缓冲管理104Android核心分析(25)AndroidGDI之共享缓冲区机制112Android核心分析(26)AndroidGDI之SUrfaCeFlinger.116Android核心分析(27)AndroidGDI之SUrfaCeFlinger之动态结构示意图.123Android核心分析(
4、28)AndroidGDI之SUrfaCe&Canvas126Android核心分析之一分析方法论探讨之设计意图分析方法论探讨之设计意图为什么要研究Android,是因为它够庞大，它够更杂，他激起了我作为一个程序员的内心的渴望，渴望理解这种复杂性。我研究的对象是作为开发平台的Android软件系统局部，而不是DaIVik虚拟机本身。作为一个从其他平台装接过来的程序员，要从事Andoid平台系统开发，我的关于平台上积累的知识已经不能满足需要了，Android为我们带来了大量的新名词，Activity,Manifest,INTENT,Service,Binder,Dalvik虚拟机，Framewo
5、rk,Linux,Navtive,JNI通过在源代码，在开发社区，在开发博客，甚至在招聘过程中，我不断的寻求AndrOid是什么。经过一定时间的沉淀，我慢慢的理解到Android不仅仅是一类的总称，不仅仅是一个开发平台，不仅仅是一个虚拟java操作系统，不仅仅是一个开发社区，一个开发标准，不仅仅是一堆代码，Android已经成了一个新的潮流。代码多，系统复杂，纵观社区中AndrOid的研究者，一开始从源代码分析AndrOid就走向迷途，不断的跋山涉水，向纵深冲刺，最终脑袋堆栈不够用，迷失在开始的旅程，或者挂在半途中，鲜有通达者。我感觉到大局部的研究者总是忘记站在高山上向下望一望设计者的意图，一
6、味的随着代码的控制流走入繁杂的谜团，陷入到复杂性的深淋I。我的研究分析是从设计者的意图出发，从抽象的甚至从哲学的高度，从最简单的系统原型开始，从设计猜想开始，而不是一开始就从代码分析展开。首先理解Android大的运行框架，主干流程，系统原型，之后再用源代码分析充实之。当然我这里的设计者意图并不是真正的Android设计者意图，而是我以为的Android设计者意图。要理解设计者意图，就需要抽象。我们需要在哲学意义空间中去考虑系统的描述，即系统在本质上要表达什么。在逻辑空间上去考虑系统根本构成和动态结构。从现实到虚拟对象的映射去理解系统对象的组成，在从数据流的角度分析数据的产生者和消费者之间作用
7、关系，从控制流的角度去分析对象之间的交互关系，从函数调用去分析具体的层次关系。在系统设计上，原型是最能表达哲学空间和逻辑空间中系统本质的东西，原型是事物本质的第一层表达。我以为任何复杂的系统都一个简洁的系统原型，都有它简洁的意义。系统原型是设计者意图的第一表达，所以我们需要从几个方向上去提炼系统原型：(1)从系统本质和根本原理出发(2)从分析系统数据流和控制流分析出发。从设计者意图出发，得出系统原型，提取到大的逻辑结构和系统构成是第一步。之后我们可以从设计者的角度考虑系统猜想系统设计，为什么要这样设计，为什么要有这些构成。这样的根本原型是什么？系统的限制是什么，应用场景有哪些，有些设计的引进还
8、是系统收敛性而为之呢。我们还可以从代码痕迹上去分析，这些概念是如何的得来的？从一定的抽象和高度去理解这些问题，遵循系统原型出发之原那么，在深入分析代码的时候，就不容易陷入细节中。我们就可以随时跳出来想，这些代码在整体上载表达一个什么概念，在描绘一个什么逻辑，他要构成一个虚拟层吗？他是在管理这个硬件吗？他在虚拟这个对象吗？他在构建管理机构？还是在构建一个对象管理？空间管理，为了快速引入了什么样的复杂算法，实际上的原型算法应该是什么样的？只有深入到这个抽象层次，我们才能很好的把握住系统的每一条线，每一个对象的意义。只用从原型出发，我们才能把握住这个系统的实质所在，在干什么？他要表达什么？设计者为什
9、么要这样想？最终极的想法是什么？这样，代码分析就变得简单明了，读代码就变成了是在印证猜想，修正方向。Android核心分析之二方法论探讨之概念空间篇方法论探讨之概念空间篇我们潜意识就不想用计算机的方式来思考问题，我们有自己的思维描述方式，越是接近我们思维描述方式，我们越容易接受和使用。各种计算机语言，建模工具，不外乎就是建立一个更接近人的思维方式的概念空间，再使用工具从该概念空间向另外一个概念空间映射，我称之为人性思维空间向Ol序列描述空间的一个映射。实现方面来看，系统就是一个翻译器，将机器性更加人性化的一种机制。大学计算机经典课”计算机体系结构，其他的可以忘记，但是下面这个图不能忘记:这个就
10、是概念空间最本质的原型表达：作为观测者看到了什么？设计者给了观察者什么？给出的答案是外部特性。(1)提供给观察者的概念空间是什么？(2)内部特性的概念空间是什么？概念空间所表达的东西带有两个方面的缠绕：一面是人性自由，一面是物性制约(实时响应，系统资源的限制)。所以程序实现的概念空间是人性自由与特定计算机系统物性之间有一个折中，并且根据实际系统而采取某种动态的平衡。而这种平衡将会影响到系统架构，以及设计的思想。特别在这样的嵌入式系统中，这种矛盾和平衡无处不在，这种折中无处不在。而对系统的选取和采用，也就接受了某个方面的折中或某中即在的，也许是看不见的标准，及这样的标准有隐式和显式的。正因为如此
11、，不管是工具的产生，新的平台的产生,都是计算机的物性向人性靠近的一个小台阶。一个新的思想的形成随即带来的新工具，新系统框架，新的体系结构。如果设计者站的高度足够高，那么设计者一开始就会考虑到“我该给他们一个什么样的概念空间，甚至一个什么样的理念，让他们这个概念空间去建立自己的产品“，于是设计者就会开始主动的去建立概念空间，这个概念空间要表达的实际意义，概念空间应该有哪些内容构成，考虑概念空间的完备性和封闭性，考虑概念空间的边界，考虑从哪个根底上建立这个概念空间，考虑如何与概念空间外的实体进行交互，考虑系统的资源限制条件，考虑功能性构建的合理性，考虑机器系统与人的平衡问题。我们在学习新系统时，首
12、先映入眼帘的就是新概念。新名词，就如现在我们面临的Android大量的新名词，在程序员的世界都是从代码实践开始的，是从写应用开始去涉及。SDK给了我们一个概念，我们就在这个概念框架下，使用SDK给我提供的函数接口，数据结构，初始化过程等，我们最初的接触到原型就是HelloWorld之类的DEMo程序，我们在Helloworld上去使用各种不同的接口函数，对于应用程序员来讲,他说看到的系统就是系统调用接口，及其编程开发流程。实际上只要一使用这些接口，就不得不接受一系列的概念，只有在这种概念系统下,我们才能工作。但是,实际上我们却忽略了这样的概念系统的理解,只是在编程接口的这个狭窄的空间去理解系统
13、.我们理解系统在形成理解概念的空间只是微小的一角，很少有资料来介绍这种概念系统的形成和理解,编程接口只是这个概念空间一个，对外部的一个表征。我们可以抽象起来，以接口，协议和行为,来描述系统的情况。SDKAPI的实质向上层提供了一个语义接口，从而在层间实现了一个转义过程，同时又成为一个功能的集合体。但是我们很少这样跳出来看，我们到底是处于一种什么样的概念空间，SDK除了调用接口外，还给了我们怎样一种整体概念？目标系统的根本构架在本质上的东西就是一个概念系统到另一个概念系统的映射。让我们大脑理解的概念系统映射到计算机能实现的概念域的一个映射。我们假定这个概念域E,机器能够理解的概念域为M,我们的软
14、件工程要做的事情实质就是：EGM领域的一个映射过程。为什么要在宏观上把握这些概念呢，显然有我的目的，理解概念空间是理解设计者意图的一个重要途径。设计者要想给开发者提供什么，设计者想要提供给最终用户什么。我们需要站在高处看待系统明白设计者意图。Android的实质还是一套管理硬件系统的软件，这个话讲起来没有多大意义,计算机操作系统本质都是如此，Andioid是GOOgIe云计算方案的一局部，我们修正成：Android建立的本质就是让计算机成为我的云接入移动智能终端。作为硬件管理软件，Android提供概念空间内涵实质上泛操作系统内涵，我们的理解可以从泛操作系统概念空间映射到Android系统中去
15、。而作为云计算的一局部的内容，我们可以云计算的概念入手去研究Andoird。一Android概念空间Andoid内特性空间Android外特性空间Android是什么之三之硬件形态硬件形态本节可能与AndrOid无关，但是Android系统现在这个阶段更多的是移动终端形态的开发平台，本节给出了Android背后的工作-AndrOid管理的硬件是什么，Android的本质就是要管理好这些硬件局部，为用户提供一个体验更好，速度更快的智能移动终端。对硬件形态的认识是要让我们对硬件组成有个感性的认识，让程序员知道系统中的代码是管理那一局部的，即我们堆破头的目的是什么，让思维有一个伸展。为了对这类嵌入式
16、系统有一个较为深入的了解，我制作了如下的硬件结构思维导图，在这张图上我们可以看到组成硬件的有哪些，初步了解到管理平台为什么要那么多的管理框架和层次，从最底层理解Android设计者的设计意图，这个思维导图其实只是不意图。mPTto动作酶岸暴无限大38检分辨室:，酸瑾淞轮巨机决口误求：.Ehll，此C匚Serial闲的H也漫耳的觉出叩i1华厉。F姿太（浬控遢俵）电单位性 百身片tie.：；PlrtT f mi,二二我们知道这种嵌入式系统，硬件架构最简单描述的描述为:应用处理器+Modem+射频对于应用处理器而言,对设计者最为本质的描述为输入输出，而对于移动终端设备电源管理,连接机制，多媒体又是很
17、重要的考虑环节，而这些环节都会在软件平台上有所表达。Android核心分析之四的软件形态的软件形态上节我给出了的硬件树，本节将给出软件形态树。主要突出软件涵盖的内容。通过该思维导图，我们可以看到软件所涉及到的方方面面，Android所涉及到的内容也不会超过下面所示太多，这个也是Andoid系统外特性空间所要展示的，这个也是Android设计者需要考虑管理的大局部内容，通过下面的整理，我们可以让我们的思维更加贴近Android设计意图，从而更深入的了解AndrOid中各种组成的由来，这个就是前面讲到的分析思想之一从退到源头出发，从思考最终极的问题开始。Android核心分析之五根本空间划分根本A
18、ndroid核心分析之五根本空间划分根本空间划分Google给了我们一张系统架构图，在这张图上我们可以看到Android的大体框架组成。ApplicationsHorneConocoPhoneBrowser.I-ApplicationFrameworkmWindowConcernVktwNocificitkyiACgtyMgEKhrarrPtovtdenSystemMaMXerLibrariesAndroidRuntimeSurcManiierMdSQUteFnfnewontCoreUbrarieiOpmCLIESFrvcTypWebKkMachSeSGLSSLlbcLinuxKernel*C
19、MnDrer三*RM常L副空C)US8MEDrMrW%Ar含七IM上从上图可以看到：AndroidApplications,ApplicationFramework,DalvikVirtualMachine,LinUXo如果将Android泛化，我们可以将系统划分成两局部：Anmd但是为了研究的方便我们先看最为本质的三层，上面是Android,中间叫DaIVik虚拟机,下面叫LinuxoAndroidMvikVm虽然上两层都包含在AndrOid中，但是为了理解的方便或者从实用主义出发，我还是将虚拟机这次给分开出来，因为我研究的对象是Android的系统相关局部，对于虚拟机我们不做太深入的研究。
20、e：prez从上面我们可以看到这个系统静态的划分成这样的三层。但是从动态运行逻辑上不是这样划分的，所以空间的划分是一个有趣的概念。我们从操作系统的角度看，Android就是一堆LinUX应用的集合。从LinUX角度看到的空间划分：进程空间和内核空间。从Android的应用对应着LinUX的一个个进程。之上，从AndrOid动态运行逻辑上我们需要将AndrOid划分成AndrOid空间和非Android空间。在AndOid系统中我们面对的是AndOid概念空间，而不是LinUX进程了，在AndOid概念空间中已经没有了LIiUX进程的概念，而是ServiCe,proxy,Activity,pro
21、vider等。设备打造的JAVA虚拟机，是一个有着自己的CodLbyte和格式的可以在嵌入式设备上高效运行的JaVa虚拟机。为了研究的深入，我们还是需要涉及到JNlNative局部。在这个分类中我将JVM分为JVM空间和C+空间。Android应用的开发者是工作在Android外特性概念空间的，这里没有了LinUX的一点气息，Android构建的外特性空间概念包含了：Activity,Provider,Interface,Events,Provider,Service等。至于JVM空间和C+空间的划分是为了研究Android核心的描述而提出的，我们在做Android系统开发时，常常需要修改到J
22、Nl的NatiVe局部。后面我将用较多的篇幅来深入阐述这个局部。Android核心分析之六IPC框架分析Binder,Service,ServicemanagerIPC框架分析Binder,Service,Servicemanager我首先从宏观的角度观察BindCr,Service,ServiceManager,并阐述各自的概念。从LinUX的概念空间中，Android的设计ACtiVity托管在不同的的进程，Service也都是托管在不同的进程,不同进程间的ACtiVity,Service之间要交换数据属于IPCoBindcr就是为了Activity通讯而设计的一个轻量级的IPC框架。在代
23、码分析中，我发现Android中只是把Binder理解成进程间通讯的实现，有点狭隘，而是应该站在公共对象请求代理这个高度来理解Binder,Service的概念，这样我们就会看到不一样的格局，从这个高度来理解设计意图，我们才会对Android中的一些天才想法感到惊奇。从Android的外特性概念空间中，我们看不到进程的概念，而是ACtivity,Service,AIDL,INTENT0一般的如果我作为设计者，在我们的根深蒂固的想法中，这些都是如下的C/S架构，客户端和效劳端直接通过BindCr交互数据，翻开Binder写入数据，通过BindCr读取数据，通讯就可以完成了。该注意到Android
24、的概念中，Binder是一个很低层的概念，上面一层根本都看不到Binder,而是ACtivity跟一个SCrViCe的对象直接通过方法调用，获取效劳。这个就是Android提供给我们的外特性：在Android中，要完成某个操作，所需要做的就是请求某个有能力的效劳对象去完成动作，而无需知道这个通讯是怎样工作的，以及效劳在哪里。所以Andoid的IPC在本质上属于对象请求代理架构，Android的设计者用CORBA的概念将自己包装了一下，实现了一个微型的轻量级CORBA架构，这就是AndOid的IPC设计的意图所在，它并不是仅仅解决通讯，而是给出了一个架构，一种设计理念，这就是Android的闪光
25、的地方。Android的Binder更多考虑了数据交换的便捷，并且只是解决本机的进程间的通讯，所以不像CORBA那样复杂，所以叫做轻量级。所以要理解AndrOid的IPC架构，就需要了解CORBA的架构。而CORBA的架构在本质上可以使用下面图来表示：Sornco在效劳端，多了一个代理器，更为抽象一点我们可以以下图来表示。公共工具L对象请求代理分析和CORBA的大体理论架构，我给出下面的AndrOid的对象代理结构。在结构图中，我们可以较为清楚的把握Android的IPC包含了如下的概念：设备上下文什(ContextObject)设备上下文包含关于客服端，环境或者请求中没有作为参数传递个操作的
26、上下文信息，应用程序开发者用COnteXtObjeCt接口上定义的操作来创立和操作上下文。Android代理：这个是指代理对象BinderLinux内核提供的Binder通讯机制Android的外特性空间是不需要知道效劳在那里，只要通过代理对象完成请求，但是我们要探究Android是如何实现这个架构，首先要问的是在CIient端要完成云效劳端的通讯,首先应该知道效劳在哪里？我们首先来看看SCrViCeManger管理了那些数据。ServiceManager提供了addservice,chockservice两个重要的方法，并且维护了一个效劳列表记录登记的效劳名称和句柄。Servicemanag
27、erservice使用O来标识自己。并且在初始化的时候，通过binder设备使用BINDER_SET_CONTEXT_MGRioctl将自己变成了CoNTEXT_MGR。Svclist中存储了效劳的名字和HandIe,这个HandIe作为Client端发起请求时的目标地址。效劳通过add_service方法将自己的名字和Binder标识handle登记在SVeliSt中。而效劳请求者，通过CheCk_servi.ee方法，通过效劳名字在SerViCelist中获取到SerViCC相关联的BindCr的标识handle,通过这个Handle作为请求包的目标地址发起请求。我们理解了SerViCCM
28、anager的工作就是登记功能，现在再回到IPC,客服端如何建立连接的？我们首先回到通讯的本质：IPCo从一般的概念来讲，Android设计者在LinUX内核中设计了一个叫做Binder的设备文件，专门用来进行Android的数据交换。所有从数据流来看Java对象从JaVa的VM空间进入到C+空间进行了一次转换，并利用C+空间的函数将转换过的对象通过driverbindcr设备传递到效劳进程，从而完成进程间的IPC。这个过程可以用以下图来表示。这里数据流有几层转换过程。(1)从JVM空间传到C+空间，这个是靠JNl使用ENV来完成对象的映射过程。(2)从c+空间传入内核Binder设备，使用P
29、roCCSSState类完成工作。(3)Service从内核中Binder设备读取数据。Android设计者需要利用面向对象的技术设计一个框架来屏蔽掉这个过程。要让上层概念空间中没有这些细节。Android设计者是怎样做的呢？我们通过c+空间代码分析，看到有如下空间概念包装(PrOCCSSState(PrOCCSSState.CPP)在PrOCeSSState类中包含了通讯细节，利用OPenbinder翻开LinUX设备dcvbindcr,通过ioctrl建立的根本的通讯框架。利用上层传递下来的SerViCChandlC来确定请求发送到那个SerViCeO通过分析我终于明白了Bnbinder,
30、BpBinder的命名含义,Bn-代表NatiVe,而Bp代表PrOXy。一旦理解到这个层次，ProcessStatc就容易弄明白了。下面我们看JVM概念空间中对这些概念的包装。为了通篇理解设备上下文，我们需要将AndrOidVM概念空间中的设备上下文和C+空间总的设备上下文连接起来进行研究。为了在上层使用统一的接口，在JVM层面有两个东西。在Android中，为了简化管理框架,引入了SerViCCMangCr这个效劳。所有的效劳都是从SerViCeManager开始的，只用通过ServiceManager获取到某个特定的效劳标识构建代理IBindCr。在AndrOid的设计中利用SerViC
31、eManager是默认的HandIe为0,只要设置请求包的目标句柄为0,就是发给SCrVieCManagCr这个SerViCe的。在做效劳请求时，Android建立一个新的SerViCCManagerProxyeServiceManagerPrOXy使用ConteXObjeCt作为Binder和SerViCeManagerService(效劳端)进行通讯。我们看到Android代码一般的获取SerViCe建立本地代理的用法如下：IXXXInlxxx=IXXXInterface.Stub,aslnterface(ServiceManager.getService(z,xx*);例如：使用输入法效
32、劳：IInputMethodManagermlmm=IInputMethodManager.Stub,aslnterface(ServiceManager.getService(inpUtnlethOcr)9这些效劳代理获取过程分解如下：(1)通过调用GetCOntCXtObjeCt调用获取设备上下对象。注意在AndrOidJVM概念空间的COnteXtObjeCt只是与SCrViCeMangCrSerViCe通讯的代理BindCr有对应关系。这个跟c+概念空间的GetCOnteXtObjCCt意义是不一样的。注意看看关键的代码Binderinternal.getContextObject()
33、BindcrInteral.javaNATIVEJNI:getContextObject()androidutiIBinder.cppAndroidutilgetConextObjectandroid_uti!Binder,cppProcessState:self()-getCotextObject(0)rocessState.cppgetStrongProxyForHandle(0)NEWBpBinder(O)注意PrOCeSSStato:self()-AgetCotextObjcct(0)processtate.cpp,就是该函数在进程空间建立了PrOCeSSState对象，翻开了Bind
34、Cr设备devbindcr,并且传递了参数0,这个0代表了与SCrViCCManager这个效劳绑定。(2)通过调用SerViCCManagCr.aslnterface(ContextObjCCt)建立一个代理SerViCCManger。mRemote=ContextObject(Binder)这样就建立起来SCrViCeManagCrProXy通讯框架。(3)客户端通过调用ServiCeManager的getService的方法建立一个相关的代理BindCroServiceMangerProxy.remote,transact(GET_SERVICE)IBindcr=ret.ReadStro
35、ngBinder()-?这个就是JVM空间的代理BinderJNlNavite:android_os_Parcel_readStrongBindcr()android_uti!binder,cppParcel-readStrongBinder()pacel.cppUnflattenbinderaccl.cppgetStrongProxyForHandle(flat_handle)NEWBPBindCr(flathandlc)-?这个就是底层c+空间新建的代理BindCrO整个建立过程可以使用如下的示意图来表示：Activity为了建立一个IPC,需要建立两个连接：访问SCrViCCnIanag
36、erService的连接，IXXX具体XXXService的代理对象与XXXSCrViCe的连接。这两个连接对应c+空间ProcessState中BPBindCr。对IXXX的操作最后就是对BPBinder的操作。由于我们在写一个Service时，在一个PaCkage中写了SerViCeNatiVe局部和SerViCePrOXy局部，而NatiVe和Proxy都实现相同的接口：IXXXInterface,但是一个在效劳端，一个在客服端。客户端调用的方式是使用rcmotc-transact方法向SerViCC发出请求，而在效劳端的OnTranSaet中那么是处理这些请求。所以在AndroidCl
37、ient空间就看到这个效果：只需要调用代理对象方法就到达了对远程效劳的调用目的，实际上这个调用路径好长好长。我们其实还一局部没有研究，就是同一个进程之间的对象传递与远程传递是区别的。同一个进程间专递效劳地和对象，就没有代理BPBindCr产生，而只是对象的直接应用了。应用程序并不知道数据是在同一进程间传递还是不同进程间传递，这个只有内核中的Binder知道，所以内核BindCr驱动可以将Binder对象数据类型从BINDER_TYPE_BINDER修改为BIM)ERJYPEJdANDLE或者BlNDERjrYPE_WEAK_HANDLE作为引用传递。Android核心分析之七Service深入
38、分析Service深入分析上一章我们分析了AndrOidIPC架构，知道了ArIdrOid效劳构建的一些根本理念和原理，本章我们将深入分析AndrOid的效劳。Android体系架构中三种意义上效劳：Native效劳Android效劳Init空间的效劳，主要是属性设置，这个IPC是利用Socket来完成的，这个我将在另外一章来讨论。Navite效劳，实际上就是指完全在C+空间完成的效劳，主要是指系统一开始初始化，通过Init.rc脚本起来的效劳，例如SerVieeMangerservice,Zygoteservice,Mediaservice,ri!demonservice等。Android效
39、劳是指在JVM空间完成的效劳，虽然也要使用NaVite上的框架，但是效劳主体存在于AndrOid空间。Android是二阶段初始(Init2)初始化时建立的效劳。1 Service本质结构我们还是从SerViCe的根本意义分析入手，效劳的本质就是响应客户端请求。要提供效劳，就必须建立接收请求，处理请求，应答客服端的框架。我想在ArIdrOidSerViCC设计者也会无时不刻把这个效劳本质框图挂在脑海中。从程序的角度，效劳一定要存在一个闭合循环框架和请求处理框架等待应答团合 楣环 分析清楚效劳框就必须弄清楚以下的机制及其构成。闭合循环结构放置在哪里？处理请求是如何分发和管理？处理框架是如何建立的
40、？概念框架是如何建立的？2 Service根本框架分析Android设计中，NatiVeService和AndrOidService采用了同一个闭合循环框架。这个闭合循环框架放置在NatiVC的C+空间中，,ProcessStatcProcessState.cpp和IPCThreadStatcIPCThreadState.cpp两个类完成了全部工作。C+JVM空间，*,-NaMivcAndruad*1:ServiceServiceC+空间iProcessStaiEHandCzBilIderDriVCr，/IPCTlireadSfctfBBindcrDriver在效劳框架中，ProcessSta
41、te是公用的局部，这个公用局部最主要的框架就是闭合循环框架和接收到从Binder来的请求后的处理框架。我们将效劳框架用PrOCCSSSate来表示,简言之：addservice(2)建立闭合循环处理框架。intmain(intargc,char*argv)(spproc(ProcessState:self();addService(Stringl6(zzxxO*),newxxxOService();addService(Stringl6(zzxxx1,),newxxxlService();ProcessState:self()-startThreadPool();IPCThreadState:
42、self()-JoinThreadPool();闭合循环框架)2.1 NativeServiceNativeService是在系统Init阶段通过Init.rc脚本建立的效劳。首先来看看一个例子mcdiaservcrnIainnICdiaSerVer.cpp的建立过程。intmain(intargc,char*argv)(spproc(ProcessState:self();spsm=defaultServiceManagcr();1.OGI(zrServiceManager:%p，sm.get();AudioFlinger:instantiate();McdiaPlayerService:i
43、nstantiate();CameraService:instantiate();AudioPolicyService:instantiate();ProcessState:self()-startThreadPool();IPCThreadState:self()-JoinThreadPool();)我们将代码向下展开了一层，更能看到事物的本质。intmain(intargc,char*argv)(spproc(ProcessState:self();spsm=defaultServiceManagcr();ClcfaultServiccManager()-addService(String
44、l6(mcdia.audioflinger*),newAudioFlingerO)；ProcessState:self()-startThreadPool();IPCThreadState:self()-JoinThreadPool();)U)效劳进程建立了PrOCeSSState对象，并将给对象登记在进程的上下文中。(2)建立一个新AUdiOFlingCr对象，并将对象登记SerViCeManagerService中。(3)开始就收请求，处理请求，应答这个循环闭合框架。2.2 AndroidServiceAndroidsservice是系统二阶段(Init2)初始化时建立的效劳。Androi
45、d的所有效劳循环框架都是建立SyStCnlSCrVer(SyStCInSCrVer.java)上。在SystemServer.java中看不到循环结构，只是可以看到建立了init2的实现函数，建立了一大堆效劳，并AddSerViCe到ServiCeManager0main()com/android/server/SystemServer(initl();)InitI()是在NatiVe空间实现的(com_andoird_server_systemServer.cpp)。我们一看这个函数就知道了，原来这个闭合循环处理框架在这里：initl-systeminit()Systeminit.cpp在S
46、yStenkinit()我们看到了这个久违的循环闭合管理框架。(Callz,comandroidserverSystemServerz,“init2”ProcessState:self()-startThreadPool();IPCThreadState:self()-JoinThreadPool();)Init2()SystemServer.java中建立了AndrOid中所有要用到的效劳：EntropyServicePowerManagerActivityManagerTelephonyRegistryPackageManagerAccountManagerContentManagerSystemContentProvidersBatteryServiceHardwareServiceAlarmManagerInitWatchdogSensorServiceWindowManagerBluetoothServicestatusbarClipboardServiceInputMethodServiceNetStatServiceConnectivityServiceAccessibilityManagerNotificationManager
