1X86轉(zhuǎn)移ARM:到底會有什么坑?
[PConline 雜談]蘋果在今年的WWDC上宣布,macOS 11將會遷移到ARM平臺,引起了轟動。蘋果稱,將會在Mac電腦上用自研ARM平臺取代Intel的X86平臺,并且遷移包括操作系統(tǒng)和軟件在內(nèi)的生態(tài),這意味著ARM在個人PC領(lǐng)域邁出了挑戰(zhàn)X86的一步。
macOS 11將兼容ARM芯片
人們對蘋果的這個舉措是寄予厚望的。macOS并不是首次“換馬”,在二十一世紀的第一個十年,Mac就從IBM PowerPC平臺遷移到了Intel X86平臺,并取得了成功,這也是人們對Mac此次換用ARM后,仍能提供良好體驗抱有如此信心的一大原因。
蘋果宣布這一消息的同時,不少人同時也聯(lián)想到了微軟——微軟已經(jīng)在ARM領(lǐng)域摸索多年,推出過windows RT這樣的特制系統(tǒng),最近更是讓W(xué)indows 10運行在了ARM上,并且兼容之前的大量軟件。然而,Win10 ARM戰(zhàn)略似乎未能取得太大反響,Windows RT甚至直接暴死。
微軟早已經(jīng)涉足ARM領(lǐng)域,推出了基于ARM的Windows平板
Mac遷移平臺來勢洶洶,人們普遍的預(yù)期是順風(fēng)順水,而Win10卻屢屢碰壁。Win10在ARM的道路上,到底行差踏錯了些什么?今天一起來談?wù)勥@個問題吧。
X86轉(zhuǎn)移ARM:到底會有什么坑?
眾所周知,ARM和X86平臺最大的區(qū)別是微架構(gòu)的不同。ARM屬于RISC簡單指令集,而X86則是CISC復(fù)雜指令集,程序要這兩個不同的平臺運行,需要編譯不同的版本。當(dāng)然,借助中間層,也可以實現(xiàn)兩個不同平臺之間的兼容。
然而,無論是那種方案,將之前兼容X86的操作系統(tǒng)要將生態(tài)遷移到ARM,都需要付出代價。
如果放棄X86平臺上老軟件的兼容,只讓新軟件兼容ARM平臺,那么就意味著生態(tài)系統(tǒng)需要從頭做起,新系統(tǒng)起步會變得非常艱難。在過渡期間,新開發(fā)的軟件需要同時兼容X86和ARM平臺,意味著要么開發(fā)者投入更多的精力自行編譯不同的版本,要么操作系統(tǒng)的開發(fā)套件提供同時編譯的功能。無論如何,都需要投入更多的工作。
而如果想要生態(tài)無縫銜接、讓新的ARM平臺起步更順利,最好可以讓X86平臺的老軟件直接可以運行在新的ARM平臺上,那么就需要對中間層做工作了。例如Android就是一個很好的例子,通過HAL來模糊硬件接口,利用善于跨平臺的JAVA作為應(yīng)用上層,無論是運行在X86的Android還是ARM的Android,都可以同時兼容絕大部分的App。
但這個方法的缺點在于,中間層可能會成為效率的瓶頸。Android的中間層就很厚,效率感人詬病已久。
X86指令轉(zhuǎn)制為ARM實現(xiàn)兼容,性能下滑不可避免
另外,由于ARM多用于移動平臺,因此如果桌面操作系統(tǒng)想要遷移到ARM,往往也會打起通過移動平臺已有生態(tài)造血的注意,也就是讓遷移到ARM的桌面操作系統(tǒng),兼容移動平臺的App。當(dāng)然,這里面也有大坑,例如UI的適配就是個麻煩——手機平板的屏幕和桌面PC顯示器不同,要有體驗好的視覺效果,UI需要靈活變形,這對UI元素的自動排列提出了極高要求,是也是個需要投入大量精力研究的課題。
2蘋果遷移ARM到底做了什么?
蘋果遷移ARM到底做了什么?
上面提到了X86遷移ARM可能會碰到的問題,大家卻對蘋果的遷移之舉抱有信心。要理解這一點,我們首先來看看蘋果為ARM平臺的遷移工作都準備了什么吧。
提前量十足的全新開發(fā)生態(tài)
蘋果打算將Mac遷移到ARM平臺,其實很早就能看出端倪了。為了平滑過渡到ARM平臺,蘋果早有準備,對開發(fā)套件作了大量工作,以統(tǒng)合的思路,開始改造其應(yīng)用生態(tài)。
蘋果這兩年做的很多事,就是為了解決ARM遷移到X86平臺上的問題。蘋果在2019年的WWDC大會上,推出了SwiftUI和Mac Catalyst。這兩個套件的作用,在于架起了ARM和X86間、以及移動平臺和桌面平臺間跨平臺開發(fā)的橋梁——蘋果本身就有著成熟的ARM移動生態(tài),這無疑能成為桌面平臺遷移到ARM的強勁助力。
先來說說Mac Catalyst,這是一個跨ARM和X86平臺的開發(fā)套件。通過Mac Catalyst,開發(fā)者在構(gòu)建一個iPad App的同時,這個App也能成為macOS的原生應(yīng)用。從某個角度來說,Mac Catalyst將會是iPadOS和macOS新的開發(fā)基準,iPadOS將會和macOS的應(yīng)用生態(tài)深度融合。此后,即使macOS遷移到了ARM平臺,基于Mac Catalyst開發(fā)的軟件應(yīng)用,也可以無縫兼容。
Mac Catalyst可以讓一個軟件應(yīng)用同時兼容iPadOS和macOS
而SwiftUI,其作用則在于為移動平臺和桌面平臺提供了跨平臺的UI適配方案。通過SwiftUI,開發(fā)者能用較為簡單的代碼,一次開發(fā)出適配多個平臺的軟件UI。例如開發(fā)者想要為macOS和IOS、iPadOS做軟件應(yīng)用,那么通過SwiftUI就可以輕松做出能適配這幾個平臺應(yīng)用的UI。可以說,SwiftUI大大降低了為不同蘋果平臺開發(fā)軟件應(yīng)用的門檻,意義重大。
SwiftUI可以讓同一個應(yīng)用的UI同時適配多個蘋果平臺
無論是Mac Catalyst還是SwiftUI,目前都已經(jīng)投入了實戰(zhàn)當(dāng)中,通過新版的Xcode以及高質(zhì)量的開發(fā)文檔,每個蘋果開發(fā)者都可以制作出基于新技術(shù)的高質(zhì)量軟件應(yīng)用。
很大程度上,蘋果已經(jīng)解決了新軟件同時兼容X86/ARM、移動/桌面平臺的開發(fā)問題。請注意,這是在ARM版macOS發(fā)布之前做的工作,可謂是兵馬未動糧草先行。目前,蘋果尚未發(fā)布ARM版Mac電腦,但為其配套的開發(fā)組件,卻已相當(dāng)完備了。待到macOS真正遷移到ARM平臺時,基于Mac Catalyst以及SwiftUI開發(fā)的軟件應(yīng)用早已經(jīng)花繁葉茂,macOS遷移ARM其軟件生態(tài)不至于會“休克”。
步步為營的生態(tài)遷移
Mac Catalyst解決了代碼在X86和ARM平臺的編譯問題,而SwiftUI則解決了移動平臺和桌面平臺的UI適配問題,但這是針對于新開發(fā)的軟件應(yīng)用的。對于macOS舊有的軟件,蘋果也祭出了招數(shù)。
在今年的WWDC大會,蘋果宣布,將會為macOS平滑過渡到ARM平臺,推出Rosetta 2中間轉(zhuǎn)換層。如果你是老果粉,對于Rosetta這個詞一定很熟悉——蘋果Mac電腦當(dāng)年從IBM PowerPC架構(gòu),遷移到Intel X86平臺,所使用的轉(zhuǎn)換層正是Rosetta。
Mac遷移平臺這事,蘋果已經(jīng)干過一次了,當(dāng)年Mac從PPC遷移到X86的兼容層被稱為“Rosetta”
Rosetta 2的作用在于,它通過指令翻譯,可以讓ARM平臺的macOS,直接運行絕大部分的X86軟件。而且Rosetta 2的性能還相當(dāng)不錯,它并不是在軟件運行的時候,才翻譯指令的,而是在軟件安裝時就做好了轉(zhuǎn)換。當(dāng)然,這也并非說Rosetta 2可以實現(xiàn)性能完全無損,它對AVX指令兼容并不好,如果X86軟件依賴AVX乃至AVX2,那么在ARM平臺上由于沒有對應(yīng)的高性能指令,運行效率會有明顯下滑。并不是所有的軟件都會用到AVX指令集,總體來說,Rosetta 2的性能還是可以接受的。
這次Mac從X86遷移到ARM,Rosetta 2對舊有X86軟件的兼容也起著至關(guān)重要的作用
和當(dāng)年的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生態(tài)徹底轉(zhuǎn)移到了X86平臺,整個過程并未有太大的陣痛。
從Rosetta的歷程來看,macOS轉(zhuǎn)移到ARM,舊有的X86軟件也會經(jīng)由數(shù)年的過渡兼容期。在未來幾年,我們或許也會看到新的macOS 11不再支持舊有X86 Mac電腦、在未來某個版本徹底不支持Rosetta 2這樣的節(jié)點。到最后,macOS 11上只剩下專為ARM開發(fā)的新軟件,而屆時ARM的軟件應(yīng)用也早已經(jīng)琳瑯滿目。
蘋果相當(dāng)清楚,新舊平臺的更迭,絕非一蹴而幾的事情。蘋果一方面通過SwiftUI和Mac Catalyst慢慢為ARM平臺的Mac營造新生態(tài),一方面通過Rosetta 2保持原有生態(tài)不流失,而且兩方面的完成度都非常高,可謂兩手都要抓、兩手都要硬的典型。加上此前從PowerPC到X86換平臺的成功經(jīng)歷,人們對Mac換用ARM架構(gòu)抱有極大期待,也就理所當(dāng)然了。
3Win10 ARM失敗在哪里?
Win10 ARM失敗在哪里?
在很多人的認知中,微軟Windows系統(tǒng)向ARM進軍的步伐,要比蘋果macOS來得更早。的確,微軟在2012年就已經(jīng)發(fā)布了用于ARM平臺的Windows RT系統(tǒng),并將其裝載于第一代Surface平板電腦上。而最近,微軟更是將Windows 10桌面系統(tǒng)整個遷移到ARM上,目前市面上已經(jīng)出現(xiàn)了基于驍龍?zhí)幚砥鞯腤indows 10平板,而微軟自身也推出了基于驍龍ARM平臺的Surface Pro X。
運行在ARM平臺上的Windows RT系統(tǒng)
從推向市場的進度來看,微軟無疑遠遠領(lǐng)先于蘋果——macOS的ARM產(chǎn)品尚未見諸市面,而微軟的ARM Windows產(chǎn)品已經(jīng)開賣多時。然而,這些產(chǎn)品并沒有在市場上掀起太大波瀾,Window RT已經(jīng)宣告終結(jié),而Surface Pro X等Windows 10 ARM產(chǎn)品,則落下了性能低下的壞口碑,并沒有取得什么好的市場表現(xiàn)。
為什么會這樣子呢?我們來回看微軟Windows在ARM平臺上的征程。
2012年,為了和iPad競爭,微軟推出了Surface平板產(chǎn)品線。然而,用于ARM平臺Surface平板的Windows RT系統(tǒng),卻擁有著諸多限制。
從外表來看,Windows RT和正兒八經(jīng)的Windows 8桌面操作系統(tǒng)無異。然而,Windows RT卻不能兼容一切傳統(tǒng)基于X86開發(fā)的Windows程序。Windows RT只能從應(yīng)用商店中獲取應(yīng)用,這讓W(xué)indows RT一度幾乎無第三方軟件可用。實際上,這是由于微軟通過數(shù)字簽名限制了第三方應(yīng)用,破除了微軟的限制后,傳統(tǒng)的X86軟件通過重新編譯為ARM應(yīng)用,是可以運行在Windows RT上的。
Windows RT不兼容傳統(tǒng)的桌面軟件,必須從Windows商店下載
為何微軟要這么做?在微軟的構(gòu)思中,Windows RT和Windows Phone共用應(yīng)用商店,雙方生態(tài)打通,開發(fā)者為Windows Phone開發(fā)App的同時,也可以顧及Windows RT。然而,這只不過是一個美好的幻想,Windows RT的這些缺陷,將它送進了墳?zāi)埂?/p>
·手機和平板的交互基礎(chǔ)差異過大。Windows Phone和Windows RT都力推Metro(Modern)設(shè)計,然而小屏和大屏之間終究有難以逾越的鴻溝。加之Windows RT仍殘留著大量桌面UI,借助Windows Phone上的App給Windows RT生態(tài)輸血,顯得不合時宜。
·Windows Phone并未建立起強有力的生態(tài)。微軟多次變更Windows Phone的開發(fā)路線,開發(fā)工具也一改再改。Windows Phone的開發(fā)環(huán)境非常不穩(wěn)定,系統(tǒng)自身從開始的CE內(nèi)核變?yōu)镹T內(nèi)核,而應(yīng)用則從一開始的XAP到APPX,到了Win10M又要求開發(fā)者開發(fā)UWP應(yīng)用……開發(fā)者連Windows Phone劇變的開發(fā)環(huán)境都無法跟上,最后冷眼旁觀WP/Win10M的垂死,更何況邊緣產(chǎn)品Windows RT?此情此景下,通過WP給Windows RT輸血是不切實際的。
Windows應(yīng)用商店不穩(wěn)定,還時不時爆出無法安裝應(yīng)用的大問題
·ARM平臺性能太弱。Surface使用的是Tegra3芯片,該芯片的性能甚至不如同時代的Atom,系統(tǒng)自帶的office運行起來卡頓無比。指望當(dāng)時的ARM芯片支撐起桌面級的體驗?根本無法勝任。
·其他因素。開發(fā)者們發(fā)現(xiàn),通過破解Windows RT系統(tǒng)數(shù)字簽名限制,可以將X86平臺上的Win32程序重新編譯后,安裝到Windows RT上,并且順利運行。然而微軟封堵相關(guān)漏洞,進一步削弱了Windows RT的擴展性。
簡單來說,盡管微軟讓W(xué)indows RT運行在了ARM平臺上,但沒有為其配備一個理想的開發(fā)環(huán)境,也沒有讓其能直接兼容傳統(tǒng)的X86軟件應(yīng)用,與此同時Windows RT還有著UI分裂、平臺性能羸弱等問題,失敗也就在情理之中。
到了最近的Windows 10 ARM版,許多問題似乎已經(jīng)得到解決。ARM芯片的性能大幅提升,甚至逼近了桌面低壓X86處理器;而可以跨平臺支持ARM和X86的UWP應(yīng)用開發(fā)環(huán)境,相對以前來說也較為穩(wěn)定;同時,微軟還讓W(xué)indows 10 ARM可以直接運行X86軟件。然而,Windows 10 ARM卻依然有著如下缺陷。
·兼容不佳。微軟為Windows 10 ARM做的中間兼容層,當(dāng)前并不能完美兼容所有的X86軟件,只有32位的軟件能夠?qū)崿F(xiàn)兼容。事實上,Windows 10 ARM使用的Thumb2指令集是和Windows RT一脈相承的,不過這次面向Win32程序開放了兼容,但這套指令集并不兼容X86-64(Windows RT時代ARM處理器仍未邁入64位),日后需要大改才能兼容64位軟件。
Windows 10 ARM運行Win32軟件效果一般
·性能低下。在Windows 10 ARM上運行的X86軟件,是邊轉(zhuǎn)碼邊運行的,并不像蘋果Rosetta 2那樣在安裝時作好轉(zhuǎn)碼工作,運行時無需再次轉(zhuǎn)碼。這就造成了Windows 10 ARM運行X86軟件性能不盡如人意。
·UWP前景成疑。UWP應(yīng)用目前仍存在諸多限制,能實現(xiàn)的功能有限,穩(wěn)定性更差,開發(fā)環(huán)境也不如傳統(tǒng)的WPF成熟。要知道,用Mac Catalyst開發(fā)應(yīng)用,是起碼有成熟的iPad生態(tài)兜底的,兼容macOS是一個加分項;用UWP開發(fā)應(yīng)用能得到什么?只會面對傳統(tǒng)Win 32軟件的強烈競爭,開發(fā)者在UWP和Win32軟件開發(fā)之間,會作何選擇不言而喻。
UWP的大餅真香,但喂不飽開發(fā)者
·微軟沒有對ARM硬件的掌控力。Windows 10 ARM運行于驍龍平臺,微軟并沒有像蘋果那樣,自行設(shè)計ARM芯片,軟硬件結(jié)合度自然有所欠缺。蘋果可以確保未來macOS跑在怎樣性能水準的ARM芯片上,而微軟只能仰仗高通。在ARM性能對X86仍處于追趕態(tài)勢的現(xiàn)狀下,這是一個藏有暗雷的要素。
蘋果可以祭出自己的芯片,微軟只能和高通合作
·Windows有著更沉重的歷史遺留兼容問題。macOS換用ARM,蘋果仍只需專心打造新的Mac電腦;而Windows換用ARM,微軟必須顧及眾多的硬件廠商,以及諸多的老軟件,轉(zhuǎn)型速度注定不如蘋果。
總結(jié)
到了這里,我們可以總結(jié)一下,為何蘋果macOS換用ARM能萬眾矚目,而微軟Windows轉(zhuǎn)移ARM卻不盡如人意了。
·蘋果提供了能編譯同時兼容X86、ARM平臺的應(yīng)用的高質(zhì)量開發(fā)方案(SwiftUI+Mac Catalyst),微軟在這方面舉棋不定;
現(xiàn)在還沒有macOS的ARM產(chǎn)品面市,但開發(fā)機卻是已經(jīng)有了,蘋果的準備力度可見一斑
·蘋果提供了X86軟件在ARM平臺的兼容方案(Rosetta 2),效率良好。而Windows RT不兼容X86軟件,Windows 10 ARM則運行X86軟件效率較差,且不支持64位;
·蘋果能夠自行設(shè)計高性能的ARM芯片,微軟沒有這樣的能力,ARM芯片性能尚不足以支撐桌面環(huán)境時就上馬Windows RT,現(xiàn)在Windows 10 ARM平板的性能也無法和同價位的其他X86平板相提并論;
·蘋果提前布局好ARM生態(tài)的轉(zhuǎn)移工作,并設(shè)置了足夠的過渡期,相應(yīng)產(chǎn)品由始至終保持了較高完成度,而微軟未準備好配套就匆匆將不成熟的產(chǎn)品推向市場;
·蘋果對生態(tài)掌控力度更大,能促使開發(fā)者更新迭代適配新平臺,而微軟背負著沉重的兼容性包袱。
在當(dāng)前,X86仍是桌面平臺的絕對主流。但ARM平臺已經(jīng)在能效上彰顯優(yōu)勢,如果微軟鐵了心要兼顧ARM平臺,就必須解決當(dāng)下的種種問題,才能帶來良好的體驗,期待微軟日后能做得更好吧。