主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
家园 作为一个新入手centro的小胖 格外喜欢这个系列。
家园 还真没人理我们SYMBIAN啊 虽然SYMBIAN C++难用了点，但是我们OS的效率很高。看NOKIA的主流机都300M+HZ， 再看看WINDOWS MOBILE和IPHONE的硬件配置，要是NOKIA狠心点搞出同样的配置，我们的OS肯定是最快的。 当然，现在我们被NOKIA收购了，和S60要整合，看整合出的新SYMBIAN FOUNDATION的RELEASE咋样了。
SYMBIAN的历史包袱太沉重，当时C++98还没通过，SYMBIAN自己搞出什么CLEANUPSTACK，描述符等一堆东西，我承认，是对程序员不太友好... 可是也没法改了，LIB里面全是这里LEAGCY CODE， 根本没法动。
GOOGLE IPHONE PALM的系统开发的迟，有后发优势。
不过我们自己觉得 对我们威胁最大的还是GOOGLE 的 ANDROID， NOKIA收购SYMBIAN主要还是为了应对ANDROID开源。
要是比软件资源，S60显然还是大大超过其他系统的～
家园 【原创】【14】AJAX适合手机吗？ 【14】AJAX 适合手机吗？
有人问，“为什么要长篇累牍地讨论Palm WebOS？这个系列写到现在，并没有明确地指出Palm WebOS好在什么地方”。这个问题问得好。Palm WebOS的价值在于提出了若干值得深思的问题，至于Palm WebOS的解决方案，却具有很大争议。
Palm WebOS首先提出的问题是，手机OS是否应当有别于PC OS？对于这个问题，笔者认为手机OS的设计的确应当有别于PC OS的设计。原因并不在于手机的CPU处理能力比PC的CPU弱，并不在于Memory和Disk空间比PC的小。虽然从目前看，手机在 CPU，Memory和Disk方面的确与PC存在差距，但是这个差距正在很快缩小。手机的问题来自三个方面，
1. 电池寿命，导致手机不能像PC那样持续地高负荷地工作。即便手机的CPU很强大，也只适合短时间内高强度地工作，而不能打持久战。
2. 不能假设手机一直在线，即便3G和LTE全面普及以后，这个局面也不会改变。3G和LTE全面普及，导致的是带宽的增加，而不能保障无线网络的永久畅通。
3. 手机输入不便，以及显示屏尺寸小，导致用户行为不同于PC。PC便于阅读大量文字信息，也便于输入大量文字信息，也支持生成复杂的图像。但是手机不适合大量的文字阅读，更不要说输入大量文字。手机展示的内容应当是图像多于文字。手机更适合信息的消费，而不是信息的生成，除非信息的生成是通过摄影摄像和录音这两种途径。
针对这三个特点，手机OS的设计或许需要强调三个方面。
1. 手机OS的设计，应当与云计算平台做一体化考虑，而不是设计一个支持手机独立工作的OS。把数据量大计算量大的逻辑，分配给云计算平台处理。然后把半成品发送给手机，手机做简单的最后处理以后，呈现给用户。这就是大纵深的前店后厂模式。这样做的好处，是最大限度地减少手机电池的消耗。
2. 手机OS的文件系统的设计，难点在于当无线网络时有时无的情况下，如何保证手机文件系统与云计算文件系统最大限度地同步，同时最小限度地占用无线网络带宽。不仅数据需要同步，而且手机装载的应用程序的版本也需要与云计算平台相应业务逻辑的版本保持一致。
3. 如何简化应用程序的开发，尤其是简化以图像为主的UI工作流程的开发。
Palm WebOS是如何解决这三个方面问题的呢？到目前为止，我们只分析了第三个方面，如何简化以图像为主的UI工作流程的开发。第一个和第二个方面，我们在后续章节中逐个讨论。
为了达到简化UI工作流程这个目标，Palm WebOS的解决方案是让手机应用的开发，尽可能逼近Web的开发。换句话说，手机应用开发商，以Ajax为基本工具，即HTML/XML + CSS + JavaScript三驾马车，实现UI工作流程以及业务处理逻辑。基于Ajax的应用程序下载到手机上并开始运行时，UI的渲染由WebKit Rendering Engine处理，业务逻辑的处理由JavaScript Engine负责。
猛一看，觉得似乎有理。用Ajax为工具进行Web开发的工程师为数众多。他们不需要做技术转型就可以为手机开发应用程序。但是仔细想一想，有一些问题需要进一步梳理。
外链图片需谨慎，可能会被源头改Figure 1. Google map UI workflow for Android
Courtesy http://farm4.static.flickr.com/3554/3385778443_b90139f91c_o.jpg
Web页面以HTML/XML为格式，HTML/XML格式的意义在于规定了网页内容的结构。结构的重要性体现在两个方面，
1. 有了结构就可以区别各段内容的性质，哪些是标题，哪些是正文，哪些是图片，哪些是链接。另外再用CSS（Cascading Style Sheets），来规定各段不同性质的内容的渲染风格，譬如标题的字体，大小和颜色，表格的宽度，表格框的宽窄和风格，视频界面的大小，音量等等。
2. 通过JavaScript对页面进行部分修改，并重新渲染修改过的那一部分时，内部操作是修改相应的XML DOM tree，然后渲染相应的子树，而不需要重新生成整个DOM Tree，不需要重新渲染整个页面。
Figure 1 显示的是Google Android 手机地图应用的部分页面截图，从中可以感悟到手机应用UI工作流程的两个特点，1. 每个单幅页面的结构并不复杂，2. 工作流程包括多幅页面。
HTML/XML + CSS + JavaScript专注于定义单幅页面的结构和渲染风格，但是并没有充分关注多幅页面组成的工作流程的结构和渲染风格。有没有必要重新定义一套专门供手机应用使用的类似与HTML/XML + CSS那样的结构化语言？
工作流程的结构大体包括三个方面，1. 明确页面与页面之间的前后顺序，2. 登记不同页面共享的构件，仔细看Google 手机地图的截图，虽然整个工作流程包括很多页面，但是很多页面共用同一幅地图作为底图。所谓共享的构件，不仅包括文字和图片，也包括代码，例如日期选择或者树展那样的，HTML，CSS和JavaScript的部分组合）3. 状态机（state machine），譬如当用户在某一页面放大了地图，后续页面里的地图底图也应当随之放大。状态机的功能在于记忆用户行为的历史和现状，以及根据现状决定未来流程。
HTML/XML + CSS + JavaScript是否可以用来定义手机本地工作流程，而不是WEB网页+WEB服务器的工作流程？如果不考虑运行效率，基本上是可以满足需要的。1. 页面与页面之间的前后顺序可以通过HTML里面HREF实现。2. 共享的构件可以单独存放，当页面引用这些共享构件时，用诸如IMG之类的TAG来实现。3. 状态机可以通过JavaScript来实现。
虽然HTML/XML + CSS + JavaScript基本可以满足定义工作流程的结构的需求，但是并不意味着这是最优解决方案，实际上，三驾马车如果原封不动地照搬到手机上去，虽然能工作，但是CPU消耗高，占用内存大，工作环节多，总之，效率不高。原因出在XML DOM Tree 和 JavaScript。
所以，一个比较激进的观点是，的确有必要另起炉灶，重新制订一套专供手机应用使用的三驾马车，这三驾马车虽然脱胎于HTML/XML + CSS + JavaScript，但是与后者有显著不同。同时，WebKit也不能原封不动地照搬到手机上去，有必要另起炉灶，重新设计一个专供手机应用使用的 Rendering Engine。当然，所谓有必要，确切地说，是技术上有必要重起炉灶，但是商务上是否合算，传统的惯性是否允许，是另一个问题。
关键词(Tags): #硅谷评论，
本帖一共被 1 帖 引用 (帖内工具实现)家园 邓兄的手机设计关注点主要放到web上？ 家园 求同存异，谈一下这个javascript 回邓兄(没准是邓嫂？你们两口子文风很象)，很多技术上面的发展细节，不是我等可以左右的，所以仅作为饭后闲聊。这里只说一下这个javascript的事情。
一个语言是否是script，是由其运行时间的状态决定的，跟语法无关。我们可以写一个C++的解释器，也可以做一个javascript的编译器，对用户的不同，就是运行速度。其实x86的汇编，也有hotspot runtime translator / optimizer，听起来很java，对不对？
所以我想问：为什么不保留javascript的语法，在后端把它变化成高效率的编译器？其实google V8已经走出了javascript runtime optimization这一步。那么为什么对于手机，不把html+css+javascript用云去进行编译+优化，转化为紧凑高效的中间格式，发给移动终端呢？这样的好处是：
1.保留了大量现存的网络应用。
2.保留了更宝贵的程序员。
3.不必担心新标准叫好不叫座的事情。
对于javascript调用本地代码的事情，主要是一个安全性问题，M$干过ActiveX可以调用本地代码的事情，这倒不是不可为，只要仔细研究了调用本地代码的危险性，并把危险隔离在某个沙盒里，就是可以做的。
其实我对google的某些做法不是很理解，比如当年收购sketchup，放着网络上面那么多VRML的东西不理，去买这么个公司，不是浪费资源么？google是靠梳理网络现有文档起家的，怎么走了这么一步？
同理，对于javascript，我的看法是：支持现有标准，保护众人已有的投资和努力，并发展之。
家园 这个这个 如果编译的话，迟早要变成当年的Client Server模式，只不过把PC变成其他东西，例如手机。。。
家园 JavaScript 编译问题 是邓兄在回复，邓嫂这几天在忙别的。刚才晚饭的时候，邓兄把最近的讨论简略地向邓嫂做了汇报。邓嫂边听边剥虾，说，“你们先讨论着，回头我看看”。邓兄把头埋下，不敢正视，咕咚一声很响地喝了一大口汤。。
说正事，
1.
一个语言是否是script，是由其运行时间的状态决定的，跟语法无关。我们可以写一个C++的解释器，也可以做一个javascript的编译器，对用户的不同，就是运行速度。其实x86的汇编，也有hotspot runtime translator / optimizer，听起来很java，对不对？反问一句，如果JS需要编译好了再发到浏览器上去，为什么需要保留JS，而不直接用Java？
换句话说，为什么浏览器一定要死抱着JavaScript，而不内置一个JVM，直接支持Java？
或许有人说，早年浏览器都支持Java Applet，后来没有人用Applet，因为JVM启动慢，版本匹配也经常出问题。启动的问题，在于每个网页的Applet都在一个独立的JVM上运行。如果有个全局的JVM，不管哪个网页都用它，就不存在启动慢的问题。版本的问题，在于浏览器厂商自行决定使用哪个版本的JVM，譬如MS的IE内置的JVM就不同于Sun的JVM。为了解决这个问题，Sun的办法是把JVM移出浏览器，搞了一个Java Web Start。但是这样做，代价是浏览器和外置的JVM之间数据交换的成本高。
所以我的偏激的看法是，美老爹分析得很对，但是结论有疑点，不是JS技术上有什么优点，它存在的理由仅仅是钻了空子，也就是浏览器内置JVM在商务上的纠葛。
2.
所以我想问：为什么不保留javascript的语法，在后端把它变化成高效率的编译器？其实google V8已经走出了javascript runtime optimization这一步。那么为什么对于手机，不把html+css+javascript用云去进行编译+优化，转化为紧凑高效的中间格式，发给移动终端呢？对于Google手机而言，它已经有了Android/Dalvik VM，何不把手机上的WebKit和Dalvik联成一体？为什么还要保留JS这个第三者？
3.
对于javascript调用本地代码的事情，主要是一个安全性问题，M$干过ActiveX可以调用本地代码的事情，这倒不是不可为，只要仔细研究了调用本地代码的危险性，并把危险隔离在某个沙盒里，就是可以做的。我的看法更极端，连Sandbox都不需要，只要规定好哪些native APIs能够被调用，哪些不能即可。
4.
其实我对google的某些做法不是很理解，比如当年收购sketchup，放着网络上面那么多VRML的东西不理，去买这么个公司，不是浪费资源么？google是靠梳理网络现有文档起家的，怎么走了这么一步？同意，同时我也不理解，为什么Google不去收购一家做Online Visio的公司，丰富Google Docs。
5.
对于javascript，我的看法是：支持现有标准，保护众人已有的投资和努力，并发展之。我比较激进，看不到JS存在的强悍理由，未来JS不看好。
观点比较偏激。无知出偏激，估计是有些问题我没有想明白，欢迎美老爹继续斧正。（你的评论很好，但是目前还没把我彻底驳倒。我是那种被按在地上动弹不得才服软认输的家伙。
