关闭

关闭

封号提示

内容

首页 Android核心分析.pdf

Android核心分析.pdf

Android核心分析.pdf

上传者: realtole 2011-09-16 评分1 评论0 下载43 收藏0 阅读量847 暂无简介 简介 举报

简介:本文档为《Android核心分析pdf》,可适用于手机软件领域,主题内容包含Android核心分析之一分析方法论探讨之设计意图Android核心分析之二方法论探讨之概念空间篇Android是什么之三手机之硬件形态Androi符等。

Android核心分析之一分析方法论探讨之设计意图Android核心分析之二方法论探讨之概念空间篇Android是什么之三手机之硬件形态Android核心分析之四手机的软件形态Android核心分析之五基本空间划分Android核心分析之六IPC框架分析BinderServiceServicemanagerAndroid核心分析之七Service深入分析Android核心分析之八Android启动过程详解Android核心分析之九ZygoteServiceAndroid核心分析之十AndroidGWES之基本原理篇Android核心分析之十一AndroidGWES之消息系统Android核心分析()AndroidGEWS窗口管理之基本架构原理Android核心分析()AndroidGWES之Android窗口管理Android核心分析()AndroidGWES之输入系统Android核心分析()Android输入系统之输入路径详解Android核心分析()Android电话系统概述篇Android核心分析()电话系统之rilDAndroid核心分析()Android电话系统之RILJavaAndroid核心分析()电话系统之GSMCallTackerAndroid核心分析()Android应用程序框架之无边界设计意图Android核心分析()Android应用框架之AndroidApplicationAndroid核心分析()Android应用框架之ActivityAndroid核心分析()AndroidGDI之显示缓冲管理Android核心分析()AndroidGDI之共享缓冲区机制Android核心分析()AndroidGDI之SurfaceFlingerAndroid核心分析()AndroidGDI之SurfaceFlinger之动态结构示意图Android核心分析()AndroidGDI之SurfaceCanvasAndroidAndroidAndroidAndroid核心分析之一分析方法论探讨之设计意图分析方法论探讨之设计意图为什么要研究Android是因为它够庞大它够复杂他激起了我作为一个程序员的内心的渴望渴望理解这种复杂性。我研究的对象是作为手机开发平台的Android软件系统部分而不是Dalvik虚拟机本身。作为一个从其他平台装接过来的程序员要从事Andoid平台系统开发我的关于手机平台上积累的知识已经不能满足需要了Android为我们带来了大量的新名词ActivityManifestINTENTServiceBinderDalvik虚拟机FrameworkLinuxNavtiveJNI。通过在源代码在开发社区在开发博客甚至在招聘过程中我不断的寻求Android是什么。经过一定时间的沉淀我慢慢的理解到Android不仅仅是一类手机的总称不仅仅是一个手机开发平台不仅仅是一个虚拟java操作系统不仅仅是一个开发社区一个开发标准不仅仅是一堆代码Android已经成了一个新的潮流。代码多系统复杂纵观社区中Android的研究者一开始从源代码分析Android就走向迷途不断的跋山涉水向纵深冲刺最终脑袋堆栈不够用迷失在开始的旅程或者挂在半途中鲜有通达者。我感觉到大部分的研究者总是忘记站在高山上向下望一望设计者的意图一味的随着代码的控制流走入繁杂的谜团陷入到复杂性的深渊。我的研究分析是从设计者的意图出发从抽象的甚至从哲学的高度从最简单的系统原型开始从设计猜想开始而不是一开始就从代码分析展开。首先理解Android大的运行框架主干流程系统原型之后再用源代码分析充实之。当然我这里的设计者意图并不是真正的Android设计者意图而是我以为的Android设计者意图。要理解设计者意图就需要抽象。我们需要在哲学意义空间中去考虑系统的描述即系统在本质上要表达什么。在逻辑空间上去考虑系统基本构成和动态结构。从现实到虚拟对象的映射去理解系统对象的组成在从数据流的角度分析数据的产生者和消费者之间作用关系从控制流的角度去分析对象之间的交互关系从函数调用去分析具体的层次关系。在系统设计上原型是最能表达哲学空间和逻辑空间中系统本质的东西原型是事物本质的第一层体现。我以为任何复杂的系统都一个简洁的系统原型都有它简洁的意义。系统原型是设计者意图的第一体现所以我们需要从几个方向上去提炼系统原型:()从系统本质和基本原理出发()从分析系统数据流和控制流分析出发。从设计者意图出发得出系统原型提取到大的逻辑结构和系统构成是第一步。之后我们可以从设计者的角度考虑系统猜想系统设计为什么要这样设计为什么要有这些构成。这样的基本原型是什么?系统的限制是什么应用场景有哪些有些设计的引进还是系统收敛性而为之呢。我们还可以从代码痕迹上去分析这些概念是如何的得来的?从一定的抽象和高度去理解这些问题遵循系统原型出发之原则在深入分析代码的时候就不容易陷入细节中。我们就可以随时跳出来想这些代码在整体上载表达一个什么概念在描绘一个什么逻辑他要构成一个虚拟层吗?他是在管理这个硬件吗?他在虚拟这个对象吗?他在构建管理机构?还是在构建一个对象管理?空间管理为了快速引入了什么样的复杂算法实际上的原型算法应该是什么样的?只有深入到这个抽象层次我们才能很好的把握住系统的每一条线每一个对象的意义。只用从原型出发我们才能把握住这个系统的实质所在在干什么?他要表达什么?设计者为什么要这样想?最终极的想法是什么?这样代码分析就变得简单明了读代码就变成了是在印证猜想修正方向。AndroidAndroidAndroidAndroid核心分析之二方法论探讨之概念空间篇方法论探讨之概念空间篇我们潜意识就不想用计算机的方式来思考问题我们有自己的思维描述方式越是接近我们思维描述方式我们越容易接受和使用。各种计算机语言建模工具不外乎就是建立一个更接近人的思维方式的概念空间再使用工具从该概念空间向另外一个概念空间映射我称之为人性思维空间向序列描述空间的一个映射。实现方面来看系统就是一个翻译器将机器性更加人性化的一种机制。大学计算机经典课“计算机体系结构”其他的可以忘记但是下面这个图不能忘记:这个就是概念空间最本质的原型体现:作为观测者看到了什么?设计者给了观察者什么?给出的答案是外部特性。()提供给观察者的概念空间是什么?()内部特性的概念空间是什么?概念空间所表达的东西带有两个方面的缠绕:一面是人性自由一面是物性制约(实时响应系统资源的限制)。所以程序实现的概念空间是人性自由与特定计算机系统物性之间有一个折中并且根据实际系统而采取某种动态的平衡。而这种平衡将会影响到系统架构以及设计的思想。特别在手机这样的嵌入式系统中这种矛盾和平衡无处不在这种折中无处不在。而对系统的选取和采用也就接受了某个方面的折中或某中即在的也许是看不见的标准及这样的标准有隐式和显式的。正因为如此不管是工具的产生新的平台的产生都是计算机的物性向人性靠近的一个小台阶。一个新的思想的形成随即带来的新工具新系统框架新的体系结构。如果设计者站的高度足够高那么设计者一开始就会考虑到“我该给他们一个什么样的概念空间甚至一个什么样的理念让他们这个概念空间去建立自己的产品”于是设计者就会开始主动的去建立概念空间这个概念空间要表达的实际意义概念空间应该有哪些内容构成考虑概念空间的完备性和封闭性考虑概念空间的边界考虑从哪个基础上建立这个概念空间考虑如何与概念空间外的实体进行交互考虑系统的资源限制条件考虑功能性构建的合理性考虑机器系统与人的平衡问题。我们在学习新系统时首先映入眼帘的就是新概念。新名词就如现在我们面临的Android大量的新名词在程序员的世界都是从代码实践开始的是从写应用开始去涉及。SDK给了我们一个概念我们就在这个概念框架下使用SDK给我提供的函数接口数据结构初始化过程等我们最初的接触到原型就是“HelloWorld”之类的DEMO程序我们在Helloworld上去使用各种不同的接口函数对于应用程序员来讲,他说看到的系统就是系统调用接口及其编程开发流程。实际上只要一使用这些接口,就不得不接受一系列的概念,只有在这种概念系统下,我们才能工作。但是,实际上我们却忽略了这样的概念系统的理解,只是在编程接口的这个狭窄的空间去理解系统我们理解系统在形成理解概念的空间只是微小的一角很少有资料来介绍这种概念系统的形成和理解,编程接口只是这个概念空间一个对外部的一个表征。我们可以抽象起来,以接口,协议和行为,来描述系统的情况。SDKAPI的实质向上层提供了一个语义接口从而在层间实现了一个转义过程同时又成为一个功能的集合体。但是我们很少这样跳出来看我们到底是处于一种什么样的概念空间SDK除了调用接口外还给了我们怎样一种整体概念?目标系统的基本构架在本质上的东西就是一个概念系统到另一个概念系统的映射。让我们大脑理解的概念系统映射到计算机能实现的概念域的一个映射。我们假定这个概念域E,机器能够理解的概念域为M,我们的软件工程要做的事情实质就是:EàM领域的一个映射过程。为什么要在宏观上把握这些概念呢显然有我的目的理解概念空间是理解设计者意图的一个重要途径。设计者要想给开发者提供什么设计者想要提供给最终用户什么。我们需要站在高处看待系统明白设计者意图。Android的实质还是一套管理手机硬件系统的软件这个话讲起来没有多大意义,计算机操作系统本质都是如此Android是Google云计算计划的一部分我们修正成:Android建立的本质就是让计算机成为我的云接入移动智能终端。作为硬件管理软件Android提供概念空间内涵实质上泛操作系统内涵我们的理解可以从泛操作系统概念空间映射到Android系统中去。而作为云计算的一部分的内容我们可以云计算的概念入手去研究Andoird。AndroidAndroidAndroidAndroid是什么之三手机之硬件形态手机硬件形态本节可能与Android无关但是Android系统现在这个阶段更多的是移动终端形态的开发平台本节给出了Android背后的工作Android管理的硬件是什么Android的本质就是要管理好这些硬件部分为用户提供一个体验更好速度更快的智能移动终端。对手机硬件形态的认识是要让我们对手机硬件组成有个感性的认识让程序员知道系统中的代码是管理那一部分的即我们堆砖头的目的是什么让思维有一个伸展。为了对手机这类嵌入式系统有一个较为深入的了解我制作了如下的手机硬件结构思维导图在这张图上我们可以看到组成手机硬件的有哪些初步了解到手机管理平台为什么要那么多的管理框架和层次从最底层理解Android设计者的设计意图这个思维导图其实只是示意图。我们知道手机这种嵌入式系统硬件架构最简单描述的描述为:应用处理器Modem射频对于应用处理器而言对设计者最为本质的描述为输入输出而对于移动终端设备电源管理连接机制多媒体又是很重要的考虑环节而这些环节都会在软件平台上有所体现。AndroidAndroidAndroidAndroid核心分析之四手机的软件形态手机的软件形态上节我给出了手机的硬件树本节将给出手机软件形态树。主要突出手机软件涵盖的内容。通过该思维导图我们可以看到手机软件所涉及到的方方面面Android所涉及到的内容也不会超过下面所示太多这个也是Andoid系统外特性空间所要展示的这个也是Android设计者需要考虑管理的大部分内容通过下面的整理我们可以让我们的思维更加贴近Android设计意图从而更深入的了解Android中各种组成的由来这个就是前面讲到的分析思想之一从退到源头出发从思考最终极的问题开始。AndroidAndroidAndroidAndroid核心分析之五基本空间划分基本空间划分Google给了我们一张系统架构图在这张图上我们可以看到Android的大体框架组成。从上图可以看到:AndroidApplications,ApplicationFramework,DalvikVirtualMachine,Linux。如果将Android泛化我们可以将系统划分成两部分:但是为了研究的方便我们先看最为本质的三层上面是Android中间叫Dalvik虚拟机下面叫Linux。虽然上两层都包含在Android中但是为了理解的方便或者从实用主义出发我还是将虚拟机这次给分开出来因为我研究的对象是Android的手机系统相关部分对于虚拟机我们不做太深入的研究。e:pre">从上面我们可以看到这个系统静态的划分成这样的三层。但是从动态运行逻辑上不是这样划分的所以空间的划分是一个有趣的概念。我们从操作系统的角度看Android就是一堆Linux应用的集合。从Linux角度看到的空间划分:进程空间和内核空间。从Android的应用对应着Linux的一个个进程。Andoid中包含一个Java虚拟机虚拟机是运行在Linux之上的Android构建在JVM之上从Android动态运行逻辑上我们需要将Android划分成Android空间和非Android空间。在Andoid系统中我们面对的是Andoid概念空间而不是Linux进程了在Andoid概念空间中已经没有了Lliux进程的概念而是ServiceproxyActivityprovider等。至于虚拟机JVM我们只需要知道JVM是DalvikVM(虚拟机)这是一个专为嵌入式设备打造的JAVA虚拟机是一个有着自己的codebyte和格式的可以在嵌入式设备上高效运行的Java虚拟机。为了研究的深入我们还是需要涉及到JNINative部分。在这个分类中我将JVM分为JVM空间和C空间。Android应用的开发者是工作在Android外特性概念空间的这里没有了Linux的一点气息Android构建的外特性空间概念包含了:Activity,Provider,Interface,Events,ProviderService等。至于JVM空间和C空间的划分是为了研究Android核心的描述而提出的我们在做Android系统开发时常常需要修改到JNI的Native部分。后面我将用较多的篇幅来深入阐述这个部分。AndroidAndroidAndroidAndroid核心分析之六IPCIPCIPCIPC框架分析BinderBinderBinderBinderServiceServiceServiceServiceServiceServiceServiceServicemanagermanagermanagermanagerIPC框架分析BinderServiceServicemanager我首先从宏观的角度观察Binder,Service,ServiceManager并阐述各自的概念。从Linux的概念空间中Android的设计Activity托管在不同的的进程Service也都是托管在不同的进程不同进程间的Activity,Service之间要交换数据属于IPC。Binder就是为了Activity通讯而设计的一个轻量级的IPC框架。在代码分析中我发现Android中只是把Binder理解成进程间通讯的实现有点狭隘而是应该站在公共对象请求代理这个高度来理解BinderService的概念这样我们就会看到不一样的格局从这个高度来理解设计意图我们才会对Android中的一些天才想法感到惊奇。从Android的外特性概念空间中我们看不到进程的概念而是ActivityServiceAIDLINTENT。一般的如果我作为设计者在我们的根深蒂固的想法中这些都是如下的CS架构客户端和服务端直接通过Binder交互数据打开Binder写入数据通过Binder读取数据通讯就可以完成了。该注意到Android的概念中Binder是一个很低层的概念上面一层根本都看不到Binder而是Activity跟一个Service的对象直接通过方法调用获取服务。这个就是Android提供给我们的外特性:在Android中要完成某个操作所需要做的就是请求某个有能力的服务对象去完成动作而无需知道这个通讯是怎样工作的以及服务在哪里。所以Andoid的IPC在本质上属于对象请求代理架构Android的设计者用CORBA的概念将自己包装了一下实现了一个微型的轻量级CORBA架构这就是Andoid的IPC设计的意图所在它并不是仅仅解决通讯而是给出了一个架构一种设计理念这就是Android的闪光的地方。Android的Binder更多考虑了数据交换的便捷并且只是解决本机的进程间的通讯所以不像CORBA那样复杂所以叫做轻量级。所以要理解Android的IPC架构就需要了解CORBA的架构。而CORBA的架构在本质上可以使用下面图来表示:在服务端多了一个代理器更为抽象一点我们可以下图来表示。分析和CORBA的大体理论架构我给出下面的Android的对象代理结构。在结构图中我们可以较为清楚的把握Android的IPC包含了如下的概念:设备上下文什(ContextObject)设备上下文包含关于客服端环境或者请求中没有作为参数传递个操作的上下文信息应用程序开发者用ContextObject接口上定义的操作来创建和操作上下文。Android代理:这个是指代理对象BinderLinux内核提供的Binder通讯机制Android的外特性空间是不需要知道服务在那里只要通过代理对象完成请求但是我们要探究Android是如何实现这个架构首先要问的是在Client端要完成云服务端的通讯首先应该知道服务在哪里?我们首先来看看ServiceManger管理了那些数据。ServiceManager提供了addservice,checkservice两个重要的方法并且维护了一个服务列表记录登记的服务名称和句柄。Servicemanagerservice使用来标识自己。并且在初始化的时候通过binder设备使用BINDERSETCONTEXTMGRioctl将自己变成了CONTEXTMGR。Svclist中存储了服务的名字和Handle这个Handle作为Client端发起请求时的目标地址。服务通过addservice方法将自己的名字和Binder标识handle登记在svclist中。而服务请求者通过checkservice方法通过服务名字在servicelist中获取到service相关联的Binder的标识handle,通过这个Handle作为请求包的目标地址发起请求。我们理解了ServiceManager的工作就是登记功能现在再回到IPC上客服端如何建立连接的?我们首先回到通讯的本质:IPC。从一般的概念来讲Android设计者在Linux内核中设计了一个叫做Binder的设备文件专门用来进行Android的数据交换。所有从数据流来看Java对象从Java的VM空间进入到C空间进行了一次转换并利用C空间的函数将转换过的对象通过driverbinder设备传递到服务进程从而完成进程间的IPC。这个过程可以用下图来表示。这里数据流有几层转换过程。()从JVM空间传到c空间这个是靠JNI使用ENV来完成对象的映射过程。()从c空间传入内核Binder设备使用ProcessState类完成工作。()Service从内核中Binder设备读取数据。Android设计者需要利用面向对象的技术设计一个框架来屏蔽掉这个过程。要让上层概念空间中没有这些细节。Android设计者是怎样做的呢?我们通过c空间代码分析看到有如下空间概念包装(ProcessState(ProcessStatecpp)在ProcessState类中包含了通讯细节利用openbinder打开Linux设备devbinder,通过ioctrl建立的基本的通讯框架。利用上层传递下来的servicehandle来确定请求发送到那个Service。通过分析我终于明白了BnbinderBpBinder的命名含义Bn代表Native而Bp代表Proxy。一旦理解到这个层次ProcessState就容易弄明白了。下面我们看JVM概念空间中对这些概念的包装。为了通篇理解设备上下文我们需要将AndroidVM概念空间中的设备上下文和C空间总的设备上下文连接起来进行研究。为了在上层使用统一的接口在JVM层面有两个东西。在Android中为了简化管理框架引入了ServiceManger这个服务。所有的服务都是从ServiceManager开始的只用通过ServiceManager获取到某个特定的服务标识构建代理IBinder。在Android的设计中利用ServiceManager是默认的Handle为只要设置请求包的目标句柄为就是发给ServiceManager这个Service的。在做服务请求时Android建立一个新的ServiceManagerProxy。ServiceManagerProxy使用ContexObject作为Binder和ServiceManagerService(服务端)进行通讯。我们看到Android代码一般的获取Service建立本地代理的用法如下:IXXXmIxxx=IXXXInterfaceStubasInterface(ServiceManagergetService("xxx"))例如:使用输入法服务:IInputMethodManagermImm=IInputMethodManagerStubasInterface(ServiceManagergetService("inputmethod"))这些服务代理获取过程分解如下:()通过调用GetContextObject调用获取设备上下对象。注意在AndroidJVM概念空间的ContextObject只是与ServiceMangerService通讯的代理Binder有对应关系。这个跟c概念空间的GetContextObject意义是不一样的。注意看看关键的代码BinderInternalgetContextObject()BinderInteraljavaNATIVEJNI:getContextObject()androidutilBindercppAndroidutilgetConextObjectandroidutilBindercppProcessState::self()>getCotextObject()processStatecppgetStrongProxyForHandle()NEWBpBinder()注意ProcessState::self()>getCotextObject()processtatecpp就是该函数在进程空间建立了ProcessState对象打开了Binder设备devbinder,并且传递了参数这个代表了与ServiceManager这个服务绑定。()通过调用ServiceManagerasInterface(ContextObject)建立一个代理ServiceManger。mRemote=ContextObject(Binder)这样就建立起来ServiceManagerProxy通讯框架。()客户端通过调用ServiceManager的getService的方法建立一个相关的代理Binder。ServiceMangerProxyremotetransact(GETSERVICE)IBinder=retReadStrongBinder()》这个就是JVM空间的代理BinderJNINavite:androidosParcelreadStrongBinder()androidutilbindercppParcel>readStrongBinder()pacelcppunflattenbinderpacelcppgetStrongProxyForHandle(flathandle)NEWBpBinder(flathandle)》这个就是底层c空间新建的代理Binder。整个建立过程可以使用如下的示意图来表示:Activity为了建立一个IPC需要建立两个连接:访问ServicemanagerService的连接IXXX具体XXXService的代理对象与XXXService的连接。这两个连接对应c空间ProcessState中BpBinder。对IXXX的操作最后就是对BpBinder的操作。由于我们在写一个Service时在一个Package中写了ServiceNative部分和ServiceProxy部分而Native和Proxy都实现相同的接口:IXXXInterface,但是一个在服务端一个在客服端。客户端调用的方式是使用remote>transact方法向Service发出请求而在服务端的OnTransact中则是处理这些请求。所以在AndroidClient空间就看到这个效果:只需要调用代理对象方法就达到了对远程服务的调用目的实际上这个调用路径好长好长。我们其实还一部分没有研究就是同一个进程之间的对象传递与远程传递是区别的。同一个进程间专递服务地和对象就没有代理BpBinder产生而只是对象的直接应用了。应用程序并不知道数据是在同一进程间传递还是不同进程间传递这个只有内核中的Binder知道所以内核Binder驱动可以将Binder对象数据类型从BINDERTYPEBINDER修改为BINDERTYPEHANDLE或者BINDERTYPEWEAKHANDLE作为引用传递。AndroidAndroidAndroidAndroid核心分析之七ServiceServiceServiceService深入分析Service深入分析上一章我们分析了AndroidIPC架构,知道了Android服务构建的一些基本理念和原理本章我们将深入分析Android的服务。Android体系架构中三种意义上服务:Native服务Android服务Init空间的服务主要是属性设置这个IPC是利用Socket来完成的这个我将在另外一章来讨论。Navite服务实际上就是指完全在C空间完成的服务主要是指系统一开始初始化通过Initrc脚本起来的服务例如ServiceMangerservice,Zygoteservice,Mediaservice,rildemonservice等。Android服务是指在JVM空间完成的服务虽然也要使用Navite上的框架但是服务主体存在于Android空间。Android是二阶段初始(Init)初始化时建立的服务。Service本质结构我们还是从Service的根本意义分析入手服务的本质就是响应客户端请求。要提供服务就必须建立接收请求处理请求应答客服端的框架。我想在AndroidService设计者也会无时不刻把这个服务本质框图挂在脑海中。从程序的角度服务一定要存在一个闭合循环框架和请求处理框架分析清楚服务框就必须弄清楚以下的机制及其构成。()闭合循环结构放置在哪里?()处理请求是如何分发和管理?()处理框架是如何建立的?()概念框架是如何建立的?Service基本框架分析Android设计中NativeService和AndroidService采用了同一个闭合循环框架。这个闭合循环框架放置在Native的C空间中,ProcessStateProcessStatecpp和IPCThreadStateIPCThreadStatecpp两个类完成了全部工作。在服务框架中ProcessState是公用的部分这个公用部分最主要的框架就是闭合循环框架和接收到从Binder来的请求后的处理框架。我们将服务框架用ProcessSate来表示,简言之:()addservice()建立闭合循环处理框架。intmain(intargc,char**argv){sp<ProcessState>proc(ProcessState::self())addService(String("xxx"),newxxxService())addService(String("xxx"),newxxxService())…ProcessState::self()>startThreadPool()IPCThreadState::self()>joinThreadPool()闭合循环框架}NativeServiceNativeService是在系统Init阶段通过Initrc脚本建立的服务。首先来看看一个例子mediaservermainmediaservercpp的建立过程。intmain(intargc,char**argv){sp<ProcessState>proc(ProcessState::self())sp<IServiceManager>sm=defaultServiceManager()LOGI("ServiceManager:p",smget())AudioFlinger::instantiate()MediaPlayerService::instantiate()CameraService::instantiate()AudioPolicyService::instantiate()ProcessState::self()>startThreadPool()IPCThreadState::self()>joinThreadPool()}我们将代码向下展开了一层更能看到事物的本质。intmain(intargc,char**argv){sp<ProcessState>proc(ProcessState::self())sp<IServiceManager>sm=defaultServiceManager()defaultServiceManager()>addService(String("mediaaudioflinger"),newAudioFlinger())…ProcessState::self()>startThreadPool()IPCThreadState::self()>joinThreadPool()}()服务进程建立了ProcessState对象并将给对象登记在进程的上下文中。()建立一个新AudioFlinger对象并将对象登记ServiceManagerService中。()开始就收请求处理请求应答这个循环闭合框架。AndroidServiceAndroidsservice是系统二阶段(Init)初始化时建立的服务。Android的所有服务循环框架都是建立SystemServer(SystemServerjava)上。在SystemServerjava中看不到循环结构只是可以看到建立了init的实现函数建立了一大堆服务并AddService到serviceManager。main()comandroidserverSystemServer{init()}Init()是在Native空间实现的(comandoirdserversystemServercpp)。我们一看这个函数就知道了原来这个闭合循环处理框架在这里:init>systeminit()Systeminitcpp在systeminit()我们看到了这个久违的循环闭合管理框架。{Call"comandroidserverSystemServer","init"…ProcessState::self()>startThreadPool()IPCThreadState::self()>joinThreadPool()}Init()SystemServerjava中建立了Android中所有要用到的服务:EntropyServicePowerManagerActivityManagerTelephonyRegistryPackageManagerAccountManagerContentManagerSystemContentProvidersBatteryServiceHardwareServiceAlarmManagerInitWatchdogSensorServiceWindowManagerBluetoothServicestatusbarClipboardServiceInputMethodServiceNetStatServiceConnectivityServiceAccessibilityManagerNotificationManagerMountServiceDeviceStorageMonitorLocationManagerSearchServiceCheckinServiceWallpaperServiceAudioServiceHeadsetObserverBackupServiceAppWidgetServiceProcessState和IPCThreadState从宏观来讲PocessState及其IPCThreadState处于IPC与内核打交道包装层。前面的章节已经提到下面我将更详细的分析。有关IPC的c空间的实现都是从ProcessState这个对象完成的。我们可以得出如下的结论:不管JVM的Binder做了多么复杂的操作最终还是需要利用ProcessState这个c空间的对象把数据传递给BinderDriver接收数据也是通过ProcessState这个对象完成ProcessState是所有BinderIPC必经的通道。ProcessState放置在全局变量gProcess中每个进程只有一个ProcessState对象负责打开Binder设备驱动建立线程池等。而IPCThreadState每个线程有一个IPCThreadState实例登记在Linux线程程的上下文附属数据中主要负责Binder数据读取写入和请求处理框架。IPCThreadSate在构造的时候获取进程的ProcessSate并记录在自己的成员变量mProcess中,通过mProcess可以获取到Binder的句柄。ProcessState的生命周期既然ProcessState是Binder通讯的基础那么Process必须在Binder通讯之前建立。客户端服务端都必须建立。由于现在重点讨论服务端所以重心放置在服务端。在Android体系中有c空间的服务JVM空间的服务这两类服务在本质上相同的只是形式上不同由于他们都是建立在ProcessState这个基础上所以在形式上不同就仅仅表现在对OnTransact的回调处理的不同。NativeService我们直接可以看到使用sp<ProcessState>proc(ProcessState::self())建立建立ProcessState一旦调用ProcessState就建立了并且这个self将ProcessSate登记在全局变量中。AndroidService建立AndroidService服务systeminitSysteminitcpp中我们可以看到相同的结构。有一点不同的是所有的AndroidService都运行在一个进程中:systemsever进程。BinderDriver包装IPCThreadStateProcessSate构造的时候使用openbinder打开driverbinder并将句柄记录在mDriverFD在ProcessState中并不使用这个句柄真正使用这个Binder设备句柄的是IPCThreadState所有关于Binder的操作放置在IPCThreadState中:()读取写入:talkWithDriver()IPCThreadState对ioctl(mProcess>mDriverFD,BINDERWRITEREAD,bwr)进行包装。()请求处理:executeCommand()IPCThreadState()循环结构:joinThreadPool()joinThreadPool(){While(){talkWithDriver()executeCommand()}}AndroidAndroidAndroidAndroid核心分析之八AndroidAndroidAndroidAndroid启动过程详解Android启动过程详解Android从Linux系统启动有个步骤()init进程启动()Native服务启动()SystemServerAndroid服务启动()Home启动总体启动框架图如:第一步:initial进程(systemcoreinit)init进程它是一个由内核启动的用户级进程。内核自行启动(已经被载入内存开始运行并已初始化所有的设备驱动程序和数据结构等)之后就通过启动一个用户级程序init的方式完成引导进程。init始终是第一个进程InitrcInitmarvellrcInit进程一起来就根据initrc和initxxxrc脚本文件建立了几个基本的服务:servicemanamgerzygote。。。最后Init并不退出而是担当起propertyservice的功能。脚本文件initSystemCoreInitInitc:parseconfigfile(Initrc)parseconfigfile(Initmarvelrc)解析脚本文件:Initrc和Initxxxxrc(硬件平台相关)Initrc是Android自己规定的初始化脚本(AndroidInitLanguage,SystemCoreInitreadmetxt)该脚本包含四个类型的声明:ActionsCommandsServicesOptions服务启动机制我们来看看Init是这样解析rc文件开启服务的。()打开rc文件解析文件内容systemcoreinitinitc将service信息放置到servicelist中。systemcoreinitparserc()restartservice()systemcoreinitinitcservicestartexecve(…)建立service进程。第二步ZygoteServicemanager和zygote进程就奠定了Android的基础。Zygote这个进程起来才会建立起真正的Android运行空间初始化建立的Service都是Navtiveservice在rc脚本文件中zygote的描述:servicezygotesystembinappprocessXzygotesystembinzygotestartsystemserver所以Zygote从main(…)frameworksbasecmdsappmaincpp开始。()main(…)frameworksbasecmdsappmaincpp建立JavaRuntimeruntimestart("comandroidinternalosZygoteInit",startSystemServer)()

职业精品

废旧物资处置管理办法.docx

学校固定资产管理制度.doc

机械合同范本.doc

显示屏广告发布合同范本.doc

用户评论

0/200
    暂无评论
上传我的资料

精彩专题

相关资料换一换

资料评价:

/ 128
所需积分:1 立即下载

意见
反馈

返回
顶部