[Android] Android架构体系（2）

文章目录

Bionic
- 精简对系统调用的支持:
- 不支持 System V IPC:
- 有限的 Pthread 功能:
- 有限支持C++:
- 不再支持本地化和/或宽字符:
- Bionic新增的特性
- - 系统属性
  - 硬编码写死的UID/GID
  - 内置了DNS解析
  - 硬编码写死的服务和协议
硬件抽象层
Linux内核
- 匿名共享内存(ASHMem)
- Binder-Binder
- Logger
- ION 内存管理
- 内存不足时的进程终止器
- RAM Console
- Sync driver
- 定时输出和 GPIO
- wakelock
参考

[Android] Android架构体系（1）

Bionic

抛开合法性问题不提，相对于GLibC,Bionic 也可以算是非常轻量级的了，而且对于Android所要达成的目标,Bionic 也更为有效。Bionic 中去掉的下列这些特性的原因或是认为没有必要或是认为太过复杂。

精简对系统调用的支持:

由于系统用是使用得非常频繁的，所以 Boinic 想要通过尽量减少对它们的封装的方式，降低因使用系统调用而引起的开销。系统调用的 stub 函数是在bionic/libc/SYSCALLS.TXT 的帮助下自动生成的，甚至有些系统调用都不会被导出。

不支持 System V IPC:

在 Boinic 没有导出的系统调用中，有一部分是用来处理UNIX System V 进程间通信(IPC，Inter-Process-Communication)和共享内存的。这是由于 Android 的设计使然，去掉这种形式的 IPC，而改用Android自己的IPC。

有限的 Pthread 功能:

一方面，Bionic 本身就支持 Pthread (即不需要一个单独的libpthread.so)。

但是另一方面，Bionic 对 Pthread 的支持也不是很全面，不少特性已经不再支持了，其中最值得注意的就是现在已经不能使用的pthread cancel()这个用来杀线程的函数了。

对 mutex 的支持也被阉割掉了，取而代之的是更为高效的内核快速 mutex(futex(2)系统调用)，此外较为高级的IPC对象(比如rwlocks)也已经不复存在了。

有限支持C++:

尽管确实是支持 C++的(而且事实上Android 的大多数代码也是用C++写的)，但是异常处理已经不支持了。与之类似，STL (Standard Template Library，标准模板库)也已经不再包含在其中了一一尽管也不是严格地不让使用 STL，不过得要手工添加一些代码才行(部分代码可以在external/stlport 项目中找到)。

不再支持本地化和/或宽字符:

Bionic 原生只需要ASCII–尽管通过 libutils.so还是可以使用Unicode的。

去掉这些东西还是很有道理的，特别是考虑到 Android 中大部分代码是跑在虚拟机里的,而使用虚拟机本身就意味着不需要 App
的开发者使用这些功能。例如，虚拟机有自己的线程管理和 Unicode 支持 (通过ICU)。不过，去掉这些特性还是会给原生代码的开发者带来一些麻烦，特别是那些想要把一些库从 Linux 移植到 Androd 上来的程序员。

Bionic新增的特性

Bionic 也在标准 LibC 中新增了一些特性，这些都是为 Android 而特别优化的，这些新增的特性包括:

系统属性

系统属性是 Android 特有的特性,它支持系统或应用在一个简明的由“键/值”构成的存储空间中记录各种配置和操作参数。它类似于 Java 中“属性”的概念(而且事实上它是可以通过 Java 的 System.properties 访问的)。Android 极度依赖于这一机制，系统属性是在一段共享内存中实现的，系统中的所有进程都能以只读权限访问它，但只有 imit 进程才有对它进行设置(写)的权限。

硬编码写死的UID/GID

与传统的 UNIX系统中依赖于 passwd 和 group 文件进行权限管理的方式不同，Android 中选择使用硬编码写死的id，并模拟getpwnam(3)及其相关函数的方法进行权限管理。我们只要考虑一下 Android 的安全模型，就会觉得这一做法也不无道理：

Android 中每个应用都会被分配到它自己的UID 和GID (从10000 开始)，而且这些ID会被映射为方便人来阅读的格式，例如：app_uxXX (或者从JellyBean 版起，这一格式改为:uX_aYYY)。

此外Android 把数字较小的UID/GID (1000-9999)保留了下来，供它自己的子系统使用。

内置了DNS解析

Bionic 中整合进了“名称-IP”的DNS 解析代码(在传统 Linux中，这部分代码是放在 libresolv.so 中的)。

Bionic 中使用的代码更为安全(源端口和Query ID都是随机的，这样做能有效地防范“生日攻击”)，并且引入了一个新奇的特性一一每个进程都可以有自己的 DNS 解析服务器列表。

这使得特定的应用可以通过重新设置net.dns.pid系统属性的方式，抓取 DNS 解析的结果或者重定向解析 DNS 请求的服务器。
DNS 配置本身也是存储在系统属性中的(net.dns#)。

硬编码写死的服务和协议

因为已经把原来 libresolvso 做的事都给包圆了，Android 中就去掉了传统 UNIX 系统中通常是放在/etc 目录下的 protocols 和 services 这两个文件。

硬件抽象层

Android 会运行在许多不同种类的设备上 (平板电脑、手机、机顶盒、跑步机等)，底层硬件在适用范围和支持方面都有极大的不同。

为了解决这个问题，Android 定义了一个硬件抽象层(HAL，Hardware Abstraction Layer)，其目标是通过定义一个转换层，使对各种不同类型硬件的操作趋于标准化。

硬件厂商可以在内核态中随心所欲地使用它们自己生产的设备的驱动程序但是必须提供一个接口库 (shim)，以Android (特别是 Dalvik) 预期的方式与操作系统对接。

硬件抽象层上定义了从 Android 的角度看来，摄像头、GPS、传感器以及其他的硬件组件应该是个什么样子。

这并不会妨碍厂商扩展或修改硬件的功能，只需要厂商把接口库放到/system/lib/hw 目录里去就行了，然后 HAL(硬件抽象层)(也就是 libhardwareso) 会自动加载它们。打印某台Android设备使用的HAL接口库，例如：
在这里插入图片描述

Linux内核

Linux 内核得益于它开源和免费授权的本质，为 Android 提供了一个极为出色的基底。

尽管它现在已经和 Linus Torvalds 最初的版本差了不止十万八千里，但是 Linux 内核仍在以不可思议的速度演进着一每个月，甚至每一周都会增加新的特性。Android 所能拥有的功能在很大程度上会受到内核的影响。

较为有名的例子当数 zRAM 和对 64 位的支持。后者有助于解释为什么表Lollipop版的Android 系统会有两个最低版本，因为 Linux 内核是从3.7 版开始才支持 ARM64(AArch64)的。

谷歌在选择内核版本时也会受到一些限制，因为它只能从http://www.kernel.org 网站中选择那些被标为长期支持 (long term)的内核版本。

与其他 Linux 内核相比，Android 内核被编译得稍有差异。因为配置文件生成时同时使用了Android 的基础配置和默认内核发布版本中的建议配置模板。

如 source.android.com 网站中 kernel

前文中已经提到过，Android 在内核中引入了一些它特有的特性(Androidism)。

其中的一些被放在内核的 core 中，用条件编译语句#ifdef 加了一层保护，而剩下的则被放在了drivers/staging/android 目录中。

这些Android 特有的特性包括:

匿名共享内存(ASHMem)

这是一种允许进程间共享内存的机制。应用可以打开一个字符设备节点 (/dev/ashmem)并创建一段内存空间，然后再把它映射 (map)到进程内存中去。这需要把工作限定在非全局可写(no world-writable)的目录中，并进行 SystemV进程间通信。

Binder-Binder

是 Android 中所有进程间通信的关键，它源自于 BeOS。Binder 表现为个所有进程都能够打开的字符设备节点 (/dev/binder)。Android 中的各种服务都注册在 Binder 这里，客户端可以在 servicemanager 的帮助下连上相应的服务。Binder 提供了一个有效的高级进程间通信机制。