一条能够承载十亿用户的桥梁，但它所通往的终点是……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却没有——而开发人员则必须据此作出代码调整。
Islandwood项目的第一款成果——《糖果粉碎传奇》。
这种影响在不同应用程序上的实际效果也有所区别。King为Windows Phone开发的《糖果粉碎传奇》已经开始使用了Islandwood项目的技术成果，而其中的代码内容调整据称仅为项目整体的“百分之几”。《糖果粉碎传奇》的Windows 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特定代码才能顺利起效的内容。可以说，它们并不会给原生开发工作带来什么威胁，因为它们完全就是另外一种原生开发途径。
需要再次强调的是，微软公司所制定的发展战略确实面临着风险。如果软件巨头无法引导开发人员将着眼点放在更为广阔的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注入一针有力的强心剂。
