Android剖析和运行机制

翻译之《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例子： [cpp] view plain copy

//mustbeprovidedbyeachAcmehardwareimplementation
typedefstruct{
int(*foo)(void);
char(*bar)(void);
…
}AcmeFunctions;
constAcmeFunctions*Acme_Init(conststructEnv*env,intargc,char
**argv);

库在runtime时按需动态加载 [cpp] view plain copy

dlHandle=dlopen(“/system/lib/libacme.so”,RTLD_NOW);
...
acmeInit=(constAcmeFunctions*(*)(conststructEnv*,
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对象来访问。例如：

[java] view plain copy

LocationManagerlm=(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

更多相关文章

随机推荐