翻译之《Android Anatomy and Physiology》,下载地址:http://download.csdn.net/detail/wuxiaoer717/6839427



大纲:

1. Android剖析

  • Linux内核
  • 本地库(Native Libraries)
  • Android运行时(Android Runtime)
  • 应用框架

2. Android运行机制

  • 启动流程
  • 层间交互(Layer Interaction)




一、 Android剖析

如下图所示为Android的架构图



1. Linux内核

  • Android系统基于Linux内核,但是Android不是Linux。
  • 没有本地的窗口系统。
  • 没有glibc库的支持。
  • 不包括完整的标准Linux工具集。
  • 标准的Linux 2.6.24内核。
  • 内核增强补丁来支持Android。


1) 为什么选择Linux内核?
  • 强大的内核和进程管理。
  • 基于权限的安全模型。
  • 可靠的驱动模型。
  • 支持共享库。
  • 已经是开源的。

2)内核增强
  • Alarm
  • Ashmem
  • Binder
  • Power Management
  • Low Memory Killer
  • Kernel Debugger
  • Logger
Binder介绍
问题:
应用和服务会运行在各自的进程当中,而进程之间必须要通信和共享数据。而IPC(进程间通信)会引入巨大的处理开销和安全漏洞。

解决方法:
  • 使用驱动来协助进程间通信(IPC)。
  • 通过共享内存来获得高性能。
  • 对于处理请求,每个进程一个线程池。
  • 引用计数,对象的引用是跨进程映射的。
  • 进程之间是同步调用。

Binder的实现机制如下图所示:

Android的接口定义语言(AIDL)见:http://developer.android.com/guide/components/aidl.html

PM介绍
问题:
移动设备是依赖电池供电来运行的,电池只有有限的容量。

解决方法:
  • 基于Linux的功率管理(PM)构建
  • 更加强大的功率管理策略
  • 通过“wake locks”来进行功率管理
  • 支持不同类型的wake locks
Android中的PM实现:
如下图中所示


Android内核源码可以通过如下http://git.android.com获取

2 本地库

本地库包括:
  • Bionic Libc
  • Function Libraries
  • Native Servers
  • Hardware Abstraction Libraries

什么是Bionic?
定制的libc实现,优化用于嵌入式。

为什么选用Bionic?
为什么要构建一个定制的libc库呢?主要从如下方面考虑:
  • 许可证:从用户角度,保持GPL许可。
  • 大小:由于将加载到各个进程,所以需要比较小。
  • 速率:有限的CPU能力意味着我们需要足够的快。
对于Bionic libc:
  • BSD许可
  • 小而快的代码路径
  • 非常快和小的定制的pthread实现
  • 内置支持重要的特定Androud服务,像1)系统属性,getprop("my.system.property", buff, default); 2)log能力,LOGI("Logging a message with priority 'Info' ");
  • 不支持某些POSIX特性。
  • 与GNU Libc(glibc)不兼容。
  • 由于Native代码必须依赖bionic来进行编译。

功能库(Function Libraries)
WebKit
  • 基于开源的WebKit浏览器:http://www.webkit.org
  • 在全视图渲染页
  • 完全支持CSS,Javascript,DOM,AJAX
  • 支持单列和自适应的视图渲染
Media Framework
  • 基于PacketVideo OpenCORE平台
  • 支持标准的video,audio,still-frame格式
  • 支持硬件/软件编码器插件

SQLite
  • 轻量级事务性数据存储
  • 大多数平台的后端数据存储

Native Servers

主要有两大类Surface Flinger和Audio Flinger
对于Surface Flinger
  • 提供系统范围的外观“组合器”,处理所有的外观渲染到帧buffer设备中。
  • 可以结合2D与3D外观和多个应用的外观。
  • Surfaces传递是作为Buffer来通过Binder IPC调用。
  • 可以使用OpenGL ES和2D硬件加速器作为其组成部分。
  • 使用page-flip的双buffer机制。
如下图展示所示



对于Audio Flinger
  • 管理所有的audio输出设备。
  • 处理多个audio流到PCM audio 输出路径。
  • 处理audio路由到各个输出。
如下图示意


硬件抽象层(HAL)
硬件抽象层在Android系统层次结构中的位置如下图所示。

硬件抽象层具有如下特点:
  • 用户空间C/C++库层。
  • 定义了接口,以便让Android请求硬件“驱动”来实现。
  • 分离了Android平台逻辑和硬件接口。

那么为什么在Android中需要一个用户空间的HAL呢?主要有如下原因:
  • 不是所有的组件具有标准的内核驱动接口;
  • 内核驱动是GPL的,其将暴露了所有的知识产权;
  • Android对于硬件驱动具有特定的要求。

HAL Header例子:
// must be provided by each Acme hardware implementation
typedef struct {
int (*foo)( void );
char (*bar)( void );
…
} AcmeFunctions;
const AcmeFunctions *Acme_Init(const struct Env *env, int argc, char 
**argv);


库在runtime时按需动态加载
dlHandle = dlopen(“/system/lib/libacme.so”, RTLD_NOW);
...
acmeInit = (const AcmeFunctions *(*)(const struct Env *, 
int, char **))dlsym(dlHandle, ”Acme_Init");
...
acmeFuncs = acmeInit(&env, argc, argv);

3.Android Runtime


Dalvik虚拟机
是Android中定制的净化实现的虚拟机,由于如下特点:
  • 提供了应用程序的可移植性和运行时的一致性
  • 运行优化的文件格式(.dex)和Dalvik字节
  • Java .class/ .jar文件在构建时转换为.dex格式
Dalvik设计用于嵌入式环境
  • 在每个设备上支持多个虚拟机进程;
  • 高度优化CPU的字节码解释器;
  • 高效的使用runtime内存。

核心库(Core Libraries)
Java语言的Core APIs提供了功能强大的,同时简单和熟悉的开发平台。
  • 数据结构(Data Structure)
  • 工具(Utilities)
  • 文件访问(File Access)
  • 网络访问(Network Access)
  • 图形(Graphics)
  • ...

4. 应用框架(Application Frameworks)


核心平台服务(Core Platform Services),具有如下特性:
  • 对于Android平台来说,服务(Services)是必需的。
  • 在幕后 —— 应用不会直接访问它们。
主要有如下的服务:
  • Activity Manager
  • Package Manager
  • Window Manager
  • Resource Manager
  • Content Provider
  • View System

硬件服务(Hardware Services)
  • 提供访问底层的硬件APIs。
  • 典型地通过局部的Manager对象来访问。例如:
LocationManager lm = (LocationManager)Context.getSystemService(Context.LOCATION_SERVICE);

主要有如下的硬件服务:
  • Telephony Service
  • Location Service
  • Bluetooth Service
  • WIFI Service
  • USB Service
  • Sensor Service
更多的关于应用框架的信息参考:
  • Google I/O :“Inside the Androoid Application Framework”
  • Online :http://code.google.com/android

二、Android运行机制
1. 启动流程
所有从init开始...

与大多数的基于Linux系统在启动阶段类似,bootLoader加载Linux内核,然后开始init进程。


init启动Linux守护进程,包括:
  • USB守护进程(usbd)来管理USB连接
  • Android调试桥守护进程(adbd)来管理ADB连接
  • 调试器守护进程(debuggerd)来管理调试进程请求(dump memory等等)
  • 射频接口层守护进程(rild)来管理与射频的通信


Init进程启动zygote进程:
  • 一个新生的进程初始化一个Dalvik VM实例
  • 加载类,并监听socket端口用于请求创建VMs实例
  • Forks请求创建VM实例用于管理进程
  • 写时复制(Copy-on-write)来最大化重用和最小化覆盖



init进程启动runtime进程:
  • 初始化Service Manager——上下文管理器用于binder来处理service注册和查询
  • 注册Service Manager作为缺省的上下文管理用于Binder


Runtime进程发送请求给Zygote来启动System Service


接着Zygote进程fork一个新的VM实例用于System Service进程,然后启动该service。



System Service启动本地系统服务器,包括:
  • Surface Flinger
  • Audio Flinger


本地system servers注册Servicee Manager作为IPC service目标:


System Service启动Android管理服务:


Android管理服务注册到Service Manager中:


到此,整个Android系统的启动后:


System Server加载完所有的services后, 系统准备...









2. 层间交互(Layer Interaction)
主要有如下三种类型的交互:
  • App -> Runtime Service -> lib
  • App -> Runtime Service -> Native Service -> lib
  • App -> Runtime Service -> Native Daemon -> lib

Android Runtime Services:


举例:Location Manager


Android Native Services:


举例:






Daemon Connection:


举例:RILD

Logo

更多推荐