聖誕夜，我站在辦公室的大會議室裡，老闆臉色紫漲，會議室裡還有老闆的老闆，更大的老闆，以及從來沒見他笑過的那位公司法務人員。我的朋友兼同事 CK 站在旁邊，嘴裡囁嚅著一句話：

「因為電腦不懂尼采…」

這一切，要從幾個月前開始說起…

十月中旬，秋

鈴聲大作，我醒來，集中精神辨認手機螢幕上的數字。必須正確計算二位數加法才能解除鬧鈴，這在乍醒時分可不簡單，就算腦子好不容易拖拖拉拉困倦地算出了個答案——也不知道對還是不對——要在觸控螢幕上把數字好好按進去也難保不出錯。一旦出錯，題目就會換掉，全部重來，搞得你怎也弄不清是算錯，還是打錯？

這麼說來，這隻手機能存活到現在倒是某種小小奇蹟了。打斷好夢正酣的人可是很危險的，更何況腦袋可能並未清醒到足以理解砸毀的東西價值幾何。小小一個裝置，所代表的可不正是人類發達文明的縮影？從高解析的螢幕、觸控、還有背後的相機跟電池，以及電路板上比以前好幾間房大小的電腦還強上許多倍的晶片，更別說不需要電話線數據機，走到哪兒都可以上網。這麼厲害的玩意，除了手機，最常用的卻是一樣的事情，就像好久好久以前的 PDA，跟更久以前的萬用手冊那四大功能：行事曆、電話簿、筆記、待辦事項。再多出來的，多半就花在遊戲跟上網這些電腦上也做的事，差別只是變小台了，走到哪兒都行。是進步了很多，不過，總覺得似乎還有更多才是？畢竟，這玩意有方向感、平衡感、眼睛、嘴巴、耳朵還有觸覺，更可以隨時存取人類有史以來最大的資料庫：網路，說起來，能做的，應該不只是讓人用來看看 Facebook，或是養養寵物、丟鳥砸豬一類的事情才是。Siri 只是第一步，以後還有好多好多會跑出來的。

就這麼照常胡思亂想到了公司，CK 最喜歡這類話題了。工作實在無聊，又耗時間，中午時間閒聊打屁，拖晚些回辦公室，已經成了重要的調劑。看看 email，回幾封信，網站逛一圈就差不多中午，CK 準時出現，敲了敲隔間。

「嘿，吃飯。」

沒聊幾句近來的科技新聞、天馬行空的賺大錢想法、抱怨一下所有好玩應用都先出現在 iPhone 之類，CK 就換了話題。

「跟你說，我昨天發現一件有趣的事情。」

「喔？什麼有趣的？不要又是敗家的喔，你已經嘗試荼毒過我很多東西了。」

「哎呀，不是那些啦。最近有個金馬影展，你知道吧？」

「嗯，你看了啥？」

「有部怪片，叫『都靈之馬』的。」

「講什麼？」

「開場是關於尼采，中間有個人出來講了一堆很像尼采的話卻被主角罵無聊，然後最後好像世界毀滅了。」

「什麼鬼啊？」

「然後整部片只有三十個鏡頭，總長快一百五十分鐘喔，三十個鏡頭。」

「意思是，一個鏡頭平均…五分鐘？哇塞，是像蔡明亮那樣嗎？如果是那不要跟我講了我不想聽。」

「不是，不是像那樣啦。我保證裡面沒有人挖西瓜。但好像更極端，黑白片，對白只有幾句，然後配樂一直都是同一首，而且演員包括那匹馬也只有四個，出現瞬間的不算的話。」

「天啊，越來越糟了。」

「然後我看完了。但好像不覺得無聊耶。這我好幾天以前看的，過了這幾天好像越來越覺得不錯。」

「喔？好，我等下去查查。但很長耶，只有幾句對白，然後演員又那麼少，他們都在幹麼啊？」

「吃飯、穿衣、挑水、睡覺。」

「哇靠，我一定要查一下。但你說你昨天發現有趣的事情，結果到底是什麼？」

「喔，就是都靈啊。」

「啥？」

「都靈啊。那是義大利的一個城市，我昨天發現他的英語拼音跟 Turing machine 的 Turing 好像喔。」

「天啊…你真的是死阿宅你知道嗎。」

CK 說來也是個有趣的傢伙。很少看他加班，但進度倒是都沒掉過。看過一些他的程式碼，簡單明瞭，只是工作本身難度不夠，看不出真正實力。剛說的 Turing machine 應該是計算理論裡頭的玩意，不是他提，早忘到爪哇國去了。至於那部電影，我查了查，是一位叫貝拉塔爾的匈牙利導演拍的，網上還提到之前有位製片人在他另一部電影的拍攝期間自殺，原因謠傳是導演預算花得太兇讓他傾家蕩產。貝拉塔爾說，都靈之馬是他最後一部電影，因為所有他想說的，都已經在這部片說完了。這傢伙，到底看的是什麼玩意啊？

接下來幾天，CK 總是一付睡眠不足的樣子。問他忙些什麼，他說：

「就是那部電影啊。」

「哪部？」

「都靈啊。」

「怎麼還在講那個？你不老早看完了嗎？」

「他只播了六天啊。我想知道第七天發生了什麼。」

「你在講什麼啊天哪？」

「毀滅啊。感覺上那部片就是要說這個。但是它停在第六天，沒有結局。我想知道第七天發生了什麼。」

「這…我查了一下，導演感覺上是會說『我想講的都講完了，影片就是答案』這種話的人耶。我看你八成沒希望了。」

「可是…」

「嗯？」

「你知道他說他是哲學家，然後拍電影只是消遣。」

「嗯，對啊。然後？」

「然後我想，哲學不是都要依照邏輯嗎？」

「對啊。」

「所以我就想啊，第七天發生了什麼，應該也可以用邏輯推斷出來吧。」

「你不睡覺就在想這個？」

「不是耶。」

「那是在幹麼？」

CK 停了半晌。突然開口問：

「你記得有個語言叫 prolog 嗎？」

「哇塞，天啊，你還記得那種鬼玩意啊？是不是那個你告訴它貓很可愛，然後加菲貓是貓，然後就可以問它加菲貓可不可愛那個？」

「對啊。」

「你該不會…」

「對啊，我想應該可以吧。只要我餵給它足夠的資料，它應該就可以跟我說發生什麼事情了。」

「你…你還好吧？」

「感覺上真的可以啊。比如笛卡兒說『我思故我在』，這豈不就可以當一條規則輸入嗎？」

「是啦，但你要輸入很多很多，才有辦法問那麼複雜的問題吧。」

「好像是。但總有更簡單的方法吧…不能叫他自己學嗎…」

「不行啊。你現在趕快離職回去唸書，也許就有辦法嘗試叫它自己學了吧。」

記得那是入秋時候的事情。後來，耶誕節腳步將近，大家都拼著在假期購物潮前出貨，這話題似乎也慢慢淡出。至少 CK 的黑眼圈是消失了。

早該知道事情沒那麼簡單。

入冬

新款手機風評不錯，連帶讓股價也有些長進。CK 寫的應用程式跟著出貨到許多使用者手上。照理說，那玩意是初版，很可能是一堆問題湧入的時候，但他看起來仍是一派悠閒，正常上下班。反倒是我焦頭爛額，一堆東西要追蹤。這天又得加班，近晚餐時分，CK 跑來找我，手上拿著兩杯珍奶。正好偷閒一會，拿到屋頂去喝。

聊了一陣，CK 忽然湊過來，神神秘秘的說：

「你記得前陣子跟你聊過的 prolog 那件事情嗎？」

「記得啊。你還在研究那個？」

「對啊。但我後來想到一個比較簡單的方法。你也知道 prolog 語法還蠻好學的，我把這玩意貼到網路論壇上，請大家幫我新增規則，還蠻多人響應的呢。」

「所以，你找出答案了嗎？」

「沒有耶，失敗。」

「為什麼？」

「因為只能照既有的東西推導，沒辦法創造新的東西。拿以前那個笛卡兒例子來講，你問它上帝存不存在，它就會跟你說不知道。」

「喔，連這種問題也找得出來呀？那不錯啊。」

「是不錯啦，但就沒辦法證明出一個結局了，因為其實結局怎麼寫都可以。」

「哈，我覺得很了不起了，這應該可以拿來檢驗大家的理論完不完備。」

「是啦。但只是完不完備，沒辦法知道對錯。」

「當然沒辦法啦。我記得有人說世界沒有實體，只存在感知者的心中。我猜這應該可以自成一個體系吧，但不見得就是真的。」

「對啊，我就是這意思。」

「所以你放棄都靈第七天的問題了？」

「放棄啦。我想，我高興它發生什麼事，它就是發生什麼事了吧。」

「那你說的那個網上計畫呢？」

「那還蠻有趣的。我現在弄了一個機制，只要有幾個人確認過沒問題的敘述就會自動加入，所以只要有人貢獻它就自己會長。只是長得太快，家裡機器快跑不動了，我那邊有好幾台伺服器閒置，改天移到上頭去跑。」

「哈，不錯喔，給我網址，說不定我回家也加幾條進去。」

「嘿嘿，那也要找得到還沒加過的才行，因為現在已經很多啦。」

CK 提供的介面真的很好玩，還可以問問題，不過由於只有邏輯能力，而沒有類比、歸納，所以大部分問題都沒結論。我試著加了幾條「上帝已死」之類的規則進去，發現早都有人加過了。仔細看看，現存的規則多得嚇人。這真的都是論壇裡的人加進去的嗎？這專案可能比想像的還受歡迎。

接下來那陣子，每當忙得有些煩了，我就會打開專案網頁來看看。資料似乎越來越多，而且幾乎是指數增加。也許這只是一人可以告訴好幾人，而他們又都很感興趣造成的現象。總之我沒多想。反倒是有天，突然想到他之前說，「都靈之馬」拼法很像圖靈（Turing），而眼前我們用的電腦，不也可以當成一台圖靈機器嗎？講起來，辛苦的工程師或許可說是「圖靈之馬」，因為我們天天都在電腦前面像馬拉車一樣工作著。如果試著把一天工作的內容輸入，不知道這系統會怎麼想？

比如，工程師會創造程式，程式會有錯誤，有錯誤就要修，不想修了還是得修，不然薪水會沒有，沒薪水會肚子餓…諸如此類的規則。

沒過幾天，我跟 CK 就在本應放假的聖誕前夕被抓去公司了。所有的伺服器，包括一部分賣出去的手機，都開始輸出亂碼，給出錯亂的回應。

「因為電腦不懂尼采啊。」CK 說。「我只是嘗試教它，看看會怎樣而已。」

老闆把氣勢洶洶的臉朝向我。

「我…我沒做什麼啊。我這幾天嘗試餵了這系統一些工程師的規則，就這樣而已。」

「工程師的規則？」CK 好奇的問。都這種時候了他好像還是缺乏危機感。「是什麼啊？」

「因為我覺得既然都靈很像圖靈，那工程師就很像『圖靈之馬』呀，整天辛苦的寫程式拉車這樣。」

「喔？所以你寫了很多我們日常工作的事情進去嗎？」

「對啊。」

CK 怔了好一會兒。他再開口時，臉上有著奇妙的表情。

「你知道，那部電影的開場是什麼嗎？」

「你們到底在講什麼鬼啊？」老闆有一點疑惑，但仍然是血壓極高的狀態。「到底怎麼回事？你們快點想出一個解決方案來！」

「我想我知道原因了。」CK 說。

「那部電影的開頭是這樣的：尼采在某年某月某日步出了家門，可能是去郵局收信，也可能只是走走。」

「途中，他看到一位車夫正在跟他拉車的馬兒奮戰。馬似乎很老了，不論他如何催促，仍然不動。到了最後，車夫失去了耐性，拿出鞭子開始抽打那匹馬。」

「尼采看到這一幕，突然爬上了馬車，抱著馬兒哭泣了起來。他的鄰居把他帶回家，他躺了兩天，最後說了一句話：『媽媽，我好傻啊…』。之後，他又在母親跟姊妹照顧下活了十年，溫和，但是完全瘋了。」

會議室一片靜寂。

「所以呢？到底怎樣？」老闆似乎在血管破裂的邊緣。

CK 說：

「我想，如果電腦懂了尼采，也會看著我們而啜泣吧…」

後記：
遊戲之作，不惴淺陋。祝所有MMDays讀者聖誕快樂，工作別太辛苦了！

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

將 Android 與 iPhone 的模式比較，可以發現 Google 與 Apple 在思維方式上的不同。Apple 將 iPhone 作為「唯一」的手機平台，所有開發出的程式都在此一平台上執行，好處是對於硬體會有所預期，環境相對單純，壞處則是假設所有人都認同 iPhone 此一產品在硬體與軟體的設計。而 Google 則是將硬體的綁定予以去除，把軟體平台開放。目前對 Android 程式碼有貢獻的，除了 Google 以及 OHA 以外，還包括世界各地的開發者。任何人都可以將想要的修改公佈在 http://review.source.android.com/ 此一網站，由 Android 的工程師審查接受後，就可以進入原始碼中。從 2008 年 10 月 Android 公開以來，每年改版三次，以原始碼的量與複雜度而言，達到這樣快速的改版與開發速度，其代表的研發能量是相當驚人的。iPhone 推出時，號稱領先業界兩年，並不誇大。Android 目前的重點仍放在發展，而不是維護，直到現在，就手機作業系統而言也不過堪堪打平，路還遠著。方便廠商移植等等的軟體內部介面改善，相對成了低優先權，要追上相當花功夫，容後再述。

如此的開放策略產生的結果是，許多細部不同的 Android 作業系統，跑在不同的硬體平台上，由許多不同廠牌發行許多不同的手機。就策略而言，這是類似開放軟體中經常提及的教堂與市集¹ 觀念，或說「中央集權」對上「遍地開花」。短時間來看，由於 Apple 面對的是一單純環境，將此環境加以充分打磨、修飾，呈現出最佳結果是相對容易的。反之就長期言，開放模式代表的「創意」、「多樣化」以及快速的演進速度，相對彈性與發展可能性都大。若以獲利能力論，iPhone 利潤空間為手機業最高，由於量大，對 OEM 廠的談判能量強，價錢可以壓得非常低，而對消費者端，其一向維持的「潮流」「高價」形象，幾乎是市場頂端，但又沒到「買不起」的境界，以可負擔的價格提供時尚奢華感，是非常有利的定位。反之，如前所述，Android Runtime 可讓應用程式在所有的 Android 系統上執行，僅依硬體不同而有不同表現。兩相比較下來，發行 Android 手機的廠商不如 Apple 賺錢，但一片機海，總數超過 iPhone 自然容易。以下是 2010 Q3 的 smartphone OS 數字 (from Communities Dominate Brands) ：

OPERATING SYSTEMS IN Q3

Symbian (Nokia) 29.0 million for 36%
Android (Google) 20.0 million for 25%
iOS (Apple) 14.1 million for 18%
Blackberry OS (RIM) 12.4 million for 16%
Windows Mobile (Microsoft) 2.4 million for 3%
Bada (Samsung) 1.3 million for 2%
Others 0.8 million for 1%

Total 80 million

對 Google 而言，並不介意各廠 Android 手機的獲利，只在乎眼球佔有。追根究底，主要獲利模式仍然是廣告，而廣告就是關於眼球數。只要拿到使用者的目光，就有賺錢機會，而控制平台，正是控制眼球的開始。Chrome OS 以及 Android/Google TV，Android tablet 等等的發展，全是同一道理。

Android Market

應用程式開發出來以後，要如何傳遞到使用者手中呢？與桌上型電腦相比，智慧型手機甚至需要更強的安全保護，因為打電話、傳簡訊、3G上網等等都是直接花費金錢的，一個閃失，可能造成的損失更加直接，私人照片、電子郵件等等被偷走已經夠糟了，如果再發現自己手機發了幾萬封廣告簡訊，那可是雪上加霜。有了執行應用程式的平台，還需要一個可靠的機制，方便的供人搜尋、下載、付費。目前由 Google 提供的 Android Market 就提供了這樣的機制。然而要讓你的裝置可以使用 Market，並不是人人都行，必須與 Google 達成協議，且通過相容性測試之後才可以使用。而要把程式放上去，則需要花錢註冊帳號、上傳，流程並不複雜。安全機制方面，Market 會檢查此應用程式需要哪些權限，使用者同意後才會下載安裝，若程式有問題，也可經由註冊帳號查到上傳者的身份。

對開發者而言，支援某一平台的動力，其一為此平台市占率，其次為消費能力、金流難易。由於 App Store 對應的是市面上 iPhone 的總數，而 Android Market 對應的則是「所有執行 Android（並且可以用 Google Market）的手機總數」，這其中包括了來自不同廠牌的許多型號，其總數要超越 iPhone 自然較為簡單。然而這僅僅是理論，實際上 iPhone 推出較早，初代產品較為優秀，已銷售的支數多，應用程式更多。App Store 在 2008年7月10日推出，到2010年1月的數據，18個月其應用程式已經達到140,000以上² 。反觀 Android Market 在2008年10月22日推出，到2010年10月25日，兩年時間才超過100,000個。³

如果說開放作業系統本身是 Android 的經濟系統重要的一半，那麼另一半必定就是 Market，因為這裡負責提供多樣的應用，以及程式遞送跟收費。在此，開放與分散不受重視，重要的是提供一集中、單一的應用程式集散地，並且讓開發者可以收得到錢。Android Market 在此步調牛步化，台灣一直到幾個月前才開放，追趕動能不如預期。對此 Market 而言，集中就是一切，廠商為了搶這部份的錢，也就是付費的抽成，自然會想自己搞一個。但問題是規模不夠的話，這樣的作法勢必造成可用的應用程式少得可憐，嘗試一陣以後就會雷聲大雨點小的自動消失，且限制了自己銷售的裝置可能的應用程式數量，也不利銷售。除非像中國移動這樣等級的通信商，做自己的 Market 才有意思。

其次是，沒有應用程式的平台是跛腳的。整個 Android 平台乍看之下程式碼開放，實則 Market 部份被卡得死死，沒跟 Google 達成協議，根本沒辦法用到。小廠就算基於 Android 推出手機，無法存取 Market 也是枉然。而大伙一窩蜂推出在其他裝置上的應用，例如平板電腦等等，怎麼賣也不可能賣得贏 iPad，很大一個原因就是沒有應用程式，而目前 Market 以及 Android 官方都並不支援智慧型手機以外的應用。如此情況號稱在3.0推出後可能改變，但在那之前，各廠就得自求多福了。由此我們可以看出 Google 的哲學，拿住幾個關鍵，其餘盡量開放。由非 Goolge 之第三方提供的類似機制，目前已經有好幾個網站，例如 AndAppStore, SlideMe, OnlyAndroid 等等，但都還不成氣候。就廠商角度來說，只要是 Android 平台，就算自身的研發能力足夠做出合格的產品，Market 部份也還是得看 Google 臉色。

手機以外…

Android 是為智慧型手機設計的作業系統，但其應用可以擴展到其他裝置上。2009 年有許多廠商嘗試將 Android 與小筆電（netbook，如 EeePC） 結合，但很明顯並不成功。原因是，推出 Android 小筆電的廠商並沒有從使用者的角度出發去思考這件事情。商品出門，其定位究竟是「裝置」還是「電腦」，使用者會將其視為 Windows 系統的延伸嗎？一般的使用案例能不能滿足？若不能滿足，替代方案是什麼等等問題，都必須思考。而 Android 原先的使用者介面是針對手機的小型螢幕，擴大到小筆電，螢幕大小不同，輸入裝置不同，使用者介面當然要有相對改變。亦即，將系統移植完成僅僅是開頭，之後還需針對使用者需求再做調整。做完也還沒結束，有句話說，”Experience is the product”，做完軟硬體僅僅是開端，使用者整體的使用經驗才能代表這產品。從此觀之，同樣是數位隨身聽，為何 iPod 一出可以打敗一票硬體並不見得差的對手，就是在於他除了提供好的工業設計、好的硬體，以及使用起來平順的裝置介面，加上電腦端各平台都有的 iTunes 方便與裝置溝通，最後更重要的是整個 iTunes music store 的經濟系統。在此同時，一般廠商功夫只花到工業設計跟硬體，加上裝置介面弄個 3D 花俏一番，PC端的應用就弱些，更別提服務端了。參考這個例子，再回過頭來看 2009 年的小筆電，以及號稱 2011 年 Q1 會有超過百種的 tablet 出現，能不能拼得過 iPad，答案應該就很清楚了。

Eric Schmidt 在11月提到⁴，Chrome OS 主要針對有鍵盤的裝置，而 Android 是為了觸控裝置。這當然引起很多疑問，但也不無道理。有沒有鍵盤的確是兩個完全不同的市場，例如有鍵盤的手機主打商務居多，而觸控使用者較著重娛樂市場，Nokia 在這部份甚至分成好幾個產品線來處理，即 E 系列與 N 系列。Chrome OS 比 Android 整整晚了兩年，強弱勢明顯，而 Android 其實可支援鍵盤，現成裝置也多，很可能會往 Chrome OS 的地盤擴張。更何況，小筆電上真正的 killer app 為 Microsoft Office，這部份沒有解決方案的話，就很難廣受歡迎。反觀觸控為基礎的 tablet，使用者對於文書處理方面的應用本來期待就較低，反而較有可為。就 Android 行動裝置部份，筆者個人意見為 tablet 較小筆電值得發展，而 tablet 在正式支援之前，先出產品的宣示意義較大，現階段若能取得 Google 合作當然最好（但很難），不行的話，那麼瞄準第二波 2011 Q2 之後的推出速度與品質會是關鍵。

Smartbook⁵ 的概念值得在此一提，最初由 Freescale, Qualcomm 等提出，包括：

1. 介於手機與筆電之間，類似或小於小筆電
2. 待機時間長，持續使用一天，斷續使用一週
3. 快速開關機，立即可用
4. 3G連線能力，隨處皆可上網
5. GPS，有導航能力，知道所處位置

光看了這些需求，大概就可以了解背後思維為何。Google 日前推出的 Chrome OS 小筆電，Cr-48，其部份規格為：

• Qualcomm Gobi 3G chip for Verizon data in the US, your carrier of choice internationally.
• 802.11n dual-band WiFi.
• 8+ hours of active use.
• 8+ days of standby.

這樣一看，企圖心就很明顯了，願景為一切移至雲端，成為適合整天帶著四處走動的隨身機器，此類機型搭配繪圖加速、硬體解影音壓縮等等功能，如此不需要很強力的 CPU 就可以滿足一般人的多媒體、遊戲需求。未來的使用情境可能變為，平時帶著 smartbook 上班、上課，休閒時刻則僅拿 smartphone。桌機將退到伺服器等等專門市場，而強力筆電則成為專業人士需要執行大型程式或需較強運算能力才用到。

至於 Google TV，技術上是基於 Android，目前不叫好也不叫座，Sony 之前推出的產品 Intel 與 ARM 都有，系統整合還沒到位，真正有意義的應用可能還要到明年中以後才開始出現。數位時代的三個螢幕，電腦、手機、電視，都是兵家必爭，就算現在不行，日後 Google 也一樣會鐵了心想辦法進入 TV 市場。除了傳統上的內容提供（高畫質影片、節目等），”Social media”，也就是以社交網路為基礎的媒體內容推薦、交換，以及不同螢幕間的整合、使用者經驗等等，都會是著墨的重點。

小結

2010年變化極大，2011年也將是極為刺激詭譎的一年，除了商業模式的異業媒合，現代的科技業，技術方面的速度與彈性將成為決定因素之一。仔細觀察 iOS 的發行速度，以及各廠商如 Nokia, RIM 等等的積極發展，可知 Android 的快速發展不會是特例，而將會是常態。台廠在如此變局中，有必要調整自己的研發模式，跟上技術前進速度，不然在全球化浪潮下，利潤進一步壓縮，me too 空間越來越少，都是可以預期的。

Notes
¹ http://www.linux.org.tw/CLDP/OLD/doc/Cathedral-Bazaar-1.html
² From Apple’s 2010/1/27 announcement.
³ http://twitter.com/#!/AndroidDev/status/28701488389
⁴ http://www.engadget.com/2010/11/15/eric-schmidt-chrome-os-aimed-at-keyboard-based-solutions-andro/
⁵ http://www.meetsmartbook.com/

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

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

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

這題目在2009年已經寫過，當時沒有完成，心中一直記掛。今年初把他拿出來翻新改寫，仍然到現在才完成一部分，就分幾篇陸續貼上，且看這次能否堅持到底吧。

Android應可說是科技界2009年第一大事。Android前身為一公司，被Google買下後繼續開發，以開放源碼的方式發行，還成立了Open Handset Alliance (OHA)作為支持Android的商業組織。其中成員如Qualcomm, TI, Wind River等在各自領域都赫赫有名，尚未上市就已經相當轟動。開放源碼（Open source）的手機作業系統，其實在此之前已經出現數個，例如Qtopia¹以及其後雷聲大雨點小的Openmoko，再如當時以行動上網裝置（Mobile Internet Device, MID）為主的Maemo等等。不過，Qtopia與Openmoko的成熟度當時並未達到商業化需求，而日前Nokia雖然已經基於Maemo發表了新一代智慧型手機N900，但當時Maemo仍侷限於行動上網裝置，而非電話。

換言之，Android除了擁有眾多大廠支持，而且在開放之初就發表了T-Mobile G1，有產品可證明商品化能力。這意味著，長久以來受制於Windows Mobile，又無能力開發自有作業系統的手機廠商，看見了站在巨人肩膀上做出自有產品的可能性。從2008年底開放以來，2009年HTC, Samsung, Motorola, Acer等等都發表了Android手機，而看來2010年中還有更多。究竟 Android 有什麼特點，與以往根基於Linux的手機差別何在，以及面對其他手機作業系統的競爭有何優劣等等，本文嘗試做一介紹與探討。

技術面淺探

要談Android，就無法迴避技術面的討論，但在此會忽略細節以及犧牲一些語言精確度，試著做一簡介。

系統架構

Android作為一作業系統，其針對的硬體為智慧型手機，並在設計伊始就考慮到3G網路以及觸控螢幕、相機、GPS等現代應用。作業系統作為裝置與人之間的媒介，以及負責讓手機正常運作。與人接軌的那端，使用者介面、應用程式等，一般稱上層。而與機器接軌的部份，比如對打電話的控制、無線網路晶片、顯示圖形到螢幕上、接受觸控螢幕收到的手指觸摸等等，就是由底層來負責。在此我們先由下層開始介紹，再步步往上。

(http://developer.android.com/images/system-architecture.jpg)

Linux Kernel

必也正名乎：一般所稱Linux，其實是統稱，指根基在Linux kerne以及其他許多跟kernel不見得有關的軟體所組成的作業系統。最早，Linux一詞其實是專指kernel，它提供了系統底層與硬體間的基本核心，讓其他程式可以在上頭執行。其最早作者是Linus Torvalds，他用自己的名字，加上採用了與Unix系統相容的介面，將自己的作品命名為Linux。

class HelloWorld
{
    public static void main(String [] argv)
    {
        System.out.println("Hello, world!");
    }
}

也就是用人比較容易看懂的語言（也許不那麼容易啦，但至少比一堆0跟1來得好）來叫電腦做事，比如上個例子是在螢幕上印一行字Hello, world。所謂程式的原始碼，就是一整篇這樣的文章，結合起來，可以叫電腦執行某些功能。這樣的語言比自然語言容易「翻譯」成電腦看得懂的「指令」，而負責翻譯的，就是「編譯器」。

電腦的核心CPU有很多不同種類。一般我們用的是Intel的產品，有些是32位元、有些是64位元。有些人用的可能是Power，例如以往蘋果電腦的使用者。還有一些小一點的電腦，可能就是用ARM架構。總之，不同的CPU具有不同的指令集合，是不能直接互通的。在此我們可以想像，同樣的程式碼，可以經由編譯器，翻譯成適合不同CPU架構的程式，而他們之間是不能互換的。例如編給ARM使用的程式，在Intel的CPU上頭就不能跑。要如何解決這個問題呢？

這裡引入第二層面：「Java 虛擬機器」（Java virtual machine）。虛擬機器可以想像成一虛擬的CPU，先設定一些共通的指令，然後針對各種不同的架構做個別轉換，如此只要是採用此「共同指令集」的程式，就可以在這虛擬機器上面執行，由虛擬機器負責轉換成目標CPU的指令集。如此一來，我們只需要把用電腦語言寫好的程式編譯成「虛擬機器」看得懂的就行了。Java使用的共通指令就稱做 “Java bytecode”。

最後則是Java runtime library，也就是一個「函式庫」，裡頭存了很多編譯好的現成程式，來讓開發者使用，這樣就可省下很多重覆的工作。比如上頭這例子裡頭的System.out.println就是函式庫提供的。那我們可以想像，如果在程式中我們用了很多某個函式庫裡頭的東西，但是用的人只拿到編譯好的程式，但沒有同樣的函式庫，那這程式還是不能用。比如說，Windows, Linux提供的基本函式庫就很不一樣，所以做同樣事情的程式，寫法可能完全不同。Java函式庫裡頭提供的工具，是有標準可循的，所以以上的程式，不管是要在Windows上頭跑，或是Linux上頭跑，都是一樣的寫法。

於是乎，我們可以把Java runtime library跟Java虛擬機器搭配起來，這樣我們只要用Java這個語言寫程式，裡頭呼叫Java runtime library裡頭的工具，用編譯器編成Java bytecode，交給虛擬機器去執行，就可以在各種平台上面跑一樣的程式了。這兩者的組合稱為「Java Runtime Environment, JRE」，只要針對某環境提供JRE，就可以執行Java應用程式了。雖然這聽起來很棒，但我們可以想像，由於隔了一層虛擬機器，程式跑起來容易比直接下命令來得慢，而且必須額外安裝JRE，用掉較多資源。

Java Runtime讓人們可以在不公開原始碼的情況下，發行編譯好的應用程式，在各種不同的平台上執行，相當適合商業應用。Android循著相同架構，也提供了Android Runtime，但有幾點不同。

Android使用的虛擬機器叫作Dalvik，原本並不是針對Java設計的。它認識的指令集並不是Java bytecode，而叫Dalvik executable，簡稱dex。Android裡頭提供了一個工具程式叫dx，可以把 Java bytecode再翻譯成dex，這樣Dalvik就可以執行它了。這虛擬機器為了適合在電話這種比較小型的平台上使用，而做了許多最佳化的處理，例如適用較慢的CPU、低記憶體使用量、減小應用程式的大小等等。

Android虛擬機器與函式庫合稱Android Runtime，在函式庫方面，提供了大部分的標準Java函式庫，讓Java工程師可以無痛的轉換，而關於手機的部份則提供許多諸如使用者介面、藍芽、GPS相關、網路、3D加速、影音、以及電話本身等等許多現成的函式可用。這些函式使得開發者可以直接取用基礎功能，進而專注於應用程式的開發。

Application Framework

提供應用程式執行環境，針對手機設計，許多觀念與一般個人電腦應用程式有相當不同。在此將開發者網站上的說明大略翻譯如下：

應用程式元件

Android的重要功能之一為，應用程式可在對方允許的情形下，使用其他應用程式的元素。例如，如果你的應用程式想要顯示一排可以捲動的影像，而另一應用程式已經開發出了適合的捲軸元件，並開放給他人使用，你可以直接呼叫這元件來使用，而不需自行開發。你的應用程式不需要包含他人的程式碼，也不需固定連結到某程式。反之，Android框架會在有需要時，自動啟動其他應用程式的相關功能。

要順利運行，系統必須能夠在需要其任一元件時，啟動一應用程式程序，並做出需要的Java物件。所以，與大部分系統上的應用程式不同，Android應用程式並沒有一個單一的「進入點」來使用所有功能。反而是，他們提供元件讓系統可以視需要使用。元件類別有四種：

Activities

Activity表示一使用者介面，用以完成某特定事務。例如，activity可呈現一選單列表，或是顯示相片跟標題。簡訊軟體可能包括一個列出所有傳簡訊對象的activity，一個讓使用者對選擇對象寫簡訊的，以及其他的activity來看舊訊息以及設定功能。他們雖然組成一個使用者介面，但各元件互相之間仍是獨立的，例如，其他軟體需要傳訊時給某人時，可能只需叫出「寫簡訊」的activity，而不需其他。

一應用程式可以只包含一個activity，也可以像剛才描述的簡訊軟體一樣，包含好幾個。當然，需要哪些，以及要多少，都是取決於應用程式的設計。一般來說，其中一個activity會被標為程式執行時第一個看到的畫面。由一個activity移動到另一個，是利用目前的來呼叫下一個。每個activity都分配到一個預設的視窗，可以在裡頭畫東西。一般說來，這視窗跟螢幕一樣大，但它也可以比螢幕小，並浮在其他視窗上。而activity也可以開多個視窗，例如跳出一個視窗來取得使用者回應，或者是針對使用者選擇顯示重要資訊。

視窗內部的視覺組成是由樹狀結構的”view”組成，每個view可以包含其他view，控制視窗中一塊長方形的區域，並可跟使用者互動。換句話說，view可組成activity與使用者互動的「實相」。Android系統中有許多現成的view可供取用，例如按鈕、文字欄位、捲軸、選單、勾選格等等。

Services

Service並沒有可見的使用者介面，而是在背景永久執行。例如，當使用者做其他事情時，service可能在播放音樂，或正從網路上抓取資料等等。

Broadcast receivers

唯一功能為收取以及回應「廣播訊息」。廣播經常來自Android系統本身，例如，手機所處的時區改變，電池快沒電了，或是剛照了一張照片，或是使用者剛改變了顯示介面的語言等等。應用程式也可以發出這類廣播，例如，讓其他應用程式知道某些資料已經下載完成，可以使用了。

一應用程式可以有任意數量的broadcast receiver來收取任何它認為重要的訊息。它沒有使用者介面，然而，他們為了回應廣播訊息，可以呼叫某個對應的activity，或者是發出一訊息通知來告訴使用者發生了什麼事情，以及震動、播放音效、閃爍軌跡球等等。

Content providers

負責對其他應用程式提供或收取資料。資料可存放在檔案系統中，或資料庫、或任何合理的方式。例如：通訊錄。

任何時候，當系統需要某一特別元件時，Android系統會先肯定擁有這個元件的應用程式正在執行，如果沒有，就啟動他。另外還會確認此元件是否已經存在於系統中，若視沒有，就製作一個。

啟動元件：intents

Content provider在有人需要存取時便會由系統啟動，而其他三類元件：activity, service, broadcast receiver都是由一種叫intent的訊息啟動的。一個intent表示的是一種「企圖」。例如，它可能是要求「顯示這張圖片」，或者是「編輯這段文字」，或「編一段訊息傳給這個人」。比如說，某應用程式想傳訊給通訊錄中的某一人，可先發出企圖「瀏覽通訊錄」，則系統中負責此事的元件便被啟動。選取對象後，便呼叫「編輯簡訊」的元件來編輯並接著發送出去。
關於應用程式運作，詳細情形可參考開發者網站上的說明⁷，在此就不詳述了。

Applications

要開發Android應用程式，並不需要下載整個平台的程式碼，只需要採用Google發行的軟體開發工具（Software Development Kit, SDK）即可。使用的電腦語言是Java，並內建模擬器，可直接驗證寫出的應用程式，而不需擁有實體手機。建議的開發環境為Eclipse，此軟體亦為開放源碼專案，不需付費即可使用，許多公司如IBM等亦根基於Eclipse推出了自有的工具，可說應用相當普遍。Google在這部份提供了Eclipse的一個延伸套件，與模擬器、除錯等等都有整合，並提供完整文件，進入門檻降得相當低。

延伸閱讀：

1. http://www.betaversion.org/~stefano/linotype/news/110/ (Dalvik: how Google routed around Sun’s IP-based licensing restrictions on Java ME)：關於 Android 如何繞過 Java ME
2. http://blogs.sun.com/jrose/entry/with_android_and_dalvik_at (with Android and Dalvik at Google I/O)：對 Dalvik 有興趣的話一定要看
3. http://sites.google.com/site/io/anatomy–physiology-of-an-android (Anatomy & Physiology of an Android)：Google 對 Android 平台內部架構的概觀介紹

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

本來 iOS（iPhone OS的新名字）在可用度以及現有應用程式就有領先，但由於用的軟硬體比較舊，慢慢被其他廠商追上時， Apple又出了一個不是迎頭趕上、就是超越的新裝置 iPhone 4，這下差距又拉開了。

優秀的硬體與工業設計

這次的 WWDC，iPhone 4 再度展現出優秀的硬體與工業設計能力。重頭戲落在高畫質的顯示螢幕 (Retina Display) 上：362326 dpi。Steve Jobs 說的沒錯，iPhone 4 是設定新標準，以後其他廠商又只能想辦法在後苦追。362326 dpi有什麼好強調的呢？關鍵是 iPhone 4 展現的是「超乎印刷品質」。例如說，一個字母實際尺寸要多大眼睛看了才舒服？大概就是那麼大，解析度高的時候字可以小些，但也不能太小。手機螢幕物理尺寸就是如此，因此你能放的內容並不會多多少。但 dpi 高，你可以用更多點來組成，觀看效果就會舒服。這點由老賈的 demo 可以明顯看出。

光是外觀與顯示上的差異，用戶就會覺得這是精緻的產品。iPhone 在顯示品質這方面是其他競爭對手所不及。例如 Nexus One 的 AMOLED 賬面上解析度不低 (800 x 480)，但實際有效的辨識度大概要折半。

右圖：數位圖案原圖，左圖：Nexus One的Amold顯示結果。原文出處

至於工業設計指的就是外表很美XD（當然你可以有不同意見），此外金屬邊殼當成兩個天線這設計很不錯，收訊會因此更好嗎？還不知道，要看校調得怎樣，如果真的好，那可能又是另一個專利保護的硬體設計。例如 MacBook 那個電源插頭，明明蘋果這樣的設計比較好，但其他廠商就是不能學。Apple 的強項就是在整體：例如同時間發表的HTC Evo 4G，在部分硬體規格勝過iPhone 4（譬如前後鏡頭的解析度），但到了實際使用，iPhone整體經驗仍然會是較佳的。

Facetime 將帶動視訊電話新標準？

除了硬體規格之外，Apple 還宣布了 Facetime 這個視訊電話的應用。雖然說這是個舊點子，但過去數年來一直沒有人推行成功。不過，ReadWriteWeb 對Facetime的評價，值得玩味。

ReadWriteWeb的論點，是Facetime即將再度帶動美國（以及全世界）電信商對視訊電話的重視，包括提供更便宜、更高的頻寬（以提供視訊電話），並且推動Facetime成為統一的通訊規格。就ReadWriteWeb原文表示，美國不同的電信網路之間，使用的視訊標準不同，因此雖然AT&T的用戶可以打電話給Sprint的用戶，卻不能用視訊通話。但iPhone 4的推出肯定會讓電信商著手整合、讓facetime成為視訊通訊的標準。

不過這個論點還頗有值得玩味之處。因為根據過去經驗，Apple並不是特別熱衷訂立開放標準，反倒比較傾向封閉標準。因此底下這段話Steve Jobs到底能做到幾分？值得觀察。

Jobs said on stage that the system was based on extensive use of open technical standards, and that the company intends to work hard to make FaceTime an open industry standard itself.

（賈柏斯在台上說，facetime是根據許多公開的技術標準所完成，而且Apple會致力於讓facetime成為產業公開通用標準）

如果順利的話，Apple 死忠粉絲開始使用Facetime => 電信商不得不跟進標準 => 現行唯一的通用標準… 然而，就算Apple這樣打算，其他人買不買帳仍然是未知數。就如同Microsoft力推 Open XML，名字很 open，規格也公開了，但真的在用的仍然只有自家產品。很可能，Google還會跳出來主導另一套標準。

那，facetime的出現會導致視訊電話需求因此大增嗎？Carrier的合作會是關鍵。以現實來說，美國其實有（還算）普遍的WiFi（AT&T之爛就被罵翻），3G 那邊技術上也沒問題，主要阻力是電信商抗拒：以後只能收3G的錢，這東西開通了誰還打普通電話啊？大家都選擇3G 吃到飽方案，錢哪裡來？幾天前有則新聞可以印證這項道理：美國AT&T不顧用戶意見，宣布停止3G吃到飽方案。

不過產業生態就是這樣：你不提供，就會有別家提供。Apple 開了視訊電話這一槍，肯定會讓電信商為難，AT&T沒有3G吃到飽，用戶會一直抱怨，競爭者就會開始提供這一服務，如同Verizon先前宣布免費無限開通Google Voice/Skype一樣。當然，這就是老賈的計畫啊。

其他功能

例如A4，其實是來自ARM的Cortex A9A8核心，由Samsung製造。目前由iPad的表現，還看不出硬體上有特別先進的地方。Battery life 雖然老賈大力鼓吹，但也並沒有特別優秀。例如 Nexus One 的 2G standby帳面數據290小時，而 iPhone 4 是300小時。3G Internet N1為5小時，iPhone 4是6小時等等，參考看看即可。雙麥克風降噪是其他裝置已有的功能，陀螺儀可以增加有趣的應用，Tap to focus（點擊螢幕對焦）在Android也有、Backside illumination sensor在低照明情況下有更好表現、720p錄影能辦到的硬體不少，例如N1 root以後也辦得到。新的 iOS 4 功能加上了Android一開始就有的資料夾與多工能力等。

結論？

回到前頭那張表：

我們發現，新的iPhone在以往較弱的領域如硬體、作業系統功能等等，不是追平就是超越，而既有的優秀使用者體驗以及大量的殺手應用程式、加上優越的工業設計能力，追趕者目前仍束手無策。iPhone 4 的出現，在其市場區隔中與其他手機陣營的差距又拉開了。老賈的自信不是沒有理由的。

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

如果要比較，請至少拿iPhone或某一隻Android手機〈例如Nexus One〉來比較，這才是一個產品；或者你要比較手機平台，那請拿iPhone OS與Android來比，然後我們再來談談多工、API差別…等等等。一個是手機，一個是OS。

Android跟iPhone從一開始就不一樣

Android跟iPhone從一開始就有根本性的差異。這樣說吧：Google 出 android 目的是什麼？是搶手機平台。重點是攻佔的手機數，所以它一開始就支援多種平台、多種硬體。

而Apple的重點是，我要賣很多上面跑我的服務的、自己做的電話。所以它只有出一種硬體：iPhone。當然現在多包括了iPad，但至少硬體裝置種類還是有限的。

就策略而言，這是類似開放軟體中經常提及的教堂與市集觀念，或說「中央集權」對上「遍地開花」。短時間來看，由於 Apple 面對的是一單純環境，將此環境加以充分打磨、修飾，呈現出最佳結果是相對容易的。

而 Android 為了避免過多的版本在市面上流通而造成混亂，於是由 Google 主導，同一時間的主流版本固定，並有一定程度的向前相容性。譬如現在推出Android 2.1版，可以向前相容1.6 apps 。而在硬體方面，就是放任遍地開花，從螢幕解析度，到硬體加速能力、運算能力等等，都有相當大的差距。要適應這麼多不同種類的平台，自然要付出代價。比如最早的G1是HVGA (320 X 480 pixel) ，到了現在Nexus One 800×480，多了兩倍還不只，應用程式設計，以及供工程師使用的應用程式介面等等都相對的困難。

所以，Android Market上的軟體，水準不如iPhone軟體統一，主要是因為商業模式以及目前市場大小的關係，而不是一個技術問題。

了解這層關係後，我們再來看T客邦兩天前這篇：Apple vs. Adobe大戰，專家怎麼看，當中有一段提到：

雖然蘋果很惡霸。但事實上要打造一個優質軟體開發圈（ecosystem）本來就必須如此決斷取捨，Android圈就是過度自由，且沒有考慮到API版本與機器間的差異，造成市場上充斥著太多運行異常的app，導致使用者對整個Android App ecosystem信心上的崩盤。

「我們從痛苦的經驗中得知，讓第三方軟體在平台與開發者間做為中介，最終必然會做出次於標準的程式，並且阻礙平台的進步與時程。」我覺得在Jobs公開信裡這句話是重點。

當中的邏輯有一些值得挑剔之處。

首先，第一段說的是Android軟體支援問題。這並不是因為「Android忽略硬體不同與API不同」，事實上Android對此花了不少功夫，而是因為一開始就選擇了市集模式，軟體開發者必須要考慮Android這個「作業系統」得支援多種平台。這狀況跟iPhone這「一隻手機」不同。如果我用的就是 Nexus One這「一隻手機」， 然後說現在要在上頭寫個好軟體，自然簡單多了。

再者，第一段說的問題，跟第二段說的「有沒有第三方軟體」有啥關係？

Android信心崩盤？言之過早。

Android的問題是分散，所以開發應用程式要多考慮很多事情， 要用「一般性」的方式去寫。也會造成部份的軟體，在多種硬體上的支援度有問題。

但是這能代表Android就是失敗嗎？整體而言 android的成長力道也很驚人，證明了Google並沒有失敗，相反的，還相當成功。摘錄今天AdMob的報告：

Android 的行動上網總量已經超過Apple了。Google當初發表Android的初衷是什麼？是搶行動上網佔有率啊，那現在 android phone 數目成長快不快？有沒有用到 google android apps？有，所以 google 成功不成功？當然成功啊！！

至於Adobe Flash與Apple iPhone的戰爭…

如果談到Flash，Apple這麼注重整體設計感的公司，要求的控制應該超強。要針對一個小的打擊區把事情做好，是比較容易的。為了這原因而踢開Flash，或許有點道理。但如果仔細研究，會發現兩者不互斥。「有flash的存在，但不希望大家用」，跟「flash不存在」，是完全兩回事。微軟可沒說過「flash沒有對MFC有足夠支援，所以以後windows不准裝flash」這樣的話。

同理，Android現在支援flash，但其實它也並沒有叫大家「用flash寫Android 應用程式」，只是說「可以看有flash的網頁」。這也是兩回事。

Adobe 如果出 Android 應用程式開發平台，Google應該也不會拒絕吧。想也知道Google會說什麼：「你要做就做啊。」不寫java可不可以？Google自己都在Android上頭寫了python scripting engine了….

而至於「Adobe第三方軟體不長進，會拖累Apple」的說法，邏輯太過跳躍。如果Adobe產出的iPhone Apps 很爛，經過市場自由競爭，死的不是 App Store，而是Adobe才對，因為軟體開發者隨時都可以轉回用原生Apple API啊！只不過，只要是Steve Jobs出品的東西，好像都不時興自由競爭、淘汰這回事。

結語

就長期言，開放模式代表的「創意」、「多樣化」以及快速的演進速度，代表了很大的可能性。未來鹿死誰手，尚在未定之天。

然後，I’m sick and tired of people comparing iphone to android.

如果是因為用戶長年來都把這兩者搞混，那我們就來比較別的：市場行銷策略、商業模式，等等等等；別再把OS與手機混為一談了。

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

歐尼斯特·拉塞福爵士，皇家學會主席、諾貝爾物理獎得主，講述了以下軼事。

前些時候，我接到同事的電話。他正打算給一位學生物理考題零分，但那位學生卻認為他應拿到滿分。這對師生需要一位公正的調人，而挑中了我。

考題如下：「請解釋如何用一支氣壓計得到一棟高樓的高度」，而那位學生的答案是：「把氣壓計拿到樓頂，繫上長繩，垂到街上，然後拉起來，量一量用掉的繩子長度。用掉繩長即為樓高。」

這學生的確有充分的理由拿滿分，因為他真的正確而完整的回答了問題！但另一方面，如果給了滿分，會讓這位學生得到很高的成績，並認可其物理能力，但從他的答案並無法確認這件事。

我建議這位學生再試一次。我給他六分鐘作答，並警告說這次的回答必須表現一定的物理知識。五分鐘之後，他什麼也沒寫。我問他是否放棄，但他說，他有好多個答案，只是正在想那個最好。我請他原諒我的打斷，並請他繼續答題。

在下一分鐘，他草草寫下答案。這次是：「把氣壓計拿到頂樓，探出屋簷。將氣壓計丟下，並用碼表計算掉落的時間。然後，利用 x = 0.5*a*t^2 的公式，算出建築的高度。」到了這時候，我問同事是否要放棄，他讓步，給了接近滿分的分數。

在離開同事辦公室時，我記起那學生說過，他有好多個答案。我問他其他是什麼。

「這個嘛，」那學生說，「有很多方法可以用一支氣壓計得知高樓的高度啊。」

「例如，你可以把氣壓計在晴朗的天氣下立著，量它的高度跟陰影的長度，然後再量建築物的陰影長度，就可以用簡單的比例算出建築物的高度了。」

「很好，」我說，「那其他呢？」

「嗯，」學生說，「有個很基本的測量方法你會喜歡。這方法是，你把氣壓計拿著，開始爬樓梯。一邊爬，一邊用氣壓計的長度來標記牆的高度。然後你算算究竟有幾個標記，就會知道樓高是幾個氣壓計長了。很直接的方法。」

「當然啦，如果你想要複雜點的方法，可以把氣壓計綁在線的一端，盪成鐘擺，用以計算地面的重力加速度值跟樓頂的重力加速度值。由這兩個值的差，原則上，就可以算出樓高了。」

「用類似的方法，你可以把氣壓計拿到樓頂，綁上長繩，垂到地面，盪成鐘擺，然後由擺動週期也可以算出樓高。」

「最後呢，」他下結論，「有很多方法可解決這問題。或許其中最好的是，」他說，「把這氣壓計拿到地下室，敲敲管理人的門。等他應門，你就這樣跟他講：管理員先生，這是一支很好的氣壓計。如果你告訴我這棟樓有多高，我就把它送給你。」

到了這時，我問這位學生，他倒底知不知道這題一般的解法。他承認他的確知道，但他受夠了高中與大學的老師嘗試教導他如何思考。

這位學生的名字是尼爾斯·波耳（1885-1962），丹麥物理學家，1922年諾貝爾物理獎得主。最為人知的是提出了第一個原子模型，也就是質子與中子周圍環繞著不同能階電子，那個我們都熟悉的原子核被三個橢圓軌道繞著的圖形。但更重要的，他是量子力學的開創者。

註一：在翻譯完成後，發現此故事已由郝廣才在「腦力發電」一書中引用。由於是分別翻譯，不涉智財權。
註二：由拉塞福與波耳生平年代，可發現此故事應為杜撰，視為寓言即可。

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

三天前，TechCrunch率先報導了Google有意推出自家品牌手機Nexus One的消息，而且這次不只是謠言而已，還附上了手機照片。隨後華爾街日報也跟進報導了更多細節，說這隻手機預計明年初就會上市，繞過電信業者直接出貨給消費者。所以，看起來Google真的打算要出自有品牌的手機了？

這個標題的意思當然不是說Google沒有能力推出自有品牌，相反地，Google在過去幾隻手機與HTC、Motorola的合作經驗，已經讓Google有足夠的信心與經驗推出自有品牌，而且這回，手機開發過程也不用受制於其他廠商，將全權由Google主宰…。

但是，如果各位夠細心的話，應該會發現這次新聞中，所有的公司通通不敢正面證實這個消息，例如Google、HTC和其他手機製造商。因為如果消息屬實，打到的人可就多了，包括許多Google的合作夥伴。怎樣個打法？下面這段文字，是TechCrunch上一位仁兄sigh2的留言：

If you check Gadget Blogs, people are already questioning their Droid purchase – because they want the real deal – the Google Phone. What i´m trying to say – the other manufacturers, although they hesitated in the beginning, put effort in spreading Android and are now left in the rain. Motorola is totally betting on Android.

Imho it´s a stupid move from Google and some manufacurers will maybe move back to WinMo. Because M$ maybe greedy, but the don´t slap their partners in the face. (at least not in this case :p)

HTC、Motorola這些推出Android手機的廠商，一瞬間跟Google從合作夥伴變成對打廠商，先前為了Android這個品牌所花下的研發工夫與行銷預算，現在看來都變成幫Google抬轎，他們的矛盾心情可想而知〈好吧至少HTC還是有代工這台手機，但其他廠商…〉。尤其現在是聖誕節銷售旺季，Google Phone消息一出，把Motorola正在北美強推的Droid鋒頭都搶走了，Moto應該是啞巴吃黃蓮，有苦說不出。

不過照理說，手機市場很大，多一個競爭者是不好，但也沒有到敵視的地步。Google此舉的目標其實或許是電信業者。現在還不清楚的是，Google Phone 上頭到底有什麼「服務」？有多少跟電信業者相關的？這將會是重點。

Android 的目標一直包括與電信業者脫鉤，而從目前的消息看來，這隻手機會跳過電信業直接銷售。最直接的猜想是，難道是因為Google手機所附功能會直接跟電信業者對打所致？這方面大家可以參考這篇：FCC 介入調查 Google Voice app 被 Apple 拒絕事件。

不過這只是第一步。如果GTalk這種的模式繼續發展下去，會進一步侵蝕到電信業者既有的利益，未來或許將只剩3G的錢可以賺。電信業者一直在玩加值服務，將手機當成生意平台，如多媒體簡訊、來電答鈴、影音服務等等。Google這種模式一進來，電信業者將會少很多利基。若真出自有品牌，真正的戰場應該在這，或說是這「附近」。想想看，電信業者原來賺錢的東西，網路上幾乎都有相同的，而且不用錢──而且大部份提供者還是Google。Google…just compete them with “free.”

這些消息都未經證實，只是根據流傳出來的消息進行猜想，所以也可以說都是虛的。Google若真的這麼做，必會引起電信業者反彈，目前情況曖昧不明、所有Spec都不公開，相信在公開後，仍會有意想不到的驚奇。

（本篇由Mr. Friday從線上對話增修而成初稿，在此致謝。）

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

一一，楊德昌

身為台灣人要談電影，不提到楊德昌是不可原諒的。楊之前的電影多半都會包含幾個鮮明的議題在其中，但到了這最後一部，卻覺得反而單純（當然也是複雜）了起來，有種反璞歸真的況味。它談的就是生命、人生，在這不大不小的年紀，每次重看都有些不同的感觸。當時是童星的張洋洋在本片的表演相當搶眼。

Citizen Kane, by Orson Welles

鼎鼎大名的「大國民」。1941年發行，而且是Orson Welles的第一部作品，卻傳世不朽，各類百大名片片單中經常的榜首。人追尋的同時也會迷失，而到了最後一刻，也許仍在企求不存在的夢。許久以前看到一篇介紹影史經典對白的文章，第一名是”Rosebud”，當時覺得莫名其妙。看完才覺得，五味雜陳盡在其中啊。

Pulp Fiction, by Quentian Tarentino

本片導演Quentian Tarentino成名前在錄影帶店打工，身為影癡看遍了全店，尤其喜歡B級電影、港片等等。基於對B級電影的熱愛，加上他本人藏不住的才華，最後便產生「黑色追緝令」這種風味十足的黑色喜劇片型。如果你喜歡電影以及五零、六零年代以降的文化，知道的越多，看起來就越有趣味。

The Usual Suspects, by Bryan Singer

「刺激驚爆點」，了不起的劇本，男主角與配角了不起的演出，酷斃的犯罪電影。結局所有看過的人都會津津樂道。Kevin Spacey以此抱走奧斯卡最佳男配角小金人。

A Clockwork Orange, by Stanley Kubrick

偉大的 Stanley Kubrick.. 史丹利庫柏力克，最為人所知的電影可能是Eyes Wide Shut「大開眼戒」或者是「金甲戰士」等，但從一推出以來就立刻到處被禁播的這部「發條橘子」才是我的最愛。其中直接探討人性、善惡對立等問題，大膽、尖銳、衝突性強。額外加分的是，影片各場景普普風格的佈置非常令人嚮往。

The Big Lebowski, by Joel Coen

「謀殺綠腳趾」。柯恩兄弟的作品幾乎沒有失手，之所以挑這部電影，是因為在他們擅長的灰暗、黑色片型之外，這部電影呈現出一種溫情，還有對嬉皮年代的緬懷。主角Jeff Bridges的演出我通常不喜歡，這片例外。

Taxi Driver, by Martin Scorsese

馬丁史柯西斯，鼎鼎大名，近年卻很少出好片（神鬼無間、美國黑幫等等）。「計程車司機」有勞勃迪尼洛，還可以看到早年的茱蒂佛斯特，以及赤裸裸的小人物、底層社會。個人意見，這部電影以及「蠻牛」，是史柯西斯最好的時光。

Blade Runner, by Ridley Scott

雷利史考特在「異形」之後，拍出了個人覺得更棒的「銀翼殺手」。關於這部電影，已經被影迷一個frame一個frame的討論到快爛掉了，它的魔力實在無窮。對於人造人這個想法，之後的電影永遠也只能東施效顰。

Nuovo cinema Paradiso, by Giuseppe Tornatore

「新天堂樂園」。如果還沒看過，建議一定、一定要找來看，並且準備好大笑與面紙。推薦後來出版的director’s cut，原先的版本剪掉太多了。

The Bridges of Madison County, by Clint Eastwood

牛仔克林伊斯威特是我個人非常喜歡的導演之一，在Unforgiven（殺無赦）跟這片之間猶豫許久，還是選了這部「麥迪遜之橋」。非常感人，對白、演技、故事，無懈可擊。Eastwood老伯在九零年後的電影都有一種年邁的圓熟，歲月燉出的深度。需要細細品味。

很可能是遺珠的，很個人的喜歡的：

Eternal Sunshine of the Spotless Mind, by Michel Gondry
The Last of the Mohicans, by Michael Mann
The Royal Tenenbaums, by Wes Anderson

加入MMDays在facebook的粉絲團 隨時閱讀最新文章

要稍微看懂這整個情況，需要一些背景知識。首先，Linux 到底是甚麼樣的東西？前文曾經述及，Linux 其實原指 Linux kernel，也就是作業系統的核心部份。而運行在這核心之上，有各式各樣的軟體，有的可以讓我們傳 MSN, Yahoo messenger、看網頁、收發 email 等等之類。在 Microsoft Windows 上我們有些熟悉的軟體來做這些事，在自由/開放軟體（Free and open source software，以下簡稱 FOSS）的世界同樣也有，例如許多人都聽過，而且也可以在 Windows 上使用的 Firefox。

把現有一大堆的 FOSS 專案組合起來呈現給使用者，形成一套完整的作業系統，這樣的組合就稱作 “Linux distribution“（後簡稱 distro）。由於 FOSS 的世界大部分的程式碼都是公開的，所以取用現有的成果以及修改已有的程式也相對容易。這就產生了互相之間版本的依賴性，以及部份的功能不同等等情況。例如 A 取用了函式庫 B 的功能，而這功能是在 1.0.2 版之後的 B 才有的，那我們就會說 A 依賴大於 1.0.2 版的 B。種種這些互相依賴性以及提供的軟體種類、安裝/移除方式等等集合起來，導致不同的 distro 之間，某些功能經常有些微的差距，程式也經常不能直接互換使用。

套用 Windows 的概念來理解就是，通常 Windows 一次只存在一個當紅炸子雞，而且程式經常都可以互換使用。但 distro 同時間有好幾個，甚至同一個 distro 也有「穩定版」、「測試版」等等不同，而且互相之間還常不能互換程式執行。一般來說，這不構成甚麼問題。因為程式碼都公開，各 distro 只要自己管好自己，把夠多的專案編譯好提供給使用者就行了。雖然有些版本、功能差異之類，但在不同的 distro 上，只要知道名字，都可以取用到差不多的功能。

但現在問題來了：那不想公佈程式碼的人怎麼辦呢？該如何提供程式給不同的 distro 使用者讓他們都可以取用呢？其實是可行的，但說起來有點麻煩，一般只想趕快弄好的廠商除非剛好內行，大概也很少真的這樣做。

提了這一大堆，意思是甚麼？這就要把 Eee PC 等等嘗試裝載 Linux 出貨的 netbook 放進來一起看了。如果朋友介紹你一個好用的 Windows 新程式，而在 Nokia 手機上不能執行，大多數情況你並不介意，因為觀念上我們認為手機跟電腦是不同的。但如果今天它不能在你的筆記型電腦上執行呢？如果用 Windows 能跑的，在你花了一萬多買來的筆記型電腦上都不能跑，那你還會對這台電腦很滿意嗎？假如它也不能讓你容易的處理朋友寄來的文件檔跟簡報檔呢？

（有興趣的讀者，可以略為打聽預載 Linux 系統的小筆電退貨率…）

那麼我們不禁要問，為何要裝 Linux 呢？為何不裝 Win XP 就行了？那是因為與 XP 相比，Linux 有開放原始碼的優勢（當然啦，也有些作業系統技術上的優勢，但這裡就不引起筆戰了），能夠在便宜的硬體上做出更好的效能，而且還可以省下付給 Microsoft 的那一筆授權費用。這表示價格優勢，也部份說明了為何現在 netbook 回到預載 XP 後又掉入效能與價格競爭的窘況。況且，目前 netbook 以 Intel CPU 為主，但若考慮目前如 ARM 系列的功耗、效能，似乎建構在其他 CPU 上的 netbook 也不遠了（其實已經出現），這在以 Intel 為主的 Windows 作業系統來說，又是另一個有趣的變數。

而 Android 的加入，可以扮演甚麼角色，又將會造成甚麼改變？前文曾提及，Android 提供了只需發行程式而不需發行程式碼的方案，因為所有程式都是在虛擬機器上面執行，所以一份程式，大家通用。這就創造出 FOSS 常欠缺的 ecosystem，讓大家各取所需，有獲利方式。另一方面，Android 在硬體層也避開了 linux driver 的灰色地帶（這部份又有一些學問，也許日後再述吧），而讓廠商可以安心的不公開驅動程式的程式碼。更遑論 Android 對 ARM 的原生支援…

然而，儘管有這麼多好處，目前 android 仍然是不能執行 windows 程式的，只是它允許了廠商相對容易的「發行 Android 版」，而又不需公開程式碼。下一步，就是看使用者的習慣能否成功的改變。一是大家開始用雲端運算處理朋友寄來的簡報檔、文件檔，這是 Google 的如意算盤，再不就是 Microsoft 推出 Android 版的 Office，這似乎也不是不可能吧？

就筆者 FOSS 推廣者的角度來說，Android 不是甚麼好事，但無可否認它在商業模式很周到，而任何一個理想都需要不餓死才好推行。

加入MMDays在facebook的粉絲團 隨時閱讀最新文章