五千年(敝帚自珍)

主题:【原创】新时代新潮流WebOS 【1】 -- 邓侃

共:💬594 🌺1902
全看树展主题 · 分页首页 上页
/ 40
下页 末页
家园 兼容,然后扩展

IT界常用的招数了。Compaq用这个占领了ibm PC的市场,微软用这个把OS2挤走。所以巨头都痛恨这个,intel一定要把transmeta弄倒,SUN对.net甚于防川。

玩这个也要有实力,3DNow!也没怎么动摇SSE的地盘。

家园 跑题的最高境界是跑到没人记得主题

然后峰回路转柳暗花明滴拉回来,比方说我现在就老觉得邓侃本篇是 Android 的公关稿呢~~~

但我对【续补】部分会提到 webOS 技术详解还是灰常灰常有信心

家园 Dalvik 快得一点儿也不吃惊

JIT 也砍掉的,一切从速度出发嘛。

反正我对 Java 没感情,所以看 Google 瞎搞还蛮有趣的。

家园 webOS...其实俺那篇东西想说的是CMS。。。

挠墙、捶胸、泪奔。。。。。

别拦着,我不活啦。。。。。

家园 又想了想,老邓你厚道阿,你这算预告吧,webOS有的扯呢

webOS

|--OS-->什么是OS?

|--Web-->浏览器之争、标准之争

|--开发和应用

|-->平台和标准以及架构

| |-->flex,SL,AJAX

|-->mashup

| |-->SaaS,云?

| |-->widget

|-->数据同步、离线应用

| |-->支持本地存储的HTML5标准?

| |-->本地应用->local webServer?

|-->嵌入式设备控制(如何点亮手机的键盘灯?)

|-->整一个localOS上面的appServer?(JVM或者Dalvik?)

哈哈过瘾阿,老老实实搬板凳等着看。。。

家园 Hot topics

谢谢:作者意外获得【通宝】一枚

鲜花已经成功送出。

此次送花为【有效送花赞扬,涨乐善、声望】

好主意呢,大家把WebOS及其相关的热点问题列出来,给我一些建议,接下去的篇幅中,我们可以有的放矢地重点讨论。

家园 下一篇最后再扯几句JVM和Android,

然后赶紧回来谈WebOS

家园 透彻

啥也不说了,透彻。

家园 这个观点要商榷

反正我对 Java 没感情

Java是方向,是未来。详细看我后文的分析。

本来要急刹车,转而去谈WebOS,省得大家说我没完没了地前戏,就是不直奔主题。得,现在又得多说几句了。

家园 请大家踊跃的感谢我

呱唧呱唧

家园 砍掉jit是系统容量的问题吧

如果容量许可,用hotspot会比JIT更好

家园 JIT 在 Android 的工作环境下

没什么意义吧,反而大大影响 Launch 速度。

当然我不清楚 ARM 架构下 Bytecode Compiler 能做到什么程度,但总觉得情况会很糟糕。

HotSpot 不是也用到了 JIT 吗? 我还以为两者是不同层次的呢。

家园 【原创】新时代新潮流WebOS 【5】

【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的技术术语,反而刻意另造一套。对比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。但是它的下盘不够考究。短期内能够吸引不少眼球,但是从长期讲,未必具有强大的后续能力。

点看全图

外链图片需谨慎,可能会被源头改

Figure 3. Android architecture

Courtesy http://purefire.bokee.com/inc/android.jpg

关键词(Tags): #硅谷评论
家园 但是Java要改革

语言特性要增加。否则没办法担当更多任务。

简单说几个我自己觉得需要的特性:

1。unsigned primitives including short,int,long

2. pointer,pointer,pointer....

家园 Java OS,Sun现在垂死挣扎的最后一根稻草了

恭喜:你意外获得【通宝】一枚

鲜花已经成功送出。

此次送花为【有效送花赞扬,涨乐善、声望】

不知道老邓以前关注国SavaJe没有?我以前一直看着。忽然Sun就把他买了,开始作JavaFX Mobile了。

但我的理解,如果不能拉拢硬件厂商,恐怕很难。

还是老话题,如果Sun+Apple,该是多美妙的组合啊

全看树展主题 · 分页首页 上页
/ 40
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河