香醇咖啡

綜觀自2008年底AOSP¹公佈以來，從2009年當紅炸子雞，所有廠商都要做Android相關產品，各種相關活動場場爆滿，到2010年漸漸回歸常態，該掛的掛，該起的起，做出些成績的都是大廠，而其他廠商雖在政府重點補助下，仍然沒什麼起色。究竟採用Android有什麼好處、進入困難的門檻何在、國內以硬體廠商為主的思維碰到了什麼問題？以下從個人觀點分析。

Open Source帶來的衝擊

許多專案/產品管理者，在面對採用開放源碼為主的軟體專案時，經常碰見以下問題。

1. 對程式碼的了解/掌握度：大多數情況下，現存的程式碼並不能完全符合專案的需求，仍需要一定程度的修改。然而，開放的程式碼並不一定容易修改，大部分情況下也沒有充分的文件說明，最多說明一下如何使用，對程式碼內部結構的文件可就更稀有了。大型、複雜的專案可以非常難追蹤、理解，不恰當的拙劣修改常常導致事後維護上的困難，但具有恰當修改能力的工程師非常稀少。對整體架構沒有全盤掌握時，修改、除錯、維護所需的資源都難以估計，造成專案更高風險。
2. 缺乏概觀：根基於開放源碼的產品常由許多專案組成，而這些專案會基於不同的科技，在系統的不同層面有不同的功能。他們之間的互動方式，以及在整個系統中扮演的角色，在沒有適當背景知識的情況下是難以理解的。故，要維持住對產品概觀的了解，以及掌握專案各部份的狀態，會變成一項挑戰。專案管理者必須對核心優勢以及商業價值有正確理解，對其他部份採取開放態度，藉此獲得社群的支援，以減低開發難度。
3. 不知與upstream合作：開源專案多半有負責維護的個人/團體，就是此處所指的upstream（上游）。要了解程式碼，以及取得支援，最直接的方法就是與上游保持良好關係。實務上最佳解決方案為，與上游直接合作，將自行開發的錯誤修正與新功能等等都回饋到原先專案。由於有貢獻，上游自然也更願意視為一份子。然而，首先公司內部文化必須克服，如何讓保守文化理解到，將非核心的開發成果公開出去與上游直接合作，實際上無損公司，並且有利減低研發成本。克服之後，還要面對與適應開源社群不同的開發模式、工具與文化。
4. 法律問題：許多商業組織刻意或非刻意的違反開源軟體的著作權要求。這會讓他們有被Harald Welte²這樣的人控告的危險，而且有損商譽。這些商業組織需要有經驗的人來處理開放源碼的著作權益題，尤其是產品本身必須混合自行開發的封閉程式碼以及開放源碼的情況。

Android帶來的額外挑戰

AOSP是由OHA主導的開放源碼專案，其背景與傳統上開放源碼略有異同，一開始差異頗大，但開放至今，其文化已較為趨近傳統開源專案。原因無他，在長時間的適應下，原先的開源專案文化，許多因素已可視為最佳實務(best practice)，有利於軟體發展。比如鼓勵貢獻、盡量公開開發流程、增加社群互動等等。此系統亦帶來了一些新的挑戰，嘗試略述如下：

1. 除錯需跨越各層：Android是由許多不同技術結合起來的複雜集合。系統上大部分提供的服務，其程式碼都由數種不同的程式語言組成，並在系統的不同層級執行。在平台內除錯（而非對應用程式層之內，這部份相對簡單）經常需要在application層、runtime層與library層來回對照，這比傳統上單純的C/C++程式碼除錯複雜許多。
2. 需跟上快速的上游開發速度：由最早的1.0/1.1到其後1.5 (Cupcake), 1.6 (Donut), 2.0/2.1 (Eclair), 2.2 (Eclair)，短短近兩年時間改變甚大，而每版又有明顯更動/改進，使得緊跟上游成為一困難課題。這意味著，當產品還在開發，其版本可能就已經過時，而業者就必須同時進行跟進與產品化，包括細節整修、除錯、新功能開發等等。這對軟體開發團隊而言是很大的挑戰。這在業界引起的效應相當明顯，例如各家廠商旗下Android手機更新版本速度不同，能力不足廠商到2.2時可能還在出1.6版的產品等等。
3. 不同領域的技術知識：如上所述，Android是一複雜的集合。週邊、電源管理、手機通訊協定、圖形加速、虛擬機器(Dalvik)、toolchain、使用者介面設計、認證等等，每個都是大題目。Android提供了一個可以往上建造的平台，然而與此同時，也需要更多領域的知識，而這些在之前可能都是由需付費的軟體提供者，例如微軟，來負責的。這意味著更高的進入門檻。

麻煩很多，優點何在？

Android很紅，這點大家都知道，市場一片樂觀，廠商紛紛跳入。然而，在跳進之前，若能先理解這倒底是怎樣的系統，特點何在，為何採用，才容易抓到開發重心。基於Android的產品各家都喊了，到現在卻是幾家歡樂幾家愁，不是沒有原因。

若如前例採用微軟視窗系統，則維護由微軟負責，廠商付費使用即可，相對單純。然而，就廠商角度而言，對系統控制低，要怎麼改都是付費看人臉色，很難累積自己的成果。比如從Windows Mobile 6.5到Windows Mobile 7，介面能客製化的程度降低，微軟的識別度增加，對想主打自身品牌辨識度的廠商來說，就不是好事。然而，做軟體就好像堆磚頭，在現代，製作一套完完全全從底層到上層所有功能都自己來的作業系統，一塊塊從底層堆起，是相當大的工作。以PC上運作的GNU/Linux系統為例，底層為Linux kernel，也就是作業系統的核心部份。而運行在這核心之上，有各式各樣的軟體，有的可以讓我們傳 MSN, Yahoo messenger、看網頁、收發 email 等等之類。在 Microsoft Windows 上我們有些熟悉的軟體來做這些事，在開放源碼的世界同樣也有，例如許多人都聽過，而且也可以在 Windows 上使用的Firefox。把許多開放源碼軟體組合起來呈現給使用者，形成一套完整的作業系統，這樣的組合就稱作 Linux distribution（後簡稱distro）。

一distro則可由社群、非營利組織或是公司來維護，其內有成千上百元件，大部份都是開源軟體，其間共同運作是否順暢、各元件維護、處理錯誤回報、修正等等，需要相當大的研發資源。如目前當紅的Ubuntu，就是由Canonical公司主導。但，到了手機領域，若想以現有系統為基礎自行開發，之前就沒有什麼真正主流的選擇。Meego的出現可能會帶來改變，不過這部份有待觀察，應另文討論。Android為何廣泛被考量作為產品之軟體平台，很大原因即在於它是一套由Google主導的開放源碼作業系統，以此為基礎，可以為廠商省下許多的研發成本，而專注於開發產品獨特的優勢。

也就是說，Android的存在，是建立了一個大家可以在其上建造的「標準平台」，而且「可以修改」。

另外一個重要的考量，則是軟體的流通。作業系統不同，程式也會不能互通。在A系統可以跑的程式，在B系統不見得能跑，因為他們對軟體的組合選擇以及採用的版本可能都不同。在開放源碼的世界，程式碼都是公開的，這就容易解決，由distro維護者選取配合的版本，把他們從原始碼一一編譯起來，發行給使用者就行了。然而，對商業應用程式的開發者來說，這就是一大問題，因為同時支援這麼多平台的花費太高。另一問題是，假定採用的硬體CPU不同，那麼就算採用同一系統，在不同硬體上，仍然無法共通，例如Intel與ARM based CPU就是。Android的存在，可從兩方面來解決這些問題：

1. 系統組合與維護交由Google and OHA主導，所以軟體平台可以固定下來，以AOSP release為參考點即可。
2. 不同硬體相容性，由Android runtime解決，只需在framework上可以執行，不同硬體影響可由Android負責處理。

Android在同一時間主流版本有限，並有一定程度的向前相容。例如以本文寫作時來說，2.2的平台為主流，並且可以向前相容上一個主要版本，也就是1.6的應用程式。而只要熟悉了Android Framework，就可以持續的開發應用程式。就此角度而言，Android與Windows類似，都減低了發行封閉原始碼程式的困難度。例如下一主流Windows版本應為Windows 7，那麼程式設計師只要以Windows 7為目標平台來製作應用程式即可，大部分之前由XP, Vista累積下來的經驗，都仍然有效。

然而Android帶來的改變，其實還不只於此。前面提到Android runtime可以讓程式在不同CPU架構下執行。在桌上型、筆記型電腦的世界，大家CPU都是 Intel，不同硬體架構的問題不大。然而到了移動裝置的世界，由於要考慮到功耗等等因素，採用的CPU種類就往往不同。這意味著，兩個裝置就算安裝了相同版本的某作業系統，但是CPU架構不同，也照樣不能執行。以往對於此問題的解決方法稱為Java ME，也就是採用Java runtime。對應到Android，則是由Android runtime解決。

走筆至此，讀者應可了解，Android提供了一方便開發、執行應用程式的平台。程式被創作出來，編譯、包裝成Android應用程式之後，便可一併通行各種不同裝置上的Android作業系統。

因應之道

了解Android開發的困難點，以及採用的好處以後，系統廠適應的策略為何呢？由現有例子可以觀察到，只要研發能力足夠，所有的問題都不是問題：拿回來全部in house自己做就行了。有趣的是，國內公司並不見得整體研發能力不足，而是公司體制內各自為政，不同部門互不合作，分則力弱，變成各單位分別挑戰，自然會發生人家手機出了一整排，自家公司蹲好久才出個一兩隻還比人家差的情況。在研發資源有限的情況下，最佳解法就是回到基本，了解Android仍然是一開源專案，採取開源專案已知的合作方式即可。也就是說，除了技術理解，對協同開發方式，也必須熟悉。視專案規模大小與不同需求，以下嘗試提出幾點方案：

1. 其他廠商合作開發，共同維護一份通用程式碼。
   1. 自家客製化部份，可視專案需求，與提供商業Android服務的公司/獨立開發者合作，或由內部訓練團隊。
   2. 外部需尋找的對象為，不只理解開放源碼如何運作，也懂得商業價值的重要，易於溝通。
   3. 由內部訓練專家。仍需要一些顧問作為種子，需時較長，但可在公司內培養出自有團隊。
2. 內部一定要有對開放源碼協同開發方式經驗豐富的經理人。不論合作、驗收、內部培養，都非常重要。
3. 在共通與自有程式碼混合情形下，需有對開放源碼著作權問題有研究的法律顧問。

建立標準、開放合作

如前所述，可以理解通用程式碼的重點應在於共用功能以及硬體支援。以目前業界情勢來講，採用的硬體平台正快速的收斂，例如手機台廠主流多為Qualcomm，既然如此，小廠可依樣畫葫蘆，合作維護一份「基於常見硬體的Android版本」，以AOSP發行為基礎，針對幾個硬體平台合作開發。畢竟將系統在某硬體上動起來，只是產品化的初步而已。以生產製造為強項的廠商，可以以此版本為基礎，專注在自己擅長的生產。而以軟體研發見長的廠商，則可以在此版本上專注於商業應用程式開發。自有品牌者，則可專注於使用者經驗、介面辨識度、工業設計等等。在共同需要的部份合作，而專注精力在自身擅長領域即可。

功能部份，由於Android並不限於手機，目前已經可以看到平板電腦與電視的應用。同一領域中，基本的功能是共通的，例如支援高解析度螢幕，來處理平板與電視的應用，平板需要不同的使用者介面，而電視需要能躺在沙發上輕鬆的操作等等。以上這些基本門檻，都是廠商可以共同努力的範圍。例如發源於日本的OESF³，就是典型的這種組織，其主要幾個功能為：

1. 廠商生意交流、媒合的場域。
2. 維護通用程式碼與支援平台。
3. 針對各領域如set-top box, VoIP, DLNA等等，訂定標準介面，開發參考用程式碼。

概念正確，在日本也蓬勃發展，但在台灣的推廣卻由於硬體廠（連同一公司都不知識分享！）的封閉觀念而感到阻力。國內如0xlab⁴自09年起就疾呼此一觀念，也不見明顯成效，實在相當可惜。

回饋上游

Android一出，最理解此一系統的當然是Google以及當年共同開發的Wind River。只是Google重心一直在軟體平台，不輕易做支援，Wind River又奇貴無比，致使Android系統內部知識益形珍貴。時至今日，開發應用程式的說明文件已經相當完整，內部結構的文件仍然欠奉，最佳的文件就是程式碼本身。至於未來開發方向，以及Google內部程式碼與外部的差異等等，Android開發團隊非常忙碌，無心也無力主動提供。身在外圍，要取得這些資訊，最佳方式便是由「工程師對工程師」的社群交流來完成。經由實際操作經驗得知，透過mailing list以及source review⁵往往可以獲得許多有用資訊。

藉由回饋上游，與AOSP達成正向合作關係，對開發團隊大大有利，卻著實違反傳統商業觀念。在硬體微利時代，軟硬體整合以及使用者體驗，都需要更佳的軟體研發能力。現狀既然已經起跑較晚，開源軟體「站在別人肩膀上開發」的特性，其實相當適合台廠快速應變、打帶跑的作戰方式，然而這也需要新的觀念、視野與執行方式。