一直以来都有传闻称，Windows 10将会兼容安卓应用，这看上去似乎是天方夜谭，但微软真的做到了，以一种很特别的方式，而且不仅是安卓，还有iOS！
Build 2015开发者大会上，微软宣布了打造Windows 10通用应用、进入Windows Store的四种新方法，个个都让开发者激动万分。
1、Web
可直接重新使用基于服务器架设的网站和工具，简单地说就是打包成一个Web应用。
开发者无需开发一个完整的应用，而且也支持应用和内购。
微软演示了斯巴达浏览器中的“22 tracks”。
2、.NET、Win32
现在海量桌面程序的根基(微软说每个月都有1600多万个此类程序在运行)，可以直接移植到Windows Store，不过出于安全考虑，此类应用的运行会与系统其他部分隔离开来。不知道性能是否会有明显损失。
演示对象是Adobe Photoshop Element。
3、Android Java/C++
这就是传说中的兼容安卓应用！
开发者可以直接重新使用安卓应用的技术所有Java、C++代码，轻松打造出Windows 10手机应用。现场的开发者纷纷故障吹哨。
Windows手机将会包含一个Android子系统，专门运行此类应用。
用来演示的是一个订酒店的应用“Choice Hotels”，直接跑在了Windows 10手机上，而导航则是Windows负责的。
4、iOS Objective C
借助Visual Studio，直接将iOS应用一直到Windows 10上！
调出所有代码，调试一番，就可以在Windows 10设备上运行了。就这么简单。现场的开发者都疯了。
用来演示的是手游《糖果传奇》(Candy Crush Saga)。
稿源：驱动之家
引用来自“eechen”的评论
一键移植，想想都有点小激动，真有那么轻松，Google早就发布自己的Android Runtime for Chrome，使 Android 应用以 Chrome 扩展形式运行在 Chrome OS 系统上了。https://github.com/vladikoff/chromeos-apk/blob/master/archon.md
http://www.omgubuntu.co.uk/2014/09/install-android-apps-ubuntu-archon
ARC(Android Runtime for Chrome)基于Google的Native Client(NaCl)功能，其允许通过浏览器来运行原生代码(通常是C或C++)，同时具备Chrome所提供的同等安全性。显然，NaCl扩展是可以做到跨平台的，这意味着它能够在PC、Mac、以及Linux等系统的桌面版Chrome浏览器上运行。
在实际体验中，该扩展还是有一些局限性和不完美的地方的。因为首先，Android APK需要通过chrome-apk tool先转换成Chrome扩展的格式，另外有些应用的稳定性并不好。我在Ubuntu上用ARC跑OSC客户端还是可以的。
引用来自“花儿笑弯了腰”的评论
来晚了啊，刚起床吗引用来自“铂金小鸟”的评论
是刚查好资料！引用来自“╭ァの修罗”的评论
那IOS应用呢？引用来自“dreamhack”的评论
test引用来自“eechen”的评论
一键移植，想想都有点小激动，真有那么轻松，Google早就发布自己的Android Runtime for Chrome，使 Android 应用以 Chrome 扩展形式运行在 Chrome OS 系统上了。https://github.com/vladikoff/chromeos-apk/blob/master/archon.md
http://www.omgubuntu.co.uk/2014/09/install-android-apps-ubuntu-archon
ARC(Android Runtime for Chrome)基于Google的Native Client(NaCl)功能，其允许通过浏览器来运行原生代码(通常是C或C++)，同时具备Chrome所提供的同等安全性。显然，NaCl扩展是可以做到跨平台的，这意味着它能够在PC、Mac、以及Linux等系统的桌面版Chrome浏览器上运行。
在实际体验中，该扩展还是有一些局限性和不完美的地方的。因为首先，Android APK需要通过chrome-apk tool先转换成Chrome扩展的格式，另外有些应用的稳定性并不好。我在Ubuntu上用ARC跑OSC客户端还是可以的。
引用来自“花儿笑弯了腰”的评论
来晚了啊，刚起床吗引用来自“铂金小鸟”的评论
是刚查好资料！引用来自“╭ァの修罗”的评论
那IOS应用呢？引用来自“duyaofei”的评论
傻，能编译出来2进制了，还虚拟个毛。同样1+1的代码，在同样架构和指令集的CPU上是一样的。实现一个2进制兼容层就OK，类似wine。Android本来就是jvm，实现一个不就行了。。。引用来自“_小小的等待”的评论
微软的想法是！先把用户与开发者吸引到自己的平台！然后用户多了！开发者就会觉得移植的APP体验不比原生好！然后自然去写原生C#应用引用来自“duyaofei”的评论
傻，能编译出来2进制了，还虚拟个毛。同样1+1的代码，在同样架构和指令集的CPU上是一样的。实现一个2进制兼容层就OK，类似wine。Android本来就是jvm，实现一个不就行了。。。引用来自“duyaofei”的评论
如果实现有重定向的API，并且把文件头替换为WinPE格式，应该问题不大，就是iOS的app兼容性问题估计不少。Android的相对好些，但是需要调用底层的估计不行，例如要运行于system空间的，要调用硬解码器的引用来自“梁选”的评论
人家是代码移植，哪来的兼容性可说？你以为是装app啊？引用来自“海淀游民”的评论
没解决实际问题，现在的实际问题是开发移动应用做两套成本太高。另外这个战略对于小公司说的过去，对于微软这种系统级厂商就不对了，系统之战实际上是API之战，这种兼容运行更没人去弄win10的API了，反正写安卓或者iOS都可以在Win10上运行。
引用来自“梁选”的评论
还不是为我win10开发，哈哈哈引用来自“duyaofei”的评论
傻，能编译出来2进制了，还虚拟个毛。同样1+1的代码，在同样架构和指令集的CPU上是一样的。实现一个2进制兼容层就OK，类似wine。Android本来就是jvm，实现一个不就行了。。。引用来自“duyaofei”的评论
如果实现有重定向的API，并且把文件头替换为WinPE格式，应该问题不大，就是iOS的app兼容性问题估计不少。Android的相对好些，但是需要调用底层的估计不行，例如要运行于system空间的，要调用硬解码器的引用来自“海淀游民”的评论
没解决实际问题，现在的实际问题是开发移动应用做两套成本太高。另外这个战略对于小公司说的过去，对于微软这种系统级厂商就不对了，系统之战实际上是API之战，这种兼容运行更没人去弄win10的API了，反正写安卓或者iOS都可以在Win10上运行。