Android 淺探

goandroid

MMDays 通常不寫技術文，不過我想從技術角度出發，來探討 Android 做了些什麼，讓人能做什麼，並且儘量採用非本科也能瞭解的語言。筆者並非 Android 開發者，故疏漏可能難免，還請指正。
Java
Android 所採用的語言是 Java，先從這開始談起。一般所謂 Java 其實包含三個元素，其一是 Java 這個「電腦語言」，也就是像這樣的東西：
class HelloWorld
{
    public static void main(String [] argv)
    {
        System.out.println("Hello, world!");
    }
}
也就是用人比較容易看懂的語言(也許不那麼容易啦，但至少比一堆 0 跟 1 來得好)來叫電腦做事，比如上個例子是在螢幕上印一行字 Hello, world。我們還會需要一個「編譯器」，來把這語言從人看得懂的，翻譯成電腦看得懂的。容後再論。
第二個元素是「Java 虛擬機器」(後稱JVM, Java virtual machine)。電腦的核心 CPU 是有很多不同種類的。一般我們用的是 Intel 的產品，有些是 32 位元、有些是 64 位元。有些人用的可能是 Power，例如部分蘋果電腦的使用者。還有一些小一點的電腦，可能就是用 ARM 架構。總之，不同的 CPU 使用方法也不同，指令是不能直接互通的。虛擬機器就是設定一些共通的指令，然後針對各種不同的架構各寫一個程式去配合這套指令。如此一來，我們只需要把程式編譯成「虛擬機器」看得懂的就行了。Java 使用的共通指令就稱做 “Java bytecode”。
其三是 Java runtime library，也就是一個「函式庫」，裡頭存了很多編譯好的現成程式，來讓開發者使用，這樣就可省下很多重覆的工作。比如上頭這例子裡頭的 System.out.println 就是函式庫提供的。那我們可以想像，如果在程式中我們用了很多某個函式庫裡頭的東西，但是用的人只拿到編譯好的程式，但沒有同樣的函式庫，那這程式還是不能用。比如說，Windows, Linux提供的基本函式庫就很不一樣，所以做同樣事情的程式，寫法可能完全不同。Java 函式庫裡頭提供的工具，是有標準可循的，所以以上的程式，不管是要在 Windows 上頭跑，或是 Linux 上頭跑，都是一樣的寫法。
二跟三兩者加起來，合稱 “Java Runtime Environment”, JRE. 它可以讓編譯好的 Java 程式「跨平台」。怎麼說呢？我們用 Java 這個語言寫程式，呼叫 Java 函式庫裡頭的工具，最後用編譯器編成共通的指令集，交給虛擬機器去執行。如此一來，同樣的程式在各個地方都能跑了。這雖然聽起來很棒，但我們可以想像，由於隔了一層虛擬機器跟函式庫，一定會比直接下命令來得慢，而且也要有人針對某作業系統跟某 CPU 架構去寫了這套東西，大家才能用。另外一個想法就是，那為何不直接把程式碼公開，讓大家針對不同的情況去處理，這樣就不需要虛擬機器，速度也一樣快，不就兩全其美了嗎？自由軟體走的就是這樣的路子。
問題是，許多公司不想公布自己的程式碼，因為必須要靠它賺錢。Java 讓他們可以不公布程式碼，只發行編譯好的程式，就在各平台上執行。使用者只需要安裝虛擬機器跟函式庫就行了。我們可以說，Java 是適合商業應用的。這點是很重要的一個特性。
以上的觀念大概瞭解了以後，我們看看 Android 在這部分做了什麼。
一、語言部分
Android 使用的 Java 語言並沒有不同，原本熟悉的工程師仍可以繼續使用。
二、虛擬機器
Android 使用的虛擬機器叫作
Dalvik
，原本並不是針對 Java 設計的。它認識的指令集並不是 Java bytecode，而叫 Dalvik executable，簡稱 dex。Android 裡頭提供了一個工具程式叫 dx，可以把 Java bytecode 再翻譯成 dex，這樣 Dalvik 就知道怎麼執行它了。這虛擬機器為了適合在電話這種比較小型的平台上使用，而做了許多最佳化的處理，例如減低記憶體的使用，而且可以有效率的同時執行好幾個程式。它仰賴底層的 Linux 作業系統來幫他處理一些事情，意味著目前 Dalvik 是綁在 Linux 上的。
三、函式庫
Android 提供了大部分的標準 Java 函式庫(來自於
Apache Harmony
)，並把他們轉換成 dex 的格式，如此 Dalvik 才認得。除此之外，還提供了很多獨有的函式，讓使用者可以直接呼叫來使用電話、GPS等元件，或者是一些視覺的元件來取得跟其他 Android 程式相同的外觀。
Android 虛擬機器與函式庫合稱 Android Runtime。它有幾個特性：

• 不能直接執行編譯好的 Java 程式。要轉換成 dex 檔案後才能執行。
  
• 若此程式使用了 Android 未提供的函式，仍不能執行。
  
• 若我們拿到了 Android 應用程式，無法在 Java Runtime 上跑起來。原因為 1. 必須把 dex 轉回 Java bytecode，這難度目前不明。2. 沒有 Android 提供的獨有函式。

仔細思考的話，會發現所謂 Android Runtime 跟 Java Runtime (尤其是 Sun所提供的套件)的不同處很多，只是「剛好」Android 提供了很多 Java 函式庫裡的功能，讓 Java 工程師可以無痛的轉換罷了。另外就是他仍然保持了對商業應用的親和性，只要發行編譯好的 dex 檔案，而不需公布程式碼。
延伸閱讀：
1.
Dalvik: how Google routed around Sun’s IP-based licensing restrictions on Java ME
關於 Android 如何繞過 Java ME
2.
with Android and Dalvik at Google I/O
對 Dalvik 有興趣的話一定要看

篇目的在儘量不觸及技術細節的情況下簡介 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 的簡報還提供了兩個重點：

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 上寫程式有關係，之後將另文介紹。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/85805/showart_1421746.html