2021年12月05日 | 浅析自动驾驶OS市场的现状及未来

站在车企的角度看，QNX有点像Mobileye——尽管“易用”，但限制了车企的自主性；而Linux则有点像英伟达——比较“难用”，但赋予了车企很大的自主权及面向未来的兼容性。

随着车企对软件技术投入的加大和能力的提升，Linux在自动驾驶市场的占有率大将会逐步上升，而QNX的市占率则会逐步下降；同时，对基于Linux自研OS失败的车企而言，还有QNX这条“退路”可以依赖，这反而让他们在自研OS时少了些“后顾之忧”。

值得注意的是，自研自动驾驶OS（已取得成功）的车企或自动驾驶公司，无论特斯拉还是Waymo、Mobileye、华为或苹果，都有一个共同点：有自主研发的ASIC芯片。那么，有没有这样一种可能：打算自研自动驾驶OS的车企，先从英伟达或Mobileye挖个芯片大牛来担任自动驾驶负责人或CTO，然后，一手抓芯片，一手抓OS？

随着电动车的EE架构从分布式向集中式演进、自动驾驶等级从L2向L2+、NOA/NOP乃至L4演进，系统对自动驾驶OS（操作系统）的要求也越来越高。并且，由于事关生命安全，自动驾驶OS对实时性及可靠性的要求要远高于车载娱乐系统的OS。

OS的价值主要在于可以更好地分配、调度运算和存储资源，但在分布式EE架构下，各ECU基本只处理某一项单一任务，并不存在资源“分配和调度”的需求；甚至连Mobileye的EyeQ 3和EyeQ 4，也只是跑单任务的ASIC，只需要处理摄像头的数据，因此，用Tier 1的MCU就可以了，不需要高性能的OS。

MCU的代码行数少，流程和功能简单，并且逻辑也不复杂，因此，用MCU的风险系数很低。

而到了域控制器时代，许多项功能都被集成到一颗性能强大的soc芯片上，尤其是，在自动驾驶功能从L2向L2+、NOA演讲的过程中，传感器的种类和数量大幅增加、需要处理的数据量更是呈指数级增加，如此复杂的任务，简单的MCU已经搞不定了，必须需要有一个强大的实时操作系统才能搞定。

从L2到L4，操作系统对实时性、功能安全、信息安全的要求都在提高。

以往，对自动驾驶OS关注较多的是芯片厂商、L4级自动驾驶方案公司、特斯拉，而大部分车企对自动驾驶OS涉猎甚少。

某美国ADAS芯片厂商市场部负责人说：“我们在2019年问很多车厂、Tier 1‘你们对什么操作系统感兴趣’，结果都大家都一头雾水，没怎么思考过。博世又很强势，觉得 RTOS搭配经典AUTOSAR的方案挺好的，但往多摄像头发展，RTOS是否可行，没有人知道。“

但随着L2+、NOA/NOP等高级自动驾驶功能逐渐成为新车的标配，无论有没有兴趣，有进取心的车企都必须要硬着头皮“恶补”关于自动驾驶OS的课程；个别车企甚至打算自研OS。

然而，自动驾驶OS尽管重要，但并没有芯片和激光雷达那么“热门”，这也导致很多人对它有些误解。比如，一旦某公司要自研自动驾驶OS，就会被不少人解读为“自研底层操作系统”，甚至有媒体的报道中会出现“基于Linux的底层操系统”这样的硬伤。

那么，目前可用的自动驾驶OS有哪些？车企所谓的“自研OS”究竟是什么意思？基于不同的内核自研OS有什么区别？未来，自动驾驶OS的话语权会掌握在谁手里？

狭义OS和广义OS

首先需要厘清两个概念：狭义OS和广义OS。

车载智能计算平台自下而上可大致划分为硬件平台、系统软件（硬件抽象层+OS内核+中间件）、功能软件（库组件+中间件）和应用算法软件等四个部分。狭义上的OS特指可直接搭载在硬件上的OS内核；而广义OS从下至上包括从BSP、操作系统内核、中间件及库组件等硬件和上层应用之间的所有程序。

系统软件，主要由硬件抽象层，操作系统内核以及中间件三部分组成，硬件抽象层里包含BSP和Hypervisor。

Hypervisor——一种运行在基础物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件,也可叫做VMM（ virtual machine monitor ），即虚拟机监视器。Hypervisors是一种在虚拟环境中的“元”操作系统。他们可以访问服务器上包括磁盘和内存在内的所有物理设备。

BSP(board support package)即板级支持包，也是介于主板硬件和操作系统之间的一层，主要目的是支持操作系统，使之能够更好的运行于硬件主板。

OS内核又称为“底层OS”，提供操作系统最基本的功能，负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性。

中间件，作为底层操作系统和这些应用程序之间的桥梁，是对软硬件资源进行管理、分配和调度的平台，充当着软件和硬件解耦的关键角色。

具体来说，中间件通常对传感器、计算平台等资源进行抽象，对算法、子系统、功能采取模块化的管理，通过提供的统一接口，让开发人员能够专注于各自业务层面的开发，而无需了解无关的细节。这为开发者快速、高效、灵活地开发和集成自动驾驶软件提供了极大的便利。

功能软件，包含自动驾驶的核心功能模块，如相关算法的编程框架（如TensorFlow、Caffe、PaddlePaddle等）。

自动驾驶OS内核的格局较为稳定，主要玩家为QNX（Blackberry）、Linux（开源基金会）、VxWorks（风河）。因打造全新OS需要花费太大的人力、物力，目前基本没有企业会开发全新的OS内核。

当前，无论是Waymo、百度、特斯拉、Mobileye，还是一众自动驾驶初创公司、车企，所谓的自研自动驾驶OS，都是指在上述现成内核的基础之上自研中间件和应用软件。

由于基于QNX开发中间件相对简单，并且受QNX官方的约束比较大，而基于Linux开发中间件有很高的技术壁垒，开发者们也可以享有更大的自主权，因此，通常，很多公司提到的“自研OS”，都特指对Linux内核做相应裁剪，并在此基础上开发中间件和应用软件。

华为的AOS，究竟是基于完全自研的OS内核还是基于Linux内核的中间件，外界存在两种说法：有不少人认为是“完全自研”，但也有不少操作系统领域的从业者认为，AOS仍是基于Linux内核的，但对Linux的内核做了深度裁剪、加了一些安全固件及特有的驱动程序，并在此基础上开发了中间件。

需要强调的是，“中间件”这个词的含义略显模糊——系统软件和功能软件里都包含了“中间件”，那企业自研的“中间件”，究竟是哪一块呢？自研操作系统可分为定制型和ROM型，定制型即修改了OS内核里的软件及“系统软件里的中间件”，而ROM型修改的范围则仅限于“功能软件里的中间件”。

此外，大众正在自研的自动驾驶OS，也是一个广义的OS。准确地说，是一个将Linux、QNX和VxWorks等多个底层OS整合到一起的平台。

OS内核：QNX 、Linux、VxWorks

以是否对需要执行的任务划分优先级为标准，OS内核可分为分时OS和实时OS两种。前者对各个用户/作业都是完全公平的，不区分任务的紧急性；而后者指在高优先级的紧急任务需要执行时，能够在某个严格的时间限制内抢占式切换到该任务上。

由于事关安全，自动驾驶需要的实时OS。QNX和VxWorks均属于实时OS，但Linux是分布式OS。

前段时间，有人质疑特斯拉“拿（Linux）分时系统做操作系统，是对生命最大的不负责”，然而，这个质疑未必成立——特斯拉的Linux系统是不是实时操作系统，以及是否按照车规级功能安全规格开发，还有待证实。

诚然，Linux原本是分布式OS，但Linux对应实时性改进的工作从未停止过。在经过优化后，Linux内核也分为抢占式内核和非抢占式内核，其中，抢占式内核的实时性足以满足自动驾驶的需求。

安霸半导体上海软件研发高级总监孙鲁毅在去年8月份发的《关于中国市场汽车智能驾驶主控芯片操作系统的思考》一文种提到，2005年，Linux2.6的发布，就开始支持内核可抢占式调度CONFIG_PREEMPT，此选项使得内核态程序只要不被spinlock保护或者在中断处理程序里，都可被更高优先级的内核线程抢占。

这就使得很多任务执行的时候，任务调度延迟大大改善。默认配置通常可以做到调度延迟在1到几个毫秒。实时性补丁CONFIG_PREEMPT_RT项目也已经比较成熟，可以手动打补丁添加提升内核的实时性。这些优化大大改善了Linux的实时性，使得Linux实际已经成为硬实时操作系统。

德国不莱梅大学曾做过一项测试，这项测试表明在系统满负荷长时间运转时，Linux标准内核不加任何补丁也不亚于常见各种实时操作系统的实时性。

QNX是一个半封闭系统，而Linux和VxWorks均是开源系统。所谓“半封闭”，即QNX的内核，客户是不能改的，但客户可自己编写中间件和应用软件；所谓开源，即所有内核源代码都向客户开放，客户可根据自己的实际需求裁剪，可配置性很高。

Linux基金会在2012年启动了开源项目Automotive Grade Linux （简称AGL），目前成员已经超过100家。当前，Linux在汽车市场的应用主要在信息娱乐系统，不过，AGL的最终目标，是提供满足安全关键系统的功能安全目标，从而服务自动驾驶应用。

按照AGL的设想，未来成员企业可以共享70%的代码，另外30%则是不同品牌厂商进行差异化开发，从而保障各自的商业化利益。

QNX早在2011年就通过了ISO26262 ASIL-D安全认证，这是第一个通过这项认证的实时操作系统。与Linux的免费不同，QNX需要商业收费，但凭着其安全性、稳定性和实时性，QNX仍牢牢占据汽车嵌入式操作系统市占率第一的位置。

QNX是微内核，即内核中只有最基本的调度、内存管理，驱动、文件系统等都是用户态的守护进程去实现的。其优点是超级稳定，驱动等的错误只会导致相应进程死掉，不会导致整个系统都崩溃。

据黑莓QNX IOT事业部大中华区首席代表董渊文介绍，目前，通用、沃尔沃、奥迪、上汽、吉利、蔚来、理想、小鹏等均用QNX作为自动驾驶OS。

黑莓提供给各自动驾驶客户的QNX系统是一个无差别的标准版，但BSP驱动是定制版。

BSP包括了Bootloader（以基础支持代码来加载操作系统的引导程序）、HAL（硬件抽象层）代码、驱动程序、配置文档等，是内核与硬件之间的接口层，目的是为操作系统提供虚拟硬件平台，使其具有硬件无关性，可以在多平台上移植。

与QNX相比，Linux更大的优势在于开源，在各种CPU架构上都可以运行，可适配更多的应用场景，并有更为丰富的软件库可供选择，因此，具有很强的定制开发灵活度。

并且，Linux是宏内核，即除了最基本的进程、线程管理、内存管理外，文件系统，驱动，网络协议等等都在内核里面，其优点是效率高，可以充分发挥硬件的性能。

此外，Linux的免费也对车企有很强的吸引力。

李星宇在演讲中提到，近几年，Linux在自动驾驶产业的使用率在攀升，“科技公司、Tier 1和车企均会基于Linux进行投入”。

但Linux内核的的组件要比QNX复杂得多，因而稳定性也要差得多，开发进程中的bug经常会导致整个系统挂掉。因此，基于Linux做开发的门槛很高。

张人杰说：“Linux平台有几千万行代码，而这些代码又不是你设计的，你怎么确保它的安全性？你只能是在外围做一些加减，你对代码的理解能力决定了你能否解决这些bug。目前，Lunix官方承认的bug就上万个了。在一定时间内，这些bug问题不大。但在某些条件下，就会引起很大的麻烦。”

Linux迟迟未能通过ISO 26262标准。相比之下，QNX的代码和功能架构都比较简单，代码也总共只有30万行代码，出现故障的可能性远远小于Linux。

基于Linux做开发的两大挑战：

1.作为开源的操作系统，Linux在被用于安全关键系统时，在代码库不断更新的情况下，存在安全认证失效的问题，因此，汽车制造商需要不断重新做安全认证，但这可能会带来额外的成本支出。

2.后续的补丁管理和版本对齐过于复杂。一家早期选择AGL的汽车制造商工程师表示，至少有4家Tier 1为他们的特定产品提供了不同版本的Linux内核，这意味着他们需要为不同的补丁管理4个不同的AGL内核。为摆脱这些麻烦，他们正在为下一代产品从AGL转向QNX作准备。

既然如此，Waymo、特斯拉、百度和Mobileye为何还要基于Linux做开发？成本考虑是一方面，更重要的，是为了减少对软件供应商的依赖，“这些代码都是开源的，而我的能力又足够强，可以在性能优化上做更多的工作。”

特斯拉就尝到了采用Linux4.4开源操作系统做开发的好处。由于自己完全掌握核心技术，不必受制于操作系统厂商，每次只要一发现问题便立即通过OTA进行快速修正与升级，提升用户体验。

简而言之，站在车企的角度看，QNX有点像Mobileye——尽管“易用”，但限制了车企的自主性；而Linux则有点像英伟达——比较“难用”，但赋予了车企很大的自主权及面向未来的兼容性。

随着车企对软件技术投入的加大和能力的提升，Linux在自动驾驶市场的占有率大将会逐步上升，而QNX的市占率则会逐步下降。

风河VxWorks的实时性已经在航空电子、医疗电子和工业安全等领域的几十亿台设备上得到了充分的验证。风河高级产品经理王鹏在此前的一次直播中说：任何“实时”Linux 的实时性都无法跟 VxWorks 相比。

VxWorks也是开源的。VxWorks实时操作系统由400多个相对独立、短小精悍的目标模块组成，但用户可获所有源代码并根据需要对OS内核在源代码层面进行裁剪和配置。

VxWorks的影响力主要在航空电子，汽车板块在其营收中占比的不高，因此，此前，风河的资源重点并没有放在汽车市场上。但近些年，风河对汽车业务的投入力度正在加大。

风河不光是能够直接卖商用性的产品，它也会提供专业定制化服务。在奥迪A8的项目中，风河除了提供VxWorks，还为TTTech汽车业务分公司提供了开发板卡支持包、中间件开发和网络栈集成。

宝马-ME-英特尔联盟的自动驾驶OS内核，一度采用了VxWorks。现代的自动驾驶量产车上也在使用Vxworks。

2018年10月，风河宣布其将为TTTech Auto最新版本的安全软件平台MotionWise提供支持，用于自动驾驶应用。

2019年2月，VxWorks通过了ISO 26262 ASIL-D认证。

VxWorks虽然和Linux同为开源系统，但两者的区别在于：后者是免费的，前者则要收取一笔高昂的授权费，开发定制成本也很高，这限制了其市场占有率的增长。

当然，各种自动驾驶OS之间并非截然对立的关系。

如百度的Robotaxi系统，一个比较普遍的说法是“在Linux内核上运行”，但赛灵思系统架构师兼市场总监毛广辉的说法是：感知部分是在Linux行运行，而非感知部分则是在QNX上运行。

奥迪A8上用了至少两套自动驾驶OS，其中英伟达的Tegra K1芯片上用的是Linux内核，而英特尔的FPGA Cyclone上用的是VxWorks内核。

简单地说，车企在选择OS内核时，主要考虑开放性、可扩展性、易用性、安全性、可靠性及成本等因素，再结合自己的需求及能力体系来做权衡。

各OS内核的简单比较如下：

表格中部分数据来自 安霸半导体上海软件研发高级总监 孙鲁毅的文章《关于中国市场汽车智能驾驶主控芯片操作系统的思考》

中间件：厂商提供or自研

在自动驾驶OS内核厂商中，风河还会为车企提供定制化的中间件。奥迪A8的FPGA Cyclone上跑的中间件，便由风河提供。此外，宝马—Mobileye—英特尔三方合作的项目中的中间件，也一度由风河提供。

但对车企或自动驾驶公司来说，使用OS厂商提供的中间件，只是权宜之计。到后面，每家公司都需要基于一个安全的内核来做符合自己独特需求的中间件。

如Mobileye在去年年底宣布，正在为下一代EyeQ5芯片切换到基于Linux的操作系统做最后的量产准备。按照Mobileye的说法，“宝马作为量产搭载客户之一，已经对这套系统进行了全方位的安全评估和严格测试”。

对于Mobileye来说，这也是其开放战略的关键一步。EyeQ5操作系统从之前专有的、定制的操作系统切换到Linux，将增加后续客户定制化开发的灵活性，同时向AGL超过100多家成员企业进行开放。

张人杰说：“一个车企相比于另一个车企技术的差异性、先进性，在很大程度上取决于你的整体框架，而框架又取决于OS的中间件组合，各种不同中间件最终组成了你的基础框架。”

因此，对车企或自动驾驶公司来说，自研中间件，不是你愿不愿意的事情，而是你必须去做的事。有进取心的车企，基本都在自研自动驾驶OS的中间件，只不过有的车企说出来了，有的没说而已。

QNX可为客户提供一部分中间件，但大部分中间件还是靠客户自己/委托第三方开发。只不过，由于基于QNX开发中间件相对简单，算不上多牛逼的事情，因此，很少有公司会在PR中强调自己开发了基于QNX的中间件。

如果使用Linux内核，则中间件就只能全部由自己来搞定了。这是一条更有价值、但也注定更艰辛的路。

张人杰说：“基于QNX内核做开发，车企是通过做加法的过程完成中间件的设计；而基于Linux做开发，则是先做减法、再做加法，难度显然要大得多。”（做减法的过程中，稍有不慎，就可能把重要的内容给裁剪掉。）

据前百度自动驾驶部门骨干成员透露，百度在跟车企合作的自主泊车项目上应车厂的要求而采用了QNX内核；但在要求更高的Robotaxi上，则基于Linux内核开发中间件。

百度开发的中间件并非是一个全新的系统，而是基于开源系统ROS做裁剪、打补丁，但这里仍然存在很高的技术壁垒。

ROS的前身是斯坦福人工智能实验室机器人项目的STAIR，后来由Willow garage 组织维护，它是免费开源框架，软件架构很清晰。原生的ROS本是机器人OS，并不能直接满足无人驾驶的所有需求，但百度针对原生ROS的弊端一一做了优化：

1. 原生ROS各个节点之间互相通信，需要依赖一个统一的ROS Master作为中转。如果ROS Master出问题了，则任何两个节点之间的通信便受到影响。

针对这个问题，百度Apollo 采用一种叫RTPS 的服务发现协议，对ROS做了“去中心化”改造。即现在的rosnode接口不再依赖于一个独立的master来进行管理，而是将其全部放置与一个公共域demain中，域中的每个rosnode都有域中其他节点的信息，这样就可以消除单点故障。

以上两段内容及图片摘自CSDN博主「逐风的小黄」在2019年3月份的文章《Apollo开源软件ROS定制版差异化分析》

2. ROS 传递的消息不支持向前兼容，接口兼容性问题会对历史数据的使用造成很大的影响。在自动驾驶领域，海量的历史数据是宝库，如果用不了，就造成极大的浪费。

对这一问题，百度Apollo框架采用的方案是使用开源的protobuf封装成ROS msg，来代替原生的ROS msg， protobuf 提供了良好的消息向前兼容性。

3. 如果一个ROS节点被挟持，黑客可以通过这个节点将资源耗尽，进而将这个系统搞垮。ROS node和node之间的消息被截获或者伪造，那么自动驾驶汽车可能会被黑客控制。

针对这一问题，百度采用linux container 这种轻量级虚拟化技术，把每个ROS Node 放入沙盒，限制每个ROS node 权限。节点与节点的通信消息可以进行加密解密处理，防止中间人攻击。

除了百度的Apollo，博世、宝马、nuTonomy、Autoware和Udacity等公司也基于ROS开发自动驾驶技术。

第三方软件公司Apex公司基于ROS 2.0开发自动驾驶软件，该公司花大量精力对ROS 2.0进行优化。在2019年2月份，Apex拿到了丰田、沃尔沃、捷豹路虎、海拉等车企和Tier 1的投资，这意味着，这些公司也在考虑使用ROS 开发自动驾驶技术。

但基于Linux内核和ROS中间件做开发这条路走起来会特别艰辛。

去年年底，某先前一直基于ROS做开发的自动驾驶明星初创公司宣布改用QNX的方案，对方的工程师给出的理由是：“QNX系统更安全，并且在可靠性和稳定性上有更大的保证”。

看来，在基于Linux自研OS失败后，车企及自动驾驶公司还有QNX这个“退路”可以依赖，这反而使他们在自研OS时少了些“后顾之忧”。

不过，中途从Linux 切换至QNX引发的工作量特别大。首先，两个内核的差异很大，这意味着，之前基于Linux开发的中间件现在都不能用了，得从头再来；此外，功能软件和算法迁移、优化的工作量也很大，甚至，有一些算法是需要做大幅度修改的。

因此，最各自动驾驶公司/车企来说，基于哪个内核做中间件的开发，最好能从一开始就对自己的需求、能力体系、风险承受能力做一个充分的评估，然后再选择最适合自己的方案。

自动驾驶OS的话语权会掌握在谁的手里？

那么，对车企来说，选择用什么内核做开发，是否完全可以自己说了算呢？这个问题的答案，有多个不同的版本。

董渊文的说法是，QNX已跟英伟达、高通等自动驾驶芯片厂商之间建立起深度合作，但跟英伟达是弱绑定，而跟高通是强绑定。即英伟达可以在Xavier、Orin中预集成QNX,但也会给车企自主选择权；而高通Snapdragon Ride的客户则只能用QNX作为自动驾驶OS，“没有自主选择权”。

一自动驾驶初创公司的工程师说，他们使用的QNX是黑莓和芯片厂商针对特定芯片集成优化后的版本，保证在该芯片上可以达到最优的系统性能。

张人杰认为，QNX跟英伟达和高通的捆绑，很容易理解。“一个OS做出来了还不够，想要获得成功，其核心点还在于建立一个强大的生态（软件+硬件）。没有强大的芯片，先进OS的优势也发挥不出来。在行业竞争的前期，OS厂商一定要跟芯片厂商形成非常强的战略耦合。”

这种绑定，是双赢，不仅OS厂商可以通过跟芯片厂商的绑定做大软件的安装量，芯片厂商通过跟安全可靠的OS捆绑，也会让芯片更好卖。

但某自动驾驶芯片厂商CMO认为，这只是一种过于乐观的假设，“对QNX来说，只有全面拥抱芯片公司，芯片公司才能把你的OS推给OEM，但OEM就非得选你吗?”

这位CMO说：“现阶段，QNX是性价比最高的方案，但如果你不是足够好的话，哪怕芯片厂商再怎么推，OEM也不会选你，然后，芯片厂商也会转而扶持另一家OS厂商。Windows以后，再在任何行业出现下一个如Windows这种有话语权的OS的可能性非常低。“

博世AI部门一位管理人员说：“芯片不会愿意被某一个OS给绑死的，除非芯片就是这家OS厂商自己的，像苹果的M1之于MacOS。”

安霸孙鲁毅曾在文章中提到：“汽车市场的OS选择主要来自于开发团队的经验积累，或者来自于主控芯片厂的SDK的默认支持。”所谓默认支持，即芯片厂商的SDK基于哪个OS开发的，就决定了车企只能用什么OS。

但也有许多人并不认同这种说法。

如某主机厂自动驾驶负责人说：“OS通过中间件可以和芯片在软件上解耦。”

某自动驾驶初创公司工程师说：“自动驾驶芯片厂商的SDK通常不会只适配一个OS，客户主要还是根据自己的需求选择最合适的OS。我们用英伟达的芯片，但QNX和Linux的OS我们都使用过，不存在被芯片供应商绑架的问题。”

上述芯片厂商CMO说：我们推出的SDK会兼容多个不同的OS。如果客户有某种特殊要求，我们会额外增加。

国内操作系统初创公司国汽智控CEO尚进在接受采访时说，国汽智控对整车厂的一大吸引力便是“不绑定芯片供应商”“华为、地平线、黑芝麻以及英伟达都是我们的合作伙伴”。

总的来说，对使用什么样的OS，车企和芯片公司的话语权是高于OS厂商的。一位受访者说：“话语权来自于谁离用户更近，OS当然有一定的决定权，但OS提供的只是基础功能，应用层都是车企一方做的，因为它离用户最近，知道用户需要什么。”

董渊文在演讲中提到：“QNX没有自己的Roadmap，主机厂的意志和钱，决定了QNX的Roadmap。”这也印证了“车企的话语权更大”一说。

不过，地平线CEO余凯认为，如果在未来出现一个“智能汽车OS”，将自动驾驶OS和智能座舱OS整合到一起，并建立起强大的开发者生态和应用生态，则这个OS在车企面前会有比较大的话语权。

国汽智控副总裁杨柯和地平线市场拓展与战略规划副总裁李星宇都提到一个观点：从IT时代30来年的历史看，通常，一款OS只会基于一款硬件架构进行深度打磨，无论PC时代的win-tel还是移动互联网时代的安卓—ARM都是如此。你很难在ARM上面把windows优化得特别到位，也很难在x86架构上面把安卓优化得非常到位。