|
发表于 2020-7-20
|
|阅读模式
) l7 m! b+ P! X6 y$ Z; _macOS换用ARM来势汹汹!Win10 ARM失败在哪里
, J& m8 O8 y6 _7 }
) a8 v; Y0 V* W: C4 W9 y2 A 苹果在今年的WWDC上宣布,macOS 11将会迁移到ARM平台,引起了轰动。苹果称,将会在Mac电脑上用自研ARM平台取代Intel的X86平台,并且迁移包括操作系统和软件在内的生态,这意味着ARM在个人PC领域迈出了挑战X86的一步。1 r7 `$ p) K& ]3 o% y& T
$ v: `+ O& B1 x
! E& U; [1 V& \: {2 R1 dmacOS 11将兼容ARM芯片- {. `4 Q# H) Q
& V w5 a* Y8 j: m人们对苹果的这个举措是寄予厚望的。macOS并不是首次“换马”,在二十一世纪的第一个十年,Mac就从IBM PowerPC平台迁移到了Intel X86平台,并取得了成功,这也是人们对Mac此次换用ARM后,仍能提供良好体验抱有如此信心的一大原因。% X1 O1 I9 n6 p) k, ~9 ?
9 Y% G' V: g! o
苹果宣布这一消息的同时,不少人同时也联想到了微软——微软已经在ARM领域摸索多年,推出过Windows RT这样的特制系统,最近更是让Windows 10运行在了ARM上,并且兼容之前的大量软件。然而,Win10 ARM战略似乎未能取得太大反响,Windows RT甚至直接暴死。' l: E" R; ] W
, D" J, n8 O6 f j' W3 T
4 ]" o% h$ ?- y) _ W/ ?微软早已经涉足ARM领域,推出了基于ARM的Windows平板5 y( W ]! `# t/ y
) X3 ^+ ^+ b" D! p7 s( z
Mac迁移平台来势汹汹,人们普遍的预期是顺风顺水,而Win10却屡屡碰壁。Win10在ARM的道路上,到底行差踏错了些什么?今天一起来谈谈这个问题吧。* g, z+ q# }8 n
/ d. [& m9 C* N) T. |% M0 I0 |
X86转移ARM:到底会有什么坑?5 k, J# ?* y! x( t2 c: \; s) x
8 C/ |+ a* R* N) J. R. `8 z# B$ e众所周知,ARM和X86平台最大的区别是微架构的不同。ARM属于RISC简单指令集,而X86则是CISC复杂指令集,程序要这两个不同的平台运行,需要编译不同的版本。当然,借助中间层,也可以实现两个不同平台之间的兼容。# j: b' t+ _" O. ?' E
* Z4 F! U" |/ A T' W/ g* U2 P1 |然而,无论是那种方案,将之前兼容X86的操作系统要将生态迁移到ARM,都需要付出代价。
1 B0 z+ ~3 O. K) D% F d2 f V/ @4 b4 H6 i2 z8 e, d
如果放弃X86平台上老软件的兼容,只让新软件兼容ARM平台,那么就意味着生态系统需要从头做起,新系统起步会变得非常艰难。在过渡期间,新开发的软件需要同时兼容X86和ARM平台,意味着要么开发者投入更多的精力自行编译不同的版本,要么操作系统的开发套件提供同时编译的功能。无论如何,都需要投入更多的工作。
/ y9 P7 C. a9 f
1 [. {; O4 {' X而如果想要生态无缝衔接、让新的ARM平台起步更顺利,最好可以让X86平台的老软件直接可以运行在新的ARM平台上,那么就需要对中间层做工作了。例如Android就是一个很好的例子,通过HAL来模糊硬件接口,利用善于跨平台的JAVA作为应用上层,无论是运行在X86的Android还是ARM的Android,都可以同时兼容绝大部分的App。
9 }# V2 j+ |+ m1 T5 m
3 m9 k0 z/ r& l6 h但这个方法的缺点在于,中间层可能会成为效率的瓶颈。Android的中间层就很厚,效率感人诟病已久。1 j4 k. c) Z8 Q: {6 g9 R
0 V7 G( t* j& W2 ?$ ?( E% ^9 x7 t" C
x4 M: k4 c3 ?" d2 C
X86指令转制为ARM实现兼容,性能下滑不可避免
G" E8 w; w# n5 }8 v/ X! X$ T* {6 G d2 m% |9 l( J* E0 E, j
另外,由于ARM多用于移动平台,因此如果桌面操作系统想要迁移到ARM,往往也会打起通过移动平台已有生态造血的注意,也就是让迁移到ARM的桌面操作系统,兼容移动平台的App。当然,这里面也有大坑,例如UI的适配就是个麻烦——手机平板的屏幕和桌面PC显示器不同,要有体验好的视觉效果,UI需要灵活变形,这对UI元素的自动排列提出了极高要求,是也是个需要投入大量精力研究的课题。
4 c# h3 f) \) E3 a8 T3 ]: i/ f7 F6 S% t8 |: i2 F/ H
苹果迁移ARM到底做了什么?* L) X' x& W/ C/ F( F% q
& a' A! O: c7 L! N7 {
上面提到了X86迁移ARM可能会碰到的问题,大家却对苹果的迁移之举抱有信心。要理解这一点,我们首先来看看苹果为ARM平台的迁移工作都准备了什么吧。
% g& s, X5 c" d' R7 F
" v7 `' _. c5 x- `, ^提前量十足的全新开发生态
; Y# y; L& v- Y$ L O2 `& Q/ q1 I
苹果打算将Mac迁移到ARM平台,其实很早就能看出端倪了。为了平滑过渡到ARM平台,苹果早有准备,对开发套件作了大量工作,以统合的思路,开始改造其应用生态。
2 O0 k- v d, W! R: o0 i1 E% u7 a; v) P
苹果这两年做的很多事,就是为了解决ARM迁移到X86平台上的问题。苹果在2019年的WWDC大会上,推出了SwiftUI和Mac Catalyst。这两个套件的作用,在于架起了ARM和X86间、以及移动平台和桌面平台间跨平台开发的桥梁——苹果本身就有着成熟的ARM移动生态,这无疑能成为桌面平台迁移到ARM的强劲助力。
5 `* M, |1 I8 [8 l* F+ h1 d/ A% [9 K
先来说说Mac Catalyst,这是一个跨ARM和X86平台的开发套件。通过Mac Catalyst,开发者在构建一个iPad App的同时,这个App也能成为macOS的原生应用。从某个角度来说,Mac Catalyst将会是iPadOS和macOS新的开发基准,iPadOS将会和macOS的应用生态深度融合。此后,即使macOS迁移到了ARM平台,基于Mac Catalyst开发的软件应用,也可以无缝兼容。
2 D/ ~0 |- d0 ]; J5 E
% c6 L- D% B3 {4 B3 \8 i
5 h6 a- \- L$ \$ l
. J4 [% I+ K: O% Y7 D% ?' l
8 x3 e) U, C v: e/ W7 MMac Catalyst可以让一个软件应用同时兼容iPadOS和macOS
0 r8 {( ~( Z. K8 N
& U, _) \- F1 ]6 P! ?而SwiftUI,其作用则在于为移动平台和桌面平台提供了跨平台的UI适配方案。通过SwiftUI,开发者能用较为简单的代码,一次开发出适配多个平台的软件UI。例如开发者想要为macOS和iOS、iPadOS做软件应用,那么通过SwiftUI就可以轻松做出能适配这几个平台应用的UI。可以说,SwiftUI大大降低了为不同苹果平台开发软件应用的门槛,意义重大。7 S5 B. F' u- C4 _2 D
/ S+ r0 y: a, s _/ X: k
! |+ ?# o1 i$ Z" c2 n
SwiftUI可以让同一个应用的UI同时适配多个苹果平台- C1 c6 S7 U" y. F! ]% y+ _
$ {1 d: K s* H7 O( W4 @
无论是Mac Catalyst还是SwiftUI,目前都已经投入了实战当中,通过新版的Xcode以及高质量的开发文档,每个苹果开发者都可以制作出基于新技术的高质量软件应用。( d( T2 c6 v Y# T& I* q
9 R5 Z" v! Z! S; k- f很大程度上,苹果已经解决了新软件同时兼容X86/ARM、移动/桌面平台的开发问题。请注意,这是在ARM版macOS发布之前做的工作,可谓是兵马未动粮草先行。目前,苹果尚未发布ARM版Mac电脑,但为其配套的开发组件,却已相当完备了。待到macOS真正迁移到ARM平台时,基于Mac Catalyst以及SwiftUI开发的软件应用早已经花繁叶茂,macOS迁移ARM其软件生态不至于会“休克”。& `2 U' k) A4 }
2 c1 E2 j/ p) x! q( s+ }步步为营的生态迁移 Q& i1 O" O A
7 ]: [- R/ H0 T9 `4 H; D7 bMac Catalyst解决了代码在X86和ARM平台的编译问题,而SwiftUI则解决了移动平台和桌面平台的UI适配问题,但这是针对于新开发的软件应用的。对于macOS旧有的软件,苹果也祭出了招数。* O+ a$ [/ K8 A5 j
( X* h! d) e' @( `/ B8 [% V* d# y
在今年的WWDC大会,苹果宣布,将会为macOS平滑过渡到ARM平台,推出Rosetta 2中间转换层。如果你是老果粉,对于Rosetta这个词一定很熟悉——苹果Mac电脑当年从IBM PowerPC架构,迁移到Intel X86平台,所使用的转换层正是Rosetta。) z) J( N5 k- P
8 G8 G4 }: {) M# T# |% }
$ g, G% P a0 O" y& t. |; r6 vMac迁移平台这事,苹果已经干过一次了,当年Mac从PPC迁移到X86的兼容层被称为“Rosetta”
/ ~! j' d' m* W- ?; V1 I
+ ?& |6 `; g" X$ E' bRosetta 2的作用在于,它通过指令翻译,可以让ARM平台的macOS,直接运行绝大部分的X86软件。而且Rosetta 2的性能还相当不错,它并不是在软件运行的时候,才翻译指令的,而是在软件安装时就做好了转换。当然,这也并非说Rosetta 2可以实现性能完全无损,它对AVX指令兼容并不好,如果X86软件依赖AVX乃至AVX2,那么在ARM平台上由于没有对应的高性能指令,运行效率会有明显下滑。并不是所有的软件都会用到AVX指令集,总体来说,Rosetta 2的性能还是可以接受的。, C) g4 g5 [' r2 K6 F! J1 C( y' X
2 L B3 {4 H) H
J. n+ j4 M1 [7 u$ N1 q
这次Mac从X86迁移到ARM,Rosetta 2对旧有X86软件的兼容也起着至关重要的作用! c! m6 a0 g/ F5 k0 m6 X
+ |3 D% q; y( L2 v; ]: n+ y
和当年的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平台,整个过程并未有太大的阵痛。
) h' B$ ^! L7 |- y% R
3 u! P2 d- [3 t; G& J3 T' h( `从Rosetta的历程来看,macOS转移到ARM,旧有的X86软件也会经由数年的过渡兼容期。在未来几年,我们或许也会看到新的macOS 11不再支持旧有X86 Mac电脑、在未来某个版本彻底不支持Rosetta 2这样的节点。到最后,macOS 11上只剩下专为ARM开发的新软件,而届时ARM的软件应用也早已经琳琅满目。
! C# N& f' T6 ]/ w% l
/ p& T' M, R) W* E# H) l苹果相当清楚,新旧平台的更迭,绝非一蹴而几的事情。苹果一方面通过SwiftUI和Mac Catalyst慢慢为ARM平台的Mac营造新生态,一方面通过Rosetta 2保持原有生态不流失,而且两方面的完成度都非常高,可谓两手都要抓、两手都要硬的典型。加上此前从PowerPC到X86换平台的成功经历,人们对Mac换用ARM架构抱有极大期待,也就理所当然了。5 N7 v9 K5 p! E" \
# i6 P) C) P/ J# h( }* E; }' u* f0 SWin10 ARM失败在哪里?* C' U4 q; I. w3 j/ j2 I
9 E/ c7 G* m6 }/ {' i- I0 U
在很多人的认知中,微软Windows系统向ARM进军的步伐,要比苹果macOS来得更早。的确,微软在2012年就已经发布了用于ARM平台的Windows RT系统,并将其装载于第一代Surface平板电脑上。而最近,微软更是将Windows 10桌面系统整个迁移到ARM上,目前市面上已经出现了基于骁龙处理器的Windows 10平板,而微软自身也推出了基于骁龙ARM平台的Surface Pro X。
% b8 ~! f7 N; `& l/ e* W' S' g
8 M3 }1 K8 l* r6 x2 \, M" { @9 T. K# l. y/ e/ `% G! D
运行在ARM平台上的Windows RT系统
( ?% q9 G7 e" Q" r: L( F% |% Y6 K+ D; o* H- r% D8 c* }8 j
从推向市场的进度来看,微软无疑远远领先于苹果——macOS的ARM产品尚未见诸市面,而微软的ARM Windows产品已经开卖多时。然而,这些产品并没有在市场上掀起太大波澜,Window RT已经宣告终结,而Surface Pro X等Windows 10 ARM产品,则落下了性能低下的坏口碑,并没有取得什么好的市场表现。' \! l. h/ Q9 h( d% A
" ], m( I# h! L
为什么会这样子呢?我们来回看微软Windows在ARM平台上的征程。
9 H! X( j# i4 q) U V/ a. ^1 O2 ~9 b
2012年,为了和iPad竞争,微软推出了Surface平板产品线。然而,用于ARM平台Surface平板的Windows RT系统,却拥有着诸多限制。6 H: U2 I; _. y( E4 G
# Y6 [( M/ ~ ? e4 O从外表来看,Windows RT和正儿八经的Windows 8桌面操作系统无异。然而,Windows RT却不能兼容一切传统基于X86开发的Windows程序。Windows RT只能从应用商店中获取应用,这让Windows RT一度几乎无第三方软件可用。实际上,这是由于微软通过数字签名限制了第三方应用,破除了微软的限制后,传统的X86软件通过重新编译为ARM应用,是可以运行在Windows RT上的。
" }# w1 A' @# }) n! @( X3 F2 \
$ Z- q. C" H( h$ Q/ h, }4 L: l- J4 y" [
+ U) c0 u+ P: y$ D: S
Windows RT不兼容传统的桌面软件,必须从Windows商店下载
* c5 f" w# R3 U3 m& Q
) t# `; O m9 h7 l2 k/ P为何微软要这么做?在微软的构思中,Windows RT和Windows Phone共用应用商店,双方生态打通,开发者为Windows Phone开发App的同时,也可以顾及Windows RT。然而,这只不过是一个美好的幻想,Windows RT的这些缺陷,将它送进了坟墓。9 O; o6 }/ T+ c- l7 a3 D
8 R, O( O) X3 u, I
·手机和平板的交互基础差异过大。Windows Phone和Windows RT都力推Metro(Modern)设计,然而小屏和大屏之间终究有难以逾越的鸿沟。加之Windows RT仍残留着大量桌面UI,借助Windows Phone上的App给Windows RT生态输血,显得不合时宜。+ m0 v' u. F" q% g
" T; y8 P. _% g/ R
·Windows Phone并未建立起强有力的生态。微软多次变更Windows Phone的开发路线,开发工具也一改再改。Windows Phone的开发环境非常不稳定,系统自身从开始的CE内核变为NT内核,而应用则从一开始的XAP到APPX,到了Win10M又要求开发者开发UWP应用……开发者连Windows Phone剧变的开发环境都无法跟上,最后冷眼旁观WP/Win10M的垂死,更何况边缘产品Windows RT?此情此景下,通过WP给Windows RT输血是不切实际的。5 _6 s1 V2 _. T" P% X: ^2 Y
9 P& O5 Z8 \7 Z8 @
2 D% J0 ^8 j1 QWindows应用商店不稳定,还时不时爆出无法安装应用的大问题* d2 l5 J6 g) b( X. L( f% j
' o1 M* I& M8 V1 r ·ARM平台性能太弱。Surface使用的是Tegra3芯片,该芯片的性能甚至不如同时代的Atom,系统自带的Office运行起来卡顿无比。指望当时的ARM芯片支撑起桌面级的体验?根本无法胜任。0 p! s/ L4 {6 T+ u, }) q
3 K# O, S+ D. G% [0 v) U ·其他因素。开发者们发现,通过破解Windows RT系统数字签名限制,可以将X86平台上的Win32程序重新编译后,安装到Windows RT上,并且顺利运行。然而微软封堵相关漏洞,进一步削弱了Windows RT的扩展性。
+ Z4 T3 i, i) V4 ?2 x. c
{) b% J0 U1 w; R' a/ _简单来说,尽管微软让Windows RT运行在了ARM平台上,但没有为其配备一个理想的开发环境,也没有让其能直接兼容传统的X86软件应用,与此同时Windows RT还有着UI分裂、平台性能羸弱等问题,失败也就在情理之中。
2 b6 A2 ]& \4 H0 J9 `7 c* g% k4 ?' ^) [& F' V/ W# B) V
到了最近的Windows 10 ARM版,许多问题似乎已经得到解决。ARM芯片的性能大幅提升,甚至逼近了桌面低压X86处理器;而可以跨平台支持ARM和X86的UWP应用开发环境,相对以前来说也较为稳定;同时,微软还让Windows 10 ARM可以直接运行X86软件。然而,Windows 10 ARM却依然有着如下缺陷。
1 b, g# m1 e: L) P% s" F
" h7 `4 u# ^+ a8 S& q* I) c1 B' c ·兼容不佳。微软为Windows 10 ARM做的中间兼容层,当前并不能完美兼容所有的X86软件,只有32位的软件能够实现兼容。事实上,Windows 10 ARM使用的Thumb2指令集是和Windows RT一脉相承的,不过这次面向Win32程序开放了兼容,但这套指令集并不兼容X86-64(Windows RT时代ARM处理器仍未迈入64位),日后需要大改才能兼容64位软件。4 |7 Q" P$ T [
5 c1 P) O( k6 I# }% H
% p. ?. k4 \7 A/ q; J# _Windows 10 ARM运行Win32软件效果一般' z6 v5 e, h4 `/ i! {
: u2 j8 j# r/ S ·性能低下。在Windows 10 ARM上运行的X86软件,是边转码边运行的,并不像苹果Rosetta 2那样在安装时作好转码工作,运行时无需再次转码。这就造成了Windows 10 ARM运行X86软件性能不尽如人意。
( |' G# e/ N% M$ o$ X# g
1 D" x$ P3 D+ N7 ~# [ ·UWP前景成疑。UWP应用目前仍存在诸多限制,能实现的功能有限,稳定性更差,开发环境也不如传统的WPF成熟。要知道,用Mac Catalyst开发应用,是起码有成熟的iPad生态兜底的,兼容macOS是一个加分项;用UWP开发应用能得到什么?只会面对传统Win 32软件的强烈竞争,开发者在UWP和Win32软件开发之间,会作何选择不言而喻。
2 O) n2 w9 X1 W; p
9 r5 @, z+ u; y7 K! ^
7 ^' P! m2 n: h |& aUWP的大饼真香,但喂不饱开发者 |
|