苹果换芯成开发者噩梦：Docker运行受影响，众多工具和库不支持ARM64

“2020 年已至，我第一次感受到苹果公司对于我这类开发人员的点点恶意。”
苹果的换芯行动

11 月 11 日凌晨，苹果“One more thing”发布会如期而至。发布会上，苹果宣布推出首款自研的 5nm M1 芯片，该款芯片将为其新一代基于 ARM 的 Mac 系列产品提供动力。苹果公司声称，该款 M1 芯片搭载了许多世界顶级工艺的产品，包括世界上最快的 CPU 内核、最快的 IGPU。
“苹果花了十几年的时间来创造和优化 Apple 芯片，因为芯片是 iPhone、iPad 和 Apple Watch 的核心。现在我们希望将其引入 Mac，因此 Mac 可以凭借令人难以置信的性能、自定义技术和行业领先的芯片来实现巨大的飞跃”，苹果如是说。
苹果公司认为，M1 是迄今为止性能最高的芯片，并且低功耗高效内核可提供与当前基于英特尔的双核 MacBook Air 相似的性能。当然，高性能内核要快得多。
M1 芯片推出以前，英特尔几乎垄断了苹果笔记本电脑的 CPU。2005 年，苹果从 PowerPC 芯片切换到了英特尔。这个过渡已经有 15 年了，过渡的成本来主要来自软件方面。开始时开发人员需要使用苹果提供的工具链来生成可以在 PPC 和 x86 Mac 上运行的通用二进制文件，并且并非所有苹果以前的 API 都可以过渡到 x86。

当年，苹果推出的工具链名叫 Rosetta，用于将 PowerPC 应用转换到 x86 上。Rosetta 能做到让大多数 PPC Mac OS X 应用程序在 x86 Mac 上运行，尽管性能有些损失（这并不是一件简单的事情）。最终，Rosetta 成为了苹果的创可贴，直到 2011 年 Mac OS X 10.7（Lion）推出时才被放弃。

现在，从英特尔切换到苹果 Silicon，苹果给出了三种解决方案：Universal 2 通用应用、Rosetta 2 工具链、原生 ARM 应用。第一种解决方案是在苹果芯片版 Mac 上使用“Universal 2”运行应用程序，针对 Adobe Photoshop、Microsoft Word 这样的系统软件。第二种解决方案是利用苹果提供的 Rosetta 2 将应用重新编译，让 x86 应用能运行在 ARM 架构上，主要针对不太涉及处理器特性的绝大部分轻量级应用。
从本质上讲，Rosetta 2 可能足以支持大多数主流生产力应用程序，但往往无法兼容那些需要与操作系统、硬件或图形硬件进行直接交互的软件。特别是，那些在关键任务需求中涉及虚拟化或高端图形、视频或科学类应用处理的用户，可能最好是等推出原生软件版本之后再考虑升级到基于 ARM 的苹果芯片版 Mac 平台。
换芯给开发者们带来的问题

很明显，这次换芯行动将给消费者们带来巨大助益，包括获得更长的电池续航并改善运行过热问题（2018 款 MacBook Pro 就是款强大的「暖宝宝」）。软件与硬件之间的紧密集成，也将进一步优化用户的使用体验。另外，产品价格也有可能随之下降。
苹果的芯片迁移决定，自然也激起了开发者们的担忧，特别是在开发者体验方面。苹果虽然表示提供了相应的解决方案，强调新的芯片将提高开发人员的生产力，但是换芯行动也同样会沉重打击高度依赖其产品及生态系统的专业开发者。
现有 Mac 应用运行速度可能减慢

如果将现有 Mac 应用借助 Rosetta 2 转换引擎重新编译为“Universal 2”二进制形式，大部分专为英特尔处理器编写的 64 位 MacOS 应用程序都能够直接运行在苹果芯片版 Mac 之上。
但苹果在开发者文档中颇为诙谐地提到，“转译过程需要时间，因此用户可能感觉转译后的应用在启动或运行时偶尔更慢。”
当然，只要涉及任何形式的仿真、虚拟化或者转译过程，应用程序的运行速度就必然要比原生版本稍慢一点。虽然还没有官方确认，但通过已经泄露的 Geekbench 5 基准测试，大家大概可以推断 Mac mini DTK 的运行速度会比在 iPad Pro (2020) 机型上慢多少。
与运行原生代码的 iPad Pro（2020）机型相比，Mac mini DTK 在通过 Rosetta 2 以单核形式运行 Geekbench 5 基准测试时，速度降低了 26%；在多核形式下，速度要慢 38%。
值得一提的是，与这款 iPad Pro 相比，Mac mini DTK 的时钟频率也有所下降，而且运行的 beta 软件并未经过优化。但如果我们假定二者时钟频率相同且在最终硬件发布时完成了进一步软件优化，那么估计通过 Rosetta 运行软件时、相较于原生应用的速度劣势应该会在 20% 到 30% 之间。可以肯定的是，基于 ARM 的苹果芯片 Mac 性能更强，甚至足以抵消引入 Rosetta 2 带来的速度劣势，最终实现与一、两年前大部分英特尔芯片版 Mac 相同的性能水平。
但是，其他人怎么办？实际上，大多数在 Mac 上进行开发的用户并不是在构建 iOS 或者 MacOS 应用。
根据 StackOveRFlow 2020 开发者调查，超过四分之一的开发者使用 MacOS，但只有 6% 的用户使用 Swift 语言。作为目前苹果唯一官方指定的苹果生态应用构建语言，Swift 孱弱的市场占有率足以说明大多数 Mac 用户其实并不是在为苹果开发产品。
换言之，相当一部分 MacOS 上的开发者是在构建其他类型的应用，例如运行在云服务器上的 Web 应用程序。对于这些已经熟悉了 Node.js、Python、Ruby、PHP、Go 甚至.NET/C# 的开发者来说，Mac 的换芯行动意味着什么？简单来说，他们的使用体验必然受到影响。
相当一部分工具和库并不支持 ARM64

虽然情况会逐渐改善，但除了 AMD64 之外，其他大多数架构都无法在 ARM 上运行。而且对其他架构的支持会带来高昂成本：开发商需要从自己的代码中删除所有指向特定架构的部分，构建基础设施（在无法或不方便进行交叉编译时，可能需要购买新的硬件）、执行测试，最后提供支持。
由于相当一部分工具和库属于开源项目，因此由此带来的维护需求增长将成为沉重的额外负担，导致某些贡献者直接放弃为新的 Mac 平台上提供支持。
当然也有一些应用程序、特别是闭源项目，压根没有 ARM 版 build，例如微软 SQL Server 或 OracleDB。一位网友曾在 Reddit 上评论说：“我在学术圈待过，之前使用 Mac 设备的学生们只能依靠 Mac + Azure Data Studio 上的 Docker 完成微软 SQL 的操作练习。因此除非微软发布 ARM 版本的 SQL Server，否则这项利好将彻底消失。目前来看似乎微软并无此意，至少在 ARM 版 Mac 推出之前是不太可能有什么动静。”
对虚拟化的支持也只能运行在 ARM64 操作系统上
苹果公司当然意识到在 Mac 上运行 Linux 的重要性，因此在发布会上演示了如何使用 Debian 虚拟机。但他们聊得不多，只是在稍后的小组讨论中证实，当时台上展示的是 Debian 的 ARM 版本。虽然不少 Linux 发行版都提供 ARM 镜像，但仍不是全部，而且多少会影响到软件可用性。更重要的是，至少 ARM 架构是绝对支持不了 Windows 的。因此，如果大家打算使用 Mac 测试自己的 Windows 应用，只能说抱歉了。你需要另外买台笔记本，或者使用远程桌面服务。另外，你也没法在 Mac 上运行虚拟机进行设备测试（例如 ESXi、pfSense、FreeNAS 等）。
Docker 受到的影响

由于 Mac 上的 Docker 只能在虚拟机内运行，再加上用户只能对基于 ARM 架构的 Linux 进行虚拟化，意味着我们未来只能在苹果芯片版的 Mac 上运行 ARM64 容器。
目前，Docker Hub 上存在 331 万 9219 个针对 AMD64 的镜像，但针对 ARM64 的镜像只有 29076 个，占比不足 1%。再有，构建多架构 Docker 镜像还特别复杂。
尤其需要注意的是，由于生产系统通常运行 Linux/AMD64，因此你生产的二进制文件及 Docker 镜像很可能无法在开发计算机上运行。当然，你也许可以进行重新编译及交叉编译，但永远无法还原其真实的运行状态。另外，如果你的应用在生产环境中发生问题，也无法仅凭二进制文件或容器镜像在自己的笔记本上进行调试。
Docker 在开发者的日常工作流程中占据非常重要的位置，所以这些令开发者们感到相当头痛。

任职于 Docker 的 Stephen Turner 博士表示：“虽然操作系统具有虚拟化功能，但苹果芯片尚不支持虚拟化。我们也无能无力，但我们正在和苹果紧密合作希望解决这个问题”，但什么时候能够解决，他表示“还没有具体的日期”。
在 11 日的发布会后，据开发者的反馈，他们怀疑问题是否已经解决：“据我所知，M1 确实具有虚拟化支持，但尚未移植 Docker。”
并且如果只能在虚拟化层上运行 Docker，将给文件 I/O 性能造成严重拖累，并导致大型项目的编译速度直线下降。有开发者表示目前他只能使用 docker-sync 来解决这个问题。另外，除非使用 docker machine 实现真虚拟机，否则没有其他方法能够将设备挂载至 Mac 上的 docker 容器当中。所以，对于大多数需要与硬件直接交互的软件厂商来说，早点发布自家软件的原生版本才是正道。
当然，你可以使用 Rosetta 2 来运行 x86 容器，但其能否进一步扩展至支持虚拟化 Linux 等 x86 操作系统仍然有待观察。
参照 2005 年的过渡方案，苹果为这次过渡给出了两年的时间。如果一切顺利，苹果应该会在两年之后的新版本 macOS 中去掉对 x86 指令集的支持，在三年之后的新版本中去掉 Rosetta 2。而这三年之中，开发者们需要付出什么样的代价，还有待验证。
『本文转载自网络,版权归原作者所有,如有侵权请联系删除』