此前，苹果CEO库克在WWDC 2020上宣布，未来Mac电脑将改采自主研发的ARM架构处理器“Apple Silicon”，而非英特尔。

事实上，两家的合作始于2005年，当时苹果创始人乔布斯在WWDC宣布放弃PowerPC处理器计划，转身就牵手英特尔。这一决定象征着苹果与英特尔在Mac电脑业务合作关系即将走向“终结”。

那么，苹果Mac采用自研处理器，可能遇到什么问题呢？来自面包板社区的明星博主——欧阳洋葱在今年5月，在WWDC 2020之前就这一角度发表了自己的看法。

---

实际上，有关 Mac 系列计算机要开始采用 Arm 处理器的传言似乎是从2010年就开始的，那会儿苹果也才刚刚开始做 iPhone 的 SoC。这一传言就10年过去了，起码今年前不久才更新的MacBook Air都还在用 Intel 的处理器。

想起来以苹果的“惯例”，对自家生态的管控，恨不得从硬件到软件由内到外全部一手包办。这样一家公司，在如今有能力自己设计处理器，为何还要受制于Intel？况且Mac设备本身的开发周期，还面临与 Intel 处理器迭代撞期的尴尬，导致Mac经常无法用上 Intel 最新的处理器。如果用自家的 A 系列 SoC，岂不是很美的一件事情吗？

这次的传言看起来格外靠谱，彭博社报道称，2021 年采用 Arm 处理器的 Mac 电脑就要问世了。彭博社线人消息称，Mac 要搭载的处理器将比 iPhone 和 iPad 之上的都更快（好像是废话）。“苹果准备在明年，至少推出一款采用自家芯片的 Mac.”“台积电将会负责制造新款的 Mac 芯片，基于 5nm 制造技术。”

“首批 Mac 处理器将有 8 个核心，核心代号 Firestorm，其中有 4 个是节能核心——内部代号 Icestorm。苹果针对未来的 Mac 处理器，还计划探索超过 12 个核心的设计。”值得一提的是，传言中的 Mac 处理器也是以 SoC 的形态出现，其上至少包含了 CPU、GPU。[1]

这件事情的可行性当然是有的，只是在具体实施上会遇到不少问题。如果说 macOS 转往 Arm 平台真的那么容易，苹果估计早就干这事儿了。而且事实上，微软这两年正在做这件事情，但在具体的方向上有些小差异。在这篇文章里，我们做一些简单的分享，虽然无法得出结论，也可与各位做探讨。

多插一句，一般来说，我首发在面包板的文章筹备周期比较短，而且相对来说内容更加个人化、娱乐化。与电子工程专辑或者其他平台发布的文章相较，会显得没有那么正式和考究。另外，这篇文章主要参照的是维基百科，我不想去翻以前苹果的开发者文档了——基于维基百科的不可靠性，以下内容可能有部分是存在事实错误的；另外，我也不搞软件和系统工程，所以贻笑大方之处还请海涵。

苹果曾有的两次迁徙经历

苹果的 Mac 产品线与 Intel 的合作是从 2005 年开始的。那一年，Intel 的 CEO 还为苹果站了台，与乔布斯一起。次年的 Mac Pro 就开始正式采用 Intel 处理器（Mac OS X 10.4.4 Tiger）。在此之前，Mac 并不是 x86 平台的拥趸，我记得看电子科技相关杂志，包括当年像台灯一样的 iMac，苹果在宣传词中都提到处理器比同时代的 Intel 奔腾快多少倍之类。

在此之前，苹果就有过两次在指令集平台上转舵的经历，看起来已经是个老手了。至于为什么要换用其他平台，这可能和软硬件更具体的技术问题相关，不过从社会上广为流传的资讯来看，都是因为老平台的效率越来越不济（就好像如今主流观点认为 x86 处理器的效率不如 Arm，虽然我不这么看；很多人认定，Mac 转向 Arm 也算是合情合理）。

从这两次转舵，其实可以大致来看一看，这回若从 x86 转往 Arm，可行性几何？或者苹果从前的转舵经验，是否有足够的参考价值。一般来说，从一个硬件平台转往另一个硬件平台，经常意味着抛弃以前的开发者，以及抛弃以前的用户。因为转往新的硬件平台，总是意味着旧有软件将停止更新，且旧的开发生态彻底终结，未来的新软件也无法安装在旧平台上。当然系统制造商总是会采用一些折中的兼容性方案来实现过渡。而“过渡”的平滑与否，真的就要看厂商的水平。

1994-1996 年前后，苹果的 Mac 电脑从更早摩托罗拉的 68k 系列芯片转往 PowerPC 处理器（参与 PowerPC 联合开发的应该有摩托罗拉、苹果和 IBM）。这个转换过程持续了几年，当时苹果的过渡方案是所谓的 Mac OS Classic（Mac OS Classic 也就是经典 Mac OS，指代了 Mac OS X 之前的 Mac 操作系统），可以同时跑在 68k 和 PowerPC 平台下。有个词叫 fat binary，形容某一种应用，占用更多的存储空间（所以才 fat 吧...），但混合了多种指令集的原生代码支持——也就能够在多种类型的处理器上跑。苹果当时搞的这种 fat binary，就是令开发者将 68k 编译版本和 PowerPC 编译版本打包到同一个执行程序中。

另一方面，当时苹果引入了一种较低层级的模拟方案。系统中有一个 Mac OS nanokernal 内核，这个内核建立在 Macintosh ROM 里面（Macintosh ROM 是最早 Macintosh 电脑中的一个固化在主板上的芯片，用于电脑启动时的初始化）。而这个 ROM 内部有个叫做 Macintosh Toolbox 的东西，类似于 BIOS 这种角色。而 Mac OS nanokernal 为 Toolbox 提供 68k 处理器的模拟环境。

Mac OS nanokernal 在电脑启动时加载，内存里开辟一个 PowerPC 内核空间加载模拟器。随后模拟器继续加载 Toolbox 对系统硬件初始化，随后的操作和 68k 时代基本上一样。这时期 PowerPC 设备的内核，实际上就是运行在 68k 模拟器里的 Toolbox。

nanokernal 的主要工作就是让现有 68k 版本的操作系统跑在新的 PowerPC 硬件下，如此系统普通状态就能跑 68k 代码。在必要的情况下可以转回到 PowerPC 模式下，基于中断处理程序（interrupt handler）实现，并将虚拟内存系统映射到 PowerPC 硬件上。不过维基百科说，这个过程，也可能只是由跑在用户态的模拟器去处理的。

iMac G4，采用 PowerPC G4 处理器

无论如何，这都是个看起来十分简单，而且还非常低效的方案（原生的 PowerPC 性能似乎很难发挥）；不过好像也很有效，Mac OS nanokernal 的 68k 模拟器也就为旧软件提供了这种低层级的兼容性。当时的模拟器提供的运行环境，和 Macintosh Centris 610（处理器具体型号为摩托罗拉 68LC040）最为接近。

早期版本的 68k 模拟器会解码每一条指令，并立即执行一系列对应的 PowerPC 指令，实现这种模拟。后续的 PCI PowerMac（PCI 总线的 PowerPC）中的动态重编译模拟器（dynamic recompilation）则对性能做了提升：将代码常见的部分，“重编译”为更快的、PowerPC 原生序列——且在本地做了缓存（locally cached）。也就是说这种模拟器能够识别一些 680x0 代码序列，并且直接跑已经缓存过的 PowerPC 代码，也就避免了重新转译。对于一般的开发者来说，这种转换也就显得比较无痛，因为模拟器是自动开始和结束的。

最初的 Mac OS nanokernal 是相当简单的，这就是个单任务系统，把大部分工作交给操作系统 68k 版本的模拟器去跑。有兴趣的同学，可以去了解一下当年的 Mac OS Classic，它似乎还称不上一个现代化的操作系统，连内存保护都没有；上层的应用程序直接跑在 Toolbox 上，除了获取系统提供的功能和资源，还能直接操作硬件和内存。这个版本的 nanokernal 似乎是到 Mac OS 8.5 终结的。[2][3][4][5]

第二版 Mac OS nanokernal 也算是越来越像样了，开始支持多任务多处理器、消息传递，可以算是微内核了；内核存在于受保护的内存空间中，并在用户态下执行设备驱动。这是题外话了。

Mac OS Classic 时代的操作系统和个人电脑还是相当的粗放和不讲究，而且层级结构也比今天要简单得多。而另一方面，其实也不难发现，即便是当年苹果电脑用户基数不多的时代，生态搬迁都需要付出这般代价；每一次平台搬迁，实际上都需要付出代价，由上至下。

还有一点值得一提，后来 Mac OS X（PowerPC 版）内部有个名为 Classic 的环境，这是一个抽象层——绝大部分 Mac OS 9 应用都依托于 Classic 环境跑在 Mac OS X 上。从 10.5 美洲豹系统开始，就已经去掉了 Classic 环境（即更晚的 x86 平台也就不再对 Classic 做出支持）。具体来说，Classic 环境包含了一个 Mac OS 9 系统文件夹，以及一个 New World ROM 文件（前文提到的早期 Macintosh ROM 算是 Old World ROM；而 New World ROM 时期，早期 Macintosh ROM 不复存在，原本的 Toolbox 成为一个文件存在硬盘上）。这里的 Classic 可以认为是 Mac OS X 之下的一个模拟子系统。[6]

从 PowerPC 转往 Intel x86

2005 年，乔布斯表示苹果对于 IBM 的 PowerPC 开发进度非常失望（这集我看过！去年的 Intel 基带事件似乎也是这么演的），而 Intel 显然可以满足苹果的需求。当年乔布斯大谈每瓦性能，实际上也就是能效比，这似乎也是如今在舆论上，x86 处理器陷入不利的原因。乔布斯在 WWDC 大会上宣称，Mac OS X 的每个版本都“秘密地”针对 Intel 处理器做了开发和编译。所以现在的 macOS 有没有“秘密地”针对 Arm 做开发和编译？

当年 Intel 为苹果站台的名场面

这次的兼容性解决方案，是一种名为 Rosetta 的指令解释器，这是一个动态二进制转译器（dynamic binary translator）。苹果在宣传中，把 Rosetta 称作是“the most amazing software you'll never see”。苹果说对于旧版 PowerPC 应用来说，那些重交互、但算力需求比较低的应用，非常适用于 Rosetta（比如文字处理）；而算力要求比较高的（比如 AutoCAD、Photoshop）可能就会悲剧（很像 Windows on Arm？？？）；一些“专业级”的媒体应用，比如 Final Cut Pro、Logic Pro，则完全不支持。

Rosetta 所处的层级比 68k 模拟器要高，是个“用户级”的程序，只能监听和模拟用户级代码。这可能和苹果担心安全问题有关，而且毕竟 Rosetta 推出的时间，操作系统也比 68k 模拟器年代要成熟很多了。所以 Rosetta 不支持的环境和状况有很多，也包括了不支持转译 PowerPC G5 指令。

苹果后来发布的 Xcode，有针对 Intel 与 PowerPC 的 Universal Binary，就跟前文提到的 fat binary 类似——这样一来，当时面对平台迁徙的开发者，在面对 Mac 应用开发时，针对基数也算多的 PowerPC 用户，不会不知该选 PowerPC 还是 x86，因为两个都可以要（微软 WinRT 借鉴对象？）。

不过 Resotta 的确在过渡平滑性上要差一些。针对 Mac OS 平台下不同类型的应用，开发者使用 Rosetta 还是需要做一些基本工作的，比如 Cocoa 应用需要重新编译、检查字节顺序问题；Carbon 应用则要求做小幅调整；而使用 Metrowerks Codewarrior 套装开发的应用则需要做较大程度的修改（Codewarrior 是一个 IDE，这个 IDE 的早期版本就针对 68k 和 PowerPC Macintosh，当年苹果转往 PowerPC 时，CodeWarrior 成为 Mac 实际上的标准开发系统，快速取代了苹果自己的 Macintosh Programmer's Workshop）。[7][8]

就最终的成果来看，Mac 的这第二次转舵还是很成功的。实际上即便到 2009 年，Mac OS X 10.6 雪豹时期，苹果已经完全不再支持 PowerPC，依然有不少开发者通过 Universal Binary 对这一平台做出后续数年的支持——这还是能够从侧标反映苹果在兼容性方案上的不错表现。

但我觉得，这次的成功主要并不来源于苹果在兼容性工作上的成功，而在于 Mac 转向 x86 本身就是一次从冷门到热门，以及低效向高效的转变，因为 x86 平台原本就相当成功。Intel 这些年起码在桌面 CPU 的效率提升上是独占鳌头的。另外要知道 PC 市场的绝对大头：Windows 就一直在用 x86。而 Mac 转往 x86，则很大程度上意味着 Mac 设备从此以后就可以名正言顺地安装 Windows 系统了。苹果自 2006 年起引入的 Boot Camp 还对 Windows 的安装做出了原生支持。

也是从这个时候开始，大批量的人在星巴克用 MacBook 装逼（以及运行的却是 Windows 系统）才变得可行。或者说至少买一台 Mac，就不用放弃 Windows——而且同一时间还有大量效率较高的虚拟程序可以跑 Windows 及对应的应用。我觉得无论如何，这都是 x86 平台的 Mac 得以大获成功的原因。

而且也是自此之后，许多软件大牌企业才开始将 Mac 生态纳入重要考虑范畴，甚至优先于 Windows 做软件开发。相较而言，以前的那点生态损失根本就不算什么；和当年 68k -> PowerPC 的转变相比，这次的转变有着天然的生态优势。当然，在 x86 成为 Mac 的选择以后，Mac 设备自身的设计变迁，为行业树立标杆也是重要原因，如 2008 年推出的 MacBook Air；另外，现在基于 web 的应用越来越多，很多人对浏览器的依赖已经大过操作系统本身，这让平台选择进一步脱耦。

所以，我觉得 Mac 在转向 x86 平台时的成功，更多的是时势造就，甚至别家生态使然；亦是苹果在电子科技发展史上的一次识时务之举；且以当年 Mac 的体量，更不存在尾大不掉的问题。

从 x86 转向 Arm？Arm 效率真的高于 x86 吗？

我们近两年听到最多有关 Mac 要从 x86 转向 Arm 的原因，好像并不是苹果要加大生态掌控力（这是我觉得苹果可能决策转向的最主要原因），而是 x86 处理器的效率比 Arm 差很多——这方面的报道也还不少。就相对直观的消费用户体验来看，这一点似乎还是有足够的论据的。这些年智能手机、平板产品的性能提升速度如此之快，感觉跟 PC 是不是已经差不多了？

苹果前些年发布 iPad Pro，并将其定位于生产力工具的时候，就不忘在发布会上黑现在的 PC，声称 iPad Pro 所用的 Ax 处理器比市面上 90% 的 PC 还要快。虽然也不知道这种对比是如何产生此等量化数据的。加上还有 GeekBench 这种苹果专用跑分工具（误）助阵，像 A13 这种芯片的跑分成绩比 AMD Ryzen 3850X 还要高；单核平均功耗才 7、8W 的 A12X，单核跑分和 TDP 95W 的 Intel Core i7-8700K 差不多，多核成绩则比 8600K 还要高。

这么说来，Arm 和苹果掌握的黑科技，已经达成体积小如此之多、功耗少如此之多的情况下，性能达成与 x86 平台几乎齐头并进的水准啦？我前俩月就听有人在社区大谈 RISC 相比 CISC 有多大优势，并以此得出 iPad 性能为何比如今 PC 强那么多的结论，言下之意是你们根本就不懂指令、现代半导体技术的神速发展。Intel 估计应该被钉在历史的耻辱柱上。

有关 GeekBench 娱乐工具跑分相近的问题，其实我们必须承认一个大前提：当代处理器微架构优化，能用上的技术基本上都用上了，前十几年的发展，什么流水线、分支预测、乱序执行、多级缓存、超线程、时间空间并发之类乱七八糟的，及这些技术本身的反复优化，外加制程工艺进化，CPU 性能总能有“质”的飞跃。但如今，CPU 单核性能提升已经十分缓慢，不仅是制程工艺步进缓慢甚而停滞，还在于能用的优化技术都已经用上了。当然我们不能排除未来还有什么黑科技出现，但至少就这两年的情况来看，新货已经鲜见了，不似当年某种新技术一出立刻造成轰动。

所以虽然 Zen 2 如此神奇，而且还被我们吹得神乎其神，但实际上其单核性能也就那么回事，拼死了也就比同代 Intel 10nm 的十代酷睿强一丢丢——当然其 CCX 架构让 Zen 2 堆核更容易了，台积电的 7nm 也的确给力。

扯远了，上面这两段是为了表明，Arm 即便作为低功耗领域的主力架构，这些年的发展致其单核心性能可与 x86 比肩也并不稀罕。不过那么大的功耗差距，却可达成相似 GeekBench 跑分又是怎么回事呢？这个问题，我在之前探讨 Surface Pro 时就提到过：不考虑散热系统的跑分成绩都是在耍流氓，尤其是 GeekBench 这种短时跑分测试。

我们知道苹果 Ax 系列 SoC 瞬时突发性能还是比较强的，包括 GPU，但一旦考察持续性能，则会有一个较大幅度的折扣，因为毕竟手机这么小的体积，而且就靠那点被动散热面积，很难做到长时间的性能发挥。有关这个问题可参考我之前写的两篇文章[9][10]。我们常戏谑说 GeekBench 是 AppleBench，一方面原因在于其中的某些测试项，在 Ax 系列 CPU 中有专门硬件单元做计算，而 x86 很多时候只能依靠通用计算单元来解决，解题效率会略低（这部分内容各位可以去自行研究，早年比较典型的是 AES 加密单元——A 系列处理器就有专用单元，所以这类项目的跑分成绩可以很高，现在可能有差别）；另一方面就在 GeekBench 整个测试周期很短，那么系统真正的综合性能其实是难以体现的。

知乎上有高人给出了 Arm 是否真的比 x86 更省电的理论分析，有兴趣的可以去看一看[11]。很多人对 x86 留下高功耗印象的原因，其实是平台（以及使用场景）差异造成的，PC 的处理器 TDP 在设定上就很高，而这种相比移动设备高得多的参考功耗，很大程度上就源于前面我说到的 PC 要求在一个较长时间内持续高性能，而不只是简单的瞬时突发性能。另一方面还在于，Arm 指令集的处理器普遍采用大小核设计，小核心是专用于低功耗场景的（而且这种小核心现在看来似乎也越来越有必要）——而直到前一阵，Intel 才表示准备要搞这种大小核设计。

当然这也是因为 PC 的具体使用场景，以往并没有多少需要像手机那样超低功耗状态的应用，或者这种必要性并不大（虽然现在也逐渐开始有这种需求）；而 Arm 平台的移动设备多用电池做电源，本身也需要对功耗做限制。

所以 x86 能效比低于 Arm 的这种印象，大抵上是两者使用场景的常年差别造成的。能效比怎么样，要对比的应该是同性能下的功耗情况。恰好 AMD 开始使用台积电的 7nm 工艺，这也给这种对比有了一个基于类似制造工艺下，同性能（而不单纯是同频）下的功耗情况对比的依据。不过这种对比需要考虑的问题还有很多，比如 x86 平台的很多 CPU 还有“睿频”的概念，而 Arm 手机和移动平台 CPU 则没有；两者的流水线长度不同等等；而且前面提到，两者使用场景目前还是有差别，这也是芯片内部专用单元有差异的关键。

从相对直观的角度来说，随性能的提升，功耗也在提升，但这两者的关系并不呈线性；意即如今 Arm 低功耗与性能的关系看起来还挺美好，但如果进一步提升性能，所需付出的功耗代价在达到一个拐点以后，就会出现指数级蹿升的状况——在高性能领域，Arm 现有的移动处理器也未必会有什么出色的表现：这其中，苹果并未掌握什么黑科技，Intel 也并不存在多大的过错。（服务器领域和 PC 领域在应用场景上又是不一样的，这里不讨论。）

上面这张图来自 AnandTech[12]，好像被人援引了无数次。这是苹果 A12 的频率功耗相关曲线。AnandTech 认为苹果做得还是比较出色的，而且在后续几百 MHz 区间内也相对保守。如果说苹果期望再把频率抬高，则按照 A12 的现状来看，很快就可以在 3GHz 附近让功耗彻底达到标压笔记本的水平。

这次的转舵可能有所不同，看看微软

上面这个大段落好像说了不少废话，与本文的主旨关系并不算太大。不过我想表达的是，其实 x86 并不像人们想的那样不堪，Arm 也不像人们想的那么美好。在不考虑散热、功耗的情况下，这两者的性能水平可能正在趋同——这也是 AnandTech 之前评价 A12 接近桌面处理器水平的原因。但就系统和具体应用场景的角度，即便 A12 有这种能力，也不可能发挥到桌面处理器的水准，因为它被功耗与散热限制了。

就性能来看，苹果应该是有能力造出 Intel 同等性能的 PC 处理器的，而且 Intel 如今在半导体制程工艺上有落伍的迹象（Intel 前不久才承认到 2021 年之前，工艺技术都将落后于竞争对手[13]）。但在 macOS 的软件生态和兼容性层面，就又要多花一番心思了。这个过程可能仍然需要数年，而且这次的转舵还不同于以往。只不过在过去苹果积累的经验，这会儿似乎还是可以派上用场。

彭博社的报道提到，可能会有部分 Mac 产品将采用 Arm 处理器。就前期来看，合理的推测是，低性能、低功耗产品线的 MacBook（比如说早前 12 寸的 MacBook）可能会率先采用苹果自己的 Arm 处理器。但如果真的是这样，那么也就意味着，Mac 产品系列将有两种架构、两种平台并存，这对开发者来说应该是个灾难。苹果大概需要重启过去两次转平台时 fat binary 和 Universal Binary 方案——一人开发，俩平台共享...

实际上在早年 fat binary 时期，把两种编译版本封装到一起，造成的文件尺寸大，在当时是比较敏感的——因为那会儿 PC 的硬盘容量真的很可怜，所以那一时期还涌现出了为了节省硬盘空间，可剥离不需要编译版本的工具。现在这已经不算什么大事儿了。

而就当代来看，苹果实际上有一个更好的参照对象，就是微软。不过微软在计划上看，并不是“转舵”，而是“扩展”，这里我们可以稍微提一提：即 Windows 不仅要在 x86 平台上发展，而且要在 Arm 平台上发展。这个计划从 Windows RT 操作系统时期就出现了，那时微软就搞了一个 Windows Runtime，这个运行时之上搭的应用可以同时支持 x86 和 Arm。当时的 Windows Phone 8.1 其实也用上了 Windows Runtime，所以那会儿微软应用商店的很多 app 都同时支持手机、PC、平板，虽然商店里的应用数量也是少的可怜。

这算是实现微软“伟大”生态 Universal Windows Platform（UWP）的重要组成部分。UWP 本质上就是为所有 Windows 设备，包括 PC、IoT、平板设备之类，或者说所有 Arm、x86 平台的 Windows 设备，提供一个通用的 API。UWP 就是一种建立在 Windows Runtime 之上的应用模型。[14][15]

Windows Runtime 提供的 API 以类库的形式，为开发者提供 Windows 8 的功能。跑在 Windows Runtime 上的应用实际上是跑在一个沙盒里，需要用户批准才能访问一些关键系统特性及下层的硬件。这个东西当时就可以打通 Windows RT、Windows 8，绝大部分应用部署在微软的应用商店里。早期 Windows Runtime 之上跑的应用被称作 Metro app（好像是因为当时微软还热衷于推 Metro UI，后来叫 modern-style app，应该还会改）。

只不过这东西到现在为止都还不能算是成功，微软的营销话术也堪称灾难，没人知道 Windows RT、on Arm、10S、10X 之类究竟是什么鬼。一般人真的很难搞懂微软这两年究竟在做什么——可见当年乔布斯在给 Mac 转平台，在告诉用户和开发者现在正在发生什么的时候，是多么科学（所以比尔盖茨说乔布斯是超级销售员）。不过在实际的决策上，我觉得微软的摇摆不定、瞻前顾后，才真正令 Windows RT 以及后来的 Windows 10S 都很失败。

微软接下来的一个“伟（zuo）大（si）”计划是 Windows 10X。从外显上来看，Windows 10X 是为双屏设备准备的一个操作系统（比如 Surface Neo 之类还没发布的设备），预计今年下半年才会看到实物。不过我觉得 Windows 10X 的意义远不止此，Windows 10X 支持 Windows Runtime API（这个是肯定的），并且“通过一个原生 container 跑 Win32 应用”[16]。我没怎么研究过如今 Windows 系统架构状况，但就对旧有 Windows 生态来看，Windows 10X 如果是微软接下来意欲统一 PC 市场的操作系统，则这个决心下的还是比较大的；而且貌似双屏 Windows 设备都是基于 Arm 平台。

谁不想要 Surface Pro X 这么性感的笔记本呢？

听起来 Windows 10X 在这一点上，和 Windows on Arm 很像（Surface Pro X 用的就是 Windows on Arm），所以我在想 Surface Pro X 将来是不是可以升级到 Windows 10X——反正微软改名部门创下那么多的“丰功伟绩”。

在针对开发者的兼容性问题上，Windows on Arm 平台下的 x86 应用是跑在模拟器上的，一个叫 WOW64 的 x86 模拟器。和前文提到苹果的 Rosetta 有点像，模拟过程就是把 x86 指令块编译成 ARM64 指令，加一些优化。会有服务对转译代码块做缓存，减少指令转译开销。貌似到目前为止，x86-64 应用（也就是传统的 Windows 64 位应用）还无法在 Arm 版 Windows 上面跑，而且某些大型应用的模拟运行比较灾难级，比如 Photoshop。WOW64 也跑在用户态[17]。

其实突然又有点搞不懂微软将来计划怎么发展，从如今微软的动作来看，好像十分偏向 Arm（和高通），只不过大业未成，生态也暂未见起色，x86 也不想抛弃。不知 Intel 看此情此景是什么心情。毕竟 Windows 作为历史用户基数庞大的操作系统，兼容性的历史包袱远大于苹果的 Mac OS：我没法从技术细节上来探讨谁做得更好，但微软一定比苹果更有难度；何况苹果还有 iOS 这颗大棋子。

如果说苹果要在同一时间针对 Mac 系列产品，既保有 x86 平台（典型如 Mac Pro 这种更新没多久的高性能工作站），又开发 Arm 平台（很可能就是 MacBook），那么对两个平台的同时支持，以及对开发者的友好度，不知能否做到比微软如今的方案更好——因为这次似乎并不是彻底抛弃上一个平台这么简单（毕竟彭博社是说部分 Mac 产品采用 Arm 处理器），也就不能以斩断过往、说抛弃就抛弃这种苹果式的任性方法来做决策（但好似当年 PowerPC 与 x86 在 Mac OS 系统上也共存了起码 5 年）。

Mac 转舵可能会遭遇的问题

一气写下来，感觉篇幅有点过长了，本来还想聊聊苹果自己在 Mac 设备里面搞的 T2 芯片，以及可将 iPad app 轻松移植给 macOS 的 Catalyst 项目——毕竟这俩看起来都很像本次转舵的重要缓冲或预备手段。但再写的话，这文章字数就要破万了，实在是太废纸了。在转换平台的问题上，即便有那么多的困难，自主掌握芯片迭代节奏，以及牢固生态发展，采用自研芯片还是有好处。

其实上面这些算是一个资料汇总，也算是我近期的学习过程吧，以简短的形式汇报给各位。这里最后谈一谈 Mac 如果真的要从 x86 转往 Arm（而不是两者并行发展，毕竟苹果很少做这么二的事情），除了兼容性和技术层面，如上述文字中提到的难度，在实际实施中还会有一些非常现实的问题。

第一就是，可能面临抛弃 Windows 用户的问题，Mac 如果彻底抛弃 x86，则未来的 Mac 设备很可能就不能再安装 Windows 系统了：这个问题我觉得十分严重，或许很多 Mac 用户对于在 Mac 设备上使用 Windows 是非常嗤之以鼻的，但这个选择对很多人来说仍然十分重要。毕竟 Windows 的生产力生态仍然十分完备，某些很偏的应用都只支持 Windows。（现在 Windows 也支持 Arm 了，只是两者的平台还是有差异）

第二是，如果低端 MacBook 产品线开始用 Arm 处理器，那么目前的 iPad Pro 产品定位会显得很尴尬。因为后者就是定位于轻度生产力工具，如果要说生产力，iOS 和 macOS 似乎并非同台竞争的对象。

第三，有个比较实际的问题：Intel 毕竟是个造芯片的公司，可以搞出一大堆不同定位的 SKU，比如什么酷睿 i3、i5、i7；超低压、低压、标压、桌面等等，并且应用到不同售价的 Mac 设备上。苹果即便有能力造芯片，是否能在短时间内，按照体质划分不同 SKU，并且应用到将来更多的 Mac 设备上？如果不能的话，难道真的要 x86 和 Arm 并行发展吗？

值得注意的是，这次的转舵并不像上次 PowerPC -> x86 那样，是转向一个在桌面市场十分受欢迎和健全的平台；而且如今苹果公司的体量远非 2005 年可比，所以这次转舵的困难程度大约不小。另外，前面花了那么多篇幅谈兼容性问题，针对某些十分细节的点，比如小到 Final Cut Pro X 中的一个插件，即便容易想见 Final Cut Pro X 会第一批支持 Arm 版 macOS，但插件未更新就可以彻底埋葬一部分用户。

具体是什么状况，等到今年的 WWDC 或可一见分晓。最后的最后，Intel 哭泣的时间应该会更长：为什么全世界都针对我？

参考来源：

[1] Apple Aims to Sell Macs With Its Own Chips Starting in 2021 - Bloomberg

https://www.bloomberg.com/news/articles/2020-04-23/apple-aims-to-sell-macs-with-its-own-chips-starting-in-2021

[2] 小议Mac OS Classic的底层架构与Mac的固件沿革 - 老Mac与MacOS收藏

https://zhuanlan.zhihu.com/p/44934452

[3] Mac OS nanokernel - Wikipedia

https://en.wikipedia.org/wiki/Mac_OS_nanokernel

[4] Mac 68k emulator - Wikipedia

https://en.wikipedia.org/wiki/Mac_68k_emulator

[5] Fat binary - Wikipedia

https://en.wikipedia.org/wiki/Fat_binary

[6] List of macOS components - Wikipedia

https://en.wikipedia.org/wiki/List_of_macOS_components#Classic

[7] Rosetta (software) - Wikipedia

https://en.wikipedia.org/wiki/Rosetta_(software)

[8] CodeWarrior - Wikipedia

https://en.wikipedia.org/wiki/CodeWarrior

[9] 聊聊无风扇的Surface Pro：性能比一般笔记本差多少？ - 面包板

https://mbb.eet-china.com/blog/3893689-413612.html

[10] 一场硬仗：华为和高通的GPU差距还有多大？ - EE Times China

https://www.eet-china.com/news/202001061219.html

[11] 为啥 Arm 架构比 x86 x64 省电？ - 木头龙的回答

https://www.zhihu.com/question/387240856/answer/1186307900

[12] The Apple iPhone 11, 11 Pro & 11 Pro Max Review: Performance, Battery, & Camera Elevated - AnandTech

https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/4

[13] Intel Says Process Tech to Lag Competitors Until Late 2021, Will Regain Lead with 5nm - Intel

https://www.tomshardware.com/news/intel-process-tech-lag-competitors-late-2021-leadership-5nm

[14] Windows Runtime - Wikipedia

https://en.wikipedia.org/wiki/Windows_Runtime

[15] How the Universal Windows Platform relates to Windows Runtime APIs - Microsoft

https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide#how-the-universal-windows-platform-relates-to-windows-runtime-apis

[16] Windows 10X Developer FAQ - Microsoft

https://docs.microsoft.com/en-us/windows/apps/10x/faq

[17] WOW64 Implementation Details - Microsoft

https://docs.microsoft.com/zh-cn/windows/win32/winprog64/wow64-implementation-details

*国际电子商情对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。