Android 淺探：系統架構【转】

系统架构

Oct 11th, 2008 by Mr. Holiday 

来自 ： http://mmdays.com/2008/10/11/android-淺探二：系統架構/

本篇目的在尽量不触及技术细节的情况下简介 Android 架构，并探讨其设计的特殊处，以及在版权上的意义。主要资料来源为 Anatomy & Physiology of an Android，有兴趣深入研究的读者可参考。

首先来一张现在大概已经很有名的图片：

由下到上，可以看到红色的 kernel 层，绿色的系统函式库，黄色的虚拟机器，以及蓝色的 Java 程式码。以下将一一介绍。

Linux kernel

必也正名乎：一般所称 Linux，其实是统称，指根基在 Linux kernel 以及其他许多跟 kernel 不见得有关的软体所组成的作业系统。最早，Linux 一词其实是专指 kernel，它提供了系统底层与硬体间的基本平台，让其他程式可以在上头执行。其最早作者是Linus Torvalds，他用自己的名字，加上採用了与 Unix 系统相容的介面，将自己的作品命名为 Linux。

如前所述，在 Linux kernel 上头执行的程式，跟 kernel 本身不见得有关系。可以是自由软体，也可以完全不是。把它加上一些自由软体，例如基本的函式库、工具、图形介面，应用程式等等，所组成的一套完整作业系统，才是一般所称的 Linux。为了避免误解，而且也为了正确传达自身的贡献，自由软体基金会建议大家称唿这样的一套作业系统为 GNU/Linux。其中的原因是，kernel 提供底层机制，但系统中重要的元件几乎都是来自于 GNU，也就是自由软体基金会。

希望大家还没被这些名词搞混。要弄清这些不同的原因是，Android 是在 Linux kernel 上头运作的，但他并不是 GNU/Linux。因为在一般 GNU/Linux 里面会有的东西，Android 很多都没有。

Linux kernel 的版权是 GNU General Public License version 2 (GPLv2)，这又是什么玩意呢？GPLv2 是所谓的 Copyleft 版权，简单来说，就是为了确保智慧财产能够继续公开流传，所以任何基于此创作的延伸创作，都自动採用了相同版权。GPL本身还有个特色，就是「共同运作」也算是延伸的一部分，意思是说你的程式没直接改GPL的程式码，但是连结了GPL的东西跟你的程式共同运作，那你的程式也必须採用GPL版权。

举例来讲，假定今天某公司觉得某GPL软体不错，拿来改了改，放在自己的产品里头拿出去卖，那某公司就一定要明确的一起散佈修改后的程式码。如果没有，那就是触犯版权了。有个组织叫 GPL Violations，专门抓这种案例，国内公司如 D-Link 以及 ASUS 都上过榜。这下问题来了：如果你是硬体厂商，希望你的硬体能在 Linux kernel 下运作，那么就必须要有驱动程式。驱动程式就是按照硬体的规格写的程式，用来告诉 kernel 怎么操作这个硬体。如果驱动程式的程式码公开，等于硬体规格也公开的差不多了。许多厂商不愿意这么做，所以就提供编好的驱动程式，但不提供原始码。版权所有者，也就是 Linus Torvalds 以及其他许许多多的 kernel 作者们，为了支援尽可能多的硬体，对这种行为是採取睁一只眼闭一只眼的态度，也就是目前这种编译好的驱动程式，算是处在灰色地带。

既然 Android 採用了 Linux kernel，当然得照游戏规矩来。但我们从前文可知，Android 的重点就是商业应用，他们可不愿意系统里有什么「灰色地带」，于是採用了一些手法来绕过这问题。他们把驱动程式移到 “userspace”，也就是说，把驱动程式变成在 Linux kernel 上头跑，而不是一起跑的东西，这样就可以避过GPL。然后，在 kernel 这边开个小门，让本来不能直接控制到硬体的 “userspace” 程式也可以碰得到，这样只要把「开个小门」的程式码公佈就行啦。事实上，目前因为 Android 已经发行，所以依法他们已经公开了对 kernel 的修改，其原始码在http://git.android.com/。

走笔至此，可以看出 Google 的原则之一 “Do no evil” 是很有意思的。他们自己的确承诺，而且也愿意公开 Android 的程式码，但是他们给了其他人 “Do evil” 的选择。这样还算不算是 Do no evil 呢？当作哲学问题吧。

关于 Android 对 kernel 的修改，Google 的简报还提供了两个重点：

1. Binder (IPC)：提供有效率的程式间沟通管道(Inter-Process Communication)。Android 系统中有很多服务，而上层的应用程式经常要取用这些服务，一般的 Linux 系统已经提供了不少 IPC 的方式，不过 Android 还是搞了套自己的。虽说文件中解释原因为「一般 IPC 会造成额外资源花费，以及安全问题」，但其实这些都是可以基于原有架构在 kernel 外头解决的，为何要改在 kernel 里头，笔者对此存疑，也只能等找时间去研究程式码才知了。
2. Power Management：与桌上型电脑或笔记型电脑不同，手持装置的电源一向相当有限，必须无所不用其极的去想办法省电，但又不损及顺畅的使用经验。Android 在此採取了颇为积极的作法：「没有人说要用，就关掉」。例如某程式在放 MP3 音乐，于是此程式会需要 CPU 的计算能力，那就得开口要。如果与此同时没其他程式在执行，那么 LCD 显示器就可能被关掉，藉以省电。另一特别处，是在于 Linux kernel 一般考虑的都是在电脑上的作法，所以多半只有进入暂停、休眠等等的选择，而不会如此细緻的去控制到各个小装置的电源供应。

系统函式库

这里说的系统函式库是指 “native libraries”，是跑在系统里头的函式库，採用的语言不是 Java，提供一些基础建设。里头有几个值得一提的元件：

1. Bionic：这是 Android 版的 libc。libc 是 GNU/Linux 以及其他类似 Unix 系统上最基础的函式库，一般最常用的是 glibc，就是 GNU 做的 libc。不然在比较小型的装置上也可以用 uclibc。不论是 glibc or uclibc，版权都是LGPL (GPL 的略为弱化版)。看到这大概可以猜到了吧，又是 Copyleft 问题。官方的说法是，除了版权问题以外，还考虑必须轻量以及快速，所以才做了自己的 libc。不过轻量、快速，本来就是小型装置用的 uclibc 一开始的目标，因此，最主要的恐怕还是版权问题。
2. Webkit：鼎鼎大名的 Apple Safari 浏览器背后的引擎就是 Webkit，Android 也包含进去了。离线使用的 html 配上 html 5 的一些新发展，产生了各种有趣的可能，这部分值得另文介绍，这里就不再赘述。
3. Surface Flinger：提供把各种”surface”组合在一起的能力。在这里 surface 解释为程式想要显示在萤幕的东西，可能同一萤幕上有来自不同程式的内容，而这些内容有可能是 2D 显示或是 3D 显示等等之类。Surface flinger 就是把这些东西结合起来，一起送到萤幕上。目前程式码还没公布，不过 2D 跟 3D 的混合显示一直都是问题，根本原因是我们通常告诉 3D 显示卡的东西都是一些「我要在哪里哪里画上什么形状，贴上某某材质然后旋转多少度」之类的事情，也就是说，我们并不知道最后显示出来会长什么样子，那是显示卡上头的 GPU 去算出来的。一般这些东西是显示在一个有装饰的视窗里头，这装饰通常是 2D 效果。接下来假定我们想要旋转这整个视窗，而且里头的东西还要继续动，那等于要随时把握 3D 视窗里的东西长什么样子，然后把它跟 2D 的视窗框框结合，然后再开始转动。目前在一般 GNU/Linux 上这件事情还没有处理的非常好，Android 怎么做，值得在程式码公布之后注意。
4. 硬体抽象层 (Hardware Abstraction Libraries)：这就是前文所述的 userspace 驱动程式，如果想要将 Android 在某硬体平台上执行，基本上完成这些驱动程式就行了。其内定义了 Android 对各硬体装置例如显示晶片、声音、数位相机、GPS、GSM 等等的需求。

Android Runtime 前文已有涉及，这里不再重复。另外蓝色部分的 “Application Framework” 主要是跟如何在 Android 上写程式有关系，之后将另文介绍。