macOS换用ARM来势汹汹！Win10 ARM失败在哪里 _换用

【PConline杂谈】苹果今年在WWDC宣布macOS11将迁移到ARM平台，引起轰动。苹果表示，将在Mac电脑上用自主研发的ARM平台取代英特尔的X86平台，并迁移包括操作系统和软件在内的生态系统，这意味着ARM在个人PC领域迈出了挑战X86的一步。

MacOS11将与ARM芯片兼容

人们对苹果此举寄予厚望。MacOS不是第一次换马了。21世纪的第一个十年，MAC从IBMPowerPC平台迁移到英特尔X86平台并取得成功，这也是人们如此有信心Mac在切换到ARM后仍能提供良好体验的原因之一。

在苹果宣布这个消息的同时，很多人也想到了微软—— 。微软在ARM领域探索多年，推出了像WindowsRT这样的特殊系统，最近Windows10在ARM上运行，兼容了大量以前的软件。然而Win10 ARM策略似乎并没有得到太大的反响，WindowsRT甚至突然死亡。

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

Mac迁移平台如火如荼，普遍预计会顺利进行，而Win10却屡屡碰壁。Win10走在ARM的路上。怎么了？今天就来说说这个问题。

X86转移ARM：到底会有什么坑？

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

但是，无论哪种方案，将以前兼容X86操作系统的生态迁移到ARM都是要付出代价的。

如果放弃X86平台上旧软件的兼容性，只让新软件兼容ARM平台，意味着生态系统需要从头开始，新系统启动起来会非常困难。在过渡期间，新开发的软件需要同时兼容X86和ARM平台，这意味着要么开发人员投入更多的精力自行编译不同的版本，要么操作系统的开发套件提供同时编译的功能。无论如何，需要投入更多的工作。

如果想做生态无缝连接，让新的ARM平台启动更顺畅，最好让X86平台的老软件直接在新的ARM平台上运行，所以需要在中间层工作。比如安卓就是一个很好的例子。硬件接口被HAL模糊，以擅长跨平台的JAVA作为上层应用。运行在X86上的安卓和运行在ARM上的安卓都可以同时兼容大多数应用。

但是这种方法的缺点是中间层可能会成为效率的瓶颈。安卓中间层比较厚，效率长期被诟病。

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

此外，由于ARM多用于移动平台，如果桌面操作系统想迁移到ARM，往往会通过移动平台关注现有的生态造血，即迁移到ARM的桌面操作系统会兼容移动平台的App 。当然，上面有大洞。比如UI适配就是个麻烦。——手机平板的屏幕与台式PC显示器不同。想要体验好的视觉效果，UI需要灵活变形，这就对UI元素的自动排列提出了很高的要求，也是一个需要花费大量精力去研究的课题。

苹果迁移ARM到底做了什么？

以上提到了X86在迁移ARM时可能会遇到的问题，但是大家对苹果的迁移还是有信心的。要理解这一点，我们先来看看苹果为ARM平台的迁移做了哪些准备。

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

苹果计划将Mac迁移到ARM平台，这一点很早就可以看出。为了顺利过渡到ARM平台，苹果已经做好了准备，做了大量的工作来开发套件，并开始用集成的思路来改造其应用生态。

苹果这两年做的很多事情，都是为了解决ARM迁移到X86平台的问题。在2019年的WWDC会议上，苹果推出了SwiftUI和MacCatalyst 。这两个套件的功能是为ARM和X86之间，移动平台和桌面平台之间的跨平台开发搭建桥梁。——苹果本身拥有成熟的ARM移动生态系统，这无疑将成为桌面平台向ARM迁移的强大助力。

我们来谈谈MacCatalyst，它是一个跨ARM和X86平台的开发工具包。有了MacCatalyst，当开发者构建一个iPadApp时，这个App也可以成为macOS的原生应用。某种程度上，MacCatalyst将成为iPadOS和macOS新的开发标杆，iPadOS将与macOS的应用生态深度融合。此后，即使macOS迁移到ARM平台，基于MacCatalyst开发的软件应用也可以无缝兼容。

MacCatalyst可以让一个软件应用程序同时兼容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年苹果Mac OS X 10.6不再支持PowerPC的Mac，2011年Mac OS X 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架构抱有极大期待，也就理所当然了。

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生态的转移工作，并设置了足够的过渡期，相应产品由始至终保持了较高完成度，而微软未准备好配套就匆匆将不成熟的产品推向市场；

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