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

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

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

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

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

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

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

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

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

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

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

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

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

上面提到了X86迁移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开发的软件应用，也可以无缝兼容。

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

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

在当前，X86仍是桌面平台的绝对主流。但ARM平台已经在能效上彰显优势。苹果打算将Mac迁移到ARM平台，其实很早就能看出端倪了。为了平滑过渡到ARM平台，苹果早有准备，对开发套件作了大量工作，以统合的思路，开始改造其应用生态。