今年双十一这一天，苹果震撼发布了全新的自研 M1 芯片，从发布到入手的这段时间内，无数开发者开启了探索与尝鲜模式。近日，PSPDFKit 创始人 Peter Steinberger 在购买了一台 MacBook Air 16GB M1 版之后，针对 Xcode、Android Studio、Homebrew 等开发者必备的工具及应用程序进行了评测，接下来，我们见一探 M1 带来的魅力。
CSDN 编者按：今年双十一这一天，苹果震撼发布了全新的自研 M1 芯片，从发布到入手的这段时间内，无数开发者开启了探索与尝鲜模式。近日，PSPDFKit 创始人 Peter Steinberger 在购买了一台 MacBook Air 16GB M1 版之后，针对 Xcode、Android Studio、Homebrew 等开发者必备的工具及应用程序进行了评测，接下来，我们见一探 M1 带来的魅力。 英文标题：Apple Silicon M1: A Developer’s Perspective 原文链接：https://steipete.com/posts/apple-silicon-m1-a-developer-perspective/ 作者：Peter Steinberger，PSPDFKit的创始人。 译者：弯月 声明：本文为 Peter Steinberger 原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请注明出处及来源。
英文标题：Apple Silicon M1: A Developer’s Perspective
原文链接：
https://steipete.com/posts/apple-silicon-m1-a-developer-perspective/
作者：Peter Steinberger，PSPDFKit的创始人。
译者：弯月
声明：本文为 Peter Steinberger 原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请注明出处及来源。
最近大家都因为苹果的新 M1 芯片而兴奋不已。我也买了一台 MacBook Air 16GB M1 版，想看看是否能当作主力开发机使用。下面是我在测试了一个星期之后的报告。
Xcode 在 M1 上的运行速度非常快。编译 PSPDFKit PDF SDK（ debug，Arm64 版）几乎能与加载了目前最快的英特尔芯片的 MacBook Pro 媲美，前者的编译时间是 8 分 49 秒，后者是 7 分 31 秒。作为比较，我的黑苹果（Hackintosh，指在非苹果生产或非苹果授权生产的普通 x86 架构 PC 上安装 MacOS 的行为）编译同样的项目需要不到 5 分钟。
对于一台无风扇的机器来说，这已经非常了不起了。苹果的上一款无风扇 MacBook 是 2017 年的 12 寸版本，用它编译同一个项目需要 41 分钟。
绝大多数测试都能通过，尽管我发现了我们之前没有注意到的一些针对 arm64 的错误，因为我们的 CI 并没有真正在 arm64 的硬件上运行过测试。模拟器采用与真实设备同样的架构很有好处，可以帮我们找到更多错误。
iOS 14 版以下的测试很有问题。似乎 WebKit 会在某个内存分配的地方崩溃，抛出异常 EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) (Apple folks: FB8920323)。性能似乎也非常差，Xcode 经常会停止响应，整个系统变得非常慢，鼠标移动都会断断续续的。一些模拟器甚至会在 iOS 14 上出问题，例如 iPad Air (4th gen) 的模拟器依然模拟的是英特尔 CPU ，所以尽量不要使用这些模拟器。
我们非常高兴地把 CI 迁移到了 M1 芯片的 Mac Mini 上，就等着 MacStadium 正式支持该设备了，不过我们需要将测试限制在 iOS 14 上，才能正常工作。根据我们目前的计划，我们打算在 2021 年三季度放弃 iOS 12 的支持，在 2022 年 3 季度放弃 iOS 13 的支持，所以我们需要等待一段时间才能完全迁移到苹果芯片上。
苹果有可能会修复这些问题，但我们不应该指望他们修复，毕竟这些问题仅影响旧版本的 iOS ，随着时间的流逝这些问题就会消失了。
更新： 目前我们解决 WebKit 崩溃的问题是通过在运行时检测 Rosetta2 转译，如果发现使用了 WebKit ，就略过测试。这并不完美，但幸好我们的项目中并没有用到太多 WebKit 。性能似乎还可以接受，只要把并行测试限制在两个实例以内，否则系统会耗尽内存，产生大量页面交换，导致变慢。
我希望在 2021 年第一季度找到运行基于 ARM 的容器的方法。我们需要一些努力添加 ARM 的支持（一些已经排上了日程），所以这只是一个过渡问题。
为了测试 Windows PDF SDK，大多数人通常都会使用 VMware 虚拟机，安装 Windows 10 和 Visual Studio 。目前没有任何 Mac 上的虚拟化程序能支持苹果芯片，但 VMware 和 Parallels 都在努力解决问题。我认为 VirtualBox 应该无法在短期内给出解决方案。
我认为最终我们肯定能通过某种商业工具运行基于 ARM 的 Windows 。目前已经有了许多概念性的验证，性能似乎非常不错。微软目前并没有基于 ARM 的 Windows ，所以如何获取授权会是很有意思的问题。
基于 ARM 的 Windows 可以模拟 x86 的应用程序，而微软正在开发 x64 模拟，目前已经在 Insider 的构建中推出了。几个月后就应该能在 M1 上通过 Visual Studio 以可以接受的性能测试我们的 Windows SDK 了。
运行旧版本的 macOS 可能问题更大。目前我们的 AppKit PDF SDK 支持 macOS 10.14 ，而 Catalyst PDF SDK 支持 macOS 10.15 ，两个发布都需要测试。我们依然需要依赖于 VMware 或 Parallels 是否会包含完整的 x64 模拟层。这模拟层将会非常慢，所以我并没有太多期待。
在这里插入图片描述
最后，16GB 内存并不多。在运行并行测试时，机器会产生大量的页面交换，导致性能大幅度下降。在运行虚拟机时问题会更严重。未来机器如果提供 32GB 的话能缓解这个问题。
IntelliJ 在努力将 JetBrains 运行时移植到苹果芯片上。目前 IntelliJ 的程序需要通过 Rosetta 2 运行，但通过 Graddle 进行编译非常慢。 Gradle 会在运行时创建代码，这个行为似乎与 Rosetta 2 的提前转译逻辑非常不契合。
我希望大部分问题能在 2021 年第一季度得到解决，但要让所有 Java 版本能在 ARM 上正常运行还需要很长一段时间。
Homebrew 目前通过 Rosetta 2 运行。只要加上 arch -x86_64 前缀就能正常使用。还可以在 /opt/homebrew 下额外安装一个 ARM 版的 Homebrew ，因为越来越多的软件都开始支持ARM。
目前还没发现问题（而且性能也不错），最终肯定能原生运行。
大多数应用程序都能运行，Rosetta 的影响可以忽略不计。大型应用程序的启动似乎受到了较大的性能影响（例如，Word 需要大约 20 秒才能转译完成），但可执行文件会缓存起来，以后的运行速度就会很快。
一小部分应用程序不能转译，导致启动失败（例如 Beamer，以及 Google Drive 的 “Backup and Sync” 客户端），但非常罕见。一些应用程序会搞不清楚自己在磁盘上的位置，会提示移动应用程序目录，但其实只是转译后的可执行文件在其他位置执行而已。绝大多数提示可以忽略。一些应用程序（例如 Visual Studio Code ）无法进行自动更新，因为转译后的应用程序是只读的。但是，就 VS Code 而言，Insider 版本已经支持 ARM ，所以可以正常工作。
基于 Electron 的应用程序在 Rosetta 上运行非常慢。似乎 V8 编译器会阻止提前转译。最新版本的 Electron（版本 11 ）已经完全支持苹果芯片，Slack 等公司已经发布了能够原生运行的 beta 版本。
Google 刚刚发布了 ARM 版本的 Chrome ，但与速度飞快的 Safari 相比还有一定距离。
新的 M1 MacBook 运行速度非常快，性能很优秀，而且很安静，所以传言都是有理有据的。不过在软件方面还有一定差距，特别是旧的 iOS 模拟器非常有问题。
这些都能在软件层面修复，整个软件行业都在努力提升体验，所以等到明年苹果发布新版 16 寸 MacBook Pro 以及下一代 M 芯片的时候，完全可能将 M1 Mac 作为主力开发机。
随着时间的推移，M1 会成为我的第二台笔记本电脑，我依然会使用2.4GHz 16 寸 MacBook Pro 32GB 内存的电脑，因为它的运行速度更快。毕竟在有了更好的选择后，就很难再使用风扇嗡嗡作响的电脑了。
针对以上的评测，引发不少网友热议：
评论1
我也是一名开发人员，不过我不使用 VSCode、Java/Gradle 等软件，我使用 Python 和 Rust 来从事开源项目的开发。
我的开源项目中，运行测试能快很多，这让我工作起来更舒服。在2017 MacBook Pro i7 上运行测试大约需要 60 秒，而在 M1 上只需要 15 秒，所以这在编辑运行测试循环中是一个巨大的进步。
我的 Rust 项目编译时间缩短了许多。以前调试版本的编译加上连接大约需要 3 分钟，现在只需 40 秒，因此同样也提高了开发效率。
对于其他项目，如 node/npm ，加速也非常明显，从源代码到可发布对象的流水线也更快。
我开发时使用的 vim 在 Rosetta 上也运行得很好，所以我可以继续使用我的插件。我用 Docker 并不多，但我会连接到云上，而不会在本地运行。
我有一台 16GB 13 寸的 MacBook Pro 。我同意作者的意见，它可以作为第二台笔记本，但它几乎能满足我的一切要求，而且更快，所以我基本上不再使用旧的 15 寸 MacBook Pro 了。
我一直在使用 16GB 的电脑，所以也许我已经习惯了小内存……我也不会大量使用 Electron 等应用程序，而且由于能够在 M1 上运行 iPad/iOS 的应用程序，对于 Electron 的需求会更小，因为像 Authy 等应用程序能启动更快。
我很期待苹果芯片的 16 寸 MacBook Pro ，但原因只不过是我希望更大的屏幕。但至少目前来看，M1 芯片的 13 寸 MacBook Pro 已经非常好了。
评论2
个人意见，我很期待升级版。很高兴能看到有人证实 16GB 内存太小。很多人说 16GB 内存足够，但作为开发人员，为了以后考虑，我真希望能有 64GB 内存。我的 MacBook Pro 已有 8 岁高龄了，但依然拥有 16GB 内存。
评论3
不知道为什么这么多人担心开发人员会被锁定到某个系统上。我有很多其他电脑，Linux、BSD 以及 Windows 等到， 所以不太可能被锁定。我更担心的是苹果会控制平台。并不是说 M1 平台，而是担心其他平台会被苹果以某种形控制。如果苹果尝试任何出格的事情，我肯定会放弃使用苹果。
