首页 > > > Android核心分析.pdf

Android核心分析.pdf

Android核心分析.pdf

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

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

Android核心分析 之一--------分析方法论探讨之设计意图.......................................... 1 Android核心分析 之二 -------方法论探讨之概念空间篇..............................................3 Android是什么 之三-------手机之硬件形态.....................................................................5 Android核心分析之四 ---手机的软件形态...................................................................... 6 Android 核心分析 之五 -----基本空间划分.................................................................... 7 Android 核心分析 之六 -----IPC框架分析 Binder,Service,Service manager..... 11 Android 核心分析 之七------Service深入分析..............................................................21 Android 核心分析 之八------Android 启动过程详解................................................... 31 Android核心分析 之九-------Zygote Service.................................................................. 36 Android核心分析 之十-------Android GWES之基本原理篇.......................................40 Android核心分析 之十一-------Android GWES之消息系统.......................................43 Android 核心分析(12) -----Android GEWS窗口管理之基本架构原理...................... 48 Android 核心分析(13) -----Android GWES之 Android窗口管理............................... 50 Android核心分析(14)------ Android GWES之输入系统..........................................57 Android核心分析(15)--------Android输入系统之输入路径详解.............................. 59 Android核心分析(16)-----Android电话系统-概述篇...............................................66 Android核心分析(17) ------电话系统之 rilD............................................................ 69 Android核心分析(18)-----Android电话系统之 RIL-Java........................................ 76 Android核心分析(19)----电话系统之 GSMCallTacker.............................................84 Android核心分析(20)----Android应用程序框架之无边界设计意图....................... 87 Android核心分析(21)----Android应用框架之 AndroidApplication....................... 88 Android核心分析(22)-----Android应用框架之 Activity..........................................93 Android核心分析(24)-----Android GDI之显示缓冲管理.........................................104 Android核心分析(25)------Android GDI之共享缓冲区机制................................ 112 Android核心分析(26)-----Android GDI之 SurfaceFlinger..................................... 116 Android核心分析(27)-----Android GDI 之 SurfaceFlinger之动态结构示意图..123 Android核心分析(28)-----Android GDI之 Surface&Canvas..................................126 AndroidAndroidAndroidAndroid核心分析 之一--------------------------------分析方法论探讨之设计意图 分析方法论探讨之设计意图 为什么要研究 Android,是因为它够庞大,它够复杂,他激起了我作为一个程序员的内心的 渴望,渴望理解这种复杂性。我研究的对象是作为手机开发平台的 Android软件系统部分, 而不是 Dalvik虚拟机本身。 作为一个从其他平台装接过来的程序员,要从事 Andoid平台系统开发,我的关于手机平台 上积累的知识已经不能满足需要了,Android为我们带来了大量的新名词,Activity,Manifest, INTENT,Service,Binder,Dalvik虚拟机,Framework,Linux,Navtive ,JNI.....。通过在 源代码,在开发社区,在开发博客,甚至在招聘过程中,我不断的寻求 Android是什么。经 过一定时间的沉淀,我慢慢的理解到 Android不仅仅是一类手机的总称,不仅仅是一个手机 开发平台,不仅仅是一个虚拟 java 操作系统,不仅仅是一个开发社区,一个开发标准,不 仅仅是一堆代码,Android已经成了一个新的潮流。 代码多,系统复杂,纵观社区中 Android的研究者,一开始从源代码分析 Android就走向迷 途,不断的跋山涉水,向纵深冲刺,最终脑袋堆栈不够用,迷失在开始的旅程,或者挂在半 途中,鲜有通达者。我感觉到大部分的研究者总是忘记站在高山上向下望一望设计者的意图, 一味的随着代码的控制流走入繁杂的谜团,陷入到复杂性的深渊。 我的研究分析是从设计者的意图出发,从抽象的甚至从哲学的高度,从最简单的系统原型开 始,从设计猜想开始,而不是一开始就从代码分析展开。首先理解 Android大的运行框架, 主干流程,系统原型,之后再用源代码分析充实之。当然我这里的设计者意图并不是真正的 Android设计者意图,而是我以为的 Android设计者意图。 要理解设计者意图,就需要抽象。我们需要在哲学意义空间中去考虑系统的描述,即系统在 本质上要表达什么。在逻辑空间上去考虑系统基本构成和动态结构。从现实到虚拟对象的映 射去理解系统对象的组成,在从数据流的角度分析数据的产生者和消费者之间作用关系,从 控制流的角度去分析对象之间的交互关系,从函数调用去分析具体的层次关系。 在系统设计上,原型是最能表达哲学空间和逻辑空间中系统本质的东西,原型是事物本质的 第一层体现。我以为任何复杂的系统都一个简洁的系统原型,都有它简洁的意义。系统原型 是设计者意图的第一体现,所以我们需要从几个方向上去提炼系统原型: (1)从系统本质和基本原理出发 (2)从分析系统数据流和控制流分析出发。 从设计者意图出发,得出系统原型,提取到大的逻辑结构和系统构成是第一步。之后我们可 以从设计者的角度考虑系统猜想系统设计,为什么要这样设计,为什么要有这些构成。这样 的基本原型是什么?系统的限制是什么,应用场景有哪些,有些设计的引进还是系统收敛性 而为之呢。我们还可以从代码痕迹上去分析,这些概念是如何的得来的?从一定的抽象和高 度去理解这些问题,遵循系统原型出发之原则,在深入分析代码的时候,就不容易陷入细节 中。我们就可以随时跳出来想,这些代码在整体上载表达一个什么概念,在描绘一个什么逻 辑,他要构成一个虚拟层吗?他是在管理这个硬件吗?他在 虚拟这个对象吗?他在构建管 理机构?还是在构建一个对象管理?空间管理,为了快速引入了什么样的复杂算法,实际上 的原型算法应该是什么样的? 只有深入到这个抽象层次,我们才能很好的把握住系统的每一条线,每一个对象的意义。只 用从原型出发,我们才能把握住这个系统的实质所在,在干什么?他要表达什么?设计者为 什么要这样想?最终极的想法是什么?这样,代码分析就变得简单明了,读代码就变成了是 在印证猜想,修正方向。 AndroidAndroidAndroidAndroid核心分析 之二 ----------------------------方法论探讨之概念空间篇 方法论探讨之概念空间篇 我们潜意识就不想用计算机的方式来思考问题,我们有自己的思维描述方式,越是接近 我们思维描述方式,我们越容易接受和使用。各种计算机语言,建模工具,不外乎就是建立 一个更接近人的思维方式的概念空间,再使用工具从该概念空间向另外一个概念空间映射, 我称之为人性思维空间向 01序列描述空间的一个映射。实现方面来看,系统就是一个翻译 器,将机器性更加人性化的一种机制。大学计算机经典课“计算机体系结构”,其他的可以忘 记,但是下面这个图不能忘记: 这个就是概念空间最本质的原型体现:作为观测者看到了什么?设计者给了观察者什么?给 出的答案是外部特性。 (1)提供给观察者的概念空间是什么? (2)内部特性的概念空间是什么? 概念空间所表达的东西带有两个方面的缠绕:一面是人性自由,一面是物性制约(实时 响应,系统资源的限制)。所以程序实现的概念空间是人性自由与特定计算机系统物性之间 有一个折中,并且根据实际系统而采取某种动态的平衡。而这种平衡将会影响到系统架构, 以及设计的思想。特别在手机这样的嵌入式系统中,这种矛盾和平衡无处不在,这种折中无 处不在。而对系统的选取和采用,也就接受了某个方面的折中或某中即在的,也许是看不见 的标准,及这样的标准有隐式和显式的。正因为如此,不管是工具的产生,新的平台的产生, 都是计算机的物性向人性靠近的一个小台阶。一个新的思想的形成随即带来的新工具,新系 统框架,新的体系结构。 如果设计者站的高度足够高,那么设计者一开始就会考虑到“我该给他们一个什么样的 概念空间,甚至一个什么样的理念,让他们这个概念空间去建立自己的产品”,于是设计者 就会开始主动的去建立概念空间,这个概念空间要表达的实际意义,概念空间应该有哪些内 容构成,考虑概念空间的完备性和封闭性,考虑概念空间的边界,考虑从哪个基础上建立这 个概念空间,考虑如何与概念空间外的实体进行交互,考虑系统的资源限制条件,考虑功能 性构建的合理性,考虑机器系统与人的平衡问题。 我们在学习新系统时,首先映入眼帘的就是新概念。新名词,就如现在我们面临的 Android大量的新名词,在程序员的世界都是从代码实践开始的,是从写应用开始去涉及。 SDK给了我们一个概念,我们就在这个概念框架下,使用 SDK给我提供的函数接口,数据 结构,初始化过程等,我们最初的接触到原型就是“HelloWorld”之类的 DEMO程序,我们在 Hello world上去使用各种不同的接口函数,对于应用程序员来讲,他说看到的系统就是系统 调用接口,及其编程开发流程。实际上只要一使用这些接口,就不得不接受一系列的概念,只 有在这种概念系统下,我们才能工作。但是,实际上我们却忽略了这样的概念系统的理解,只是 在编程接口的这个狭窄的空间去理解系统.我们理解系统在形成理解概念的空间只是微小的 一角,很少有资料来介绍这种概念系统的形成和理解,编程接口只是这个概念空间一个,对 外部的一个表征。我们可以抽象起来,以接口,协议和行为,来描述系统的情况。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的大体框架组成。 从上图可以看到:Android Applications,Application Framework,Dalvik Virtual Machine,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进程的概念,而是 Service,proxy,Activity,provider等。 至于虚拟机 JVM,我们只需要知道 JVM是 Dalvik VM(虚拟机)这是一个专为嵌入式 设备打造的JAVA虚拟机,是一个有着自己的 code-byte和格式的可以在嵌入式设备上高 效运行的 Java虚拟机。 为了研究的深入,我们还是需要涉及到 JNI Native 部分。在这个分类中我将 JVM分为 JVM空间和 C++空间。 Android应用的开发者是工作在 Android外特性概念空间的,这里没有了 Linux的一点 气息,Android构建的外特性空间概念包含了:Activity,Provider,Interface,Events,Provider, Service等。至于 JVM空间和 C++空间的划分是为了研究 Android核心的描述而提出的,我 们在做 Android系统开发时,常常需要修改到 JNI的 Native部分。后面我将用较多的篇幅来 深入阐述这个部分。 AndroidAndroidAndroidAndroid 核心分析 之六 -----IPC-----IPC-----IPC-----IPC 框架分析 BinderBinderBinderBinder, ServiceServiceServiceService,ServiceServiceServiceService managermanagermanagermanager IPC框架分析 Binder,Service,Service manager 我首先从宏观的角度观察 Binder,Service,Service Manager,并阐述各自的概念。从 Linux 的概念空间中,Android的设计 Activity托管在不同的的进程,Service也都是托管在不同的 进程,不同进程间的 Activity,Service之间要交换数据属于 IPC。Binder就是为了 Activity通 讯而设计的一个轻量级的 IPC框架。 在代码分析中,我发现 Android中只是把 Binder理解成进程间通讯的实现,有点狭隘, 而是应该站在公共对象请求代理这个高度来理解 Binder,Service的概念,这样我们就会看 到不一样的格局,从这个高度来理解设计意图,我们才会对 Android中的一些天才想法感到 惊奇。从 Android的外特性概念空间中,我们看不到进程的概念,而是 Activity,Service, AIDL,INTENT。一般的如果我作为设计者,在我们的根深蒂固的想法中,这些都是如下的 C/S架构,客户端和服务端直接通过 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代理:这个是指代理对象 Binder Linux内核提供的 Binder通讯机制 Android的外特性空间是不需要知道服务在那里,只要通过代理对象完成请求,但是我 们要探究 Android是如何实现这个架构,首先要问的是在 Client端要完成云服务端的通讯, 首先应该知道服务在哪里?我们首先来看看 Service Manger 管理了那些数据。Service Manager提供了 add service,check service两个重要的方法,并且维护了一个服务列表记录登 记的服务名称和句柄。 Service manager service 使用 0来标识自己。并且在初始化的时候,通过 binder 设备使用 BINDER_SET_CONTEXT_MGR ioctl将自己变成了 CONTEXT_MGR。Svclist中存储了服务 的名字和 Handle,这个 Handle作为 Client端发起请求时的目标地址。服务通过 add_service 方法将自己的名字和 Binder标识 handle登记在 svclist中。而服务请求者,通过 check_service 方法,通过服务名字在 service list中获取到 service 相关联的 Binder的标识 handle,通过这个 Handle作为请求包的目标地址发起请求。 我们理解了 Service Manager的工作就是登记功能,现在再回到IPC上,客服端如何 建立连接的?我们首先回到通讯的本质:IPC。从一般的概念来讲,Android设计者在 Linux 内核中设计了一个叫做 Binder的设备文件,专门用来进行 Android的数据交换。所有从数据 流来看 Java对象从 Java的 VM空间进入到 C++空间进行了一次转换,并利用 C++空间的函 数将转换过的对象通过 driver\binder设备传递到服务进程,从而完成进程间的 IPC。这个过 程可以用下图来表示。 这里数据流有几层转换过程。 (1) 从 JVM空间传到 c++空间,这个是靠 JNI使用 ENV来完成对象的映射过程。 (2) 从 c++空间传入内核 Binder设备,使用 ProcessState类完成工作。 (3) Service从内核中 Binder设备读取数据。 Android设计者需要利用面向对象的技术设计一个框架来屏蔽掉这个过程。要让上层 概念空间中没有这些细节。Android设计者是怎样做的呢?我们通过 c++空间代码分析,看 到有如下空间概念包装(ProcessState@(ProcessState.cpp) 在 ProcessState类中包含了通讯细节,利用 open_binder打开 Linux设备 dev\binder, 通过 ioctrl建立的基本的通讯框架。利用上层传递下来的 servicehandle来确定请求发送到那 个 Service。通过分析我终于明白了 Bnbinder,BpBinder 的命名含义,Bn-代表 Native,而 Bp代表 Proxy。一旦理解到这个层次,ProcessState就容易弄明白了。 下面我们看 JVM概念空间中对这些概念的包装。为了通篇理解设备上下文,我们需要 将 Android VM概念空间中的设备上下文和 C++空间总的设备上下文连接起来进行研究。 为了在上层使用统一的接口,在 JVM层面有两个东西。在 Android中,为了简化管理框架, 引入了 ServiceManger这个服务。所有的服务都是从 ServiceManager开始的,只用通过 Service Manager 获取到某个特定的服务标识构建代理 IBinder。在 Android 的设计中利用 Service Manager是默认的 Handle为 0,只要设置请求包的目标句柄为 0,就是发给 Service Manager 这个 Service的。在做服务请求时,Android建立一个新的 Service Manager Proxy。Service Manager Proxy使用 ContexObject 作为 Binder和 Service Manager Service(服务端)进行通讯。 我们看到 Android代码一般的获取 Service建立本地代理的用法如下: IXXX mIxxx=IXXXInterface.Stub.asInterface(ServiceManager.getService("xxx")); 例如:使用输入法服务: IInputMethodManager mImm= IInputMethodManager.Stub.asInterface(ServiceManager.getService("input_method")); 这些服务代理获取过程分解如下: (1) 通过调用 GetContextObject调用获取设备上下对象。注意在 AndroidJVM概念空 间的 ContextObject只是 与 Service Manger Service通讯的代理 Binder有对应关系。这个 跟 c++概念空间的 GetContextObject意义是不一样的。 注意看看关键的代码 BinderInternal.getContextObject() @BinderInteral.java NATIVE JNI:getContextObject() @android_util_Binder.cpp Android_util_getConextObject @android_util_Binder.cpp ProcessState::self()->getCotextObject(0) @processState.cpp getStrongProxyForHandle(0) @ NEW BpBinder(0) 注意 ProcessState::self()->getCotextObject(0) @processtate.cpp,就是该函数在进程空 间建立 了 ProcessState 对象,打开了 Binder 设备 dev\binder,并且传递了参数 0,这个 0代 表了与 Service Manager这个服务绑定。 (2)通过调用 ServiceManager.asInterface(ContextObject)建立一个代理 ServiceManger。 mRemote= ContextObject(Binder) 这样就建立起来 ServiceManagerProxy通讯框架。 (3)客户端通过调用 ServiceManager的 getService的方法建立一个相关的代理 Binder。 ServiceMangerProxy.remote.transact(GET_SERVICE) IBinder=ret.ReadStrongBinder() -》这个就是 JVM空间的代 理 Binder JNI Navite: android_os_Parcel_readStrongBinder() @android_util_binder.cpp Parcel->readStrongBinder() @pacel.cpp unflatten_binder @pacel.cpp getStrongProxyForHandle(flat_handle) NEW BpBinder(flat_handle)-》这个就是底层 c++空间新建的代理 Binder。 整个建立过程可以使用如下的示意图来表示: Activity为了建立一个 IPC,需要建立两个连接:访问 Servicemanager Service的连接, IXXX 具体 XXX Service 的代理对象与 XXXService 的连接。这两个连接对应 c++空间 ProcessState中 BpBinder。对 IXXX的操作最后就是对 BpBinder的操作。由于我们在写一个 Service 时,在一个 Package 中写了 Service Native 部分和 Service Proxy 部分,而 Native 和 Proxy都实现相同的接口:IXXX Interface,但是一个在服务端,一个在客服端。客户端调用 的方式是使用 remote->transact方法向 Service发出请求,而在服务端的 OnTransact中则是处 理这些请求。所以在 Android Client空间就看到这个效果:只需要调用代理对象方法就达到 了对远程服务的调用目的,实际上这个调用路径好长好长。 我们其实还一部分没有研究,就是同一个进程之间的对象传递与远程传递是区别 的。同一个进程间专递服务地和对象,就没有代理 BpBinder产生,而只是对象的直接应用 了。应用程序并不知道数据是在同一进程间传递还是不同进程间传递,这个只有内核中的 Binder知道,所以内核 Binder驱动可以将 Binder对象数据类型从 BINDER_TYPE_BINDER 修改为 BINDER_TYPE_HANDLE或者 BINDER_TYPE_WEAK_HANDLE作为引用传递。 AndroidAndroidAndroidAndroid 核心分析 之七------Service------Service------Service------Service深入分析 Service深入分析 上一章我们分析了 Android IPC架构,知道了 Android服务构建的一些基本理念和原理,本章 我们将深入分析 Android的服务。Android体系架构中三种意义上服务: Native服务 Android服务 Init空间的服务,主要是属性设置,这个IPC是利用Socket来完成的,这个我将 在另外一章来讨论。 Navite服务,实际上就是指完全在 C++空间完成的服务,主要是指系统一开始初始化,通过 Init.rc脚本起来的服务,例如 Service Manger service,Zygote service,Media service , ril_demon service等。 Android服务是指在 JVM空间完成的服务,虽然也要使用 Navite 上的框架,但是服务主体 存在于 Android空间。Android是二阶段初始(Init2)初始化时建立的服务。 1 Service本质结构 我们还是从 Service的根本意义分析入手,服务的本质就是响应客户端请求。要提供服务, 就必须建立接收请求,处理请求,应答客服端的框架。我想在 Android Service设计者也会 无时不刻把这个服务本质框图挂在脑海中。从程序的角度,服务一定要存在一个闭合循环框 架和请求处理框架 分析清楚服务框就必须弄清楚以下的机制及其构成。 (1)闭合循环结构放置在哪里? (2)处理请求是如何分发和管理? (3)处理框架是如何建立的? (4)概念框架是如何建立的? 2 Service基本框架分析 Android设计中,Native Service和 Android Service采用了同一个闭合循环框架。这个 闭 合 循 环 框 架 放 置 在 Native 的 C++ 空 间 中 , ,ProcessState@ProcessState.cpp 和 IPCThreadState@IPCThreadState.cpp两个类完成了全部工作。 在服务框架中,ProcessState是公用的部分,这个公用部分最主要的框架就是闭合循环框架 和接收到从 Binder来的请求后的处理框架。我们将服务框架用 ProcessSate来表示,简言之: (1) addservice (2) 建立闭合循环处理框架。 int main(int argc, char** argv) { sp<ProcessState> proc(ProcessState::self()); addService(String16("xxx0"), new xxx0Service()); addService(String16("xxx1"), new xxx1Service()); … ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool();//闭合循环框架 } 2.1 Native Service Native Service是在系统 Init阶段通过 Init.rc脚本建立的服务。 首先来看看一个例子 mediaserver@main_mediaserver.cpp的建立过程。 int main(int argc, char** argv) { sp<ProcessState> proc(ProcessState::self()); sp<IServiceManager> sm = defaultServiceManager(); LOGI("ServiceManager: %p", sm.get()); AudioFlinger::instantiate(); MediaPlayerService::instantiate(); CameraService::instantiate(); AudioPolicyService::instantiate(); ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); } 我们将代码向下展开了一层,更能看到事物的本质。 int main(int argc, char** argv) { sp<ProcessState> proc(ProcessState::self()); sp<IServiceManager> sm = defaultServiceManager(); defaultServiceManager()->addService(String16("media.audio_flinger"), new AudioFlinger()); … ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); } (1)服务进程建立了 ProcessState对象,并将给对象登记在进程的上下文中。 (2)建立一个新 AudioFlinger对象,并将对象登记 Service Manager Service中。 (3)开始就收请求,处理请求,应答这个循环闭合框架。 2.2 Android Service Androids service是系统二阶段(Init2)初始化时建立的服务。 Android 的所有服务循环框架都是建立 SystemServer@(SystemServer.java)上。在 SystemServer.java中看不到循环结构,只是可以看到建立了 init2的实现函数,建立了一大堆 服务,并 AddService到 service Manager。 main() @ com/android/server/SystemServer { init1(); } Init1()是在 Native 空间实现的(com_andoird_server_systemServer.cpp)。我们一看这个函数就 知道了,原来这个闭合循环处理框架在这里: init1->system_init() @System_init.cpp 在 system_init()我们看到了这个久违的循环闭合管理框架。 { Call "com/android/server/SystemServer", "init2" ….. ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); } Init2()@SystemServer.java中建立了 Android中所有要用到的服务: Entropy Service Power Manager Activity Manager Telephony Registry Package Manager Account Manager Content Manager System Content Providers Battery Service Hardware Service Alarm Manager Init Watchdog Sensor Service Window Manager Bluetooth Service statusbar Clipboard Service Input Method Service NetStat Service Connectivity Service Accessibility Manager Notification Manager Mount Service Device Storage Monitor Location Manager Search Service Checkin Service Wallpaper Service Audio Service Headset Observer Backup Service AppWidget Service 3 ProcessState和 IPCThreadState 从宏观来讲,PocessState及其 IPCThreadState处于 IPC与内核打交道包装层。前面的章节已 经提到,下面我将更详细的分析。有关 IPC的 c++空间的实现都是从 ProcessState这个对象 完成的。 我们可以得出如下的结论:不管 JVM的 Binder 做了多么复杂的操作,最终还是需要利用 ProcessState 这个 c++空间的对象把数据传递给 Binder Driver,接收数据也是通过 ProcessState这个对象完成,ProcessState是所有 Binder IPC必经的通道。 ProcessState放置在全局变量 gProcess 中,每个进程只有一个 ProcessState 对象,负责打开 Binder设备驱动,建立线程池等。而 IPCThreadState每个线程有一个,IPCThreadState实例 登记在 Linux线程程的上下文附属数据中,主要负责 Binder数据读取,写入和请求处理框 架。IPCThreadSate在构造的时候,获取进程的 ProcessSate并记录在自己的成员变量mProcess 中,通过 mProcess可以获取到 Binder的句柄。 3.1 ProcessState的生命周期 既然 ProcessState是 Binder通讯的基础,那么 Process必须在 Binder通讯之前建立。 客户端,服务端都必须建立。由于现在重点讨论服务端,所以重心放置在服务端。在 Android 体系中有 c++空间的服务,JVM空间的服务,这两类服务在本质上相同的,只是形式上不 同,由于他们都是建立在ProcessState这个基础上,所以在形式上不同就仅仅 表现在对 OnTransact的回调处理的不同。 Native Service 我们直接可以看到使用 sp<ProcessState> proc(ProcessState::self()),建立建立 ProcessState,一 旦调用 ProcessState就建立了,并且这个 self将 ProcessSate登记在全局变量中。 Android Service 建立 Android Service服务 system_init @System_init.cpp中我们可以看到相同的结构。有一点 不同的是所有的 Android Service都运行在一个进程中:systemsever进程。 3.2 Binder Driver包装 @IPCThreadState ProcessSate 构造的时候,使用 open_binder 打开 /driver/binder,并将句柄记录在 mDriverFD,在 ProcessState 中并不使用这个句柄,真正使用这个 Binder 设备句柄的是 IPCThreadState,所有关于 Binder的操作放置在 IPCThreadState中: (1) 读 取 \ 写 入 : talkWithDriver ( ) @IPCThreadState 对 ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr)进行包装。 (2)请求处理:executeCommand(...)@ IPCThreadState (3)循环结构:joinThreadPool() joinThreadPool() { While(1){ talkWithDriver(...) ... executeCommand(...) } } AndroidAndroidAndroidAndroid 核心分析 之八------Android------Android------Android------Android 启动过程详解 Android 启动过程详解 Android从 Linux系统启动有 4个步骤; (1) init进程启动 (2) Native服务启动 (3) System Server,Android服务启动 (4) Home启动 总体启动框架图如: 第一步:initial进程(system\core\init) init进程,它是一个由内核启动的用户级进程。内核自行启动(已经被载入内存,开 始运行,并已初始化所有的设备驱动程序和数据结构等)之后,就通过启动一个用户级程序 init的方式,完成引导进程。init始终是第一个进程. Init.rc Init.marvell.rc Init进程一起来就根据 init.rc和 init.xxx.rc脚本文件建立了几个基本的服务: servicemanamger zygote 。。。 最后 Init并不退出,而是担当起 property service的功能。 1.1脚本文件 init@System/Core/Init Init.c: parse_config_file(Init.rc) @parse_config_file(Init.marvel.rc) 解析脚本文件:Init.rc和 Init.xxxx.rc(硬件平台相关) Init.rc是 Android自己规定的初始化脚本(Android Init Language, System/Core/Init/readme.txt) 该脚本包含四个类型的声明: Actions Commands Services Options. 1.2 服务启动机制 我们来看看 Init是这样解析.rc文件开启服务的。 (1)打开.rc文件,解析文件内容@ system\core\init\init.c 将 service信息放置到 service_list 中。@ system\core\init parser.c (2)restart_service()@ system\core\init\init.c service_start execve(…).建立 service进程。 第二步 Zygote Servicemanager和 zygote进程就奠定了 Android的基础。Zygote这个进程起来才会建立起 真正的 Android运行空间,初始化建立的 Service都是Navtive service.在.rc脚本文件中 zygote 的描述: service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server 所以 Zygote从 main(…)@frameworks\base\cmds\app_main.cpp开始。 (1) main(…)@frameworks\base\cmds\app_main.cpp 建立 Java Runtime runtime.start("com.android.internal.os.ZygoteInit", startSystemServer); (2)

编辑推荐

  • 名称/格式
  • 评分
  • 下载次数
  • 资料大小
  • 上传时间

用户评论

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

相关资料

资料评价:

/ 128
所需积分:1 立即下载
返回
顶部
举报
资料
关闭

温馨提示

感谢您对爱问共享资料的支持,精彩活动将尽快为您呈现,敬请期待!