关于 Rosetta (Universal 2) 和苹果的 ARM 架构迁移

今年(2020年)的 WWDC 苹果宣布最快将于年底发布运行在自家设计的 CPU (Apple Silicon) 上的 Mac 硬件。在发布会上苹果也演示了搭载了 A12Z 芯片(iPad Pro 2020 同款芯片)的 MacBook Pro。

在之前的播客节目里(枫言枫语 #24 和枫言枫语 #25)我们也就这场 CPU 架构大迁移进行了讨论，感兴趣的朋友可以订阅"枫言枫语"播客收听。

CPU 迁移带来的影响

硬件性能上的影响

老的 Mac 系列机器是基于 Intel 生产的 x86/x86_64 架构的芯片，所有的 App 也都是基于这个架构编译的。

新的 ARM 架构实际上就是 iPhone/iPad 在用的同款 CPU。好处是 ARM 是为了低功耗场景设计的，未来 Mac 设备可以获得更好的续航，而苹果自己设计的 CPU 在经过 10 多年 iPhone/iPad 的迭代之后，性能也逐渐追上了英特尔。虽然有人拿 2019 年 iPad 的 A12X CPU 跟英特尔的 i7 对比跑了个分，但是 Mac 的实际性能表现还是需要拿到真机后才能见分晓，所以现在只能猜测 CPU 性能可能是差不多的。

一台 Mac 的整体表现好不好还得看其他的关键组成部分，硬件上影响比较大的是显卡。但是 Mac 平台向来显卡的游戏性能就很差，可以看到我的 MacBook Pro (15-inch, 2017) 用的是一张 Intel HD Graphics 630 集显，游戏如 RimWorld/Factorio 这类型是没什么问题的，3A 大作就不必考虑了。

上图是 WWDC 2020 上用了 A12Z 芯片的 MacBook 系统信息，可以看到不会再单独列出显卡一项了。理论上苹果自家芯片的性能在 iPad 上的表现还是很不错的，不过同样也是 3A 大作免谈。目前苹果是想直接搬运 iOS App Store 上的游戏大作来弥补。

以往 Mac 上的重度游戏玩家可以通过 eGPU (External Graphics Processing Unit 外置显卡)获得不少性能的提升(得益于 Thunderbolt 的高速和大带宽)。不过目前 Apple 没有透露关于 ARM-based Mac 是否支持 eGPU 的消息。

所以仅从硬件比较上来看，ARM-based 和 Intel-based 的 Mac 在 CPU/GPU 的差距上应该不会很大(毕竟老的 Mac 游戏性能已经很差了)。

软件上的影响

软件的影响是巨大且显而易见的：老的 Apps 可能无法在 ARM-based CPU 上直接运行。

如我们在节目中所云，这并不是苹果第一次迁移 CPU 架构。历史上 Mac 平台曾经有过三次 CPU 架构迁移。

第一次是 1994 年苹果的 Macintosh 从摩托罗拉的 68k 系列处理器迁移到苹果、摩托罗拉、IBM 三家联合设计的 PowerPC 处理器。这个处理器和 ARM 设计的一样，也是一颗 RISC (精简指令集处理器) CPU。

第二次是 2005 年从 PowerPC 转到 Intel 处理器，这时候乔布斯已经回归苹果，并且成功了推出了 OS X 操作系统。

第三次就是本届 WWDC 的 Intel 到 ARM 的迁移了。

鉴于过往丰富的迁移经验，再加上制作 iPhone 时 Mac 与 iOS 共享 XNU 内核代码，此番过渡应该要比历史上的前两次简单一些。过渡时期苹果提供的解决方案有两个:

开发者要编译多一个 Universal (Fat) Binary，同时支持 Intel 和 ARM CPU 两种架构，曰: Universal 2。
提供 Rosetta 2 在 App 安装时自动转换代码

第一种方案对于苹果第一方的 App 是完全可控的，在本届 WWDC 苹果也演示了自家的专业视频编辑软件 Final Cut Pro X (我个人比较怀疑 FCPX 可能还没完成全部代码的迁移，发布会上的演示版可能只是个初级 Demo 版) 跑在 ARM MBP 上的样子。第三方软件就需要开发者自行适配了。如果是简单软件，只依赖 AppKit 的，那应该只需要升级 Xcode，编译成带多一个 ARM 架构的 Universal Binary 就行了，应该也可以单独编译对应架构的 binary。

第二种方案，Rosetta 2 对于开发者和用户都是无感知的。当你双击 App Icon 启动一个 Intel-based App 时，集成在系统中的 Rosetta 会对该 App 执行 JIT (Justin-in-Time)编译，将 x86 指令实时转成 ARM 指令并运行。Rosetta 2 还提供了安装时转译，这样只需一次安装以后就都不需要实时转译了。理想情况下这种转译就跟你跑 JS 代码一样，可以完美无痛过渡。

05 年苹果推出的 Rosetta 是来自 Transitive 公司开发的 QuickTransit。那个年代 Windows/Linux/Mac 等多种桌面版操作系统同时存在，使用过桌面版 Linux 系统比如 Ubuntu 的朋友肯定都用过 Wine 这个软件，用于跨平台执行 Win32 应用，它可以把 Windows 调用转成 Mac 系统的调用。关于 QuickTransit/Rosetta 的技术细节文档很少，所以不太能确定它的内部实现。这家公司 2008 年被 IBM 收购了，所以今年苹果推出的 Rosseta 2 应该是自己研发的。Rosetta 2 的使用是有限制的，可以参考苹果这篇官方文档:

不支持 Kernel extensions
不支持 x86_64平台的虚拟机
大部分 x86_64 指令都可以被转译，除了部分比较新的向量指令比如 AVX, AVX2 以及 AVX512。

像 AVX512 这么高级的指令，iMac Pro 上的高级软件比如 Final Cut Pro X 应该用得到。但是就今年底会生产的第一台 ARM 设备来看，比较大可能是入门级设备，Rosetta 不支持很正常。另外苹果早就已经把 iMovie 之类的很多 Mac Apps 都搬到了 iOS 上，相信他们已经有丰富的 API 转换经验，所以这次过渡应该会比当年迁移到 Intel CPU 容易得多。

另外使用 Rosetta 转译 Intel App 会产生额外的消耗，性能肯定没有原生编译的好，并且因为 Cache 了部分 JIT 代码，可能还会加大内存占用。所以原生 Mac 生态里寥寥无几的游戏在过渡初期就更少了，当然这点可以由 iOS 游戏的无缝过渡来弥补一部分。

P.S. Mac 上的可执行文件是 Mach-O 格式，Mac-O 多年前就支持同时包含多种架构的代码。苹果从 iOS 9 开始就支持对在 App Store 分发的 App 进行 App Slicing。这样不同架构的 iPhone 只需下载对应的 Binary，可以减少下载时的文件体积。这套工作流已经非常成熟，如果使用 App Store 分发不会有什么问题，如果是自己签名分发的 Mac App，则可以选择编译成一个兼容两种架构的大文件，或者分开各自编译一个。

P.P.S. Rosetta 这个名字来自于罗塞塔石碑(Rosetta Stone)，是一块来自公元前 196 年的刻有埃及象形文字的石碑，现收藏于大英博物馆。这里夹带下私货，没有看过枫影夜读 #4 ——《大英博物馆世界简史》的朋友可以看一下，1822 年语言学家商博良正是通过对罗塞塔石碑的研究才破译了古埃及象形文字的。所以苹果才以此命名这个转译软件的吧。

ARM-based Mac 将不支持 Boot Camp

2005 年苹果宣布迁移到 Intel CPU 之后，第二年发布了 Boot Camp，用户可以在 Mac 机器上直接安装 Windows 操作系统。不过未来 ARM 架构的 Mac 将不支持 Boot Camp，并且目前也没有替代品。

我自己在 Mac 上安装过 Boot Camp Windows 用来玩《欧洲卡车模拟》这个游戏，因为 Windows 对 G29 方向盘模拟器的支持比较好，Boot Camp 安装的系统效率也更高。但是这样安装的 Windows 蓝牙支持比较糟糕，所以未来的 Mac 支不支持倒是对我影响不大，需要的时候我可以选择 VMWare 或 Parallels 跑个虚拟机就行了。

其他影响

原先苹果开发新的 Mac 系列需要看 Intel 能否产出新技术，同时 Mac 系列也依赖 Intel 的产能。但是 Intel 近些年来作为牙膏厂，每一代新产品的性能提升非常有限。

并且近几年关于苹果对英特尔的不满也时有报道，比如说 9to5Mac 报道的苹果的 5G modem 因为弃用英特尔改用高通的要等到 2025 年，又比如这篇报道称苹果因为英特尔的 10nm 工艺的 CPU 有问题改用旧的 14nm 工艺的 CPU 而不得不修改 MacBook 的设计。

商业上没有永远的敌人，也没有永远的伙伴。这位队友掉队了，苹果当然要有备选方案，他可以选隔壁的 AMD，或者自己来。目前看来苹果选择了后者。

如此，苹果不仅对自家硬件生产的品控有了更好的掌握，而且未来 Mac 苹果的软硬件结合也会变得更好，就像 iPhone/iPad 一样。对于消费者来说，苹果自家硬件的成本降低了，也许可以带来产品价格的降低也不一定。

使用 Xcode Beta 迁移尝试

我尝试给 Just Focus 编译一个 Universal 版本。因为 App 本身很简单，只是把编译架构变成 arm64 arm64e i386 x86_64，编译过程没有问题。但是引用的第三方库果然出了问题: appcenter 的 CocoaPods 版本因为用的是预编译的 binary，下载下来没有包含 arm 架构所以链接失败了。

我尝试下载 appcenter 的源码自己编译。因为这个工程比较大，修复了几个简单的源码编译错误之后，还需要继续解决依赖问题。而 Beta 版的 Xcode 频频卡死，暂时没有耐心继续折腾下去。

删除 appcenter 后可以编译成功，不过我手头没有 ARM 架构的设备没法真机调试。但是也印证了我之前的想法：简单 App 的迁移并不困难，麻烦的是引入的第三方库可能没那么快适配。这时候就看作者有没有动力去帮第三方库解决编译问题了。

P.S. 截止本文发布日期 2020/06/29，已经有部分开发者收到了上周申请的 DTK，接下来可以看看有没有人发评测文章出来。