android学习笔记----架构剖析
- 格式：pdf
- 大小：733.54 KB
- 文档页数：15
Android学习笔记----Android架构剖析首先在网上google了一下，发现对Android进行源码分析的文章并不少，不过大都着重于细节描述，初学者反而会陷入代码的细节中缺乏对全局的把握。
以我学习的经验初学新知识时先从大局入手，等了解系统框架的构成后再逐步深入，下图是Android系统的架构图(官方的标配)：这幅图是Google的原创图，网上很多的架构图应该都是基于此图。
完整的演讲稿和视频来自于2008 GoogleI/O大会（https:///site/io/anatomy--physiology-of-an-android），基础好的同学建议结合演讲稿认真看下整个演讲视频，强烈推荐！看完此视频基本上对Android架构心中有数了。
下面基于这篇演讲稿“Android Anatomy and Physiology”从底层到上层逐步解剖：Layer1: Linux KernelLinux内核，对应上图中红色部分。
这是Android的操作系统层，主要用C语言编写。
1.1 Android基于Linux Kernel，但不是Linux。
演讲稿上说当时是基于2.6.24，而从Linux3.3开始Android对内核代码改动部分已经融入kernel主线。
据说最新的Android4.3是基Linux 3.8，等到7月9号就知道Android4.3的新特性啦!Android不是Linux。
在我看来Android本质上就是Linux的一个变种，不管是上图绿色部分的Libraries还是黄色部分的 Dalvik VirtualMachine(Android不在使用原java的HotSpot虚拟机,原因不解释)，以及蓝色Application Framework的部分Service都直接使用了Linux kernel提供的API。
甚至于虚拟机上层的Java库最终也是下层API的面向对象的封装（比如你可以自己编写一个Java类库接口提供到特定硬件的访问）。
好像基本上所有的基于Linux的智能手机系统如Meego，Tizen等都不会在命名中提到Linux，可能长期以来在普通用户心中Linux 就是界面不友好的代名词，厂商考虑到产品形象不会在产品名称中包含Linux字样。
1.2 没有本地窗口系统。
这是肯定的，没有带X Window这种在Linux发行版中广泛使用的GUI系统。
1.3 没有glibc支持。
废话，这是Linux kernel。
1.4 没有包含标准Linux中一系列工具集。
一般的嵌入式Linux都不会包含，都是裁剪后的能满足需求的最小系统。
1.5 提供了内核增强补丁以支持Android。
包括Alarm（时钟），Ashmem（匿名共享内存），Binder（IPC驱动），Power Management（电源管理），Logger（日志记录），Low Memory Killer（替代标准Linux中的OOM Killer，在内存不足时有选择性地杀掉非活跃进程）。
补充：从Android 3.0开始在kernel的netfilter模块中又增加了xt_qtaguid支持应用程序流量计数，引入xt_quota2支持流量限制告警。
1.5.1 Binder IPC。
为什么不用常规的IPC？这里给出了答案：常规IPC会引入过重的处理开销和安全漏洞，并且通过共享内存实现的IPC性能更高。
1.5.2 PM电源管理。
Android的电源管理是基于标准的Linux电源管理模块，并提供的更多的策略和不同类型的wake lock。
Layer2: Native Libraries本地库，对应架构图中绿色部分。
大量使用了开源软件，主要用C/C++编写。
2.1 Bionic Libc库。
为什么要使用Bionic Libc库而不是标准的Libc库，这里提到了几个优点：Bionic库是专为CPU和内存受限的嵌入式系统而实现的libc 库，其代码短小运行速度很快，而且有很精简的pthread多线程库实现。
另外其License不是GPL而是BSD，以此规避了GPL License的感染性。
其缺点是：不支持某些POSIX标准功能，并不完全兼容glibc。
2.2 Function Libraries。
Android所需要的各种功能库，如Webkit提供浏览器所需的各种基本功能，Media Framework提供音频视频的各种编解码，SQLite 提供轻量级的关系型数据库。
2.3 Native Servers。
本地服务器。
如Surface Manager负责图像显示管理，Audio Manager负责音频管理。
2.4 Hardware Abstraction Libraries。
这一层就是所谓的硬件抽象层，是用C/C++编写的动态库文件。
这一层相当于是用户态程序和底层驱动交互的一个中间层，本质上还是在用户空间。
其目的主要是为了规避GPL License，保护硬件设备商的知识产权。
Layer3: Android RuntimeAndroid运行时库，对应架构图中黄色部分。
主要用C/C++编写。
3.1 Dalvik Virtual Machine。
Java世界的基础Dalvik虚拟机，Java代码所编写的.class/.jar文件最终都在编译时转换为.dex文件格式。
专为嵌入式环境设计的设计，支持每个应用进程一个虚拟机实例，高度优化的字节码解释器，能更高效地使用运行时内存。
在我看来，实际上每个Java应用在启动后都会动态链接到libdvm.so这个动态库文件，然后由这个动态库文件对.dex文件进行解释执行Java字节码。
3.2 Core Libraries。
Java的基本核心库，提供Java常用的一些基本类，如标准I/O，文件访问，网络访问，图形界面等。
Layer4: Application Framework应用层框架，对应架构图从上到下的第二层蓝色部分。
这一层为最上层的Java应用提供一些公共的服务和框架，主要用Java和C/C++混合编码。
其中公共服务主要分成两大类：核心平台服务和硬件服务。
4.1 核心平台服务包括Activity Manager（Java应用程序激活管理），Package Manager（Java应用程序安装卸载管理），Window Manager（图形界面窗口管理），Resource Manager（资源管理），Content Provider（数据共享服务），View System （也和图形界面管理有关）。
4.2 硬件服务包括Telephony Service（电话相关服务，如拨号，短信，彩信，GPRS等），Location Service（GPS定位服务），Bluetooth Service（蓝牙服务），WiFi Service（WiFi服务），USB Service（USB服务），Sensor Service （传感器服务，如重力感应，温度计等）。
更多介绍请参考Google I/O的另一次演讲“Inside the Android Application Framework”。
前面部分是从软件系统架构上剖析Android的静态组成，下面是从运行时入手，剖析Android的系统的启动过程和各层间的交互。
Part1: Start-up Walkthrough1.1 和常见的嵌入式Linux一样Kernel启动完成后会调用/sbin/init作为第一个启动的进程（进程pid为1）。
此后init进程会解析/etc/init.rc文件启动一些daemon服务如usbd，adbd，debuggerd，rild。
1.2 启动Service Manager这个服务管理进程，此进程会打开Binder驱动，负责Service的注册和查找。
注意：在这篇演讲稿中Zygote的启动在Service Manager之前，但根据我对Android 2.3源码中init.rc的分析，Service Manager的启动是在Zygote之前，甚至于1.1提到的一些daemon如debuggerd，rild都在ServiceManager之后。
这篇演讲稿应该是基于比较老的Android版本，以下分析都是以Android 2.3源码为准。
1.3 启动Zygote进程，这个进程主要做哪些事情呢：- 初始化Java虚拟机环境- 预加载公共的Java类并在一个unix socket上监听- 若收到请求则为指定的Java应用程序fork出一个新的虚拟机实例- 通过fork调用加快了虚拟机实例的创建速度，并利用copy-on-write最大化利用有限的内存资源这意味着所有的Java应用程序都是通过Zygote这个受精卵快速创建出新的Java应用，并且fork出来后Java的runtime环境以及公共的Java类已经初始化完毕了。
不得不说在这里fork被应用得相当的精妙。
1.4 Runtime进程发送请求到Zygote启动System Service。
（原文：Runtime process sends request for Zygote to start System Server）注意：在Android2.3中System Server并不是这样启动的，并不是Runtime进程通过socket发送请求到Zygote要求fork出System Server，而是Zygote进程在启动后主动通过fork调用分裂出System Server。
1.5 启动到了System Server，现在看看System Server做了哪些事。
首先启动两个Native Service：Surface Flinger和Audio Flinger。
在Android 2.3中实际上先启动的是Surface Flinger和Sensor Service。
这两个Service 都要通过Binder向Service Manager注册（下图中虚线部分表示注册Service）。
然后，System Server继续启动其他各种各样的Service，并且这些Service都要向Service Manager注册。
1.6 至此，系统环境准备完毕。
下图中的RUNTIME代表Service Manager。
1.7 当系统准备完毕后，最终会启动HOME程序，这就是大家看到的手机桌面。
可以看出，HOME也是一个独立的Linux进程，有自己的Dalvik虚拟机实例。
Part2: Layer Interaction层间交互方式主要有三种：·App -> Runtime Service -> lib·App -> Runtime Service -> Native Service-> lib ·App -> Runtime Service -> Native Daemon ->lib 看起来很抽象吧，下面逐个分解:2.1 第一种交互方式：App ->Runtime Service -> lib在这里Runtime Service是一个独立的服务进程，这个服务进程会通过JNI直接调用Native Library中提供的服务接口函数并动态加载HAL Library（硬件抽象层的动态库）。
