[PConline 雜談]蘋果在今年的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的道路上，到底行差踏錯了些什麼？今天一起來談談這個問題吧。
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元素的自動排列提出了極高要求，是也是個需要投入大量精力研究的課題。
蘋果遷移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架構抱有極大期待，也就理所當然了。
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平臺，就必須解決當下的種種問題，才能帶來良好的體驗，期待微軟日後能做得更好吧。