苹果在今年的WWDC上宣布，macOS 11将会迁移到ARM平台，引起了轰动。苹果称，将会在 Mac 电脑上用自研 ARM 平台取代 Intel 的 X86平台，并且迁移包括操作系统和软件在内的生态，这意味着 ARM 在个人 PC 领域迈出了挑战 X86的一步。

macOS 11将兼容 ARM 芯片

人们对苹果的这个举措是寄予厚望的。macOS 并不是首次 “换马”，在二十一世纪的第一个十年，Mac 就从 IBM PowerPC 平台迁移到了 Intel X86平台，并取得了成功，这也是人们对 Mac 此次换用 ARM 后，仍能提供良好体验抱有如此信心的一大原因。

苹果宣布这一消息的同时，不少人同时也联想到了微软——微软已经在 ARM 领域摸索多年，推出过 Windows RT 这样的特制系统，最近更是让 Windows 10运行在了 ARM 上，并且兼容之前的大量软件。然而，Win10 ARM 战略似乎未能取得太大反响，Windows RT 甚至直接暴死。

微软早已经涉足 ARM 领域，推出了基于 ARM 的 Windows 平板

Mac 迁移平台来势汹汹，人们普遍的预期是顺风顺水，而 Win10却屡屡碰壁。Win10在 ARM 的道路上，到底行差踏错了些什么?今天一起来谈谈这个问题吧。

1.X86转移 ARM：到底会有什么坑?

众所周知，ARM 和 X86平台最大的区别是微架构的不同。ARM 属于 RISC 简单指令集，而 X86则是 CISC 复杂指令集，程序要这两个不同的平台运行，需要编译不同的版本。当然，借助中间层，也可以实现两个不同平台之间的兼容。

然而，无论是那种方案，将之前兼容 X86的操作系统要将生态迁移到 ARM，都需要付出代价。

如果放弃 X86平台上老软件的兼容，只让新软件兼容 ARM 平台，那么就意味着生态系统需要从头做起，新系统起步会变得非常艰难。在过渡期间，新开发的软件需要同时兼容 X86和 ARM 平台，意味着要么开发者投入更多的精力自行编译不同的版本，要么操作系统的开发套件提供同时编译的功能。无论如何，都需要投入更多的工作。

而如果想要生态无缝衔接、让新的 ARM 平台起步更顺利，最好可以让 X86平台的老软件直接可以运行在新的 ARM 平台上，那么就需要对中间层做工作了。例如 Android 就是一个很好的例子，通过 HAL 来模糊硬件接口，利用善于跨平台的 JAVA 作为应用上层，无论是运行在 X86的 Android 还是 ARM 的 Android，都可以同时兼容绝大部分的 App。

但这个方法的缺点在于，中间层可能会成为效率的瓶颈。Android 的中间层就很厚，效率感人诟病已久。

X86指令转制为 ARM 实现兼容，性能下滑不可避免

另外，由于 ARM 多用于移动平台，因此如果桌面操作系统想要迁移到 ARM，往往也会打起通过移动平台已有生态造血的注意，也就是让迁移到 ARM 的桌面操作系统，兼容移动平台的 App。当然，这里面也有大坑，例如 UI 的适配就是个麻烦——手机平板的屏幕和桌面 PC 显示器不同，要有体验好的视觉效果，UI 需要灵活变形，这对 UI 元素的自动排列提出了极高要求，这也是个需要投入大量精力研究的课题。

2.苹果迁移 ARM 到底做了什么?

上面提到了 X86迁移 ARM 可能会碰到的问题，大家却对苹果的迁移之举抱有信心。要理解这一点，我们首先来看看苹果为 ARM 平台的迁移工作都准备了什么吧。

提前量十足的全新开发生态

苹果打算将 Mac 迁移到 ARM 平台，其实很早就能看出端倪了。为了平滑过渡到 ARM 平台，苹果早有准备，对开发套件作了大量工作，以统合的思路，开始改造其应用生态。

苹果这两年做的很多事，就是为了解决 ARM 迁移到 X86平台上的问题。苹果在2019年的 WWDC 大会上，推出了 SwiftUI 和 Mac Catalyst。这两个套件的作用，在于架起了 ARM 和 X86间、以及移动平台和桌面平台间跨平台开发的桥梁——苹果本身就有着成熟的 ARM 移动生态，这无疑能成为桌面平台迁移到 ARM 的强劲助力。

先来说说 Mac Catalyst，这是一个跨 ARM 和 X86平台的开发套件。通过 Mac Catalyst，开发者在构建一个 iPad App 的同时，这个 App 也能成为 macOS 的原生应用。从某个角度来说，Mac Catalyst 将会是 iPadOS 和 macOS 新的开发基准，iPadOS 将会和 macOS 的应用生态深度融合。此后，即使 macOS 迁移到了 ARM 平台，基于 Mac Catalyst 开发的软件应用，也可以无缝兼容。

Mac Catalyst 可以让一个软件应用同时兼容 iPadOS 和 macOS

而 SwiftUI，其作用则在于为移动平台和桌面平台提供了跨平台的 UI 适配方案。通过 SwiftUI，开发者能用较为简单的代码，一次开发出适配多个平台的软件 UI。例如开发者想要为 macOS 和 iOS、iPadOS 做软件应用，那么通过 SwiftUI 就可以轻松做出能适配这几个平台应用的 UI。可以说，SwiftUI 大大降低了为不同苹果平台开发软件应用的门槛，意义重大。

SwiftUI 可以让同一个应用的 UI 同时适配多个苹果平台

无论是 Mac Catalyst 还是 SwiftUI，目前都已经投入了实战当中，通过新版的 Xcode 以及高质量的开发文档，每个苹果开发者都可以制作出基于新技术的高质量软件应用。

很大程度上，苹果已经解决了新软件同时兼容 X86/ARM、移动 / 桌面平台的开发问题。请注意，这是在 ARM 版 macOS 发布之前做的工作，可谓是兵马未动粮草先行。目前，苹果尚未发布 ARM 版 Mac 电脑，但为其配套的开发组件，却已相当完备了。待到 macOS 真正迁移到 ARM 平台时，基于 Mac Catalyst 以及 SwiftUI 开发的软件应用早已经花繁叶茂，macOS 迁移 ARM 其软件生态不至于会 “休克”。

步步为营的生态迁移

Mac Catalyst 解决了代码在 X86和 ARM 平台的编译问题，而 SwiftUI 则解决了移动平台和桌面平台的 UI 适配问题，但这是针对于新开发的软件应用的。对于 macOS 旧有的软件，苹果也祭出了招数。

在今年的 WWDC 大会，苹果宣布，将会为 macOS 平滑过渡到 ARM 平台，推出 Rosetta 2中间转换层。如果你是老果粉，对于 Rosetta 这个词一定很熟悉——苹果 Mac 电脑当年从 IBM PowerPC 架构，迁移到 Intel X86平台，所使用的转换层正是 Rosetta。

Mac 迁移平台这事，苹果已经干过一次了，当年 Mac 从 PPC 迁移到 X86的兼容层被称为 “Rosetta”

Rosetta 2的作用在于，它通过指令翻译，可以让 ARM 平台的 macOS，直接运行绝大部分的 X86软件。而且 Rosetta 2的性能还相当不错，它并不是在软件运行的时候，才翻译指令的，而是在软件安装时就做好了转换。当然，这也并非说 Rosetta 2可以实现性能完全无损，它对 AVX 指令兼容并不好，如果 X86软件依赖 AVX 乃至 AVX2，那么在 ARM 平台上由于没有对应的高性能指令，运行效率会有明显下滑。并不是所有的软件都会用到 AVX 指令集，总体来说，Rosetta 2的性能还是可以接受的。

这次 Mac 从 X86迁移到 ARM，Rosetta 2对旧有 X86软件的兼容也起着至关重要的作用

和当年的 Rosetta 一样，Rosetta 2只是一个临时举措，它的意义在于为迁移到 ARM 平台提供平滑的过渡期。我们可以参考一下 Rosetta 的进度：2005年苹果在 WWDC 宣布换用 X86，接着苹果在2006年推出基于 X86平台的 Mac 电脑并部署了 Rosetta，到2009年苹果 MacOS 10.6不再支持 PowerPC 的 Mac，2011年 MacOS 11.7不再支持 Rosetta，放弃了对 PowerPC 时代 Mac 软件的支持。从此以后，苹果 Mac 生态彻底转移到了 X86平台，整个过程并未有太大的阵痛。

从 Rosetta 的历程来看，macOS 转移到 ARM，旧有的 X86软件也会经由数年的过渡兼容期。在未来几年，我们或许也会看到新的 macOS 11不再支持旧有 X86 Mac 电脑、在未来某个版本彻底不支持 Rosetta 2这样的节点。到最后，macOS 11上只剩下专为 ARM 开发的新软件，而届时 ARM 的软件应用也早已经琳琅满目。

苹果相当清楚，新旧平台的更迭，绝非一蹴而几的事情。苹果一方面通过 SwiftUI 和 Mac Catalyst 慢慢为 ARM 平台的 Mac 营造新生态，一方面通过 Rosetta 2保持原有生态不流失，而且两方面的完成度都非常高，可谓两手都要抓、两手都要硬的典型。加上此前从 PowerPC 到 X86换平台的成功经历，人们对 Mac 换用 ARM 架构抱有极大期待，也就理所当然了。

3.Win10 ARM 失败在哪里?

在很多人的认知中，微软 Windows 系统向 ARM 进军的步伐，要比苹果 macOS 来得更早。的确，微软在2012年就已经发布了用于 ARM 平台的 Windows RT 系统，并将其装载于第一代 Surface 平板电脑上。而最近，微软更是将 Windows 10桌面系统整个迁移到 ARM 上，目前市面上已经出现了基于骁龙处理器的 Windows 10平板，而微软自身也推出了基于骁龙 ARM 平台的 Surface Pro X。

运行在 ARM 平台上的 Windows RT 系统

从推向市场的进度来看，微软无疑远远领先于苹果——macOS 的 ARM 产品尚未见诸市面，而微软的 ARM Windows 产品已经开卖多时。然而，这些产品并没有在市场上掀起太大波澜，Window RT 已经宣告终结，而 Surface Pro X 等 Windows 10 ARM 产品，则落下了性能低下的坏口碑，并没有取得什么好的市场表现。

为什么会这样子呢?我们来回看微软 Windows 在 ARM 平台上的征程。

2012年，为了和 iPad 竞争，微软推出了 Surface 平板产品线。然而，用于 ARM 平台 Surface 平板的 Windows RT 系统，却拥有着诸多限制。

从外表来看，Windows RT 和正儿八经的 Windows 8桌面操作系统无异。然而，Windows RT 却不能兼容一切传统基于 X86开发的 Windows 程序。Windows RT 只能从应用商店中获取应用，这让 Windows RT 一度几乎无第三方软件可用。实际上，这是由于微软通过数字签名限制了第三方应用，破除了微软的限制后，传统的 X86软件通过重新编译为 ARM 应用，是可以运行在 Windows RT 上的。

Windows RT 不兼容传统的桌面软件，必须从 Windows 商店下载

为何微软要这么做?在微软的构思中，Windows RT 和 Windows Phone 共用应用商店，双方生态打通，开发者为 Windows Phone 开发 App 的同时，也可以顾及 Windows RT。然而，这只不过是一个美好的幻想，Windows RT 的这些缺陷，将它送进了坟墓。

· 手机和平板的交互基础差异过大。Windows Phone 和 Windows RT 都力推 Metro(Modern)设计，然而小屏和大屏之间终究有难以逾越的鸿沟。加之 Windows RT 仍残留着大量桌面 UI，借助 Windows Phone 上的 App 给 Windows RT 生态输血，显得不合时宜。

·Windows Phone 并未建立起强有力的生态。微软多次变更 Windows Phone 的开发路线，开发工具也一改再改。Windows Phone 的开发环境非常不稳定，系统自身从开始的 CE 内核变为 NT 内核，而应用则从一开始的 XAP 到 APPX，到了 Win10M 又要求开发者开发 UWP 应用…… 开发者连 Windows Phone 剧变的开发环境都无法跟上，最后冷眼旁观 WP/Win10M 的垂死，更何况边缘产品 Windows RT?此情此景下，通过 WP 给 Windows RT 输血是不切实际的。

Windows 应用商店不稳定，还时不时爆出无法安装应用的大问题

·ARM 平台性能太弱。Surface 使用的是 Tegra3芯片，该芯片的性能甚至不如同时代的 Atom，系统自带的 Office 运行起来卡顿无比。指望当时的 ARM 芯片支撑起桌面级的体验?根本无法胜任。

· 其他因素。开发者们发现，通过破解 Windows RT 系统数字签名限制，可以将 X86平台上的 Win32程序重新编译后，安装到 Windows RT 上，并且顺利运行。然而微软封堵相关漏洞，进一步削弱了 Windows RT 的扩展性。

简单来说，尽管微软让 Windows RT 运行在了 ARM 平台上，但没有为其配备一个理想的开发环境，也没有让其能直接兼容传统的 X86软件应用，与此同时 Windows RT 还有着 UI 分裂、平台性能羸弱等问题，失败也就在情理之中。

到了最近的 Windows 10 ARM 版，许多问题似乎已经得到解决。ARM 芯片的性能大幅提升，甚至逼近了桌面低压 X86处理器;而可以跨平台支持 ARM 和 X86的 UWP 应用开发环境，相对以前来说也较为稳定;同时，微软还让 Windows 10 ARM 可以直接运行 X86软件。然而，Windows 10 ARM 却依然有着如下缺陷。

· 兼容不佳。微软为 Windows 10 ARM 做的中间兼容层，当前并不能完美兼容所有的 X86软件，只有32位的软件能够实现兼容。事实上，Windows 10 ARM 使用的 Thumb2指令集是和 Windows RT 一脉相承的，不过这次面向 Win32程序开放了兼容，但这套指令集并不兼容 X86-64(Windows RT 时代 ARM 处理器仍未迈入64位)，日后需要大改才能兼容64位软件。

Windows 10 ARM 运行 Win32软件效果一般

· 性能低下。在 Windows 10 ARM 上运行的 X86软件，是边转码边运行的，并不像苹果 Rosetta 2那样在安装时作好转码工作，运行时无需再次转码。这就造成了 Windows 10 ARM 运行 X86软件性能不尽如人意。

·UWP 前景成疑。UWP 应用目前仍存在诸多限制，能实现的功能有限，稳定性更差，开发环境也不如传统的 WPF 成熟。要知道，用 Mac Catalyst 开发应用，是起码有成熟的 iPad 生态兜底的，兼容 macOS 是一个加分项;用 UWP 开发应用能得到什么?只会面对传统 Win 32软件的强烈竞争，开发者在 UWP 和 Win32软件开发之间，会作何选择不言而喻。

UWP 的大饼真香，但喂不饱开发者

· 微软没有对 ARM 硬件的掌控力。Windows 10 ARM 运行于骁龙平台，微软并没有像苹果那样，自行设计 ARM 芯片，软硬件结合度自然有所欠缺。苹果可以确保未来 macOS 跑在怎样性能水准的 ARM 芯片上，而微软只能仰仗高通。在 ARM 性能对 X86仍处于追赶态势的现状下，这是一个藏有暗雷的要素。

苹果可以祭出自己的芯片，微软只能和高通合作

·Windows 有着更沉重的历史遗留兼容问题。macOS 换用 ARM，苹果仍只需专心打造新的 Mac 电脑;而 Windows 换用 ARM，微软必须顾及众多的硬件厂商，以及诸多的老软件，转型速度注定不如苹果。

总结

到了这里，我们可以总结一下，为何苹果 macOS 换用 ARM 能万众瞩目，而微软 Windows 转移 ARM 却不尽如人意了。

· 苹果提供了能编译同时兼容 X86、ARM 平台的应用的高质量开发方案(SwiftUI+Mac Catalyst)，微软在这方面举棋不定;

现在还没有 macOS 的 ARM 产品面市，但开发机却是已经有了，苹果的准备力度可见一斑

· 苹果提供了 X86软件在 ARM 平台的兼容方案(Rosetta 2)，效率良好。而 Windows RT 不兼容 X86软件，Windows 10 ARM 则运行 X86软件效率较差，且不支持64位;

· 苹果能够自行设计高性能的 ARM 芯片，微软没有这样的能力，ARM 芯片性能尚不足以支撑桌面环境时就上马 Windows RT，现在 Windows 10 ARM 平板的性能也无法和同价位的其他 X86平板相提并论;

· 苹果提前布局好 ARM 生态的转移工作，并设置了足够的过渡期，相应产品由始至终保持了较高完成度，而微软未准备好配套就匆匆将不成熟的产品推向市场;

· 苹果对生态掌控力度更大，能促使开发者更新迭代适配新平台，而微软背负着沉重的兼容性包袱。

在当前，X86仍是桌面平台的绝对主流。但 ARM 平台已经在能效上彰显优势，如果微软铁了心要兼顾 ARM 平台，就必须解决当下的种种问题，才能带来良好的体验，期待微软日后能做得更好吧。