作者：面包板博主 歐陽洋蔥

此前，蘋果CEO庫克在WWDC 2020上宣布，未來Mac電腦將改采自主研發的ARM架構處理器“Apple Silicon”，而非英特爾。事實上，兩家的合作始于2005年，當時蘋果創始人喬布斯在WWDC宣布放棄PowerPC處理器計劃，轉身就牽手英特爾。這一決定象征著蘋果與英特爾在Mac電腦業務合作關系即將走向“終結”。那么，蘋果Mac采用自研處理器，可能遇到什么問題呢？

此前，蘋果CEO庫克在WWDC 2020上宣布，未來Mac電腦將改采自主研發的ARM架構處理器“Apple Silicon”，而非英特爾。

事實上，兩家的合作始于2005年，當時蘋果創始人喬布斯在WWDC宣布放棄PowerPC處理器計劃，轉身就牽手英特爾。這一決定象征著蘋果與英特爾在Mac電腦業務合作關系即將走向“終結”。

那么，蘋果Mac采用自研處理器，可能遇到什么問題呢？來自面包板社區的明星博主——歐陽洋蔥在今年5月，在WWDC 2020之前就這一角度發表了自己的看法。

實際上，有關 Mac 系列計算機要開始采用 Arm 處理器的傳言似乎是從2010年就開始的，那會兒蘋果也才剛剛開始做 iPhone 的 SoC。這一傳言就10年過去了，起碼今年前不久才更新的MacBook Air都還在用 Intel 的處理器。

想起來以蘋果的“慣例”，對自家生態的管控，恨不得從硬件到軟件由內到外全部一手包辦。這樣一家公司，在如今有能力自己設計處理器，為何還要受制于Intel？況且Mac設備本身的開發周期，還面臨與 Intel 處理器迭代撞期的尷尬，導致Mac經常無法用上 Intel 最新的處理器。如果用自家的 A 系列 SoC，豈不是很美的一件事情嗎？

這次的傳言看起來格外靠譜，彭博社報道稱，2021 年采用 Arm 處理器的 Mac 電腦就要問世了。彭博社線人消息稱，Mac 要搭載的處理器將比 iPhone 和 iPad 之上的都更快（好像是廢話）。“蘋果準備在明年，至少推出一款采用自家芯片的 Mac.”“臺積電將會負責制造新款的 Mac 芯片，基于 5nm 制造技術。”

“首批 Mac 處理器將有 8 個核心，核心代號 Firestorm，其中有 4 個是節能核心——內部代號 Icestorm。蘋果針對未來的 Mac 處理器，還計劃探索超過 12 個核心的設計。”值得一提的是，傳言中的 Mac 處理器也是以 SoC 的形態出現，其上至少包含了 CPU、GPU。［1］

這件事情的可行性當然是有的，只是在具體實施上會遇到不少問題。如果說 macOS 轉往 Arm 平臺真的那么容易，蘋果估計早就干這事兒了。而且事實上，微軟這兩年正在做這件事情，但在具體的方向上有些小差異。在這篇文章里，我們做一些簡單的分享，雖然無法得出結論，也可與各位做探討。

多插一句，一般來說，我首發在面包板的文章籌備周期比較短，而且相對來說內容更加個人化、娛樂化。與電子工程專輯或者其他平臺發布的文章相較，會顯得沒有那么正式和考究。另外，這篇文章主要參照的是維基百科，我不想去翻以前蘋果的開發者文檔了——基于維基百科的不可靠性，以下內容可能有部分是存在事實錯誤的；另外，我也不搞軟件和系統工程，所以貽笑大方之處還請海涵。

蘋果曾有的兩次遷徙經歷

蘋果的 Mac 產品線與 Intel 的合作是從 2005 年開始的。那一年，Intel 的 CEO 還為蘋果站了臺，與喬布斯一起。次年的 Mac Pro 就開始正式采用 Intel 處理器（Mac OS X 10.4.4 Tiger）。在此之前，Mac 并不是 x86 平臺的擁躉，我記得看電子科技相關雜志，包括當年像臺燈一樣的 iMac，蘋果在宣傳詞中都提到處理器比同時代的 Intel 奔騰快多少倍之類。

在此之前，蘋果就有過兩次在指令集平臺上轉舵的經歷，看起來已經是個老手了。至于為什么要換用其他平臺，這可能和軟硬件更具體的技術問題相關，不過從社會上廣為流傳的資訊來看，都是因為老平臺的效率越來越不濟（就好像如今主流觀點認為 x86 處理器的效率不如 Arm，雖然我不這么看；很多人認定，Mac 轉向 Arm 也算是合情合理）。

從這兩次轉舵，其實可以大致來看一看，這回若從 x86 轉往 Arm，可行性幾何？或者蘋果從前的轉舵經驗，是否有足夠的參考價值。一般來說，從一個硬件平臺轉往另一個硬件平臺，經常意味著拋棄以前的開發者，以及拋棄以前的用戶。因為轉往新的硬件平臺，總是意味著舊有軟件將停止更新，且舊的開發生態徹底終結，未來的新軟件也無法安裝在舊平臺上。當然系統制造商總是會采用一些折中的兼容性方案來實現過渡。而“過渡”的平滑與否，真的就要看廠商的水平。

1994-1996 年前后，蘋果的 Mac 電腦從更早摩托羅拉的 68k 系列芯片轉往 PowerPC 處理器（參與 PowerPC 聯合開發的應該有摩托羅拉、蘋果和 IBM）。這個轉換過程持續了幾年，當時蘋果的過渡方案是所謂的 Mac OS Classic（Mac OS Classic 也就是經典 Mac OS，指代了 Mac OS X 之前的 Mac 操作系統），可以同時跑在 68k 和 PowerPC 平臺下。有個詞叫 fat binary，形容某一種應用，占用更多的存儲空間（所以才 fat 吧。..），但混合了多種指令集的原生代碼支持——也就能夠在多種類型的處理器上跑。蘋果當時搞的這種 fat binary，就是令開發者將 68k 編譯版本和 PowerPC 編譯版本打包到同一個執行程序中。

另一方面，當時蘋果引入了一種較低層級的模擬方案。系統中有一個 Mac OS nanokernal 內核，這個內核建立在 Macintosh ROM 里面（Macintosh ROM 是最早 Macintosh 電腦中的一個固化在主板上的芯片，用于電腦啟動時的初始化）。而這個 ROM 內部有個叫做 Macintosh Toolbox 的東西，類似于 BIOS 這種角色。而 Mac OS nanokernal 為 Toolbox 提供 68k 處理器的模擬環境。

Mac OS nanokernal 在電腦啟動時加載，內存里開辟一個 PowerPC 內核空間加載模擬器。隨后模擬器繼續加載 Toolbox 對系統硬件初始化，隨后的操作和 68k 時代基本上一樣。這時期 PowerPC 設備的內核，實際上就是運行在 68k 模擬器里的 Toolbox。

nanokernal 的主要工作就是讓現有 68k 版本的操作系統跑在新的 PowerPC 硬件下，如此系統普通狀態就能跑 68k 代碼。在必要的情況下可以轉回到 PowerPC 模式下，基于中斷處理程序（interrupt handler）實現，并將虛擬內存系統映射到 PowerPC 硬件上。不過維基百科說，這個過程，也可能只是由跑在用戶態的模擬器去處理的。

iMac G4，采用 PowerPC G4 處理器

無論如何，這都是個看起來十分簡單，而且還非常低效的方案（原生的 PowerPC 性能似乎很難發揮）；不過好像也很有效，Mac OS nanokernal 的 68k 模擬器也就為舊軟件提供了這種低層級的兼容性。當時的模擬器提供的運行環境，和 Macintosh Centris 610（處理器具體型號為摩托羅拉 68LC040）最為接近。

早期版本的 68k 模擬器會解碼每一條指令，并立即執行一系列對應的 PowerPC 指令，實現這種模擬。后續的 PCI PowerMac（PCI 總線的 PowerPC）中的動態重編譯模擬器（dynamic recompilation）則對性能做了提升：將代碼常見的部分，“重編譯”為更快的、PowerPC 原生序列——且在本地做了緩存（locally cached）。也就是說這種模擬器能夠識別一些 680x0 代碼序列，并且直接跑已經緩存過的 PowerPC 代碼，也就避免了重新轉譯。對于一般的開發者來說，這種轉換也就顯得比較無痛，因為模擬器是自動開始和結束的。

最初的 Mac OS nanokernal 是相當簡單的，這就是個單任務系統，把大部分工作交給操作系統 68k 版本的模擬器去跑。有興趣的同學，可以去了解一下當年的 Mac OS Classic，它似乎還稱不上一個現代化的操作系統，連內存保護都沒有；上層的應用程序直接跑在 Toolbox 上，除了獲取系統提供的功能和資源，還能直接操作硬件和內存。這個版本的 nanokernal 似乎是到 Mac OS 8.5 終結的。［2］［3］［4］［5］

第二版 Mac OS nanokernal 也算是越來越像樣了，開始支持多任務多處理器、消息傳遞，可以算是微內核了；內核存在于受保護的內存空間中，并在用戶態下執行設備驅動。這是題外話了。

Mac OS Classic 時代的操作系統和個人電腦還是相當的粗放和不講究，而且層級結構也比今天要簡單得多。而另一方面，其實也不難發現，即便是當年蘋果電腦用戶基數不多的時代，生態搬遷都需要付出這般代價；每一次平臺搬遷，實際上都需要付出代價，由上至下。

還有一點值得一提，后來 Mac OS X（PowerPC 版）內部有個名為 Classic 的環境，這是一個抽象層——絕大部分 Mac OS 9 應用都依托于 Classic 環境跑在 Mac OS X 上。從 10.5 美洲豹系統開始，就已經去掉了 Classic 環境（即更晚的 x86 平臺也就不再對 Classic 做出支持）。具體來說，Classic 環境包含了一個 Mac OS 9 系統文件夾，以及一個 New World ROM 文件（前文提到的早期 Macintosh ROM 算是 Old World ROM；而 New World ROM 時期，早期 Macintosh ROM 不復存在，原本的 Toolbox 成為一個文件存在硬盤上）。這里的 Classic 可以認為是 Mac OS X 之下的一個模擬子系統。［6］

從 PowerPC 轉往 Intel x86

2005 年，喬布斯表示蘋果對于 IBM 的 PowerPC 開發進度非常失望（這集我看過！去年的 Intel 基帶事件似乎也是這么演的），而 Intel 顯然可以滿足蘋果的需求。當年喬布斯大談每瓦性能，實際上也就是能效比，這似乎也是如今在輿論上，x86 處理器陷入不利的原因。喬布斯在 WWDC 大會上宣稱，Mac OS X 的每個版本都“秘密地”針對 Intel 處理器做了開發和編譯。所以現在的 macOS 有沒有“秘密地”針對 Arm 做開發和編譯？

當年 Intel 為蘋果站臺的名場面

這次的兼容性解決方案，是一種名為 Rosetta 的指令解釋器，這是一個動態二進制轉譯器（dynamic binary translator）。蘋果在宣傳中，把 Rosetta 稱作是“the most amazing software you‘ll never see”。蘋果說對于舊版 PowerPC 應用來說，那些重交互、但算力需求比較低的應用，非常適用于 Rosetta（比如文字處理）；而算力要求比較高的（比如 AutoCAD、Photoshop）可能就會悲劇（很像 Windows on Arm？？？）；一些“專業級”的媒體應用，比如 Final Cut Pro、Logic Pro，則完全不支持。

Rosetta 所處的層級比 68k 模擬器要高，是個“用戶級”的程序，只能監聽和模擬用戶級代碼。這可能和蘋果擔心安全問題有關，而且畢竟 Rosetta 推出的時間，操作系統也比 68k 模擬器年代要成熟很多了。所以 Rosetta 不支持的環境和狀況有很多，也包括了不支持轉譯 PowerPC G5 指令。

蘋果后來發布的 Xcode，有針對 Intel 與 PowerPC 的 Universal Binary，就跟前文提到的 fat binary 類似——這樣一來，當時面對平臺遷徙的開發者，在面對 Mac 應用開發時，針對基數也算多的 PowerPC 用戶，不會不知該選 PowerPC 還是 x86，因為兩個都可以要（微軟 WinRT 借鑒對象？）。

不過 Resotta 的確在過渡平滑性上要差一些。針對 Mac OS 平臺下不同類型的應用，開發者使用 Rosetta 還是需要做一些基本工作的，比如 Cocoa 應用需要重新編譯、檢查字節順序問題；Carbon 應用則要求做小幅調整；而使用 Metrowerks Codewarrior 套裝開發的應用則需要做較大程度的修改（Codewarrior 是一個 IDE，這個 IDE 的早期版本就針對 68k 和 PowerPC Macintosh，當年蘋果轉往 PowerPC 時，CodeWarrior 成為 Mac 實際上的標準開發系統，快速取代了蘋果自己的 Macintosh Programmer’s Workshop）。［7］［8］

就最終的成果來看，Mac 的這第二次轉舵還是很成功的。實際上即便到 2009 年，Mac OS X 10.6 雪豹時期，蘋果已經完全不再支持 PowerPC，依然有不少開發者通過 Universal Binary 對這一平臺做出后續數年的支持——這還是能夠從側標反映蘋果在兼容性方案上的不錯表現。

但我覺得，這次的成功主要并不來源于蘋果在兼容性工作上的成功，而在于 Mac 轉向 x86 本身就是一次從冷門到熱門，以及低效向高效的轉變，因為 x86 平臺原本就相當成功。Intel 這些年起碼在桌面 CPU 的效率提升上是獨占鰲頭的。另外要知道 PC 市場的絕對大頭：Windows 就一直在用 x86。而 Mac 轉往 x86，則很大程度上意味著 Mac 設備從此以后就可以名正言順地安裝 Windows 系統了。蘋果自 2006 年起引入的 Boot Camp 還對 Windows 的安裝做出了原生支持。

也是從這個時候開始，大批量的人在星巴克用 MacBook 裝逼（以及運行的卻是 Windows 系統）才變得可行。或者說至少買一臺 Mac，就不用放棄 Windows——而且同一時間還有大量效率較高的虛擬程序可以跑 Windows 及對應的應用。我覺得無論如何，這都是 x86 平臺的 Mac 得以大獲成功的原因。

而且也是自此之后，許多軟件大牌企業才開始將 Mac 生態納入重要考慮范疇，甚至優先于 Windows 做軟件開發。相較而言，以前的那點生態損失根本就不算什么；和當年 68k -》 PowerPC 的轉變相比，這次的轉變有著天然的生態優勢。當然，在 x86 成為 Mac 的選擇以后，Mac 設備自身的設計變遷，為行業樹立標桿也是重要原因，如 2008 年推出的 MacBook Air；另外，現在基于 web 的應用越來越多，很多人對瀏覽器的依賴已經大過操作系統本身，這讓平臺選擇進一步脫耦。

所以，我覺得 Mac 在轉向 x86 平臺時的成功，更多的是時勢造就，甚至別家生態使然；亦是蘋果在電子科技發展史上的一次識時務之舉；且以當年 Mac 的體量，更不存在尾大不掉的問題。

從 x86 轉向 Arm？Arm 效率真的高于 x86 嗎？

我們近兩年聽到最多有關 Mac 要從 x86 轉向 Arm 的原因，好像并不是蘋果要加大生態掌控力（這是我覺得蘋果可能決策轉向的最主要原因），而是 x86 處理器的效率比 Arm 差很多——這方面的報道也還不少。就相對直觀的消費用戶體驗來看，這一點似乎還是有足夠的論據的。這些年智能手機、平板產品的性能提升速度如此之快，感覺跟 PC 是不是已經差不多了？

蘋果前些年發布 iPad Pro，并將其定位于生產力工具的時候，就不忘在發布會上黑現在的 PC，聲稱 iPad Pro 所用的 Ax 處理器比市面上 90% 的 PC 還要快。雖然也不知道這種對比是如何產生此等量化數據的。加上還有 GeekBench 這種蘋果專用跑分工具（誤）助陣，像 A13 這種芯片的跑分成績比 AMD Ryzen 3850X 還要高；單核平均功耗才 7、8W 的 A12X，單核跑分和 TDP 95W 的 Intel Core i7-8700K 差不多，多核成績則比 8600K 還要高。

這么說來，Arm 和蘋果掌握的黑科技，已經達成體積小如此之多、功耗少如此之多的情況下，性能達成與 x86 平臺幾乎齊頭并進的水準啦？我前倆月就聽有人在社區大談 RISC 相比 CISC 有多大優勢，并以此得出 iPad 性能為何比如今 PC 強那么多的結論，言下之意是你們根本就不懂指令、現代半導體技術的神速發展。Intel 估計應該被釘在歷史的恥辱柱上。

有關 GeekBench 娛樂工具跑分相近的問題，其實我們必須承認一個大前提：當代處理器微架構優化，能用上的技術基本上都用上了，前十幾年的發展，什么流水線、分支預測、亂序執行、多級緩存、超線程、時間空間并發之類亂七八糟的，及這些技術本身的反復優化，外加制程工藝進化，CPU 性能總能有“質”的飛躍。但如今，CPU 單核性能提升已經十分緩慢，不僅是制程工藝步進緩慢甚而停滯，還在于能用的優化技術都已經用上了。當然我們不能排除未來還有什么黑科技出現，但至少就這兩年的情況來看，新貨已經鮮見了，不似當年某種新技術一出立刻造成轟動。

所以雖然 Zen 2 如此神奇，而且還被我們吹得神乎其神，但實際上其單核性能也就那么回事，拼死了也就比同代 Intel 10nm 的十代酷睿強一丟丟——當然其 CCX 架構讓 Zen 2 堆核更容易了，臺積電的 7nm 也的確給力。

扯遠了，上面這兩段是為了表明，Arm 即便作為低功耗領域的主力架構，這些年的發展致其單核心性能可與 x86 比肩也并不稀罕。不過那么大的功耗差距，卻可達成相似 GeekBench 跑分又是怎么回事呢？這個問題，我在之前探討 Surface Pro 時就提到過：不考慮散熱系統的跑分成績都是在耍流氓，尤其是 GeekBench 這種短時跑分測試。

我們知道蘋果 Ax 系列 SoC 瞬時突發性能還是比較強的，包括 GPU，但一旦考察持續性能，則會有一個較大幅度的折扣，因為畢竟手機這么小的體積，而且就靠那點被動散熱面積，很難做到長時間的性能發揮。有關這個問題可參考我之前寫的兩篇文章［9］［10］。我們常戲謔說 GeekBench 是 AppleBench，一方面原因在于其中的某些測試項，在 Ax 系列 CPU 中有專門硬件單元做計算，而 x86 很多時候只能依靠通用計算單元來解決，解題效率會略低（這部分內容各位可以去自行研究，早年比較典型的是 AES 加密單元——A 系列處理器就有專用單元，所以這類項目的跑分成績可以很高，現在可能有差別）；另一方面就在 GeekBench 整個測試周期很短，那么系統真正的綜合性能其實是難以體現的。

知乎上有高人給出了 Arm 是否真的比 x86 更省電的理論分析，有興趣的可以去看一看［11］。很多人對 x86 留下高功耗印象的原因，其實是平臺（以及使用場景）差異造成的，PC 的處理器 TDP 在設定上就很高，而這種相比移動設備高得多的參考功耗，很大程度上就源于前面我說到的 PC 要求在一個較長時間內持續高性能，而不只是簡單的瞬時突發性能。另一方面還在于，Arm 指令集的處理器普遍采用大小核設計，小核心是專用于低功耗場景的（而且這種小核心現在看來似乎也越來越有必要）——而直到前一陣，Intel 才表示準備要搞這種大小核設計。

當然這也是因為 PC 的具體使用場景，以往并沒有多少需要像手機那樣超低功耗狀態的應用，或者這種必要性并不大（雖然現在也逐漸開始有這種需求）；而 Arm 平臺的移動設備多用電池做電源，本身也需要對功耗做限制。

所以 x86 能效比低于 Arm 的這種印象，大抵上是兩者使用場景的常年差別造成的。能效比怎么樣，要對比的應該是同性能下的功耗情況。恰好 AMD 開始使用臺積電的 7nm 工藝，這也給這種對比有了一個基于類似制造工藝下，同性能（而不單純是同頻）下的功耗情況對比的依據。不過這種對比需要考慮的問題還有很多，比如 x86 平臺的很多 CPU 還有“睿頻”的概念，而 Arm 手機和移動平臺 CPU 則沒有；兩者的流水線長度不同等等；而且前面提到，兩者使用場景目前還是有差別，這也是芯片內部專用單元有差異的關鍵。

蘋果 A12 的頻率功耗曲線，來源：AnandTech

從相對直觀的角度來說，隨性能的提升，功耗也在提升，但這兩者的關系并不呈線性；意即如今 Arm 低功耗與性能的關系看起來還挺美好，但如果進一步提升性能，所需付出的功耗代價在達到一個拐點以后，就會出現指數級躥升的狀況——在高性能領域，Arm 現有的移動處理器也未必會有什么出色的表現：這其中，蘋果并未掌握什么黑科技，Intel 也并不存在多大的過錯。（服務器領域和 PC 領域在應用場景上又是不一樣的，這里不討論。）

上面這張圖來自 AnandTech［12］，好像被人援引了無數次。這是蘋果 A12 的頻率功耗相關曲線。AnandTech 認為蘋果做得還是比較出色的，而且在后續幾百 MHz 區間內也相對保守。如果說蘋果期望再把頻率抬高，則按照 A12 的現狀來看，很快就可以在 3GHz 附近讓功耗徹底達到標壓筆記本的水平。

這次的轉舵可能有所不同，看看微軟

上面這個大段落好像說了不少廢話，與本文的主旨關系并不算太大。不過我想表達的是，其實 x86 并不像人們想的那樣不堪，Arm 也不像人們想的那么美好。在不考慮散熱、功耗的情況下，這兩者的性能水平可能正在趨同——這也是 AnandTech 之前評價 A12 接近桌面處理器水平的原因。但就系統和具體應用場景的角度，即便 A12 有這種能力，也不可能發揮到桌面處理器的水準，因為它被功耗與散熱限制了。

就性能來看，蘋果應該是有能力造出 Intel 同等性能的 PC 處理器的，而且 Intel 如今在半導體制程工藝上有落伍的跡象（Intel 前不久才承認到 2021 年之前，工藝技術都將落后于競爭對手［13］）。但在 macOS 的軟件生態和兼容性層面，就又要多花一番心思了。這個過程可能仍然需要數年，而且這次的轉舵還不同于以往。只不過在過去蘋果積累的經驗，這會兒似乎還是可以派上用場。

彭博社的報道提到，可能會有部分 Mac 產品將采用 Arm 處理器。就前期來看，合理的推測是，低性能、低功耗產品線的 MacBook（比如說早前 12 寸的 MacBook）可能會率先采用蘋果自己的 Arm 處理器。但如果真的是這樣，那么也就意味著，Mac 產品系列將有兩種架構、兩種平臺并存，這對開發者來說應該是個災難。蘋果大概需要重啟過去兩次轉平臺時 fat binary 和 Universal Binary 方案——一人開發，倆平臺共享。..

實際上在早年 fat binary 時期，把兩種編譯版本封裝到一起，造成的文件尺寸大，在當時是比較敏感的——因為那會兒 PC 的硬盤容量真的很可憐，所以那一時期還涌現出了為了節省硬盤空間，可剝離不需要編譯版本的工具。現在這已經不算什么大事兒了。

而就當代來看，蘋果實際上有一個更好的參照對象，就是微軟。不過微軟在計劃上看，并不是“轉舵”，而是“擴展”，這里我們可以稍微提一提：即 Windows 不僅要在 x86 平臺上發展，而且要在 Arm 平臺上發展。這個計劃從 Windows RT 操作系統時期就出現了，那時微軟就搞了一個 Windows Runtime，這個運行時之上搭的應用可以同時支持 x86 和 Arm。當時的 Windows Phone 8.1 其實也用上了 Windows Runtime，所以那會兒微軟應用商店的很多 app 都同時支持手機、PC、平板，雖然商店里的應用數量也是少的可憐。

這算是實現微軟“偉大”生態 Universal Windows Platform（UWP）的重要組成部分。UWP 本質上就是為所有 Windows 設備，包括 PC、IoT、平板設備之類，或者說所有 Arm、x86 平臺的 Windows 設備，提供一個通用的 API。UWP 就是一種建立在 Windows Runtime 之上的應用模型。［14］［15］

Windows Runtime 提供的 API 以類庫的形式，為開發者提供 Windows 8 的功能。跑在 Windows Runtime 上的應用實際上是跑在一個沙盒里，需要用戶批準才能訪問一些關鍵系統特性及下層的硬件。這個東西當時就可以打通 Windows RT、Windows 8，絕大部分應用部署在微軟的應用商店里。早期 Windows Runtime 之上跑的應用被稱作 Metro app（好像是因為當時微軟還熱衷于推 Metro UI，后來叫 modern-style app，應該還會改）。

只不過這東西到現在為止都還不能算是成功，微軟的營銷話術也堪稱災難，沒人知道 Windows RT、on Arm、10S、10X 之類究竟是什么鬼。一般人真的很難搞懂微軟這兩年究竟在做什么——可見當年喬布斯在給 Mac 轉平臺，在告訴用戶和開發者現在正在發生什么的時候，是多么科學（所以比爾蓋茨說喬布斯是超級銷售員）。不過在實際的決策上，我覺得微軟的搖擺不定、瞻前顧后，才真正令 Windows RT 以及后來的 Windows 10S 都很失敗。

微軟接下來的一個“偉（zuo）大（si）”計劃是 Windows 10X。從外顯上來看，Windows 10X 是為雙屏設備準備的一個操作系統（比如 Surface Neo 之類還沒發布的設備），預計今年下半年才會看到實物。不過我覺得 Windows 10X 的意義遠不止此，Windows 10X 支持 Windows Runtime API（這個是肯定的），并且“通過一個原生 container 跑 Win32 應用”［16］。我沒怎么研究過如今 Windows 系統架構狀況，但就對舊有 Windows 生態來看，Windows 10X 如果是微軟接下來意欲統一 PC 市場的操作系統，則這個決心下的還是比較大的；而且貌似雙屏 Windows 設備都是基于 Arm 平臺。

誰不想要 Surface Pro X 這么性感的筆記本呢？

聽起來 Windows 10X 在這一點上，和 Windows on Arm 很像（Surface Pro X 用的就是 Windows on Arm），所以我在想 Surface Pro X 將來是不是可以升級到 Windows 10X——反正微軟改名部門創下那么多的“豐功偉績”。

在針對開發者的兼容性問題上，Windows on Arm 平臺下的 x86 應用是跑在模擬器上的，一個叫 WOW64 的 x86 模擬器。和前文提到蘋果的 Rosetta 有點像，模擬過程就是把 x86 指令塊編譯成 ARM64 指令，加一些優化。會有服務對轉譯代碼塊做緩存，減少指令轉譯開銷。貌似到目前為止，x86-64 應用（也就是傳統的 Windows 64 位應用）還無法在 Arm 版 Windows 上面跑，而且某些大型應用的模擬運行比較災難級，比如 Photoshop。WOW64 也跑在用戶態［17］。

其實突然又有點搞不懂微軟將來計劃怎么發展，從如今微軟的動作來看，好像十分偏向 Arm（和高通），只不過大業未成，生態也暫未見起色，x86 也不想拋棄。不知 Intel 看此情此景是什么心情。畢竟 Windows 作為歷史用戶基數龐大的操作系統，兼容性的歷史包袱遠大于蘋果的 Mac OS：我沒法從技術細節上來探討誰做得更好，但微軟一定比蘋果更有難度；何況蘋果還有 iOS 這顆大棋子。

如果說蘋果要在同一時間針對 Mac 系列產品，既保有 x86 平臺（典型如 Mac Pro 這種更新沒多久的高性能工作站），又開發 Arm 平臺（很可能就是 MacBook），那么對兩個平臺的同時支持，以及對開發者的友好度，不知能否做到比微軟如今的方案更好——因為這次似乎并不是徹底拋棄上一個平臺這么簡單（畢竟彭博社是說部分 Mac 產品采用 Arm 處理器），也就不能以斬斷過往、說拋棄就拋棄這種蘋果式的任性方法來做決策（但好似當年 PowerPC 與 x86 在 Mac OS 系統上也共存了起碼 5 年）。

Mac 轉舵可能會遭遇的問題

一氣寫下來，感覺篇幅有點過長了，本來還想聊聊蘋果自己在 Mac 設備里面搞的 T2 芯片，以及可將 iPad app 輕松移植給 macOS 的 Catalyst 項目——畢竟這倆看起來都很像本次轉舵的重要緩沖或預備手段。但再寫的話，這文章字數就要破萬了，實在是太廢紙了。在轉換平臺的問題上，即便有那么多的困難，自主掌握芯片迭代節奏，以及牢固生態發展，采用自研芯片還是有好處。

其實上面這些算是一個資料匯總，也算是我近期的學習過程吧，以簡短的形式匯報給各位。這里最后談一談 Mac 如果真的要從 x86 轉往 Arm（而不是兩者并行發展，畢竟蘋果很少做這么二的事情），除了兼容性和技術層面，如上述文字中提到的難度，在實際實施中還會有一些非常現實的問題。

第一就是，可能面臨拋棄 Windows 用戶的問題，Mac 如果徹底拋棄 x86，則未來的 Mac 設備很可能就不能再安裝 Windows 系統了：這個問題我覺得十分嚴重，或許很多 Mac 用戶對于在 Mac 設備上使用 Windows 是非常嗤之以鼻的，但這個選擇對很多人來說仍然十分重要。畢竟 Windows 的生產力生態仍然十分完備，某些很偏的應用都只支持 Windows。（現在 Windows 也支持 Arm 了，只是兩者的平臺還是有差異）

第二是，如果低端 MacBook 產品線開始用 Arm 處理器，那么目前的 iPad Pro 產品定位會顯得很尷尬。因為后者就是定位于輕度生產力工具，如果要說生產力，iOS 和 macOS 似乎并非同臺競爭的對象。

第三，有個比較實際的問題：Intel 畢竟是個造芯片的公司，可以搞出一大堆不同定位的 SKU，比如什么酷睿 i3、i5、i7；超低壓、低壓、標壓、桌面等等，并且應用到不同售價的 Mac 設備上。蘋果即便有能力造芯片，是否能在短時間內，按照體質劃分不同 SKU，并且應用到將來更多的 Mac 設備上？如果不能的話，難道真的要 x86 和 Arm 并行發展嗎？

值得注意的是，這次的轉舵并不像上次 PowerPC -》 x86 那樣，是轉向一個在桌面市場十分受歡迎和健全的平臺；而且如今蘋果公司的體量遠非 2005 年可比，所以這次轉舵的困難程度大約不小。另外，前面花了那么多篇幅談兼容性問題，針對某些十分細節的點，比如小到 Final Cut Pro X 中的一個插件，即便容易想見 Final Cut Pro X 會第一批支持 Arm 版 macOS，但插件未更新就可以徹底埋葬一部分用戶。

具體是什么狀況，等到今年的 WWDC 或可一見分曉。最后的最后，Intel 哭泣的時間應該會更長：為什么全世界都針對我？

參考來源：

[1] Apple Aims to Sell Macs With Its Own Chips Starting in 2021 - Bloomberg

https://www.bloomberg.com/news/articles/2020-04-23/apple-aims-to-sell-macs-with-its-own-chips-starting-in-2021

[2] 小議Mac OS Classic的底層架構與Mac的固件沿革 - 老Mac與MacOS收藏

https://zhuanlan.zhihu.com/p/44934452

[3] Mac OS nanokernel - Wikipedia

https://en.wikipedia.org/wiki/Mac_OS_nanokernel

[4] Mac 68k emulator - Wikipedia

https://en.wikipedia.org/wiki/Mac_68k_emulator

[5] Fat binary - Wikipedia

https://en.wikipedia.org/wiki/Fat_binary

[6] List of macOS components - Wikipedia

https://en.wikipedia.org/wiki/List_of_macOS_components#Classic

[7] Rosetta (software) - Wikipedia

https://en.wikipedia.org/wiki/Rosetta_(software)

[8] CodeWarrior - Wikipedia

https://en.wikipedia.org/wiki/CodeWarrior

[9] 聊聊無風扇的Surface Pro：性能比一般筆記本差多少？ - 面包板

https://mbb.eet-china.com/blog/3893689-413612.html

[10] 一場硬仗：華為和高通的GPU差距還有多大？ - EE Times China

https://www.eet-china.com/news/202001061219.html

[11] 為啥 Arm 架構比 x86 x64 省電？ - 木頭龍的回答

https://www.zhihu.com/question/387240856/answer/1186307900

[12] The Apple iPhone 11, 11 Pro & 11 Pro Max Review: Performance, Battery, & Camera Elevated - AnandTech

https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/4

[13] Intel Says Process Tech to Lag Competitors Until Late 2021, Will Regain Lead with 5nm - Intel

https://www.tomshardware.com/news/intel-process-tech-lag-competitors-late-2021-leadership-5nm

[14] Windows Runtime - Wikipedia

https://en.wikipedia.org/wiki/Windows_Runtime

[15] How the Universal Windows Platform relates to Windows Runtime APIs - Microsoft

https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide#how-the-universal-windows-platform-relates-to-windows-runtime-apis

[16] Windows 10X Developer FAQ - Microsoft

https://docs.microsoft.com/en-us/windows/apps/10x/faq

[17] WOW64 Implementation Details - Microsoft

https://docs.microsoft.com/zh-cn/windows/win32/winprog64/wow64-implementation-details