爲了換上 Apple Silicon 的「芯」，蘋果都做了什麼
蘋果要換「芯」早就不是新聞，但當 Tim Cook 正式宣佈 Apple Silicon 的那一刻，彷彿以 Apple Park 的環形大樓爲震央，全世界科技圈發生了一次地震。
「Apple Silicon 地震」不僅震動了所有關注蘋果的人，更是一場對蘋果團隊自身的挑戰。Mac 換「芯」之後，原來的應用還能不能正常運行？從 iOS 到 macOS，應用能帶給用戶一致的良好體驗嗎？
爲了這次換「芯」手術，蘋果做好準備了嗎？
從 Intel 到 Apple Silicon，應用適配的挑戰
換「芯」之後的第一項挑戰，就是 Mac 應用對 Apple Silicon 的適配。
對於 Windows 與 macOS 之間的應用不能通用，可能比較容易理解，畢竟兩類應用從編程語言、源代碼到系統都完全不同。但同樣是 Big Sur 系統，應用也都是基於 Swift 語言（或 Object-C），爲什麼搭載 Apple Silicon 的 Mac，就不能直接運行現有的 macOS 應用呢？
問題就出在「應用編譯」這一步。
開發者使用高級語言（例如 Swift、Java 或者 C++）編寫應用，形成 源代碼（Source code) ，但 CPU 不能直接識別源代碼，只能識別二進制的 機器代碼（Machine code） 組成的指令。所以開發者需要藉助編譯器，將源代碼轉換成機器代碼。這個過程就像是建築師（開發者）完成了設計（源代碼），但工人們（CPU）沒法看着漂亮的渲染圖就開始施工，於是還需要技術人員，將建築師的設計轉換爲工人能理解施工圖紙（機器代碼），在上面很多固定格式的標註（ x86_64 指令 ），這就是編譯的作用。
不過 Apple Silicon 替換 Intel 芯片後，相當於換了一批建築工人。很不巧，這羣建築工人讀不懂圖紙上的 x86_64 指令，他們只認識一種叫 arm64 指令 。所以即使建築師、設計圖紙都相同，但是建築工人是沒法照着爲上一個團隊準備的施工圖紙開工。
既然有兩個施工團隊，那就讓技術人員在做施工圖紙的時候，一次性標註兩套圖紙，再打包到一起。到時候無論是哪個施工團隊，找到自己能讀懂的那一套不就可以開工了？
Universal 2 正是照着這個思路實現的。在 Xcode 12 中，開發者可以選擇同時爲 Intel 芯片和 Apple Silicon 編譯應用，並且會將編譯後得到的兩套可執行代碼文件，打包成一個 Universal 應用。由於包含了兩套文件，Universal 應用的體積自然也會變大。不過之後無論是在裝有 Intel 芯片還是 Apple Silicon 的 Mac，Universal 應用都能順利運行。
然而這項技術也不能完美地解決 Apple Silicon 帶來的應用適配問題。
雖然在 Xcode 中只需要將應用選爲 Universal 就可以開始編譯，但如果你有基於某些 CPU 特性的代碼，可能需要開發者做相應的修改 1 。其次如果開發者使用了第三方（非蘋果官方提供）的代碼庫，那就必須等到第三方代碼庫的開發者提供 Universal 版本，才能將自己的應用也編譯爲 Universal 版本。如果應用是支持插件的，插件也必須爲 Appli Silicon 重新編譯 2 。
所以對於開發者來說，Universal 2 並不是一棵忘憂草，想要保證應用能達到之前一樣的體驗和性能，還是需要付出額外的工作。
不僅如此，Universal 2 最大的問題，是它不支持第三方框架開發的應用。
「框架」是提供給開發者的 一套可重複利用的組件 ，便於開發者快速完成應用開發功能。就像有人給建築師提供了一套模版圖紙，讓他不用從頭開始設計建築。蘋果官方給 macOS 提供了 AppKit，但同時也允許開發者使用其他團隊提供的框架，例如 VS Code 所用的 Electron 和 WPS 使用的 Qt 框架。
爲了解決第三方框架應用的適配問題，蘋果準備了 Rosetta 2 。
Rosetta 2 的思路和 Universal 2 不同，雖然我不能重新做一套帶有 arm64 指令的標註，但是我給施工團隊發一套字典，讓他們自己查字典，將 x86_64 指令轉換成 arm64 指令，這不就可以開工了嗎？
在用戶從 Mac App Store 下載、通過安裝包安裝或者第一次啓動時，Rosetta 2 就會啓動，開始將應用所使用到的指令進行翻譯，最終形成一本字典（官方稱之爲 「Stored translation」）。在應用運行時，發出的 x86_64 指令就會先經過 Rosetta 2 的翻譯，變成 Apple Silicon 能理解的指令。整個過程都是會在後臺進行，對於用戶來說，就像一切如常。
Rosetta 2 可以讓用戶在 Apple Silicon 的 Mac 上運行原來的應用，但性能和運行速度就無法保證和在 Intel 芯片的 Mac 上一樣了。根據開發者的測試，Geekbench 5 通過 Rosetta 2 運行在裝有 A12Z 芯片的 Apple Mac Mini Developer Transition Kit 中，單核跑分比 A12Z 在 iPad Pro 12.9 中低了大約 25% 。儘管兩者的硬件環境以及芯片頻率等因素都不相同，這個跑分對比並不嚴謹，但 Rosetta 2 對於應用運行效率有不小影響這一點，是可以得出肯定結論的。
值得注意的是，即使是針對 Apple Silicon 編譯過的應用，用戶還是可以自己以 Rosetta 2 來運行。某些應用本體更新了 arm64 版本，但插件沒有更新的時候，用戶就可以選擇以 Rosetta 2 來啓動，保證之前的工作流不受影響。
最後，即使是 Rosetta 2 也不保證能完美運行所有應用，官方文檔中明確指出，「Kernel extensions」和針對 x86_64 的虛擬機應用將無法通過 Rosetta 2 運行，只能期待開發者會推出 arm64 版本的應用。
不過作爲消費者的我們不必太過擔心，Universal 2 和 Rosetta 2 雖然不能完全解決應用適配問題，但它倆更重要的使命是 給開發者和用戶爭取時間 。從上一次 PowerPC 到 Intel 芯片的遷移歷史來看，蘋果從宣佈遷移到最終終止對 PowerPC 芯片的系統更新，足足有 四年時間 ，這四年時間一方面讓使用 PowerPC 的 Mac 用戶得以發揮設備的價值，另一方面給開發者足夠時間去適配自己的應用，由此最大程度降低了過渡期對開發者和用戶的影響。
有了之前的經歷，再加上蘋果目前在科技圈如日中天的影響力，給了開發者很大的信心。奇點微博、One Switch 的開發者圖拉鼎就說道：
（芯片架構的轉變）對普通用戶來說，可能不熟悉。但對有點年份的開發者來說，這件事已經發生過一次了。所以開發者們普遍都比較積極和充滿信心。
從 iOS 到 macOS，應用如何遷移
Apple Silicon 帶來的重大機遇，就是 iOS 和 iPadOS 的應用可以原生地運行在 macOS 中了。
對蘋果持續有關注的讀者，可能會指出來，去年 WWDC 2019 的時候，就宣佈 macOS Mojave 能運行 iPadOS 上的應用了，這次只不過加上了 iOS，並沒有實質性的改變。
其實雖然結果都是 macOS 上運行移動設備上的應用，其實這兩次有着本質的不同。
去年蘋果推出的是 Mac Catalyst 計劃，引導開發者將 iPadOS 上的應用移植到 macOS 中。在這個過程中，開發者 需要重新編譯應用 ，編譯後的應用是可以 運行在 Intel 芯片的 Mac 中的（當然有 arm64 的編譯版本，也可以運行在 Apple Silicon）。而今年蘋果宣佈的計劃中，iOS 應用 不需要 由開發重新編譯，就可以直接從 Mac App Store 中下載運行，但只有 裝載 Apple Silicon 的 Mac 能享受到這項福利。
瞭解了兩者的不同，可能會產生一個疑惑：既然經過編譯可以讓 iPadOS 應用運行在 Intel 芯片上，爲什麼蘋果不提供工具，讓開發者可以把 iOS 應用也編譯一下，也運行在 Intel 芯片的 MacBook 上呢？蘋果這麼做，是不是爲了特意給裝 Apple Silicon 的 Mac 增加賣點呢？
想了解背後的緣由，我們還得回到去年 WWDC 上，看看 Mac Catalyst 計劃做了什麼。
想讓一直跑在 A 系列芯片的 iOS 應用運行在 Intel 芯片的 Mac 上，要將應用從 arm64 編譯到 x86_64 版本，這恰好和從 Intel 遷移到 Apple Silicon 的過程相反。但這麼多年阻止 iOS 登陸 macOS 還有更深的原因：兩類應用的開發框架不同。雖然都是蘋果的原生開發框架，但 iOS 應用使用的是 UIKit，和 AppKit 完全不同。
而 Mac Catalyst 所做的，是確保 AppKit 和 UIKit 所使用一樣的底層技術，並移植一部分 UIKit 組件在到 macOS 中，這樣也就實現了在 macOS 中運行 iPadOS 應用的目的。而今年 iOS 應用能登陸 macOS，同樣是依靠 UIKit 在 macOS 中的移植，而且比 Mac Catalyst 更方便的是，因爲 iOS 應用本身就是爲 A 系列芯片編譯的，在 Apple Silicon 上都不需要開發者重新編譯，只需要開發者在後臺開啓跨平臺選項，用戶就能在 Mac App Store 中搜索到 iOS 應用。
將這兩屆 WWDC 串聯起來看，爲了實現系統大一統， macOS 與 iOS 在底層技術和交互層面上不斷融合，其中開發框架自然也會開放融合， Mac Catalyst 項目只是 UIKit 與 AppKit 在融合過程中誕生出的副產物 。去年就提供給開發者，而不是等到今年，其實是給開發者多一年時間，去嘗試同時適用全平臺的交互與開發範式。
如果明白了這一點，站在蘋果的角度，不難看出投入人力物力實現 iOS 應用在 Intel 芯片的運行，其實沒有太大意義，畢竟兩年後所有的 Mac 產品線都會是 Apple Silicon。
更重要的是從開發者的角度出發，Mac Catalyst 其實並 沒有明顯地吸引 iPadOS 應用開發者投入精力 ，因爲直接移植的應用品質不佳，並不能吸引消費者付費。正如國外知名設計團隊 Iconfactory 在 《What to Expect From Marzipan》 一文中說道：
如果做一個 Mac 應用只是撥開開關的功夫，客戶爲什麼要爲它付費呢？
所以開發者也不買賬 Mac Catalyst，由此一來，蘋果團隊自然會全力投入到 macOS 與 iOS 在 Apple Silicon 上的融合，而不是開倒車，去解決 iOS 應用在 Intel 芯片上運行的的事情。
當然，macOS 與 iOS 的系統融合是一個漫長的過程，iOS 應用目前也只是能運行在 macOS 上而已。從採用 Mac Catalyst 的應用表現來看，iOS 應用運行在 macOS 上，會因爲硬件差別、UI 差別與系統差別出現不少體驗上的問題。
One more thing
自從 2015 發佈 Apple Music 之後，蘋果似乎已經忘記了讓觀衆腎上腺素飆升的「One more thing」環節，這次 Apple Silicon 的宣佈，雖然 Tim Cook 沒有念出這句「咒語」，但是達到了相同的效果。
對於我來說，讓我振奮的不僅是 Apple Silicon 出現後，Mac 系列可能會出現的巨大變化，更是折服於蘋果團隊爲實現目標所做出的精心準備。爲了實現橫跨多種類的大一統系統，微軟選擇直接將 Windows 通用於不同設備，谷歌選擇從 Chrome OS 和 Android 兩條路線嘗試。而蘋果選擇的是先硬件、再軟件，先底層、再 UI 的路線，一步一個腳印，讓目標逐漸變爲了現實。
其實技術路線本身並沒有對錯優劣，但相比各種天馬行空的技術設想，工程師嘔心瀝血做出的成果，更讓我爲之動容。
編注：感謝 @圖拉鼎 對本文提供的建議。
關聯閱讀：
> 下載少數派客戶端、關注少數派公衆號，第一時間瞭解 WWDC 2020 資訊 :newspaper:
> 特惠、好用的硬件產品，盡在 少數派 sspai 官方店鋪
