这次传言是正确的，苹果刚刚宣布他们将把Mac过渡到ARM处理器。这些消息对软件开发者有一些副作用，特别是那些不与苹果生态系统合作的软件开发者。 而且它们也影响到同时依赖macOS和Windows的人。
内容
在这篇文章中，我不打算关注x86_64和ARM、RISC和CISC以及所有基准之间的差异。让我们假设苹果设法提供基于ARM的CPU，其性能可以与苹果产品线中的大多数英特尔处理器相媲美，甚至让我们假设他们可以制造出ARM Mac Pro。(关于命名的说明：Apple Silicon是官方名称，但它听起来很丑。对于英特尔，我将使用英特尔或x86（_64）。
对于许多用户来说，这种过渡或多或少是透明的。当然，他们会失去一些应用程序，就像他们可能对Catalina所做的那样（它放弃了对32位英特尔应用程序的支持），或者在过渡的头几个月，一些应用程序将无法使用/会出现错误（尽管它将比PowerPC的过渡更容易，因为苹果在ARM上使用小endian字节顺序）。
在苹果公司的土地上，它将如何运作？
对于只从事iOS应用程序的开发者来说，过渡也没有什么意义。 也许会有更快、更准确的模拟器。他们迟早需要购买一台ARM Mac（在未来5年内），因为苹果要求他们使用最新的Xcode版本来提交App Store，而Xcode最多支持之前的macOS版本。 但这一直是苹果的政策，当这种情况发生时，英特尔Mac可能会在通常的淘汰范围内。
对只使用macOS的开发者的要求是非常明显的，他们需要在第一天就购买一台ARM Mac，这样他们就可以在新的平台上测试他们的应用程序。 他们还需要致力于ARM的兼容性。尽管在苹果公司的土地上，为新的操作系统更新你的应用程序是每年的例行公事，所以这也是大多数情况下的业务（除非你的代码中做了很多不可移植的低级别的东西）。有一些专业的应用程序往往会落后于苹果的新法令（有些可能已经受到Catalina的冲击），这些应用程序的用户可能更愿意在英特尔那里多呆一段时间。
但随后，我们就会涉及到使用Mac的开发者的要求，但他们并不完全使用苹果的平台。这是一个相当大的群体，因为许多开发者喜欢Mac，因为它有良好的硬件，基于Unix的软件，以及两者的整合。而在某种程度上，非开发者也受到了影响。
谁需要非苹果的操作系统？
第一类人是以某种方式与Windows绑定的人。他们中的一些人可能正在使用Boot Camp玩游戏。其他人可能使用Boot Camp或虚拟化软件（Parallels Desktop、VMware Fusion、Oracle VM VirtualBox）来运行Windows和Windows特定的应用程序，也许他们需要Windows版本的Office，或各种Windows专用的专业应用程序，或者他们需要Windows来报税，因为他们的政府并不关心非Windows操作系统。或者他们是网络开发者，他们需要测试与Windows版本的浏览器或旧的微软浏览器（IE和Chromium Edge之前）的兼容性。
第二组是需要Linux的软件开发者。虽然macOS提供了一个非常合格的开发环境，而且许多东西可以直接在macOS上运行，但有些使用情况可能需要一个Linux虚拟机。 也许最值得注意的情况是Docker。
Docker是一个轻量级应用容器的解决方案，它可以提供应用之间的分离，并且可以简化和标准化部署。Docker本身不是一个虚拟化解决方案（至少在传统意义上）。Docker必须运行在Linux之上（也有Docker-on-Windows，但这是另一个故事）。Docker Desktop for Mac应用程序运行一个轻量级Linux虚拟机，并在该虚拟机中运行容器。Docker for Mac使用的虚拟化解决方案是Hypervisor.framework ，它是macOS本身的一部分。
还有谁需要虚拟化？安卓开发者。Android模拟器也是一个运行Android操作系统的虚拟机。Android可以在不同的架构上运行，因此，Emulator通常使用x86系统镜像。
在 ARM 上是否可以进行虚拟化？
是的，当然可以。自从4月份在iOS上发现上述的Hypervisor.framework ，苹果已经在更早的时候进行了测试。而苹果在主题演讲中宣布了对ARM Mac的虚拟化支持，并展示了一个Linux虚拟机的例子。当然，该虚拟机运行的是ARM64版本的Linux。
但是，我们可以用它来做什么呢？事实证明，这很复杂。在之前提到的几个用例中，最简单的是Android。谷歌只需要让模拟器在ARM Macs上工作，并将其发送给开发者。
那么一般的Linux呢？许多主流发行版都支持ARM64，所以一般来说这不是一个问题。对特定发行版或软件的支持可能比x86_64差，但对用户来说一般不是问题。
但是对于Docker来说，有一个问题。Docker的众多优势之一是开发--开发平价。如果你用Docker把你的应用部署到x86_64的Linux服务器上，你也可以把Docker安装在x86_64的Linux开发者机器上（或者Intel Mac/Windows PC上的Linux虚拟机）。服务器和开发机都可以运行相同的镜像、相同的代码、相同的配置。如果它们是不同的架构，这就不会发生。这意味着你可能会因为不同的环境而发生错误，也有可能你所依赖的一些图像在两种架构上都无法使用。
然后我们再来看看Windows。Windows也有一个ARM版本，但是它目前只能和新的ARM设备一起使用（你不能独立购买）。如果微软要卖这个，我们会有一个软件的问题。ARM上的Windows 10支持32/64位ARM软件，并可以使用仿真技术运行32位英特尔（x86）软件。然而，它不能模拟需要64位英特尔处理器（x86_64）的应用程序。 这使得该平台上的软件情况稍好一些。虽然许多开发者不关心ARM，而且可能没有为ARM构建的软件，但大多数Windows软件都有x86和x86_64两个版本，或者完全是32位。但是，某些专业的应用程序只有x86_64版本，所以如果没有ARM版本，ARM的Windows电脑目前不能运行它。（更新：微软宣布在ARM上进行x86_64模拟，这意味着更多的软件可以运行）。
并注意到，微软知道转型，但我们在主题演讲中没有听到任何关于Windows的消息。
我们可以模拟x86(_64)并运行x86(_64)Windows 10吗？
理论上？是的。实践上呢？不能。
仿真的问题是速度。有一些x86模拟器可用，这些模拟器可以在ARM设备上很好地运行。你可以在YouTube上找到一些视频（我知道，这不是一个非常可靠的信息来源），在这些视频中，人们试图对那些进行基准测试，或者试图使用这样的模拟器运行Windows。而即使是古老的Windows版本，模拟的速度也是痛苦的。如果你试图模拟所有的Windows 10，基本上就无法使用了。
Windows 10的ARM的x86模拟是如何工作的？你可以观看Channel 9关于Windows 10 on ARM的视频（大约6:00）了解更多细节。诀窍在于，系统DLLs使用的是x86/ARM64混合库格式，这意味着x86代码可以以原生速度调用这些DLLs。这意味着许多应用程序以接近原生速度运行（取决于自定义代码与系统DLL调用的比例）。这种技术不能用于模拟整个操作系统。如果ARM上的Windows 10可以用于ARM Macs，那么运行x86 Windows应用程序将变得可行。
Rosetta可能使用类似的技术。大多数应用程序将在安装时被翻译，而不是在运行时。但你不能对整个操作系统这样做。
对于同时依赖macOS和Windows的人来说，下一步是什么？
再过几年，英特尔Mac仍然会得到苹果（新的macOS版本）和软件供应商的支持。但在那之后呢？那么，你就只能用两台机器了，至少在ARM上的Windows变得可行并可在Mac上运行之前。或者你可以开始探索macOS软件的替代品。如果你是macOS-as-UNIX-with-great-UX的开发者之一（你好！），也许你将不得不切换到Linux或者是Windows与Windows Subsystem for Linux？(后者随着每一个Windows版本的发布而变得更加可用，所以请关注我在WSL2中用NeoVim写了这篇文章，Windows终端支持许多高级终端功能，透明的文件系统集成让我可以直接访问Windows文件）。
M1公告后更新 (2020-11-14)
Parallels已经确认支持M1 Macs并提供M1虚拟化产品的技术预览。此公告中提到Windows 10 ARM支持x86_64应用程序，导致一些技术作者认为Parallels将在M1 Macs上支持Windows 10 ARM。这并不是公告中所说的。Parallels 没有，也不能宣布对该操作系统的支持，因为 Windows 10 ARM （仍然）只提供给 ARM OEMs 安装在他们的设备上 - 今天正式宣布该功能就等于承认做了违法的事情/EULA 不允许。我敢肯定，在微软向公众开放Windows 10 ARM之前，他们现在和可预见的未来都不会致力于对Windows 10 ARM的支持。
