一條能夠承載十億用戶的橋梁，但它所通往的終點是……Android與iOS？！

在上周召開的Build開發者大會上，微軟公司連續發布了一系列關于Windows系統平臺的開發聲明，其中一項內容甚至堪稱爆炸性：Windows系統將支持面向iOS以及Android開發的應用程序。

從第一印象來看，這一舉動明顯極度危險。Windows絕不是第一款希望能夠將其它應用程序納入自身支持范疇的系統平臺。眾所周知，IBM公司曾經于上世紀九十年代將OS/2宣揚為一套“比Windows更Windows”的操作系統，并鼓吹其能夠運行全部現有Windows應用程序、且具備更出色的穩定性與性能表現。就在最近，BlackBerry 10也實現了對Android應用程序的支持能力，黑莓通過Amazon App Store提供許可并利用其作為通向Android兼容性軟件的捷徑。

然而無論是OS/2還是BlackBerry 10都沒能成功踐行自己所承諾的能力。在一套利基平臺上支持其它應用程序主要面對著兩大難題。第一是便捷性：它消除了開發人員費心了解目標平臺原生特性的理由。投入時間與精力學習某種小眾平臺，這本身就不啻為一種賭博，而向開發人員們傳達“哦嘿，你可以直接使用自己的現有Win16或者Android程序……”的作法，正如IBM與黑莓原先所做的，實際上傳遞出了一種對自己殊為不利的信息——“別費心學習我們的平臺或者為其編寫原生應用了，沒必要。”

事實證明，這兩款平臺也遭遇到了如預期一樣的命運。盡管確實有開發人員編寫出一些真正的OS/2應用程序——同樣的情況也發生在BlackBerry 10平臺之上——但它們的數量與規模都非常有限。關于這種情況，我們不妨再說得明確一點。如果IBM公司計劃投入大量資源來改善Win16應用程序在OS/2上的運行效果，而這些Win16應用程序又確實能夠同時被出售給OS/2用戶與Windows 3.1用戶，那么開發人員為什么還要費力氣去編寫Win16之外的純OS/2應用呢？

這種能力在實現過程中放棄了大部分控制空間。為了讓這些面向第三方平臺開發出的應用程序能夠順利運行在自身環境之下，我們必須拱手聽命于第三方平臺、根據其實際情況調整自己的API并添加新功能。這一點絕對讓OS/2吃盡了苦頭：就在IBM公司一直忙于宣傳OS/2在運行16位Windows應用程序時的出色表現時，微軟公司則將時間與精力用于鼓勵開發人員創建新的32位Windows應用程序，從而推動最終用戶們購買能夠支持32位應用的Windows 95。32位軟件的新世界顯然不是OS/2能夠就會得了的，因此IBM公司在營銷過程中著重強調的OS/2重要特性就這樣變得一文不值。OS/2確實在一部分利基市場上獲得了成功，但其最終仍然難逃失敗的命運。

支持Android應用程序也將帶來類似的風險。如果Android軟件成為一套平臺上軟件生態系統的主要組成部分，那么Android系統中的任何變動（例如新型API或者其它功能的出現）在給相關應用程序帶來提升的同時、也會給支持其運行的其它系統平臺帶來巨大壓力。不過在這方面，Android陣營糟糕的系統更新狀況倒是能讓人少一點擔心。畢竟大多數Android手機都沒能匹配最新的Android功能或者系統版本，所以大多數Android軟件都不具備這種與時俱進的新特性。這意味著Android兼容性平臺能夠在一年甚至更長的時間段內與谷歌的前沿設計思路保持距離，而同時繼續擁有對Android應用程序的良好支持能力。

但這種狀況在iOS陣營方面卻并不適用。要想與蘋果的應用程序相兼容，Windows平臺必須始終跟得上iOS的發展步伐，因為蘋果的開發者社區絕不接受任何形式的功能妥協。

考慮到上述問題，我們就能明白為什么在Windows平臺上支持Android應用程序會被視為一種混亂的開端，而且自去年相關消息傳出后技術業界就一直抱持著這種負面態度?？雌饋?，微軟公司只是單純犯下了此前其他人犯過的錯誤——希望依靠一己之力幫助其手機平臺進行最后一搏。

微軟公司上周在Build大會上提出的Android與iOS支持議案時并沒有為二者提供特別的推廣力度。Astoria項目與Islandwood項目——二者分別為Android與iOS應用程序支持方案的代號——只是分別在自己的主題演講中得到了強調。也許有人會認為，Android與iOS應用程序支持能力將成為Windows 10在各類硬件基礎之上實現通用化Windows App發展思路的堅實根基。但我們得說，從開發者的角度來看，為其它平臺開發應用程序再將其移植到Windows上、明顯要比直接開發原生Windows應用要劃算得多。

很明顯，Astoria與Islandwood兩大項目確實有可能帶來原生Windows應用無人問津的風險。這種強行支持的作法也很像當初IBM公司讓OS/2與Win16軟件相兼容、或者BlackBerry 10擁抱Amazon App Store的掌故。不過必須承認，這二者之間并不完全相同。盡管目前還無法確定，但我們也許會發現在微軟的引導下、情況將會走向與IBM及黑莓不同的推進道路。

Astoria項目深入剖析

Astoria與Islandwood從表面上看非常相似，但其底層技術與實現方式則迥然有別。對于開發人員而言，Astoria項目可能顯得更為直觀。Windows系統長久以來一直擁有著利用所謂子系統機制支持多種API體系的能力。其中Win32 API一直為幾乎所有Windows軟件所使用（其中也包括通用型Windows應用），它同時也是影響最大、知名度最大的API之一。而在Windows的現代版本當中，它事實上也成為惟一留存的API。不過從歷史角度講，Windows上的API家族其實也曾經興盛。在此之中，首個Windows NT版本當中就包含有一套OS/2子系統，其能夠支持一部分特定OS/2應用程序。但這僅僅是歷史上的一段小插曲，是證明著微軟曾經與IBM協作開發操作系統的故紙殘留。

Windows還曾經包含有一套POSIX子系統。POSIX屬于IEEE標準化下的API，從本質上講用于定義Unix API。以Solaris、Linux、OS X以及AIX為代表的多種操作系統都擁有POSIX或者其它類似的實現方法。Windows NT之所以要將POSIX納入支持范疇，是因為美國政府方面的監管機構曾經就此作出過強制要求。與OS/2子系統不同，這套POSIX子系統的維護甚至是擴展工作都延續了多年，相關任務首先由第三方（也就是Inetrix公司）負責，而后由微軟親自打理。微軟方面而后收購了Interix工具并將其重新命名為Services For Unix（簡稱SFU）以及Subsystem for UNIX Applications（簡稱SUA）。

從Windows 2000開始，OS/2子系統正式被扔進歷史的垃圾堆。而POSIX子系統則直到最近的Windows 7才開始作為可選組件存在——而在Windows 8中，其支持能力則徹底告別了歷史舞臺。然而，在新版本中用于支持子系統的底層操作系統組件卻被保留了下來，而且依然能夠發揮作用——Astoria項目的出現也正是得益于此。其引入了新的Windows子系統：Android子系統。

這套Android子系統在Windows上實現了Android API組合的一套子集。該子系統能夠提供Android風格的各類API，包括文件系統訪問、圖形處理、傳感器與攝像頭訪問、進程與線程創建、安全性以及網絡等等，這一切核心服務都將通過Windows內核實現交付。

目前微軟方面尚未公布或者說設定受支持API的具體類別，不過這份最終清單很可能由以下三大部分所組成——它們也直接反映了Android系統的構建方式。Android擁有一套Linux內核以及一系列開源原生庫，這些用于支撐原生代碼應用程序的正常運行; 一套開源Java API集合，用于支撐Java應用程序的正常運行; 此外還有一套專用性Java API組合，其與各谷歌服務相綁定，且被統稱為Google Mobile Services（即谷歌移動服務，簡稱GMS）。前兩類同樣被包含在AOSP，也就是Android開源項目當中，但第三項則為商用Android系統所獨有。

在開源方面，微軟公司在原則上能夠利用其實現機制使用這些開源代碼，從而為應用程序提供其運行所需的Java API——只不過其會根據實際情況被重新定向至Windows服務處。舉例來說，Android共享API能夠被引導至Windows的共享系統處。對于GMS，微軟則不會使用與之相關的源代碼。相反，微軟方面已經決定至少為為一部分GMS API提供替代性方案。舉例來說，GMS當中包含用于實現應用內購以及位置服務的API，而微軟方面則開發出了由自有服務所支持的同類機制。

這套新的子系統將以預安裝方式成為Windows Mobile的內置組成部分——沒錯，Windows Mobile這個我們曾經非常熟悉的名稱此次換了新顏，再次成為手機及小屏幕平板設備上Windows版本的名號。其只支持ARM處理器，而且Windows的其它版本還未將其納入自身。

開發人員在使用Astoria時，其體驗與普通Android開發人員非常相似。開發者將能夠繼續使用Android開發環境，例如Eclipse或者IntelliJ，而且也可以繼續構建Android應用軟件包，也就是APK文件。

如果應用程序僅僅使用AOSP API子集、也就是Windows子系統中所支持的部分，那么在原則上其內容不需要作出任何改變。事實上，被分發到Android用戶手中的各類現有APK都應該能夠在無需重新編譯或者修改的前提下順利運行在Windows平臺之上。采用GMS API的應用程序則需要進行一些調整，因此它們需要將原本的谷歌代碼替換為由微軟提供的同類機制。

微軟公司還會提供一部分特殊的Windows API，從而保證Android應用能夠訪問實時磁貼等Windows環境下特有的功能。當然，開發人員還需要進行相應的代碼變更來發揮這些API的實際效果。不過這種改動非常有限，而且Android應用本身并不會對全部底層Windows功能進行訪問。

微軟公司并不打算像黑莓那樣在Windows平臺上支持Amazon App Store。相反，Android開發人員需要將其APK提交至Windows軟件商店。在這里，微軟方面會識別出其中所包含的不受支持的API，而后將APK重新封裝為Windows AppX軟件包。

#p#

踏上Islandwood新大陸

有人可能會以為讓iOS應用運行在Windows平臺上所需要的技術機制跟讓Android登陸Windows差不多。Andoird支持所使用的子系統方案并沒什么特別之處，而且APK以及其它常規性Android開發流程的存在意味著Android開發人員只要愿意、完全能夠在不費什么工夫的前提下為自己的應用弄出一套Windows版本來。

不過Islandwood項目與Astoria可以說完全不同。Islandwood程序并不具備自己的子系統機制。它們完全屬于利用常規Win32子系統實現運行的常規Windows應用程序。但更令人意外的是，它們并非采用傳統意義上的Windows程序編寫語言所開發，例如C++或者C#。相反，它們所采用的編程語言目前在iOS開發領域仍然占據著主導地位，這就是Objective-C。

微軟公司已經在Visual Studio添加了對Objective-C的支持能力。整套開發環境能夠實現Xcode項目的導入并理解Objective-C源文件，開發人員在開發環境中經常使用的彩色編碼、自動補全以及其它各類功能也一樣不少。其編譯器支持Objective-C，而且能夠將其編譯為常規的Windows可執行文件。

Objective-C programs built in Visual Studio get all this from the compiler.從實現過程的角度看，這種對Objective-C的支持能力主要由其開源Clang編譯器實現，其作為開源LLVM工具鏈的組成部分、存在于微軟的現有C++編譯器體系當中。之所以如此重要，是因為這套C++編譯器架構完成了大部分核心性工作。它能夠以Visual Studio可以識別的格式輸出調試結果，并奇跡般地實現C++與.NET之間的各類互操作性等等。它同時也負責收集運行安全檢查的各項結果，從而檢測出程序員們不小心留下的紕漏。

這意味著該編譯器將支持微軟C++編譯器所能應對的全部硬件平臺類型。就目前而言，其主要分為三大平臺——32位與64位x86，再加上32位ARM。據稱今年晚些時候，微軟會加入第四種平臺的支持能力——64位ARM。

一款面向iOS的應用程序正在Visual Studio 2015環境下進行編輯。

那么蘋果的另一款開發語言，Swift，又獲得了怎樣的支持效果呢？據稱相關工作仍在進行當中。

當然，代碼編譯還僅僅是這項宏偉工具的一小部分。單單能夠構建Objective-C代碼還不足以完成任務，因為如果開發人員必須對每一項API調用進行重寫、那么前面提到的一切都將失去意義。就這一問題，微軟公司已經在Windows上實現了iOS API的一套子集。其中包含有大量底層Objective-C功能，例如自動引用計數與塊，CoreFoundation等基礎庫，UIKit、CoreAnimation、CoreGraphics以及CoreText等圖形庫，利用OpenGL實現的3D支持能力以及StoreKit與Notifications等其它服務。正如在Astoria項目當中一樣，這些能力被融合到了Windows自身當中，而且事實了證明其確實行之有效。舉例來說，StoreKit應用內購機制將被映射到Windows Store中的同類功能處。

這套API支持庫將被綁定至Islandwood應用程序當中。

Islandwood項目的一大顯著特征在于，微軟方面一直對其三緘其口。Astoria項目自一年前誕生之時起就立刻得到了公布。然而Islandwood項目則似乎是某種收購交易下的產物; 一家名為Inception Mobile的初創企業曾經拿出過一套類似的方案，旨在將iOS應用程序移植到其它平臺之上。Inception Mobile聯合創始人Salmaan Ahmed在本次Build大會的Islandwood環境上露了一面，而且他的領英信息顯示其自去年八月開始就一直在為微軟公司效力。

即使有了Islandwood項目作為支持，將iOS應用程序移植到Windows環境下所需要的努力仍然遠遠超過Android應用。相較于一部分Android應用程序已經能夠100%為Astoria項目所兼容的樂觀形勢，Islandwood項目的狀況就比較被動了。不同平臺之間存在著大量需要加以解決的本質性差異——舉例來說，Android與Windows Phone都具備后退按鈕，但iOS卻沒有——而開發人員則必須據此作出代碼調整。

[[133841]]

Islandwood項目的第一款成果——《糖果粉碎傳奇》。

這種影響在不同應用程序上的實際效果也有所區別。King為Windows Phone開發的《糖果粉碎傳奇》已經開始使用了Islandwood項目的技術成果，而其中的代碼內容調整據稱僅為項目整體的“百分之幾”?！短枪鬯閭髌妗返腤indows Phone版本支持多項功能，包括應用程序內購，而這自然要得益于StoreKit API映射機制的幫助。不過作為一款游戲，其用戶界面仍然進行了大幅度定制。在深入了解了UIKit之后，應用程序成果應該還需要作出更多努力，從而保證Windows用戶能夠在其中獲得符合自身預期的界面效果。

在另一方面，這些應用程序完全屬于Windows應用范疇。它們能夠訪問任何Windows API，即使這些API在iOS上并沒有同類的替代性方案，例如活動磁貼與NFC。此外，這些應用程序也并不限于Windows Mobile平臺; Islandwood應用能夠運行在任何Windows 10平臺之上。由于它們使用同樣的標準Windows編譯器架構，因此能夠支持多種編程語言。舉例來說，開發人員可以選擇利用C#實現活動磁貼支持能力——即使該項目的其它部分完全由Objective-C編寫而成。

#p#

與OS/2以及黑莓的發展戰略類似，但并不完全相同

是否要使用Astoria或者Islandwood，這正是微軟與當初IBM及黑莓之間的本質區別。Astoria與Islandwood都要求開發者為其作出一些承諾，相比之下那些編寫Win16應用的開發者可絕對用不著為OS/2作任何形式的考慮——他們只需要單純編寫Win16應用即可。偶爾也會有一部分OS/2用戶購買了Win16軟件的縮水版本來證明他們要將其使用在OS/2之上，但這些開發人員顯然根本感受不到。

BlackBerry 10也存在著類似的狀況。開發人員可以將自己的應用程序提交到Amazon App Store上，但這僅僅是因為他們對于Amazon生產的平板設備（或者是其手機產品）抱有興趣。事實上，一部分BlackBerry 10用戶確實下載了這些應用程序，但這些與開發人員既不相關、也無法為其所知曉。

但現在有了Astoria與Islandwood，開發人員必須首先邁出這第一步。這一步可能還算不上巨大——從潛在層面講，他們需要做的也許只是拿出一套未針對Windows經過任何調整的APK——但無論如何，每位開發人員都必須意識到，自己的應用程序從這里開始將被呈現在Windows用戶面前。Windows雖然仍然沒法就此成為他們的首選平臺，但同樣的，他們也不可能對其完全加以忽視。

反過來，這也會讓開發人員對于自己的應用程序在Windows平臺上的運行效果采取更為審慎的態度。如果無法使用Xbox成就或者活動磁貼等Windows的特有功能，那么這些應用程序在外觀與第一印象上都會變得非常糟糕?？偠灾?，開發人員會清醒地意識到，這些應用程序可是專門針對Windows客戶群體所推出的。

Islandwood項目則會讓這一切變得更為突出，因為開發人員需要對自己的開發成果進行重新編譯、并對部分代碼加以調整。只有投入心力，這些應用才能切實起效，這至少在一定程度上類似于開發一款純粹的Windows應用程序。

從這種意義來看，微軟要求開發人員將應用程序使用體驗移植到Windows上的作法應該要比歷史上那些已經折戟沉沙的前輩們更高明一些。

按理來說，微軟公司的方案也不太可能阻礙原生應用程序的開發趨勢。Astoria項目中的局限性排除了其真正取代原生開發活動的機率，而且擔心這些限制最終會被放開的朋友們也不用緊張了——至少在相當長的一段時間里，這種情況都還不可能發生。Astoria應用程序將能夠在手機以及小尺寸平板設備上發揮作用，但更為廣闊的Windows平臺（例如筆記本、PC、Xbox One甚至是未來可能出現的HoloLens）仍將成為擋在其面前的壁壘。要想登陸這些，開發者朋友，拿出你的原生應用來。

當然，這種局限也不能說毫無負面影響。與當初的OS/2以及BlackBerry 10相比，Windows所處的市場地位可謂完全不同。盡管Windows在智能手機與平板設備領域一直沒能達到微軟所預期的普及程度，但其在筆記本與PC市場上仍然是絕大多數用戶的首要選項。微軟公司表示，其希望能夠在Windows 10發布的兩到三年內將其用戶數量提升至10億之巨。正是出于這樣的考量，微軟才會以免費升級的方式將Windows 10半賣半送到Windows 7及Windows 8用戶手上。微軟公司并不希望自己的平臺呈現出過度碎片化的版本生存狀態; 他們的想法是，每種設備都運行有Windows 10，每種設備也都能運行通用型Windows應用。

即使最終目標只能達到預期值的一半，5億用戶也仍然是個龐大的基數，其中當然也蘊含著可觀的潛在經濟收益。Astoria應用程序自然不可能對這塊蛋糕熟視無睹。微軟公司之所以采取現在的這種機制，是為了確保Astoria項目不至于徹底扼殺手機以及小型平板設備上的原生Windows應用開發活動。盡管Astoria項目將成為一塊極具實效的跳板，但微軟公司這次賭的是開發人員并不希望單純將其應用限定在手機設備之上。他們應該會愿意將應用成果拓展到整個Windows設備陣營，而要做到這一點、開發人員就必須編寫出真正的Windows應用程序。

但如果事實證明開發人員對這片更為廣闊的市場不感興趣，那么情況就相當棘手了。只對手機平臺感興趣的開發人員將徹底放棄Astoria應用。雖然這類應用程序確實無法帶來完美的使用體驗，但在開發者看來可能已經足夠好了，特別是如果他們壓根沒考慮過為其開發真正的Windows版本的前提下。

那么Islandwood項目又會如何？恐怕更加棘手。Islandwood應用程序將成為跟傳統Windows應用類似的弱勢群體。它們將成為一類利用奇怪語言所編寫、需要利用大規模代碼庫加以翻譯才能將自身API調用轉換成Windows可接受的形式的特殊Windows應用，而且這意味著它們與其它Windows應用存在同樣的問題——其中包含大量只有依靠Windows特定代碼才能順利起效的內容?？梢哉f，它們并不會給原生開發工作帶來什么威脅，因為它們完全就是另外一種原生開發途徑。

需要再次強調的是，微軟公司所制定的發展戰略確實面臨著風險。如果軟件巨頭無法引導開發人員將著眼點放在更為廣闊的Windows市場，那么Astoria很可能給Windows智能手機平臺上的開發工作帶來純粹的負面影響。此外，微軟公司肯定會與其開發者社區進行明確交流，即盡管這項發展戰略存在諸多風險，但卻并不是一定會出現?？偠灾?，這類話題完全是全憑一張嘴，怎么都解釋得通。

當然，前面提到的這一切都有個必要條件，就是假設Android與iOS開發人員至少會對Astoria以及Islandwood抱有興趣?？紤]到iOS平臺的廣泛影響力，Islandwood思路可能更容易被人們所接受，但這也需要微軟方面的努力推動。目前已經有很多開發人員在Xamarin的幫助下利用C#與.NET為Android以及iOS系統平臺開發應用程序。這些應用應該能夠較為輕松地被移植到Windows 8以及Windows Phone之上——當然，前提是開發人員有閑心這么做。

但如果這種直接無視的習慣未來仍然得不到扭轉，那么無論是Astoria還是Islandwood項目都不會給Windows帶來任何顯著的影響——無論是好的還是壞的。但如果二者真能受到廣泛關注，如果移動開發人員確信Windows用戶是值得而且易于拉攏的，那么Astoria與Islandwood必將給正呈現出疲態的Windows注入一針有力的強心劑。