前言
在Apple iPhone引起了廣大群眾和業界對於高階行動裝置應用的注目，另外也在市面上掀起了一陣波瀾。 從許多角度觀看iPhone，iPhone可以說是一個銷售不錯的單一產品。 然而iPhone能否持續熱潮也是相當值得注意的事。 而Microsoft一直有著自己的手持式平臺Windows CE/Mobile與相關的合作夥伴。在這塊市場上目光也集中在另一個軟體巨頭-Google，對於Google在這塊市場的後續行動，或許iPhone的炒作起了作用，iPhone單一產品的思維讓人們一直不斷地傳言Google將類似Apple iPhone也推出自己的手機終端產品gPhone。 甚至有人對於該預期存在的gPhone的
產品規劃和網路應用方面，都有相當的預測。而在2007年11月，Google公布了Android計劃，一方面映證了Google確實對於Mobile
Device有著長久的計劃和行動，一方面也否定了gPhone這樣單一的產品存在。如預期的網路上出現了許多關於Android的評論，綜觀這些評論，
有的是淺嘗即止，有的是過於聚焦在技術層面的政治爭議，不然就是忽略了平臺技術在應用上的影響和差異差異而大放市場策略的預測，更甚者拿著現有的
Android
Emulator說著不知所以的說著gPhone抄襲iPhone的UI的可笑話。本文希望從系統和技術層面上探討Android對於應用層面的影響，或
許透過對於Android正確的認知，可以對於市場策略上的分析能有更正確的判斷。
Just Another Mobile Linux Platform?
乍看之下Android只是個有如OpenMoko/MobiLin/GreenPhone等眾多開放式手持Linux平臺的一個，並沒有甚麼特別之處，然而進一步了解之後，就不難了解Android 平臺在系統建構上獨到的設計。可以說Android重點並不在於Linux，而Android專案採用了這樣的組合，在整體規劃上考量了相當廣的的層面，自個人/第三方軟體開發，系統開發建構，實際應用性到系統平臺開放性。 而Android 計劃除了制定了系統架構外，還針對這個平臺提供了完善的軟體開發工具與環境，在IDE上採用了開放式開發平臺 Eclipse，在該IDE 上建構了Android 專屬的plugin。 另外還以自由軟體QEMU為基礎提供了Android平臺專屬的Emulator，讓個人/第三方軟體商迅速開發軟體，無需依靠實際硬體開發軟體。
Application/Application Framework
對於開發者而言，開發Linux Mobile/Embedded 軟體時，多半採用C/C++做為軟體開發語言，由於C/C++目前的開發工具與底層硬體平臺有相當的相關性，因此首先遭遇到的問題是cross-tool chain的使用和開發環境的架設，再來就是每個Mobile Linux組織所制定出不同的embedded linux平臺有相當迥異的system architecture/runtime environment，而各組織所提供的軟體開發環境，也並不如Win CE/Mobiles單一系統一般有一致的架構及API，更不用說對於硬體平臺的多樣性更有著軟體相容性的問題，因此即便API能做到有如Windows CE/Mobiles一般的一致，在各種硬體平臺(ex:ARM/MIPS/PowerPC..)也無法建立單一且能夠相容且運作的binary，相較於在現在以x86為主要硬體平臺的開發環境，行動裝置硬體平臺的多樣性對於軟體開發和使用性上無疑增添了不少硬體限制，而Java軟體雖能夠解決這方面的問題，然而Java因為設計上的緣故，在應用性上更為侷限。在這方面Android很特別的，採用了Java Language來做為App的撰寫語言。 採用Java語言的好處相當多，物件導向語法相較於常用的C語言更便於GUI Programming Model的建置，另一方面Java開發及執行環境的建構在Desktop 上相當容易，參考文件的維護也較為容易，而且Java相關的開發工具已經很齊全且成熟，再者Java所制定的bytecode，沒有所需要對應平臺的問題。儘管最後在Android平臺上執行的並非Java bytecode ，而是自有的dex 格式，然而dex 格式也有如Java bytecode般取決於VM的實作，而VM的角色在Android平臺終適度的隱藏了底層硬體的差異。
Runtime Environment - Libraries & Dalvik VM
在Rutime方面的library層面上，為了提供基本且標準的功能，Android 還是針對平臺的執行環境制定了一套標準的C/C++ Library set，從現有的標準模組看來，主要是針對網路/多媒體/GUI以及安全性提供底層的實作，值得注意的是在此Android特別將OpenGL ES/SQLite的納入，使得系統對於3D/資料庫有著標準支援。而儘管平臺上有著C/C++ libraries，這部分並不讓開發者在開發軟體時直接地使用，C/C++libraries在使用上還是間接地透過上層的Application Framework，並且透過Virtual Machine(VM)使用類似Java JNI技術來橋接 libraries 與 VM的運行。 由於軟體開發上使用了Java Language，若要使用Java VM這對於一般使用者與開發者而言難免存在著應用性相當侷限，執行效率不佳，系統資源需求過高，以及Java ME授權等問題的存在。 為了解決上述這些問題，Google 特地實作了Dalvik VM，Dalvik並非是Java VM，因此所執行的也並非是bytecode，目前需要依靠轉換工具將Java bytecode轉為Dalvik VM執行時特有的dex(Dalvik EXcutable)格式。Dalvik VM相較於Java VM最大的不同在於Java VM為Stack-based，而Dalvik是register-based。 以技術層面考量Register-based VM的特性有個很大的好處，那就是對於現有主流的硬體架構，如此很容易與現有系統整合且最佳化，而所需要的資源也相對較少。 甚至在硬體實作VM上會比較容易實現。 最重要的是Dalvik 並非是Java ME的實作，因此沒有Java ME授權相關的議題。 由android目前的介紹可以看出Dalvik目前實作在Linux 平臺[2]，僅依靠Linux kernel作低階動作與memory management。
而從這一點的延伸更可以看出Android平臺中的重點為負責執行層面的Dalvik
VM而非Linux，也因此Linux在Android平臺中所扮演的角色並非是舉足輕重的主角，也可以想見Google採用Linux的原因是
Linux本身所具有的自由開放的特性，而另外在手持式裝置中Linux已經具有相當質量的軟體開發資源，另外就是VM的使用，考量到的就是軟體在各式硬
體上的通用性，所以對於有些人猜測Android最後還是會開放C/C++
API供開發者使用，若是如此，Android就失去了最大的特點，與LiMo/OpenMoko之類的Mobile
Linux平臺無異，所以這是太不可能發生的。既然採用了VM的方式，這麼一來，Dalvik
VM在其他平臺上建構也不無可能，或許這樣的推敲或許也能合理解釋在Open Handset Alliance成員中有著長期耕耘Windows
Mobile平臺的HTC在列。
Eclipse IDE + Android Emulator
針對特定平臺提供完善的開發/除錯工具，以及整合式的開發環境是開發行動應用軟體的另一個困難點，針對此點Google為Android平臺開發了一系列的開發/偵除錯工具。 一系列的工具中最引人注目的莫過於Eclipse ADT-plugin和Android Emulator。現今，獨立的IDE軟體開發需要投注相當多的人力和時間，因此以提供eclipse plug-in的方式來達到提供完善的IDE目的，對於許多開放專案或商業產品而言，這樣的作法已經是首選。 而提供Emulator更可以解決在軟體開發階段對於硬體平臺需求的問題。 從Android Emulator的程式碼[3]看來是以QEMU為基礎，延伸打造了該Emulator，功能上除了一些無法以軟體模擬的功能外(USB連線，SD 插拔，Audio-In，Camera，電池/AC狀態…等等)，甚至許多的偵錯功能是與Emulator環境整合的(有興趣的話可以下載SDK和Eclipse ADT來玩，在Eclipse上所開發的程式可以很直接地輸出到Emulator上執行，無需製作image或是安裝)，在硬體模擬程度上相當的全面。在開發工具上，Android透過QEMU/Eclipse的方式，以很務實簡單的作法達到了這樣的目的。Google在Android平臺上大量採用了開放和自由的軟體，不害怕公開程式或視之為洪水猛獸，這樣的作法相較於Symbian/ PalmOS/ Windows Mobile而言，宣告了軟體上的高價值不在於封閉進而販賣程式碼和SDK工具本身，透過採用開放/自由軟體的力量，更能加速達到目的和增加自身的價值。
Java的美麗與哀愁 - Dalvik所引來技術上的政治爭議
這個部分寫的有點長，是個人看了一些討論後的想法，沒有興趣的話請跳過。在Android平臺採用Java語言做為程式開發語言的同時，提出了
Dalvik
VM。這樣的舉動引起最廣泛探討的是：Android是否分裂了Java。在討論這樣的問題之前，或許該討論Java本身的問題，在這裡個人提供另一個思
考觀點，Sun在Java的提出之後，一度曾經想過將Java交由ISO標準化，然而或許是透過JCP對於Java在各應用上制定的完全主導，讓Sun由
Java在各方面確實地獲得了相當的利益，所以即便面對Microsoft提出.NET這樣對於許多人而言美好又開放的平臺的挑戰，長久以來Sun還是一
直以相同的論調來否決開放Java這個語言，而這個論調就是："這會分裂Java"。從Java的出現，在軟體開發的歷史上確實有著相當的意義，然而
Java的提出到現在經過的時間並不算短，即便是歷史最悠久的Java
SE在現今Desktop應用上還是相當侷限，這樣的結果或許可以去檢討的是，或許Java淪落到現今這樣的局面是Sun自己導致的。多年來Sun封閉了
Java讓Java只在他們允許的方式下運作，在bytecode + stack
VM低落的效能和反應下，多少開發者期望能用Java語言開發原生(Native)程式，而又有多少開發者在AWT/
Swing這樣既具有難以有效駕馭的UI
Model而且又與系統本身的Look&Feel格格不入的情況下充滿挫折，更不用說許多難以理解的各種不實用的應用Framework
(ex: JMF/Java3D). 而這許多問題當人們嘗試自己解決而提出不錯的方案，像是GCJ 和 Eclipse
SWT，換得的是Sun的無視或敵對。而許多的方案換得的是:
"Java已經有了XXX，這樣的做法會分裂Java"。這麼一句總是出現的話，到底是不是因為它本身真的很有道理？至少Sun
達到目的了，與Java扯上的問題第一個被討論的總是"它會不會分裂Java？"，Sun這麼多年來是否有心改進Java？這個問題或許Sun應該捫心自
問，在人們對於Java在應用上的各種需求的改進有所要求的同時，Sun對於Java是否真的針對貼近人們本質需求而改進？檢視過去Sun
到底做了甚麼，在"分裂Java"這樣的保護傘下，原本大好前程的Java又改進了甚麼？這樣一來"Android是否分裂了Java？"是對於問題的一
箭中的還是只是長年來受到的刺激的反射式思考？Android計劃中Dalvik
VM的出現不妨視之為軟體開發演進中的必然，一方面Google從沒宣稱說這是Java，而現今也有其他程式語言能夠開發在Dalvik
VM上運作的軟體。如果Sun的Java做的夠好Dalvik可能就只是Java的次世代技術。Dalvik
VM的問題點或許只是在於扯上了Java而不在於他是個VM，在不同的Instruction Set上用Java語言開發程式，在GCJ/.Net
iKVM出現的同時就已經被證明了，如果這算分裂Java，那這件事一直因為人們的需求而發生。軟體開發或許就如同電影侏儸紀公園中所說的"Life
will find its
way."，更不用說開發軟體的是人，程式開發者總是期盼有更好的系統架構和方案。在相容性的保護問題上，在網路上有人問過"為何沒有人有勇氣對
Google詢問他們對OpenJDK的質疑"，或許人們該想想Sun用了這麼多的手段去控制Java的演進，卻無法自己提出Dalvik，那麼
Google這麼做除了保障平臺的相容性又何能控制全球的人們往更好的應用方向發展？另外許多軟體廠商(Ex: Trolltech)
說了"Google不過是制定了另一套Java"，這樣的說法某些層面上是對的，但是對於由這些人說出的這些話，姑且以Android計劃會妨礙他們的產
品(Ex

topia/Jambi)的銷售這樣的想法而一笑置之。
說了這麼多，那Android到底是甚麼?
總結上述歸納幾點:
1. Android是個軟體平臺，讓人們可以開發軟體。這代表拿Apple iPhone與之相比，不只是不對等，更凸顯出iPhone的譁眾取寵和Apple的短視無力(SDK原本是不打算開放的), 拿iPhone與Android現有UI相較更是可笑的舉動.
2. 和以往的Mobile平臺不同的是，Android的設計讓它在採用VM得到類似Java
bytecode在不同硬體平臺的相容性的同時，VM對於底層硬體平臺貼近的設計能夠依然保有相當不錯的效能。相較於Windows
Mobile限定使用ARM CPU, 其他Mobile Linux平臺則僅止制定了API層次的一致的作法，Android 算是有突破性的作法。
3. 現在的Android是Linux平臺，不過由於Android的核心在於上述的VM實作，這代表未來底層軟體平臺也或許是可以轉換的(甚至是Desktop)。目前缺乏詳細Dalvik VM實作細節這項目純屬猜測。