蘋果在今年的WWDC上宣布，macOS 11將會遷移到ARM平臺，引起了轟動。蘋果稱，將會在 Mac 電腦上用自研 ARM 平臺取代 Intel 的 X86平臺，并且遷移包括操作系統和軟件在內的生態，這意味著 ARM 在個人 PC 領域邁出了挑戰 X86的一步。

macOS 11將兼容 ARM 芯片

人們對蘋果的這個舉措是寄予厚望的。macOS 并不是首次 “換馬”，在二十一世紀的第一個十年，Mac 就從 IBM PowerPC 平臺遷移到了 Intel X86平臺，并取得了成功，這也是人們對 Mac 此次換用 ARM 后，仍能提供良好體驗抱有如此信心的一大原因。

蘋果宣布這一消息的同時，不少人同時也聯想到了微軟——微軟已經在 ARM 領域摸索多年，推出過 Windows RT 這樣的特制系統，最近更是讓 Windows 10運行在了 ARM 上，并且兼容之前的大量軟件。然而，Win10 ARM 戰略似乎未能取得太大反響，Windows RT 甚至直接暴死。

微軟早已經涉足 ARM 領域，推出了基于 ARM 的 Windows 平板

Mac 遷移平臺來勢洶洶，人們普遍的預期是順風順水，而 Win10卻屢屢碰壁。Win10在 ARM 的道路上，到底行差踏錯了些什么?今天一起來談談這個問題吧。

1.X86轉移 ARM：到底會有什么坑?

眾所周知，ARM 和 X86平臺最大的區別是微架構的不同。ARM 屬于 RISC 簡單指令集，而 X86則是 CISC 復雜指令集，程序要這兩個不同的平臺運行，需要編譯不同的版本。當然，借助中間層，也可以實現兩個不同平臺之間的兼容。

然而，無論是那種方案，將之前兼容 X86的操作系統要將生態遷移到 ARM，都需要付出代價。

如果放棄 X86平臺上老軟件的兼容，只讓新軟件兼容 ARM 平臺，那么就意味著生態系統需要從頭做起，新系統起步會變得非常艱難。在過渡期間，新開發的軟件需要同時兼容 X86和 ARM 平臺，意味著要么開發者投入更多的精力自行編譯不同的版本，要么操作系統的開發套件提供同時編譯的功能。無論如何，都需要投入更多的工作。

而如果想要生態無縫銜接、讓新的 ARM 平臺起步更順利，最好可以讓 X86平臺的老軟件直接可以運行在新的 ARM 平臺上，那么就需要對中間層做工作了。例如 Android 就是一個很好的例子，通過 HAL 來模糊硬件接口，利用善于跨平臺的 JAVA 作為應用上層，無論是運行在 X86的 Android 還是 ARM 的 Android，都可以同時兼容絕大部分的 App。

但這個方法的缺點在于，中間層可能會成為效率的瓶頸。Android 的中間層就很厚，效率感人詬病已久。

X86指令轉制為 ARM 實現兼容，性能下滑不可避免

另外，由于 ARM 多用于移動平臺，因此如果桌面操作系統想要遷移到 ARM，往往也會打起通過移動平臺已有生態造血的注意，也就是讓遷移到 ARM 的桌面操作系統，兼容移動平臺的 App。當然，這里面也有大坑，例如 UI 的適配就是個麻煩——手機平板的屏幕和桌面 PC 顯示器不同，要有體驗好的視覺效果，UI 需要靈活變形，這對 UI 元素的自動排列提出了極高要求，這也是個需要投入大量精力研究的課題。

2.蘋果遷移 ARM 到底做了什么?

上面提到了 X86遷移 ARM 可能會碰到的問題，大家卻對蘋果的遷移之舉抱有信心。要理解這一點，我們首先來看看蘋果為 ARM 平臺的遷移工作都準備了什么吧。

提前量十足的全新開發生態

蘋果打算將 Mac 遷移到 ARM 平臺，其實很早就能看出端倪了。為了平滑過渡到 ARM 平臺，蘋果早有準備，對開發套件作了大量工作，以統合的思路，開始改造其應用生態。

蘋果這兩年做的很多事，就是為了解決 ARM 遷移到 X86平臺上的問題。蘋果在2019年的 WWDC 大會上，推出了 SwiftUI 和 Mac Catalyst。這兩個套件的作用，在于架起了 ARM 和 X86間、以及移動平臺和桌面平臺間跨平臺開發的橋梁——蘋果本身就有著成熟的 ARM 移動生態，這無疑能成為桌面平臺遷移到 ARM 的強勁助力。

先來說說 Mac Catalyst，這是一個跨 ARM 和 X86平臺的開發套件。通過 Mac Catalyst，開發者在構建一個 iPad App 的同時，這個 App 也能成為 macOS 的原生應用。從某個角度來說，Mac Catalyst 將會是 iPadOS 和 macOS 新的開發基準，iPadOS 將會和 macOS 的應用生態深度融合。此后，即使 macOS 遷移到了 ARM 平臺，基于 Mac Catalyst 開發的軟件應用，也可以無縫兼容。

Mac Catalyst 可以讓一個軟件應用同時兼容 iPadOS 和 macOS

而 SwiftUI，其作用則在于為移動平臺和桌面平臺提供了跨平臺的 UI 適配方案。通過 SwiftUI，開發者能用較為簡單的代碼，一次開發出適配多個平臺的軟件 UI。例如開發者想要為 macOS 和 iOS、iPadOS 做軟件應用，那么通過 SwiftUI 就可以輕松做出能適配這幾個平臺應用的 UI。可以說，SwiftUI 大大降低了為不同蘋果平臺開發軟件應用的門檻，意義重大。

SwiftUI 可以讓同一個應用的 UI 同時適配多個蘋果平臺

無論是 Mac Catalyst 還是 SwiftUI，目前都已經投入了實戰當中，通過新版的 Xcode 以及高質量的開發文檔，每個蘋果開發者都可以制作出基于新技術的高質量軟件應用。

很大程度上，蘋果已經解決了新軟件同時兼容 X86/ARM、移動 / 桌面平臺的開發問題。請注意，這是在 ARM 版 macOS 發布之前做的工作，可謂是兵馬未動糧草先行。目前，蘋果尚未發布 ARM 版 Mac 電腦，但為其配套的開發組件，卻已相當完備了。待到 macOS 真正遷移到 ARM 平臺時，基于 Mac Catalyst 以及 SwiftUI 開發的軟件應用早已經花繁葉茂，macOS 遷移 ARM 其軟件生態不至于會 “休克”。

步步為營的生態遷移

Mac Catalyst 解決了代碼在 X86和 ARM 平臺的編譯問題，而 SwiftUI 則解決了移動平臺和桌面平臺的 UI 適配問題，但這是針對于新開發的軟件應用的。對于 macOS 舊有的軟件，蘋果也祭出了招數。

在今年的 WWDC 大會，蘋果宣布，將會為 macOS 平滑過渡到 ARM 平臺，推出 Rosetta 2中間轉換層。如果你是老果粉，對于 Rosetta 這個詞一定很熟悉——蘋果 Mac 電腦當年從 IBM PowerPC 架構，遷移到 Intel X86平臺，所使用的轉換層正是 Rosetta。

Mac 遷移平臺這事，蘋果已經干過一次了，當年 Mac 從 PPC 遷移到 X86的兼容層被稱為 “Rosetta”

Rosetta 2的作用在于，它通過指令翻譯，可以讓 ARM 平臺的 macOS，直接運行絕大部分的 X86軟件。而且 Rosetta 2的性能還相當不錯，它并不是在軟件運行的時候，才翻譯指令的，而是在軟件安裝時就做好了轉換。當然，這也并非說 Rosetta 2可以實現性能完全無損，它對 AVX 指令兼容并不好，如果 X86軟件依賴 AVX 乃至 AVX2，那么在 ARM 平臺上由于沒有對應的高性能指令，運行效率會有明顯下滑。并不是所有的軟件都會用到 AVX 指令集，總體來說，Rosetta 2的性能還是可以接受的。

這次 Mac 從 X86遷移到 ARM，Rosetta 2對舊有 X86軟件的兼容也起著至關重要的作用

和當年的 Rosetta 一樣，Rosetta 2只是一個臨時舉措，它的意義在于為遷移到 ARM 平臺提供平滑的過渡期。我們可以參考一下 Rosetta 的進度：2005年蘋果在 WWDC 宣布換用 X86，接著蘋果在2006年推出基于 X86平臺的 Mac 電腦并部署了 Rosetta，到2009年蘋果 MacOS 10.6不再支持 PowerPC 的 Mac，2011年 MacOS 11.7不再支持 Rosetta，放棄了對 PowerPC 時代 Mac 軟件的支持。從此以后，蘋果 Mac 生態徹底轉移到了 X86平臺，整個過程并未有太大的陣痛。

從 Rosetta 的歷程來看，macOS 轉移到 ARM，舊有的 X86軟件也會經由數年的過渡兼容期。在未來幾年，我們或許也會看到新的 macOS 11不再支持舊有 X86 Mac 電腦、在未來某個版本徹底不支持 Rosetta 2這樣的節點。到最后，macOS 11上只剩下專為 ARM 開發的新軟件，而屆時 ARM 的軟件應用也早已經琳瑯滿目。

蘋果相當清楚，新舊平臺的更迭，絕非一蹴而幾的事情。蘋果一方面通過 SwiftUI 和 Mac Catalyst 慢慢為 ARM 平臺的 Mac 營造新生態，一方面通過 Rosetta 2保持原有生態不流失，而且兩方面的完成度都非常高，可謂兩手都要抓、兩手都要硬的典型。加上此前從 PowerPC 到 X86換平臺的成功經歷，人們對 Mac 換用 ARM 架構抱有極大期待，也就理所當然了。

3.Win10 ARM 失敗在哪里?

在很多人的認知中，微軟 Windows 系統向 ARM 進軍的步伐，要比蘋果 macOS 來得更早。的確，微軟在2012年就已經發布了用于 ARM 平臺的 Windows RT 系統，并將其裝載于第一代 Surface 平板電腦上。而最近，微軟更是將 Windows 10桌面系統整個遷移到 ARM 上，目前市面上已經出現了基于驍龍處理器的 Windows 10平板，而微軟自身也推出了基于驍龍 ARM 平臺的 Surface Pro X。

運行在 ARM 平臺上的 Windows RT 系統

從推向市場的進度來看，微軟無疑遠遠領先于蘋果——macOS 的 ARM 產品尚未見諸市面，而微軟的 ARM Windows 產品已經開賣多時。然而，這些產品并沒有在市場上掀起太大波瀾，Window RT 已經宣告終結，而 Surface Pro X 等 Windows 10 ARM 產品，則落下了性能低下的壞口碑，并沒有取得什么好的市場表現。

為什么會這樣子呢?我們來回看微軟 Windows 在 ARM 平臺上的征程。

2012年，為了和 iPad 競爭，微軟推出了 Surface 平板產品線。然而，用于 ARM 平臺 Surface 平板的 Windows RT 系統，卻擁有著諸多限制。

從外表來看，Windows RT 和正兒八經的 Windows 8桌面操作系統無異。然而，Windows RT 卻不能兼容一切傳統基于 X86開發的 Windows 程序。Windows RT 只能從應用商店中獲取應用，這讓 Windows RT 一度幾乎無第三方軟件可用。實際上，這是由于微軟通過數字簽名限制了第三方應用，破除了微軟的限制后，傳統的 X86軟件通過重新編譯為 ARM 應用，是可以運行在 Windows RT 上的。

Windows RT 不兼容傳統的桌面軟件，必須從 Windows 商店下載

為何微軟要這么做?在微軟的構思中，Windows RT 和 Windows Phone 共用應用商店，雙方生態打通，開發者為 Windows Phone 開發 App 的同時，也可以顧及 Windows RT。然而，這只不過是一個美好的幻想，Windows RT 的這些缺陷，將它送進了墳墓。

· 手機和平板的交互基礎差異過大。Windows Phone 和 Windows RT 都力推 Metro(Modern)設計，然而小屏和大屏之間終究有難以逾越的鴻溝。加之 Windows RT 仍殘留著大量桌面 UI，借助 Windows Phone 上的 App 給 Windows RT 生態輸血，顯得不合時宜。

·Windows Phone 并未建立起強有力的生態。微軟多次變更 Windows Phone 的開發路線，開發工具也一改再改。Windows Phone 的開發環境非常不穩定，系統自身從開始的 CE 內核變為 NT 內核，而應用則從一開始的 XAP 到 APPX，到了 Win10M 又要求開發者開發 UWP 應用…… 開發者連 Windows Phone 劇變的開發環境都無法跟上，最后冷眼旁觀 WP/Win10M 的垂死，更何況邊緣產品 Windows RT?此情此景下，通過 WP 給 Windows RT 輸血是不切實際的。

Windows 應用商店不穩定，還時不時爆出無法安裝應用的大問題

·ARM 平臺性能太弱。Surface 使用的是 Tegra3芯片，該芯片的性能甚至不如同時代的 Atom，系統自帶的 Office 運行起來卡頓無比。指望當時的 ARM 芯片支撐起桌面級的體驗?根本無法勝任。

· 其他因素。開發者們發現，通過破解 Windows RT 系統數字簽名限制，可以將 X86平臺上的 Win32程序重新編譯后，安裝到 Windows RT 上，并且順利運行。然而微軟封堵相關漏洞，進一步削弱了 Windows RT 的擴展性。

簡單來說，盡管微軟讓 Windows RT 運行在了 ARM 平臺上，但沒有為其配備一個理想的開發環境，也沒有讓其能直接兼容傳統的 X86軟件應用，與此同時 Windows RT 還有著 UI 分裂、平臺性能羸弱等問題，失敗也就在情理之中。

到了最近的 Windows 10 ARM 版，許多問題似乎已經得到解決。ARM 芯片的性能大幅提升，甚至逼近了桌面低壓 X86處理器;而可以跨平臺支持 ARM 和 X86的 UWP 應用開發環境，相對以前來說也較為穩定;同時，微軟還讓 Windows 10 ARM 可以直接運行 X86軟件。然而，Windows 10 ARM 卻依然有著如下缺陷。

· 兼容不佳。微軟為 Windows 10 ARM 做的中間兼容層，當前并不能完美兼容所有的 X86軟件，只有32位的軟件能夠實現兼容。事實上，Windows 10 ARM 使用的 Thumb2指令集是和 Windows RT 一脈相承的，不過這次面向 Win32程序開放了兼容，但這套指令集并不兼容 X86-64(Windows RT 時代 ARM 處理器仍未邁入64位)，日后需要大改才能兼容64位軟件。

Windows 10 ARM 運行 Win32軟件效果一般

· 性能低下。在 Windows 10 ARM 上運行的 X86軟件，是邊轉碼邊運行的，并不像蘋果 Rosetta 2那樣在安裝時作好轉碼工作，運行時無需再次轉碼。這就造成了 Windows 10 ARM 運行 X86軟件性能不盡如人意。

·UWP 前景成疑。UWP 應用目前仍存在諸多限制，能實現的功能有限，穩定性更差，開發環境也不如傳統的 WPF 成熟。要知道，用 Mac Catalyst 開發應用，是起碼有成熟的 iPad 生態兜底的，兼容 macOS 是一個加分項;用 UWP 開發應用能得到什么?只會面對傳統 Win 32軟件的強烈競爭，開發者在 UWP 和 Win32軟件開發之間，會作何選擇不言而喻。

UWP 的大餅真香，但喂不飽開發者

· 微軟沒有對 ARM 硬件的掌控力。Windows 10 ARM 運行于驍龍平臺，微軟并沒有像蘋果那樣，自行設計 ARM 芯片，軟硬件結合度自然有所欠缺。蘋果可以確保未來 macOS 跑在怎樣性能水準的 ARM 芯片上，而微軟只能仰仗高通。在 ARM 性能對 X86仍處于追趕態勢的現狀下，這是一個藏有暗雷的要素。

蘋果可以祭出自己的芯片，微軟只能和高通合作

·Windows 有著更沉重的歷史遺留兼容問題。macOS 換用 ARM，蘋果仍只需專心打造新的 Mac 電腦;而 Windows 換用 ARM，微軟必須顧及眾多的硬件廠商，以及諸多的老軟件，轉型速度注定不如蘋果。

總結

到了這里，我們可以總結一下，為何蘋果 macOS 換用 ARM 能萬眾矚目，而微軟 Windows 轉移 ARM 卻不盡如人意了。

· 蘋果提供了能編譯同時兼容 X86、ARM 平臺的應用的高質量開發方案(SwiftUI+Mac Catalyst)，微軟在這方面舉棋不定;

現在還沒有 macOS 的 ARM 產品面市，但開發機卻是已經有了，蘋果的準備力度可見一斑

· 蘋果提供了 X86軟件在 ARM 平臺的兼容方案(Rosetta 2)，效率良好。而 Windows RT 不兼容 X86軟件，Windows 10 ARM 則運行 X86軟件效率較差，且不支持64位;

· 蘋果能夠自行設計高性能的 ARM 芯片，微軟沒有這樣的能力，ARM 芯片性能尚不足以支撐桌面環境時就上馬 Windows RT，現在 Windows 10 ARM 平板的性能也無法和同價位的其他 X86平板相提并論;

· 蘋果提前布局好 ARM 生態的轉移工作，并設置了足夠的過渡期，相應產品由始至終保持了較高完成度，而微軟未準備好配套就匆匆將不成熟的產品推向市場;

· 蘋果對生態掌控力度更大，能促使開發者更新迭代適配新平臺，而微軟背負著沉重的兼容性包袱。

在當前，X86仍是桌面平臺的絕對主流。但 ARM 平臺已經在能效上彰顯優勢，如果微軟鐵了心要兼顧 ARM 平臺，就必須解決當下的種種問題，才能帶來良好的體驗，期待微軟日后能做得更好吧。

標簽： ARM