Windows上的Android和iOS应用程序：深度解密

原文： Arstechnica ，本文由TECH2IPO/创见编译。

创见干货：Build2015 大会上，微软宣布 Windows 10 将支持 Android 和 iOS 应用程序，消息一出引来哗然。绝大多数人都认为微软这么做必然将走向黑莓的老路。但是当我们深入挖掘这一 Android 和 iOS 应用支持技术的背后，我们发现，微软很有信心，而且成功几率也远远 BlackBerry 10 操作系统支持 Android，但依旧存在失败的风险。创见认为，这次微软的成功几率能到 50%。

在自家平台上运行其他家的应用程序，以前也有人这么干过，但是这么做并没有什么卵用。

上周，微软在美国召开了 Build 开发者大会，宣布了可以让有些疲惫的 Windows 用户一点小激动的内容：Windows 系统将支持 iOS 和 Android 应用程序。

很明显，这一举动非常危险。Windows 并否第一个运行外部操作系统应用程序的操作系统。其他系统也有先例，比如 IBM 在上世纪 90 年代的时候曾经宣布自己的 OS/2 操作系统是“比 Windows 更 Windows 的操作系统”，它既可以保留下 Windows 应用的稳定性，同时又能保证性能。而最近几年，黑莓 BlackBerry10 操作系统也曾支持 Android 应用程序，用户可以直接从 Amazon App Store 或使用自家商店来使用兼容的 Android 应用程序。

不管是 OS/2 还是 BlackBerry 10，他们系统都没有取得什么成功。在自家平台上运行外部应用程序主要面临两大问题。第一个很明显：原生平台的开发者开发兴趣荡然无存。在一个小众的平台上开发应用程序本来就是一场赌博，然而兼容其他平台的应用程序就相当于向这批开发者传递出了这样的信息：“还学个屁 Windows 开发啊，还写个毛 Windows 原生应用呀。”

最终，IBM 和黑莓的两个操作系统都失败了。最后的结果是，OS/2 操作系统上基本上没有任何原生应用程序，BlackBerry 10 上也没什么原生应用程序。这想表达个什么意思呢？既然 IBM 的 OS/2 已经可以支持开发者写好的 Windows 3.1 应用程序，为什么还要去给 OS/2 开发 Win16 位应用程序呢？

这样的兼容性将使操作系统放弃许多控制权。因为选择了兼容第三方平台上的应用程序，第三方平台的所有者就可以轻易地控制应用程序的 API 和许多新特性。还是以 OS/2 为例，在 IBM 努力地告诉开发者他们的平台兼容 WIn 16 位应用程序的时候，微软已经开始鼓励开发者为 Windows 95 操作系统开发 Win 32 位应用程序。新的 Win 32 位应用程序无法在 OS/2 上运行，而 IBM 鼓吹的许多 OS/2 功能到了市场上和 Win 32 位的一比基本上就废了。OS/2 一开始确实取得了一丢丢小成功，但最后也是失败的一踏糊涂。

支持 Android 应用程序也是同样道理。如果 Android 应用程序中很大一部分内容是生态系统的一部分的话，Android 操作系统中任何的变化（比如 API 和功能等）都将导致旧的版本不如新的版本好用。也就是说，会陷入 Android 应用无法更新不好用的窘境。不过鉴于绝大部分 Android 手机无法获得最新和最好的 Android 版本或最新最好的 Android 功能，所以绝大多数 Android 应用程序都避免使用最新的操作系统功能。也就是说兼容 Android 的平台可以追在 Google 后面跑上一年甚至更久的时间，Android 应用程序无论怎么更新都能带来很高的兼容性。

然而对 iOS 来说，就不行了。如果一个平台想要兼容 iOS 应用程序，就必须无时无刻、亦步亦趋地更上苹果的发展，因为苹果的开发者社区跟进速度太快了。

这一顾虑从去年传闻 Windows 兼容 Android 应用以来就不断传出。看起来微软似乎要犯其他操作系统平台之前也会犯的兼容错误，让自己的平台也兼容 Android。

微软上周在台上说的兼容 Android 和 iOS 也没有特别地让人激动。Project Astoria 和 Islandwood（兼容 Android 和 iOS 项目的代号）出现在幻灯片里的时候，有人觉得 Android 和 iOS 兼容一定会取代微软通用应用程序，而之前 Windows 10 一直坚定地支持通用应用程序。有了替换的方法，似乎没人愿意再去开发什么通用、原生 Windows 应用程序了。

所以说，Astoria 和 Islandwood 会取代 Windows 原生应用开发的可能性是存在的。这么做带来的问题就相当于当年 IBM 的 OS/2 兼容 Win16 软件或者 BlackBerry 10 内置了 Amazon App Store 一样。但这一次又不能说是历史的车轮又按照原样滚了一趟。过去的是历史，未来的我们未知，我们现在还无法断言微软这次的举动是不是和 IBM、黑莓一样。

深入 Astoria

Astoria 和 Islandwood 表面上看起来基本上是差不多的东西，但是它们底层的技术和实现却截然相反。对于开发者来说，Astoria 可能更直观一些。很长时间以来，Windows 对于多平台的 API 都有很好的支持力度，这一功能又被称作是“子系统（subsystemsn)”。Win32 API 是所有的 Windows 软件（包括通用 Windows 应用程序）都在使用的、也是最被开发者熟悉的 API，而在最近几版的 Windows 操作系统中，WIn32 API 也是开发 Windows 软件所需要的唯一 API。但从历史来看，微软也用过其他的 API。第一版的 Windows NT 中包含了 OS/2 子系统，可以运行所有来自 OS/2 的应用程序。怎么说呢，OS/2 也算是微软和 IBM 曾经联合开发的操作系统。

Windows 也曾包含 POSIX 子系统。POSIX 是基于 IEEE 标准 API 的系统，使用了 Unix API。Solaris、Linux、OS X 和 AIX 都包括了 POSIX 或其他非常相似的系统。Windows NT 之所以包含了 POSIX 子系统，是因为当时的美国政府强制要求加入的。跟 OS/2 的子系统不同，POSIX 子系统在 Windows 上维护、扩展了很长一段时间，之前这份工作是由 Interix 来做的，后面就有微软来负责。Interix 后来被微软收购，然后改名为 SFU（Services For UNIX）以及 SUA（UNIX 应用子系统）。

OS/2 子系统在 Windows 2000 上被弃用。POSIX 子系统在 Windows 7 上还可以选择添加的，不过到了 Windows 8 上就已经完全不能选了。不过系统底层还是有组件可以支持子系统运行的，而且该功能完整可用，而 Project Astoria 也正利用了这一点。于是乎，在月初的 Build 大会上，微软推出了一个全新的 Windows 子系统：Android 子系统。

Android 子系统是 Android API 在 Windows 系统上的实现。这个子系统提供了类似于 Android 的 API，可以让应用程序获得系统文件访问、图形访问、使用传感器和摄像机，处理计算和创建线程，保护应用安全，建立网络连接，利用 Windows 内核来实现上述功能。

完整的 Android 子系统 API 集还未发布，或还没有制作完成，不过却可以反映出 Android 操作系统到底是怎么开发出来的。Android 系统采用那个 Linux 内核，使用了大量的开源原生库（原生 Android 应用可以使用），一系列开源 Java API（供 Java 开发应用使用）以及一些与 Google 服务连接的 Java API（这些统称为 Google Mobile Service，GMS）。前两条存在于 AOSP 中（Android Open Source Project，即 Android 开源项目）。然而 GMS 却不包括在 AOSP 中，需要付费。

对于开源的那部分代码，微软原则上是可以使用的，不过在适当的时候，会将一些 Google 的服务重新定向到微软的服务上。例如，Android 的分享 API，就可以直接在 Windows 的分享系统中替换使用。对于 GMS 来说，使用 Google 的资源并不靠谱。于是乎，微软就开发出了跟 GMS 相似的那部分代码。例如，GMS 包含了内购、地理位置服务等 API，微软可以用它自己的服务来代替。

新的 Android 子系统将于装在 Windows Mobile 操作系统（好吧，以后 Windows 手机和小屏幕平板电脑都这么叫）中，但只能用于 ARM 处理器。其他版本的 Windows 不会包含这个子系统。

Astoria 的开发者体验和 Android 开发体验非常非常像。开发者依旧可以在他们习惯的开发环境中开发，比如 Eclipse、IntelliJ，生成 Android 应用程序文件：.apk。

原则上来说，使用 AOSP 开发的应用程序不需要任何修改就可以在 Android 子系统中运行。实际上，现有的 APK 文件在 Android 手机上也不需要进行任何再编译或修改就可以直接安装、运行。使用 GMS API 的应用程序则需要做出一些更改，好用给微软的服务替换 Google 的服务。

微软还会给 Android 应用程序提供一些 Windows 独有的功能，比如活动磁贴等。也就是说，开发者需要修改下代码才能有效地利用微软的 API。因为存在局限性，所以 Android 应用程序并不能很好地在 Windows 上表现出良好的兼容性。

微软也不会像黑莓那样在 Windows 上直接出现一个 Android 应用商店，相反，Android 开发者需要向 Windows 商店提交他们的 APK 文件。上传之后，商店会验证 APK 中是否存在不支持的 API，然后将 APK 重新打包称 Windows AppX 文件。

再说说 Islandwood

看到这里，你可能会觉得 Windows 兼容 iOS 应用应该跟兼容 Android 一样。因为 Android 子系统和 Android 开发环境的关系，Android 开发者将 apk 文件转成 Windows Appx 文件非常简单。

但是 Islandwood 却跟 Astoria 截然不同。Islandwood 没有自己的子系统。Islandwood 转换的应用程序使用了常规的 Win32 子系统。创新之处并不是把 iOS 应用转换成 Windows 应用程序所用的 C++或 C#，而是直接运行 iOS 主流开发语言：Objective-C。

微软已经在 Visual Studio 中加入了对 Objective-C 的支持。Visual Studio 的开发环境可以导入 Xcode 的项目，分析 Objective-C 源文件，所有 Xcode 中的特性都能迁移到 Visual Studio 中。编译器支持 Objective-C 语言，可以将其编译成常见的 Windows 可执行文件。

其背后的技术是把开源 LLVM 工具的部分编译器集成到微软 C++编译器架构中。这一步非常重要，因为 C++编译器架构在整个过程中有着非常重要的地位。C++编译器是 Visual Studio 的 debug 工具，也是 C++和.NET 以及其他功能工具的连接桥梁。它同样负责多种运行安全检查，用以检测编程错误等内容。在 Visual Studio 中编写 Objective-C 程序可以充分利用 C++编译器的强大性能。

也就是说它可以支持所有 C++编译器支持的平台。现在 32 位和 64 位 x64 平台，32 位 ARM 平台以及之后的 64 位 ARM 平台，都将支持 C++编译器。

Islandwood 是否支持苹果的 Swift 编程语言呢？目前正在开发过程中。

编译代码只能说是整个过程的一部分而已；能在 Visual Studio 中开发 Objective-C 代码也并不能让 iOS 应用程序利用所有的 API。于是乎，微软在 Windows 操作系统中实现了 iOS API 集。其中包括低等级的 Objective-C 功能，比如自动引用计数，基本的库等，比如 CoreFoundation，图形库等，比如 UIKit、CoreAnimation、CoreGraphics、CoreText，以及通过 OpenGL 的 3D 支持，还有一些比如 StoreKit、通知等服务。跟 Astoria 一样，有些功能和 Windows 上的功能重叠了。StoreKit 内购 API 可以帮助 iOS 转换应用将购买行为指向到 Windows 商店中去。

API 支持库也将捆绑在 Islandwood 应用中。

值得注意的是，微软的 Islandwood 项目现在依旧处于保密状态。Astoria 项目始于一年前，立项之初就瞬间被曝光。Islandwood 似乎是通过收购招聘而来的项目，有一家名为 Inception Mobile 的创业公司曾开发出将 iOS 应用导出到其他平台的功能。Inception Mobile 公司的联合创始人 Salmaan Ahmed 在 Build 大会上演示了 Islandwood 的一部分功能。他的 LinkedIn 记录也显示，从去年 8 月开始，他已经开始在微软公司上班。

即便是有 Islandwood 项目的帮助，将 iOS 应用导出到 Windows 依旧需要更多的工作要做。在 Astoria 中，可能存在 100% 兼容的 Android 应用程序，但在 Islandwood 中，这种情况绝对不可能发生。这是两种完全不一样的平台，例如，Windows Phone 有返回键，而 iOS 只有一个 home 键，所以开发者需要据此修改代码。

具体的影响要根据 app 来定。Windows Phone 上 King 公司开发的 Candy Crush Saga 就是通过 Islandwood 转制的 iOS 应用，在 Build 会议上说是只需要修改几个百分点的代码即可。Candy Crush Saga 支持了 Windows Phone 版的内购功能，充分录用了 StoreKit 的 API。然而，作为一款游戏，它的用户界面不需要遵循应用程序的 UI 来设计。比较依赖 UIKit 的应用程序可能需要更多的工作来使满足 Windows 用户的需求。

不过得知关注住的是，转制的 iOS 应用程序是完整的 Windows 应用程序。它们可以使用所有的 Windows API，即便 iOS 系统中没法使用活动磁贴和 NFC 功能，也可以在转制过程中得到应用。此外，Islandwood 转制的应用程序不仅仅可以登陆 Windows Mobile，还可以在 Windows 10 操作系统中使用。因为他们使用了标准的 Windows 编译器架构，可以支持混合语言。即，开发者的应用程序主体使用 Objective-C，而活动磁贴则可以使用 C# 来编写。

接近 OS/2 和 BlackBerry 10，但又不相同

开发者如果使用 Astoria 或 Islandwood，那就跟以前 IBM 和黑莓的做法有着重大的区别。无论是 Astoria 还是 Islandwood，都需要开发者参与。而以前开发 Win16 位应用程序的开发者从来就不关心他们的应用程序在 OS/2 上是否能运行。他们只关心自己能不能开发出 Win16 位应用程序。用兼容应用的用户可能会想要原生的 OS/2 应用程序，但是开发者并不在乎。

BlackBerry 10 也是一样的情况。开发者向 Amazon App Store 上传应用程序，是因为他们对与 Amazon 的平板电脑和手机感兴趣。而对于 BlackBerry 10 用户下载的应用程序，他们才不会去关心呢。

而在 Astoria 和 Islandwood 中，第一步就需要开发者的参与。工程量可能并不大（有可能直接上传就可以上架 Windows Store），但是开发者要想把自己的应用程序交付给 Windows Phone 用户的话，就必须细心一点。Windows 可能并不是开发者首选的平台，但也不是不可忽略的平台。

这样一来，开发者就需要对自己开发的应用程序在 Windows 平台上的表现是否优秀而上心。如果他们的应用程序没有使用 Xbox 成就或动态磁贴功能，在商店中就可以看到差评。

这一点上，Islandwood 项目表现的更加明显，因为 iOS 应用转制 Windows 应用必然需要重新编译和一些代码改动。如果开发者根本就不喜欢这个平台，他们是不会做出任何更改的，所以转制应用程序的都是关心这个平台的开发者，哪怕是那么一点点关心。

这样一来，转制 Windows 应用程序的结果就会比之前的 OS/2 和 BlackBerry 10 要好很多。

当然，我们不能逃避可能会对原生 Windows 应用开发产生的影响。Astoria 的局限性就是它可能会让开发者原生应用开发，或者是长期内这个问题不会得到解决。Astoria 应用程序可以被安装在手机和平板中，但却不能在其他 Windows 平台中使用（比如笔记本、电脑、Xbox One 以及 HoloLens 等）。如果开发者想触及这些平台，就必须开发原生 Windows 应用程序。

但这并不十分重要。相比 OS/2 和 BlackBerry 10 操作系统，Windows 的地位可非同凡响。虽然在智能手机和平板电脑领域 Windows 并没有多少市场份额，但是在笔记本电脑和 PC 市场中，微软的 Windows 是绝对的王者。微软曾表示，希望 Windows 10 操作系统能在发布后的 2-3 年里覆盖 10 亿用户。这也是为什么 Windows 7 和 Windows 8 用户可以免费升级 Windows 10 的缘由了。微软不希望自己的平台太过碎片化，它希望所有的 Windows 10 电脑都运行 Windows 通用应用程序。

即便只能达到 5 亿，那也是不可估量的数字。这一部分市场能创造巨大的利润，而 Astoria 应用程序就无权参与这场游戏了。微软希望通用应用能确保 Astoria 应用程序不会抹杀掉 Windows 手机和平板上的原生应用程序。虽说 Astoria 是权宜之计，但微软赌开发者绝对不会把所有兴趣都只放在手机和小尺寸电脑上。开发者如果想要把应用程序全方位推向所有 Windows 设备，就必须开发通用应用。

如果开发者对于这个更大的市场并不感兴趣的话，麻烦的问题就来了。只对手机市场感兴趣的开发者只会用 Astoria 工具来转换 Android 应用程序。虽然体验并非完美，但也算够用，满足用户的基本需求，至少不会出现缺应用的问题。

那 Islandwood 呢？更麻烦的问题也来了。Islandwood 应用程序会把 iOS 应用转制成传统的 Windows 应用程序。这个 Windows 应用程序用诡异的语言编写，用了大量的库来把 iOS 的 API 翻译成诡异的 Windows API，但却和原生应用一样可以出现在市场里……然后需要用 Windows 的编程语言来让他们运行。可以说，这些转制应用不会对原生应用开发产生任何威胁，因为他们来自于完全不同不同的开发环境。

此外，微软的这个策略也极具风险性。如果微软并不能让开发者有兴趣参与到更大的市场中去，那么 Astoria 将切底腐蚀 Windows 智能手机的开发。微软肯定会更明确地告知开发者，但策略确实有风险，开发者也不会这么快就听话地去开发通用应用。微软还有许多东西需要解释。

除此之外，也要考虑开发者是否有兴趣参与 Astoria 和 Islandwood 项目。Islandwood 或许更吸引眼球，但是没有一个是可以自动完成的。现在有很多开发者在 Xamarin 上用 C# 和.NET 开发 Android 和 iOS 因那个用那个程序。这些应用程序可以轻松地导出到 Windows 8 和 Windows Phone 上，但是这些开发者并不会这么做。

如果开发者的这种“病”不能得到治疗，Astoria 和 Islandwood 的出现并没有什么“卵用”。如果能够让开发者“服药”，那么 Astoria 和 Islandwood 可谓是微软 Windows 现在急需的一剂猛药。