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 上写程式有关系,之后将另文介绍。

发表评论

电子邮件地址不会被公开。 必填项已用*标注