有关智能操作系统的讨论

原文地址：http://www.fullstackengineer.net/zh/blog/weiyongming/5857e45ef34acfa6e680ebab6dfcb989

引言

“@空明魏 发了条微博说下一代OS。我对自称OS这事没以前那么反感，OS现在已成你国一种hype...” 这是就最近本人发起的“下一代智能操作系统开发讨论”给出的其中一条来自 @有个梨UGlee 的评论。从三年前阿里 YunOS 被大众知悉以来，有关自主操作系统的各种争论和业界动作连连不断，呈现欣欣向荣之势。在博主本人发表《“自主”操作系统，为什么及如何？》这篇文章以来，我也一直在头脑中探索到底应该如何做操作系统，操作系统是否还有可做的空间？本博客即是对该问题的一个思考及部分回答。同时，本博客也是国内众多软件界高手参与讨论的结果整理。

魏永明 2015-03-24 09:08 CST

•  
•  0 
•  0 
•  0

智能操作系统开发倡议

以智能手机为代表的智能设备为移动互联网的发展奠定了坚实基础，但我们未能抓住智能手机发展的大好时机，智能设备上的关键系统软件——操作系统——仍然被老美把持。即使 Android 是开源的，但我们所做的事情，除了换几个皮肤、加固一下安全之外，仍然未能掌握核心技术，也无法打造完整的围绕操作系统的生态系统。

现在，除了智能手机之外的智能可穿戴式设备、智能机器人以及其他所有可冠以智能两字的设备成为下一个移动互联网、互联网+、物联网或者车联网的发展方向。同时，Android Wear 不再开源，这将带给我们发展自主操作系统的绝佳机会。

与此同时，国内的软件工程师水平也有了长足进步，主动参与开源运动的国内软件工程师越来越多，具备了一定的实力可以和海外的工程师一较高下。国内的风险投资快速发展，越来越多的风险投资商开始关注并投入到纯技术的创新项目中。

在这天时地利人和之际，本人发起此项倡议，征集三到五名国内的顶级系统软件高手，面向全球市场开发智能设备操作系统。

魏永明 2015-03-24 11:54 CST

•  
•  0 
•  0 
•  0

下一代智能操作系统设想

下一代智能操作系统的思路是这样的。首先，这个操作系统是传统通用操作系统的一个封装，而不是要替代现有的传统、通用操作系统，以下先简称为 NGSOS（Next Generation Smart Operating System）。NGSOS 主要有两个特征：一个是统一的开发语言，另外一个是一次开发完成然后可运行在所有的现有操作系统之上。在 NGSOS 上，不同的设备或节点承担不同的角色，可以划分为客户端、服务器端和中继端。这些节点之间通过类似 DDP 的协议和 IM 协议同步和传输数据并进行各自的展现或处理。比如在智能手表上，主要负责收集数据然后发给智能手机，智能手机再发给云端服务器进行处理。这种情况下，智能手表是客户端，云端是服务器，智能手机是中继端。

一种实现思路是这样的：将现有的浏览器功能做扩充（同时要移除不必要的兼容性包袱），使用 JavaScript 或 CoffeScript 为主要编程语言，通过扩展的 API 访问设备资源，使用类似Meteor 的方式实现客户端和服务器端的数据交互（需要 WebSocket 支持），另外通过即时通讯机制，提供数据流的访问和处理许可机制。这样，浏览器将化身为 NGSOS 的操作系统外壳。在设备端，该浏览器运行在 Linux 的 Docker 容器中，用来增强安全性 ，并限制应用的设备资源访问能力。在服务器端，主要的服务由 Node.JS 提供，但还可以通过即时通讯机制扩展后台服务器的处理能力，用来接入 PHP、Python 等语言开发的服务器处理软件。在中继端（智能手机）中，通过运行定制的浏览器来参与处理或展现相关数据，应用的开发过程将和普通的 WebApp 一致，通过 PhoneGap 等的支持封装成原生应用运行在 Android 和 iOS 上。

当然，也可以从头设计一门新的编程语言，最好是支持编译执行，同时支持解释运行，然后使用包/类接口来扩展各种各样的功能。

这样在智能设备端，人们可以使用 Linux 或者 RTOS 来开发自己的框架应用，而其他的应用，尤其是可下载的应用，则基于 NGSOS 来开发。RTOS 或者 Linux 上的原生 APP，主要用来开发框架和系统应用，尤其是那些和底层设备直接打交道的应用。

鉴于 JavaScript 语言的的诸多问题，最终引入一种新语言是必要的。但一种可行的技术路线是 JavaScript 和新语言并行开发，前者是个保障，后者面向将来。

魏永明 2015-03-24 09:15 CST

•  
•  0 
•  0 
•  0

花絮

在仔细说明下一代智能操作系统设想的进一步细化之前，先说说高手们在一起讨论的情况，让大家感受下。

花絮一：微信群红包之争

话说我在上个周日（3月22日）晚上八点建立了一个名为“下一代智能操作系统开发讨论”的微信群，并在微博上公布了微信群二维码。很快加入人数就达到了四十人之多，并且引来了一堆做“微商”和“生意”的群友。来者就是客嘛，只要不说话，不发广告，我就睁一只眼闭一只眼了。可恨的是，第二天我们邀请广州周立功（周公是技术创业的楷模，现在是世界级高端示波器的领导者）入群。周公一看这么多高手，手一抖，发了个五千块的红包。大家一个劲抢啊！结果一看，抢到最多的居然是不搞软件的无关人等。这可了得？于是我立马移除了大部分一看就知道不是相关人等的人员，并制定了入群规则，并让一位抢了最多红包的女生吐出来一些回馈给大家。这样我心里才平衡一些。

之后的周一（3月23日），这个群的成员很快就超过了一百人。看来关注相关议题的高手很多哇！这给我这个群主更大的压力，要管好、呵护好这个群————这个群可是代表中国软件业最高水平的人员集聚地啊！

那么这个群里都有哪些高手呢？待我写几个出来：

• RT-Thread 创始人午夜熊以及主要开发者；
• ElastOS 发起者陈榕以及主要开发者；
• sylixOS 创始人韩辉；
• SkyEye 创始人及 ucore 操作系统发起人，清华大学副教授陈渝；
• CSE 编程语言作者 Wayne Chan；
• Blot UI 架构提出者，迅雷高级工程师刘智聪；
• 华米科技美国总经理李晓峰，对编程语言有很深造诣；
• 知名计算机软件专家潘爱民（曾任阿里云OS首席架构师）；
• 外号老铁的计算机博士章锋。

还有来自华为、小米、优酷等国内顶尖IT及互联网企业的高管或技术主管，恕不一一罗列。

花絮二：如有雷同，纯属巧合

刘智聪在微博上和我互动，提到他曾经也有个类似的想法，他称为“NGOS”，就差一个字母，而其关键思想更是如出一辙。初一看，刘智聪还以为是自己写的东西什么时候泄露了呢。这应了一句话：“英雄所见略同”。不过，就连名字都能取得差不多的情形，还真是少见。

花絮三：对各种编程语言的吐槽

由于操作系统和编程语言的密切关系，再说大家整天和各种编程语言打交道，编程高手们在一起，自然就会提出对各种编程语言的吐槽。

受吐槽最多的语言是 JavaScript，这个当今浏览器中唯一的编程语言。虽然有很多问题，但架不住没有其他可选的。其次是 Python，这个语言最大的问题是版本不兼容问题。被大家戏称为“版本帝”。另外，有些人认为 C++ 很好，有些人认为 C++ 过度设计太臃肿。在高手们看来，Swift 是当前设计最好的编程语言。不过 Java 呢，C# 呢？

有关语言的讨论会无休止进行下去。那到底能不能设计一门完美的语言？这也是我们下一代智能操作系统需要仔细琢磨的问题。

花絮四：外围码农

为了保证讨论质量以及保护众多高手隐私，微信群需要限制参与人员。这让许多码农失去了和众多高手直接交流的机会。对这点，本人深表歉意。为了补偿，我会按时整理讨论的情况，给大家一个汇报（主要通过这篇博客进行）。当然，这么做也是为了保持一点点神秘感，所谓“距离带来美”嘛。另外，大家还可以选择通过微博和本人以及其他高手互动。

我们把这些不能参与微信群讨论的程序猿或程序媛称为“外围码农”。怎么，这个名字不好听？像“外围女”？大家都自称“屌丝”呢，“外围码农”更好听的（纯粹玩笑啊，大家别当真哦）。另外，要是大家能提出真知灼见，这个微信群的大门还是给大家敞开的。:)

好了，接下来言归正传。

魏永明 2015-03-25 00:00 CST

•  
•  0 
•  0 
•  0

下一代智能操作系统设想之进一步细化

对我所提出的下一代智能操作系统之设想，这里做进一步的细化。在细化之前，先看看外围码农的评论。

@有个梨UGlee @空明魏 发了条微博说下一代OS。我对自称OS这事没以前那么反感，OS现在已成你国一种hype；但下一代这三个字我严重不满，只有一种OS算下一代OS：软件开发、部署、存储三件事情都在云端不在本地，否则就不能叫下一代OS，目前只有ChromeOS符合此定义。

@盗跖怒丘 首先赞一下，感觉描述的跟智能有出入，是一个移植性非常好的framework,可以run在现在所有的操作系统之上．这个没仔细考虑过，学习了．我对＂智能＂这个方面有个想法,我们能否开发一套库和语言，库里面有一些智能化逻辑，语言支持动态改变code，从而迭代？

@tipsky 感觉是个中间层，是个业务容器。

回复@tipsky:看如何定义了，从哪个角度看了。

回复@空明魏:从服务的角度看是OS，屏蔽所有差异平台。

我的操作系统概念

从上面的评论可见，大家对下一代操作系统的期望有所不同，站在不同的角度会得到不同的结论。

现代操作系统的概念，在上个世纪七十年代末由贝尔实验室的两位图灵奖获得者通过 UNIX 获得广泛认同。在其后很长一段时间内，操作系统被认为是管理计算机硬件资源的主要软件层。操作系统将 CPU、RAM、存储、网络、外设等硬件对象抽象为一系列可编程的对象；其中包括进程、文件、文件系统、虚拟内存、用户账号、虚拟字符（块）设备、套接字等等。从那时起到现在，操作系统的基本概念没有太大变化，为今天互联网的形成起到了重要的奠基作用。

那么下一代的操作系统会是什么样？要回答这个问题，我们需要看当前传统操作系统走到了那一步。笔者愚见：传统操作系统基本上没有啥可继续深入做的了，也就是说，相关技术已经发展到了极致。有兴趣的读者可以看看我另外一篇博客（“自主”操作系统——为什么及如何），其中讨论的就是传统的操作系统。

我所提的下一代智能操作系统，是构建于传统操作系统之上的分布式、“虚拟”操作系统。我们可以将传统操作系统看成是单机操作系统，它们运行在实实在在或者被虚拟化的计算机之上，管理这个计算机的硬件资源。所以，我们在扮演不同计算机角色的系统上使用各种操作系统和不同的编程语言、平台或框架进行开发。比如，在 PC 上，针对 Windows .Net 平台，使用 C++ 或者 C# 编程；在智能手机上，针对 Android 使用 Java 语言编程或针对 iOS 、Objective-C 或者 Swift 编程；在服务器上，针对 Linux 使用 PHP、Python 等语言编程等等。

于是，我们的软件工程师要学会和理解的东西越来越多，相关的技术也越来越复杂。在这种情况下，人们开始寻求可能的统一解决方案。在我的设想中提到的 Meteor 则是其中的一个典型。

当前，Meteor 针对 Web 应用的开发提供了两个最为关键的特性：

• 前后端统一编程语言为 JavaScript。也就是说，后端和前端使用同一种编程语言，并且被组织到了一起，可以交叉重复利用。这在当前流行的 PHP 后端开发技术中是难以做到的。
• 通过动态数据交换协议（DDP），将前端数据操作和后端数据操作无缝连接了起来，从而抹平了前端和后端的代码差异。

这两个关键特性使 Meteor 如日中天，成为美国硅谷 YC 孵化器的明星创业项目。当然，值得一提的是，Meteor 技术利用了很多已经趋于成熟的其他开源项目，比如后端的 Node.js、MongoDB、前端的 jQuery 等等，而且目前仅针对 Web 应用。Meteor 所做的工作可以简化为如下要点：针对上述关键特性整合了大量现有的开源软件和技术。

如果我们结合传统操作系统的概念以及 Meteor 项目所带来的新思路，我们可以做如下思考：

• 我们能否跳出单机概念，将整个互联网看成是下一代操作系统主要面对的“硬件”资源？
• 我们能否将互联网上运行的服务、应用、带宽、数据流等像传统操作系统那样做进一步抽象，进而设计出一种新的操作系统？

答案是肯定的，尽管我们尚没有开发出这个系统。但从技术的发展来讲，任何全新技术的出现都需要相关技术有一定的积累基础，然后在更高的层次上进行抽象，提出一套自洽和完备的架构出来。这个架构就是下一代操作系统的雏形，然后充分利用现有的技术积累，尤其是开源软件，将其实现出来，并持续迭代。

如此，下一代智能操作系统的概念基本上就清晰了，要点如下：

• 下一代智能操作系统将面向互联网业务，运行在各种可能的单机操作系统之上。
• 单机操作系统将作为类似驱动程序那样的作用而存在于下一代智能操作系统中。
• 下一代智能操作系统通过抽象互联网业务的硬件实体，隐藏单机操作系统所提供给我们的各种细节，从而让开发者可以在更高的层面、更接近业务的层面上设计软件、开发软件。
• 下一代智能操作系统有可能通过单个编程语言来开发所有单机操作系统上的应用或业务组件。

如果按照这个思路设计下一代智能操作系统，这个系统将不再是一种框架，而的确就是一个实实在在的操作系统。

魏永明 2015-03-24 12:33 CST

•  
•  0 
•  0 
•  0

下一代智能操作系统之架构初探

那么下一代智能操作系统如何做抽象呢？笔者这里先给出一个典型的应用场景。

设想现在互联网、物联网、智能设备的发展趋势，就拿智能手表为例。智能手表为代表的智能设备将在很长一个时间内作为智能手机的伴侣存在。智能手表展示时间、天气以及来自智能手机的提醒等等，并采集一些健康相关的数据交给智能手机做更好的展示和分析。智能手机可进一步将这些数据传输到云端服务器做处理，然后通过大数据、深度学习等高大上的计算，提供给用户一些健康建议，更好完成一些健康和生活习惯方面的建议。如此等等。

在这样的场景中，我们发现智能手表这类智能设备是受限的计算设备，屏幕小、功耗要求高等等。受限于硬件发展，这种形态可能会存在较长一段时间。有些智能家居设备可能连屏幕都没有，只是在那里默默采集数据默默控制家里的开关、温度和湿度等等。但无论如何，这些设备要和其他具有更强计算能力的设备互联，比如智能手机和云端服务器。因此，互联网化将是我们所讨论的这种业务的最本质特征。

为了描述方便，我们可以将所有参与此种业务的计算机软件一个明确的分类：服务器、客户端和微客户端，分别对应于服务器端应用、智能手机上运行的应用以及在智能手表上运行的应用。

这样，下一代智能操作系统将跨这三类应用，在各自设备上的传统操作系统支撑下运行。

在这样一个场景下，我们可以将某些东西做如下抽象：

• 容器。容器对应于传统操作系统上的进程概念。每个容器是一个完成特定应用任务的进程组。
• 数据流。数据流对应于传统操作系统上的文件或管道概念。容器接收、处理数据并产生数据。
• 存储。存储对应于传统操作系统上的文件系统概念，将提供直接基于 SQL 或者 NoSQL 数据库的存储抽象机制，应用无需处理文件及文件系统。
• 容器名。容器名对应传统操作系统上的文件名或套接字概念。容器之间通过符合某种规范的名称来找到对方或多方，建立信任关系后可互相发送数据。
• 数据处理驱动器。数据处理驱动器对应于传统操作系统上的驱动程序概念，本质上就是其他的传统操作系统实例。这些传统操作系统实例通过互联网协议连接到我们的下一代智能操作系统上，获取数据并通过 Java、PHP、Python 等语言进行数据的分析和处理，然后再反馈给其他容器。

这就是下一代智能操作系统的雏形。要我画个图吗？等我有空的时候补上吧，大家先脑补一下。

魏永明 2015-03-24 11:27 CST

•  
•  1 
•  0 
•  0

一些设计和实现细节

为了让大家对我所描述的下一代智能操作系统有个更具体的理解，这里给出一些设计细节供参考。

在设想中，我们提到将下一代智能操作系统建立在改造后的浏览器之上。但关键点并不是浏览器的 HTML5/CSS 渲染技术，而是建立在 WebSocket 或者传统 IM 机制上的消息机制。

通过 WebSocket 和 IM 机制，我们的容器名称将变成我们所熟知的微信号、QQ号等东西。当然，要区分不同的应用以及同一账号的不同设备。这样，我们的容器名将是：

@/

熟悉 XMPP 协议的人肯定知道这个名称是怎么来的。

类似针对文件的操作，在下一代智能操作系统中，我们通过上面的容器名来建立容器之间的连接，然后就可以通过 IM 机制互相传递消息了。用消息可以做什么？你可以实现请求和应答机制，也可以做数据收集，还可以做其他很多事情。就如同现在微信的公众号所做的事情那样。

当然，怎么发现连入同一个业务的其他容器呢？这就需要一个目录服务，提供类似文件系统遍历那样的机制。然后通过添加好友、同意请求等机制建立信任关系（这就是 Apple Watch 和 iOS 设备配对的过程）。当然，我们还可以通过 OTR（off-the-record，免记录）机制给建立连接的容器的通讯做加密处理。这点很重要，因为智能设备上的数据对使用者来讲，将是非常敏感的。

另外，我们还可以对同一个业务中的容器建立群组关系，或者订阅关系。嗯哼，是不是看到微信提供的各种服务的影子了？这就是腾讯为什么提出“微信连接万物”这个口号的原因。只是，当我们的下一代智能操作系统开发出来之后，你自己就可以连接万物，而你自己的数据将出现在自己信任的容器里边，不会跑到腾讯的服务器里边。

对运算能力比较弱的智能设备怎么办？其实问题不在我们一定要使用浏览器，而是要提供上面的抽象机制，这些抽象机制最终会演变成 API 槽，传统的操作系统需要实现这些槽，进而就可以将我们的容器运行在下一代智能操作系统中了。

那要是运行在已有的智能手机操作系统上，我们打算怎么办？其实我们也许不需要自己扩展一个浏览器。我们只需要提供一个服务，这个服务提供本地的 WebSocket 端口，并接收来自智能手表的数据，然后由浏览器中运行的 WebApp 连到这个 WebSocket 上就可以了。

魏永明 2015-03-25 10:00 CST

•  
•  0 
•  0 
•  0

为下一代智能操作系统开发一门新的编程语言

如前所述，为下一代智能操作系统开发一门专门的编程语言是可行的。这门编程语言不是如 C 那样的低层编程语言，而应该如 JavaScript 或者其他脚本语言那样，易学易用，同时是面向下一代智能操作系统抽象对象的编程语言。

但是，从工程的角度来讲，一门新的编程语言要变得成熟而被广泛接受，需要很长的时间。所以，务实一些的话，我们应该选择 JavaScript 或者 CoffeScript 来开发下一代智能操作系统，同时并行开发我们的专门编程语言。等成熟后再推广给开发者。

如此，大事可成也！

魏永明 2015-03-24 11:52 CST

•  
•  0 
•  0 
•  0

国内操作系统大PK

今天（3月24日），博主建的“下一代智能操作系统开发讨论”微信群，迎来来 DJYOS 等操作系统的主要开发者。这样，除了 COS、TVOS、YunOS 等国字头的操作系统没有代表参与本群讨论之外，基本上所有由说中文的开发者主导开发的操作系统都参与了相关讨论。

国内操作系统大阅兵

我们先看看国内都有哪些操作系统。注意：以下排名不分先后；来自操作系统的官方介绍用词经本人编辑并稍作修改，以求客观中立。

• SylixOS。SylixOS 是目前国内功能最为完整的实时内核通用操作系统，全球第三个支持多核实时调度的 RTOS，性能与 VxWorks 相当，同时内核还提供了丰富的外设与文件系统类型支持。SylixOS 符合 IEEE1003/IEC9945/POSIX 规范，实时性方面符合 POSIX 1003.1b 规范。由于 SylixOS 接口的标准符合性，使之可以支持 GNU/Linux 上的多数应用程序，其中包括 Qt、MySQL 及 Apache 等。SylixOS 同时提供 VxWorks 软件兼容层，其中实现了 VxWorks 6+ 80% 的接口。SylixOS 不仅仅提供 C/C++ 编程，同时也支持 Python 等其他编程语言，开发者可通过完整的集成开发环境与虚拟机实现应用软件的开发。目前，SylixOS 主要支持 ARM v4-v8 体系架构，对 IA32 的支持由清华大学贡献，未来计划支持 PowerPC 和 MIPS 架构。

• RT-Thread。RT-Thread 是国内曝光率最高的自由（GPL V2 许可证）RTOS，曾获开源社区评选奖项。RT-Thread 现已由纯粹的社区驱动转变为商业公司（赛瑞德）运作。RT-Thread 目前除了用于工控等实时要求高的系统之外，同时还尝试为新兴的智能可穿戴试设备提供方案。

• DJYOS。DJYOS（都江堰操作系统）是一种开源 RTOS，遵循 BSD 许可证发布，目前主要应用在工控领域，近期目标是替代 VxWorks。创始人期望通过开源社区合作模式打造一款通用操作系统，在不远的将来替代 Android 等智能操作系统。DJYOS 目前由自动化领域的专业公司（深瑞）主持开发。作为 RTOS，DJYOS 的调度实现机制有些特点，内核采用事件驱动模型开发，但仅提供基于 ANSI C 的开发环境，包括一些私有的 API。据主要开发者描述，DJYOS 可以不修改任何代码而支持 64 位处理器架构，并且在容错方面有自己的特长，可以在系统崩溃重启期间和启动关机过程中响应中断，还提供有优化的内存分配机制等。DJYOS 当前提供对 ARM 和 PowerPC 架构的支持。

• Elastos。Elastos 是面向智能设备的类 Android 操作系统，提供了 Android 兼容接口，同时还提供了一套 C++ 的 Android 兼容 API 接口，目标是替代 Android 系统。Elastos 内部使用了 CAR 技术（其作用类似微软的 WinRT），然后通过 CAR 技术来提供针对不同编程语言的接口层。

• Deepin Linux。Deepin（深度）Linux 是一款面向桌面的通用操作系统，属于 Linux 发行版范畴。深度 Linux 的最大特点是重写了许多 Linux 桌面上的常见应用软件，以求提高 Linux 发行版作为桌面操作系统的产品化程度，使之可以在一定程度上媲美 Windows 系统。

• 元心操作系统（抱歉没找到官网）。元心操作系统的主要开发者也介绍了元心操作系统的情况。目前，元心操作系统提供 Linux+Android+Qt 的混合模式，用户可以使用 Android 开发应用，也可以使用 Qt 开发应用。据主要开发者描述，元心操作系统在某款智能手表中表现良好。元心操作系统可能是这里唯一一个国字头操作系统了。

上面这几个操作系统基本上可以说是国内正在活跃开发的操作系统之典型范例了，代表了不同的产品思路。读者在接下来的描述中会看到非常有意思的争论。

不过在给大家介绍高手们过招的细节之前，我先吐槽一下这些操作系统的官网。当然，大家可以一一点开来看看就知道我要吐槽什么了：

所有的官网都还停留在 Web 1.0 时代，更不要说兼容移动端了！当然，Elastos 的官网有点 Web 2.0 的影子，可是很不稳定。据说是把服务器放在了公司里边，所以周末的时候会关机。听到这个，我的这个汗啊，那是止不住的流！

魏永明 2015-03-25 12:29 CST

•  
•  0 
•  0 
•  0

高手在群里过招，最嫌爹妈只给生了两只手

周二（3月24日）傍晚，群里就有关操作系统的定位讨论到了白热化阶段。说实话，混乱了好一阵子，谁也无法说服谁。其中主要的议题集中在 Elastos 兼容 Android 这一特性上。

Elastos 开发者认为，通过兼容 Android 才能充分利用 Android 生态中已有的应用。比如，Elastos 推向市场时，我们就可以说所有的 Android 应用都可以运行在 Elastos 上，重新编译都不要。然后，等到有一定地位了，开发者尝到用 Elastos 的甜头了，告诉他说，其实你的应用跑在 Elastos 上而不是 Android 上，怎么样，比谷歌的 Android 好吧。然后，Elastos 最终抢占 Android 的份额，厂商纷纷找 Elastos 合作，开发者开始使用 Elastos 提供的其他 API（C++ 的，性能更好）。最终，Elastos 踢掉谷歌，成为智能手机操作系统的新霸主，制定规则并赚取商业利益。

对这一模式，高手的看法明显分成了两派：

• 必须兼容派：兼容是必须，不兼容没戏唱。
• 兼容无用派：兼容是死路一条。

当然，还有一派认为应该是看情况确定。这个按下不表，将来再说。

我们先分析 Elastos 路线中的逻辑问题。注意，我们经常看到一些洗脑的话（俗称“心灵鸡汤”），里边有“所以”或者“然后”两个字，很多人就以为后面的结论是自然得出来的，是符合逻辑的，少有人去仔细分析其实“所以”或者“然后”两个字之前根本就没有靠得住的论据。

在博主看来，Elastos 路线中存在如下几个重要的逻辑硬伤：

• 当你推出 Elastos 并以兼容 Android 为卖点时，用户（这里指开发者）可能接受了，也许是因为 Elastos 的性能要比谷歌的 Android 好一些，或者谷歌的 Android 尚不支持用户选择的硬件平台，或者你会给用户钱（如同阿里 YunOS 干的那样）。反正最后用户用了你的系统。但注意，用户用 Elastos 的根本原因是 Elastos 兼容 Android。所以，用户会继续用 Java 的 Android 接口来开发他的应用。因为兼容是 Elastos 的卖点，而且 Java 的 Elastos 应用还可以跑在谷歌的 Android 上，那为什么要用 Elastos 的 C++ 接口？在这种情况下，Elastos 号称的其他好处，恐怕没有几个用户会真心实意地尝试，而且 Elastos 的实现一旦有不兼容的地方，或者 Android 升级带来了接口变化，用户肯定会首先要求 Elastos 修改系统，使之 100% 兼容。其结果就是，在用户眼里，Elastos 就是 Android，充其量就是个优化或者适合特定硬件平台的 Android 实现。Elastos 里边的 CAR 技术，对操作系统的实现有意义，但对用户没有意义。
• 这个路线没有考虑到兼容一个良性发展的生态系统之操作系统（Android）的最大风险：Android 自身的升级和优化。毋庸置疑，Android 现在正处在一个良性发展的生态系统中，Android 自身的更新速度非常快。Elastos 选择兼容 Android，也要不停兼容 Android 的升级版本。这其中的难度将是巨大的。说白了，Elastos 的路线做了一个非常大胆的假定：Android 将停滞不前。这样的一个假定下得出的结论是靠不住的。

也就是说，Elastos 路线中的第一步可以跨出去，但接下来发生的事情是不太可能按照自己设想的路线前进的。

经过两派的唇枪舌战，两派谁也未能说服谁。Elastos 开发者最后的陈述如下：

手机市场很大，哪怕我们仅占一点点市场份额，也会很大。执着是我们的理念。

魏永明 2015-03-25 12:31 CST

•  
•  0 
•  0 
•  0

兼容之争在第二天继续

兼容之争在周三（3月25日）继续，毕竟我们没有得到一个大部分人都认同的结论。不过，Elastos 的总架构师陈榕博士趁着凌晨人少时分阐述了一下 Elastos 的设计理念：

兼容 Android 应用就没有前途吗？Elastos 用 C++/CAR 重新实现了 Android 框架，主要是为了实现分布式系统。俗称为“家庭云”。...

其他的我没看懂，估计大部分人也看不懂，所以我就不写了。

博主本人是兼容无用派，所以我对 Elastos 的看法是：

Elastos 操作系统的设计理念很先进，未来也看起来很美好，但却陷在了兼容 Android 的泥潭中无法自拔，动弹不得。Elastos 的路线需要反思。

我为什么认为兼容是无用的呢？先给大家打个比方：

某个人把 Android 的内核从 Linux 换成了 BSD，那 Android 还是 Android 吗？几乎所有人针对这个问题的答案是肯定的。那么，如果把 Android 的虚拟机换成自己的实现（阿里 YunOS 最初就是这个路线），还是 Android 吗？大部分人针对这个问题的答案还是肯定的。这个问题继续演进；如果把 Android 里边所有的东西都换了，但还是提供 Android 一样的 API，一样的框架，一样的系统应用，一样的界面效果，那还是 Android 吗？笔者的回答仍然是肯定，读者您呢？

博主认为，一个操作系统区别于另外一个操作系统，最本质的部分就是 API。这点在博主本人的其他文章中有过多次阐述。只有 API 是操作系统的 DNA，其他的都不是。

有关兼容这个问题，兼容无用派的很多群友还提到如下事实：iOS 替代功能机没有选择兼容，Android 通过谷歌占得巨大市场份额，没有选择兼容，那么为什么我们做操作系统首先想到的就是兼容呢？

可能 Elastos 工程师的回答比较引人深思：

我们曾尝试推广自己设计的 API，但发现根本没有人用，我们自己也不用。

Elastos 工程师甚至怀疑我们自己是否有能力设计一套自己的框架和 API。

魏永明 2015-03-25 12:32 CST

•  
•  0 
•  0 
•  0

理性的分析结论

周三（3月25日）上午，兼容之争终于落下了帷幕。在此之前，博主需要阐明两个概念：

• 复制或模仿。偏市场的人员通常会使用这个两个词。
• 兼容。偏技术的人更多使用这个词。

这两个术语在市场人员和技术人员共同参与讨论问题的时候会出现很大的混乱。技术人员认为说复制、模仿就是技术层面的兼容；而市场人员听到技术人员说兼容以为谈的是复制或模仿。这里需要分清楚：复制或者模仿是产品层面的，而兼容是技术层面的。

在接下来的讨论中，博主兼群主使用了问答式方法来主持讨论。

第一个问题是：为什么人们会想到兼容其它系统？这是由于，市场上某个系统已经有大面积的市场份额，大家想兼容他，就是利用人家形成的生态系统。

第二个问题是：复制/模仿和兼容的区别是什么？复制/模仿和兼容不是一个层面上的东西。Android 模仿/复制 iOS，但搞的不是兼容。这就是区别。

第三个问题是：如果我们要做智能手表操作系统，有没有必要复制/模仿 Android Wear，有没有必要兼容 Android Wear。就兼容这个子问题，其答案可采纳群友的话：

没必要，因为 Android Wear 也是不够成熟。

对是否有必要复制/模仿 Android Wear 的问题，同样引用群友的话：

当我们对功能和特性感到迷茫和纠结的时候，看看 Android Wear 或 Apple Watch

结合博主针对 ElastOS 的分析，我们基本上可以就兼容问题盖棺定论了：

按照必须兼容派的观点讲，是否兼容要看对方是否已经形成了一个良性发展的生态，就是是否已经有众多的开发者为那个系统写应用；然而，当这个系统已经形成了良性发展生态的时候，博主认为已经没有机会了（具体分析见上个小节）——兼容也是白搭。

其实，兼容就是个悖论，嘿嘿嘿...

魏永明 2015-03-25 11:42 CST

•  
•  0 
•  0 
•  0

再回到智能操作系统上

就兼容的讨论基本落下帷幕之后，群众的讨论进一步深入下去了，并将议题限定在智能设备（尤其是智能手表上）。主要议题集中在：

• 我们是否有能力设计一套自己 API？
• 智能操作系统如何做？

精彩明天继续，敬请期待。