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

人們對蘋果的這個舉措是寄予厚望的。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的道路上，到底行差踏錯了些什麼？今天一起來談談這個問題吧。

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到底做了什麼？

蘋果遷移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年蘋果Mac OS X 10.6不再支持PowerPC的Mac， 2011年Mac OS X 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架構抱有極大期待，也就理所當然了。

3Win10 ARM失敗在哪裡？

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平台，就必須解決當下的種種問題，才能帶來良好的體驗，期待微軟日後能做得更好吧。