编译
Tina、核子可乐
“年已至，我第一次感受到苹果公司对于我这类开发人员的点点恶意。” 苹果的换芯行动11月11日凌晨，苹果“Onemorething”发布会如期而至。发布会上，苹果宣布推出首款自研的5nmM1芯片，该款芯片将为其新一代基于ARM的Mac系列产品提供动力。苹果公司声称，该款M1芯片搭载了许多世界顶级工艺的产品，包括世界上最快的CPU内核、最快的IGPU。
“苹果花了十几年的时间来创造和优化Apple芯片，因为芯片是iPhone、iPad和AppleWatch的核心。现在我们希望将其引入Mac，因此Mac可以凭借令人难以置信的性能、自定义技术和行业领先的芯片来实现巨大的飞跃”，苹果如是说。
苹果公司认为，M1是迄今为止性能最高的芯片，并且低功耗高效内核可提供与当前基于英特尔的双核MacBookAir相似的性能。当然，高性能内核要快得多。
M1芯片推出以前，英特尔几乎垄断了苹果笔记本电脑的CPU。年，苹果从PowerPC芯片切换到了英特尔。这个过渡已经有15年了，过渡的成本来主要来自软件方面。开始时开发人员需要使用苹果提供的工具链来生成可以在PPC和x86Mac上运行的通用二进制文件，并且并非所有苹果以前的API都可以过渡到x86。
当年，苹果推出的工具链名叫Rosetta，用于将PowerPC应用转换到x86上。Rosetta能做到让大多数PPCMacOSX应用程序在x86Mac上运行，尽管性能有些损失（这并不是一件简单的事情）。最终，Rosetta成为了苹果的创可贴，直到年MacOSX10.7（Lion）推出时才被放弃。
现在，从英特尔切换到苹果Silicon，苹果给出了三种解决方案：Universal2通用应用、Rosetta2工具链、原生ARM应用。第一种解决方案是在苹果芯片版Mac上使用“Universal2”运行应用程序，针对AdobePhotoshop、MicrosoftWord这样的系统软件。第二种解决方案是利用苹果提供的Rosetta2将应用重新编译，让x86应用能运行在ARM架构上，主要针对不太涉及处理器特性的绝大部分轻量级应用。
从本质上讲，Rosetta2可能足以支持大多数主流生产力应用程序，但往往无法兼容那些需要与操作系统、硬件或图形硬件进行直接交互的软件。特别是，那些在关键任务需求中涉及虚拟化或高端图形、视频或科学类应用处理的用户，可能最好是等推出原生软件版本之后再考虑升级到基于ARM的苹果芯片版Mac平台。
换芯给开发者们带来的问题很明显，这次换芯行动将给消费者们带来巨大助益，包括获得更长的电池续航并改善运行过热问题（款MacBookPro就是款强大的「暖宝宝」）。软件与硬件之间的紧密集成，也将进一步优化用户的使用体验。另外，产品价格也有可能随之下降。
苹果的芯片迁移决定，自然也激起了开发者们的担忧，特别是在开发者体验方面。苹果虽然表示提供了相应的解决方案，强调新的芯片将提高开发人员的生产力，但是换芯行动也同样会沉重打击高度依赖其产品及生态系统的专业开发者。
现有Mac应用运行速度可能减慢如果将现有Mac应用借助Rosetta2转换引擎重新编译为“Universal2”二进制形式，大部分专为英特尔处理器编写的64位MacOS应用程序都能够直接运行在苹果芯片版Mac之上。
但苹果在开发者文档中颇为诙谐地提到，“转译过程需要时间，因此用户可能感觉转译后的应用在启动或运行时偶尔更慢。”
当然，只要涉及任何形式的仿真、虚拟化或者转译过程，应用程序的运行速度就必然要比原生版本稍慢一点。虽然还没有官方确认，但通过已经泄露的Geekbench5基准测试，大家大概可以推断MacminiDTK的运行速度会比在iPadPro()机型上慢多少。
与运行原生代码的iPadPro（）机型相比，MacminiDTK在通过Rosetta2以单核形式运行Geekbench5基准测试时，速度降低了26%；在多核形式下，速度要慢38%。
值得一提的是，与这款iPadPro相比，MacminiDTK的时钟频率也有所下降，而且运行的beta软件并未经过优化。但如果我们假定二者时钟频率相同且在最终硬件发布时完成了进一步软件优化，那么估计通过Rosetta运行软件时、相较于原生应用的速度劣势应该会在20%到30%之间。可以肯定的是，基于ARM的苹果芯片Mac性能更强，甚至足以抵消引入Rosetta2带来的速度劣势，最终实现与一、两年前大部分英特尔芯片版Mac相同的性能水平。
但是，其他人怎么办？实际上，大多数在Mac上进行开发的用户并不是在构建iOS或者MacOS应用。
根据StackOverflow开发者调查，超过四分之一的开发者使用MacOS，但只有6%的用户使用Swift语言。作为目前苹果唯一官方指定的苹果生态应用构建语言，Swift孱弱的市场占有率足以说明大多数Mac用户其实并不是在为苹果开发产品。
换言之，相当一部分MacOS上的开发者是在构建其他类型的应用，例如运行在云服务器上的Web应用程序。对于这些已经熟悉了Node.js、Python、Ruby、PHP、Go甚至.NET/C#的开发者来说，Mac的换芯行动意味着什么？简单来说，他们的使用体验必然受到影响。
相当一部分工具和库并不支持ARM64虽然情况会逐渐改善，但除了AMD64之外，其他大多数架构都无法在ARM上运行。而且对其他架构的支持会带来高昂成本：开发商需要从自己的代码中删除所有指向特定架构的部分，构建基础设施（在无法或不方便进行交叉编译时，可能需要购买新的硬件）、执行测试，最后提供支持。
由于相当一部分工具和库属于开源项目，因此由此带来的维护需求增长将成为沉重的额外负担，导致某些贡献者直接放弃为新的Mac平台上提供支持。
当然也有一些应用程序、特别是闭源项目，压根没有ARM版build，例如微软SQLServer或OracleDB。一位网友曾在Reddit上评论说：“我在学术圈待过，之前使用Mac设备的学生们只能依靠Mac+AzureDataStudio上的Docker完成微软SQL的操作练习。因此除非微软发布ARM版本的SQLServer，否则这项利好将彻底消失。目前来看似乎微软并无此意，至少在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容器。
目前，DockerHub上存在万个针对AMD64的镜像，但针对ARM64的镜像只有个，占比不足1%。再有，构建多架构Docker镜像还特别复杂。
尤其需要注意的是，由于生产系统通常运行Linux/AMD64，因此你生产的二进制文件及Docker镜像很可能无法在开发计算机上运行。当然，你也许可以进行重新编译及交叉编译，但永远无法还原其真实的运行状态。另外，如果你的应用在生产环境中发生问题，也无法仅凭二进制文件或容器镜像在自己的笔记本上进行调试。
Docker在开发者的日常工作流程中占据非常重要的位置，所以这些令开发者们感到相当头痛。
任职于Docker的StephenTurner博士表示：“虽然操作系统具有虚拟化功能，但苹果芯片尚不支持虚拟化。我们也无能无力，但我们正在和苹果紧密合作希望解决这个问题”，但什么时候能够解决，他表示“还没有具体的日期”。
在11日的发布会后，据开发者的反馈，他们怀疑问题是否已经解决：“据我所知，M1确实具有虚拟化支持，但尚未移植Docker。”
并且如果只能在虚拟化层上运行Docker，将给文件I/O性能造成严重拖累，并导致大型项目的编译速度直线下降。有开发者表示目前他只能使用docker-sync来解决这个问题。另外，除非使用dockermachine实现真虚拟机，否则没有其他方法能够将设备挂载至Mac上的docker容器当中。所以，对于大多数需要与硬件直接交互的软件厂商来说，早点发布自家软件的原生版本才是正道。
当然，你可以使用Rosetta2来运行x86容器，但其能否进一步扩展至支持虚拟化Linux等x86操作系统仍然有待观察。
参照年的过渡方案，苹果为这次过渡给出了两年的时间。如果一切顺利，苹果应该会在两年之后的新版本macOS中去掉对x86指令集的支持，在三年之后的新版本中去掉Rosetta2。而这三年之中，开发者们需要付出什么样的代价，还有待验证。
参考链接：