对于 M1 MacBook 的一些看法
介于知乎、bilibili 等中文社区上关于 M1 MacBook 有大量“好为人师、人云亦云”、“简单剪辑 = 生产力”的误导言论,加上自己 3 年的 Intel Mac 和 1 个月的 Apple Slicon Mac 的使用经验,我觉得从开发:包括前端、后端和客户端(JVM 生态,NPM 生态,iOS 生态)的角度总结一下 M1 芯片的优点和不足是一件很有必要的事情。
带 PD 供电的扩展坞烧主板
关于烧主板的帖子在早期引起了广泛讨论,似乎问题在于 M1 Macbook 的硬件设计缺少 Intel 南桥上的一颗负责稳定电压的芯片,但烧主板仅限于很早之前的帖子。求证 Apple “天才” 客服得知,此问题在 macOS Big Sur 的一次更新中已经通过软件规避,询问京东绿联客服保证现在不存在烧主板的事情。况且,新机器烧主板,在保修期内免费换和维修的。如果实在想安心,牺牲一个 USB-4 的口充电,使用不带 PD 供电的扩展坞即可。
性能无敌 or 性能垃圾
前者往往存在于一些没有任何计算机基础的“剪辑小白”在偶然利用了 M1 协处理器优势的剪辑任务中(比如 4K H265),对比 i9 的 MacBook 夸张的处理速度,觉得“好牛逼”。后者往往存在于一些几乎没有实际使用经验的抱着厚重游戏本或者台式机的只会看 CPU BenchMark 的云评测家或者依赖于老旧架构工业软件的“工科学生”群体,他们要么用 100w 的桌面 16 核心 CPU 来对比一个 20w 不到的 4 大核 + 4 小核 M1,要么把成吨的老旧平台代码(比如 Matlab)通过 Rosetta 转译后对比来试图说明 M1 的“垃圾性能”。实际上,M1 最优秀的是功耗比,在夸张的功耗比下提供了依旧不错的 CPU 性能,这让它在移动笔记本上的表现非常亮眼:长续航 + 高性能 —— 而这在 Windows x86 平台几乎是不可能做到的事情:要么牺牲性能,要么牺牲续航(注意,键盘手们通常会在牺牲性能的情况下和 M1 比续航,得出续航不弱的结论,在牺牲续航的情况下比性能,得出性能不差的结论)。如果是不计功耗的任务,我也更愿意使用 x86 平台跑 Linux 而非选择售价高昂且 I/O 扩展性差的 Mac Studio。而对于 macOS 和 aarch 架构不合适的软件生态问题,与其跑 Rosetta,还不如买一台 Windows 笔记本更适合。
对于 Xcode 下的 Swift 代码提示、编译速度,提升了不只一个层次,有此需求果断抛弃 Intel x86 吧。需要注意,Xcode 占用的磁盘空间、内存和耗电都是很恐怖的,尤其是 lldb-server 这个进程。
对于 IDEA 下的 JVM 平台开发,比如 Java、Scala、Kotlin、Clojure,IDEA 和 JVM 的启动速度略微有所提升,但差距不大,对于 Clojure 这类动态语言可以说是几乎毫无区别。对于 Maven 编译,得益于 CPU 性能和统一内存带宽,基本上比 6 核 12 线程的桌面 CPU 和 DDR4 DRAM + NVMe SSD 快了大概 2 - 4 倍左右。
对于 IDEA 下的 JavaScript 生态,速度快感知比较明显,但我觉得重要的原因是 NPM 依赖的解决速度快,即 SSD 和统一内存的速度快,直接受益于 CPU 的部分不少,不过也不多。
8GB vs 16GB
8GB 绝对不够,16GB 对于普通负载可能有点多,最合适的其实是 12GB。看看闲鱼和京东拍拍上什么容量的二手 MacBook 出的最多,什么值得买和拼多多上什么型号的 MacBook 打骨折最厉害就知道了。除了极其特殊的需求,需要使用高速 CPU 能力、内存速度而不依赖内存大小的(即间歇性的只运行单个应用:浏览器的话仅限于很少的标签页),我想不出来有购买 8GB 版本的场景。8GB 不仅体现在同时打开多个程序切换变卡,更重要的是对 swap 的使用导致磁盘读写恐怖的增加,SSD 的寿命比 HDD 差很多,而不可更换的硬盘意味着 8GB Macbook 的使用寿命比更大内存的版本也短了很多。
此外,16GB 的优势还体现在:对于打开又关闭的应用,其可执行程序会缓存在内存中,下次使用时启动速度更快。典型的就是 Word 这类软件,冷启动第一次很慢,但强制退出后再启动会很快。而 8GB 版本没有更多的冗余内存,第一次启动慢,后来启动次次都慢。
外接 1080P 显示器模糊问题
这可能是传播范围最广的“谣言”了,说 Macbook 外接 1080P 显示器会很模糊,且在 M1 芯片上没有很好的办法改善。“谣言”用括号括起来的原因是,这是事实,而用括号括起来的原因是,我认为 Apple 压根都没想着让你这样用。人们人云亦云的发明了一系列的把 Macbook 外接的方案,包括且不限于:① 把 Macbook 用支架垫高;② 外接显示器作为第二显示器;③使用 Macbook 的键盘和触摸板工作。在这样的工作流中,需要解决两个问题:其一:Macbook 合上屏幕后,外接显示器会自动休眠,因此诞生了一些自作聪明的软件,比如“安非他命”等任务栏工具让 Macbook 保持唤醒,合盖不休眠。但有没有一种可能,在 Apple 的理念中,通过扩展坞外接显示器是单独使用显示器的,而不是将其作为第二显示器使用的。因为 macOS 内置了这样的支持:在任何情况下合盖状态的 MacBook 外接显示器,都可以通过外接鼠标或键盘唤醒此外接显示器工作,就像一台台式机一样,不需要任何的设置。我想不出任何的理由需要把 Macbook 作为主屏幕,另外接一块副屏幕,然后使用 Macbook 的键盘和鼠标,如果这样需要输入,那么势必 Macbook 会在你的正前方,而副显示器则始终扮演者一个“边缘”的角色。为什么有人需要一块大屏幕扮演“边缘”角色,而小屏幕扮演“核心”角色的呢?对于这种需求,Apple 其实有很好的处理方案:使用 iPad 的 Sidecar 和连续互通:iPad 的小屏幕正好扮演“边缘”角色。
所以,停止这种愚蠢的行为,并且在不需要移动性的时候,直接将 Macbook 合盖作为一台“主机”,通过扩展坞输出视频信号连接到外部显示器,通过拓展坞连接外部键盘和鼠标控制设备 —— 毕竟这才是拓展坞真正称之为“坞”的地方。如果真的需要更多的工作空间,换一台 4K 显示器 而不是使用别扭的两台不合逻辑的大小屏幕,反之,一台 28 英寸的外接 1080P 的主显示器的生产力不仅不会像作为第二显示器那样模糊(起码其和直接作为主显示器的 Mac Mini 一样清晰),并且也足够使用。
对于 macOS 的一些迷思
macOS 不带 APNs,不像 iOS 一样退出应用后还可以接收通知。
macOS 应用的启动速度并不快,甚至大部分时候比同等性能的 Windows 本更慢,如果你觉得快,那么唯一的可能就是应用的可执行代码被提前缓存了。
macOS 或者说类 Unix 下的代码编译任务确实比 Windows 更出色,包括且不限于 Windows 下的 WSL(受限于拉胯的 I/O 性能)。
对于 macBook 的一些迷思
触控板真的好用,我的日常使用中,除了 Figma 设计作图需要鼠标外,其余任务:编程、打字、摸鱼和划水都不需要鼠标。我个人觉得,这块触控板最大的优点在于够大,够精准,手势支持完备,以至于在 Windows 本上很多需要多次移动触摸板完成的任务在 Macbook 上只需要一次带精准惯性的移动,多个位置点击即可完成。这个体验我觉得比 ThinkPad 上的小红点要好很多(后者也可以在单程精准完成点击,但费手指,且缺乏手势支持)。
续航很好,但也没那么好。Xcode 编译、代码提示、模拟器和 Canvas 运行,甚至 Firefox 都是耗电大户,能坚持四五个小时已经很不错了。