疯狂

由下到上，可以看到红色的 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 的简报还提供了两个重点：

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

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

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