新时代新潮流 WebOS【5】何为系统，何为核心

前两篇说了不少 Android 的好话，有人质疑是不是有蓄意吹捧 Google 的软文的嫌疑。又有人抱怨前奏过长，有跑题的迹象，何不尽快切入正题谈 WebOS。我的想法是这样的，假设我立刻说 WebOS 的招式是上三路拳法，WebOS 长治久安的策略是主动谋求与 Android 融合，大家是不是会觉得奇怪，什么是上三路拳法，下三路功夫？Palm 在手持设备的资历比 Android 深厚的多，市场根基更扎实，为什么要屈尊去找晚辈合作？与其到时候大家一头雾水，然后忙不及地倒叙补叙，不如稳妥点，按部就班地循序渐进。

闲话少说，接着讨论前文提出的五个问题。

Figure 1. iPhone CPU, Samsung S3C6400 internal structure
Courtesy http://www.ugamm.org.mo/forum/attachments/universal-no-heart-itunes_EeeNVaerhNt8.jpg

问题四. JVM，Dalvik 和 CLR/.NET，谁更可能最终胜出？

虽然迄今为止，还没有广为各方接受的 benchmark，说明 Dalvik 比传统的 JVM 究竟快多少小多少，但是 Dalvik 性能超越前辈，应该没有太多争议。但是并不是说，JVM 只有坐以待毙的份儿。

初版 iPhone 的 CPU 是 Samsung 的 S3C6400 芯片，这颗芯片的速度是 667MHz，是当今世界手持设备使用的最快的 CPU，Intel 的竞争产品的速度是 624MHz，屈居第二。S3C6400 不仅快，而且还包含 Java 加速器子系统。这个 Java 加速器采用的技术叫 Jazelle，原理是让绝大多数 Java bytecode 在硬件中执行，但是具体细节未见公开介绍。

Jazelle 之所以令人感兴趣，不仅在于纯软件的 Dalvik，与有硬件支持的 JVM 相比较，哪一个更快，不仅在于期待出现能够支持 Dalvik 的芯片，而且在于如果 Jazelle 进一步完善，Java 是不是有可能取代 C/C++。

1995 年，Java 初出茅庐之际，很多人预测 Java 将对 PC 的应用开发带来冲击。十多年过去了，这个预言没有成为现实，Java 在 PC 方面依然处于弱势，出乎意料的是，Java 逐渐在 server 领域成为主流语言。随着 Jazelle 技术的完善，有没有可能出现纯 Java 的手机，也就是从底层 OS 到上层应用软件，完全依赖于 Java 语言的手机？据说 Microsoft 盟下的 Danger PDA，正在做这方面的尝试。

从长远来看，Java 终将与 C#合流。不明白的是，当初 Microsoft 模仿 Java 发明 C#的时候，为什么不延用 Java 的技术术语，反而刻意另造一套，譬如 Java 把线程叫着 thread，而 C#叫 fiber。对比 Android/Dalvik 的做法，Android 尽可能延用 Java 的术语。结果是，Android 让 Java 开发者们倍感亲切，从而轻而易举地吸引了众多 Java 程序员，摩拳擦掌地要为 Android 开发应用程序。

谈这么长远的未来有什么现实的意义？

我有一个朋友 Y 君，致力于自己动手重构 OS（http://osfromscratch.org/）。我给他的建议是，与其钻研 Linux Kernel，不如专注于 Java 虚拟机。Apache Harmony 是一个开源项目，目标是提供开源的免费的 Java 实现，其中包括 Java 虚拟机。如果 Y 君能借鉴 Dalvik 的设计，贡献第二代嵌入式 Java 虚拟机给 Apache Harmony，那将是造福人类的义举。

对于手机应用开发商而言，应该选择什么语言？在没有显著地降低运行效率的前提下，尽可能使用 Java。

Figure 2. Comparison of various kernels
Courtesy http://upload.wikimedia.org/wikipedia/commons/d/d0/OS-structure2.svg

问题五. Android 是 platform，还是 OS？

关于这个问题，请教了 Y 君。下面抄袭 Y 君的原话，

“在纯粹宏内核 OS 中，我们可以讲，一个 Kernel 就是一个 OS，另外有 Libraries（以下简称 Lib）夹在 Kernel 和 Applications（以下简称 App）中间。当然我们可以说 Lib 本质上跟 App 是一样的，User Mode，所以跟 App 合并，统一叫 App，于是 Kernel 就是 OS，剩下的全是 App。但或许这时候就有人跳出来说，这样是不对的，Lib 固然是在 User Mode，试问，没有 Lib，你的系统跑得起来吗？他没准给你举个例子，你去买汽车，没有外壳，没有坐垫，没有后备箱，光一套驱动设备，能成吗？不成。所以 Lib 应该跟 Kernel 一起算 OS 的一部分。这还不算完，他还可能将 Shell 划到 OS 那头，将 Compiler、Text Editor、PS Viewer…… 都划到 OS 那头，理由很简单：没这些玩意，系统是没实用价值的。光个 Kernel 孤零零地有个啥用。

宏内核如此，微内核和混合内核（Hybrid kernel）更加复杂。文件系统（FS）算不算 Kernel 的一部分？严格来讲不算。但它显然算是 OS 的一部分。然后就有人跳出来说，既然 FS 算是 OS 的一部分，那 Lib 就” 坚决” 应该算是 OS 的一部分…… 讲理是讲不通的，大家都有理。

事情这么复杂，商家就可以发言了。在 Kernel 外面加点东西，就能叫 OS ── 不是人家吹，的确能叫 OS。而且还能叫自己的名，比如 Ubuntu、RedHat，把内核名 Linux 省去。Palm WebOS 和 Android 也是如此，当然，Kernel 外面不是加了一点东西，而是很多东西。WebOS 和 Android 的情况虽然不详，但据 GNU 说，2008 年的 gNewSense（另一个 Linux 发行版）中，Kernel 的代码量只占 1.5%。我想 WebOS 和 Android 或许也类似，Kernel 不会超过 5%。所以他们完全可以很自信地宣称那是自己的 OS。这就好比，劳斯莱斯卖汽车，里面装的是 BMW 或者 VW 的发动机，人们还是管那汽车叫劳斯莱斯。”
为什么 Google 把 Android 定义成 platform，而不是 OS？除了回避 OS 界定的模糊以外，还有减少应用开发商的误会的意图。实际上，图三对于 Android 架构的描述就有误导的嫌疑。按照这张图的解释，所有应用软件都应该基于 Dalvik 虚拟机之上，用 Java 编写。

但是对于一些需要处理大量数据的应用程序，如果完全用 Java 语言编写，执行效率会受影响。即便 Dalvik 比传统 JVM 快几倍，但毕竟比 C/C++还是慢，除非将来有硬件支持 Dalvik。对于这样的涉及大量数据处理的应用程序，更合理的做法是把它一分为二，UI 部分用 Java 编写，数据处理模块用 C/C++。C/C++模块作为 library，运行在 MiddleWare 层面。

如果把 Android 称为 OS，那么应用开发商可能会误以为，他们没有权限在 Middleware 层面，内置用 C/C++写的应用模块。为了避免这样的误解，把 Android 称为 platform 更准确。

但是图三清晰地描述了 Android 的着力点，即，Linux Kernel，Middleware libraries，以及 Dalvik VM。我把 Android 概括为下三路，没有丝毫贬低的意思，相反，我认为 Android 一出手就以稳住下盘为目标，落子凶狠。但是缺陷是，上盘空虚，估计战线过长，负担太重，一时顾不过来了。

下文将介绍 WebOS 的做法，它的主打是上三路，即，UI widget base，Services，以及 Palm bus。但是它的下盘不够考究。短期内能够吸引不少眼球，但是从长期讲，未必具有强大的后续能力。