王淮,大城小胖论辩HTML5 局部有小雨

<![CDATA[

<

div >

最近看了@王淮Harry的文章《HTML5的明天–局部有小雨》,由于作者本身并不是专业搞HTML5的技术专家,而且他自己也很坦诚的说了这文章是在【最近对HTML5产生兴趣,做了粗浅的研究,并和硅谷的两位玩弄此道多年的技术大佬电话交流】之后写下的,所以我看后第一时间也没有太去较真,只是在微博上说了一句“精神可嘉”。

而且客观来说,这篇文章写的真的很不错,文中的结论(或称作观点)很多我也是非常认可,例如

* 在移动端是否采用HTML5技术,取决于你的产品形态

* 将来可能90%的应用会是HTML5,而那10%,可能永远也不适合HTML5

* HTML5性能的提升很大程度上将取决于低耗电高性能CPU/内存的出现,或者电池技术的极大改善。

但是不错的结论却掩盖不了得出这个结论的过程(论据和原因)中所出现的一些疏漏和错误。

而后来看到很多转发和评论的人在认可结论的时候,连带那些错误的东西也一并认同(甚至主要就是认同那些错误的东西),我觉得我不能再沉默了,因为人们对HTML5的误解已经很多,不能再多下去啊。

首先声明,我不是HTML5黑,也绝对不是HTML5红橙黄绿青蓝紫什么乱七八糟的东西,我就是一个靠写代码吃饭的人,什么代码我写着顺手,我就用什么。我用HTML5开发应用或游戏,绝对不是HTML5有多牛逼,而是因为目前我用JS+HTML+CSS这个组合最熟练,仅此而已。

《HTML5的明天–局部有小雨》(以下简称H文,请读者将其和H文学相区分)一文的内容大体如下: 

HTML5是什么 

HTML5的现状和优劣

HTML5的明天会如何

这个基本上是任何介绍、点评、分析HTML5的(或其他任何技术)文章的标准结构,无任何不妥。

但是H文中每一部分都有一些值得商榷的地方。

首先,在HTML5是什么一节当中,作者无视了HTML5的8大特性,反而把HTML5中微不足道的一些小功能点当做主要内容来写。如果大家真的对HTML5感兴趣,但是又没有时间去仔细的阅读HTML5官方规范,又不相信Google和百度的搜索结果,那么至少应该去W3C官方的HTML5主题页上去看一下,对HTML5的8大特性有所了解

网页里用很清晰明了的说明了什么是HTML5以及HTML5带来的主要的新特性。

而在HTML5现状中,作者引用了一个数据“App Store上超过50%的应用已经是用HTML5来开发”,我实在不知道这个统计是怎么来的。但是不可否认的是,最近一年以来App Store上基于Hybrid开发的应用确实越来越多了。我的iOS设备里就有几十款HTML5开发的网页手机游戏,不过目测在浩如烟海的App当中,HTML5应用应该不到50%,不过我也拿不出证据,在这里就不明确表态了。

在对HTML5优点的表述中,作者主要提及了“跨平台”这个特性,也没什么不妥,只能说不够全面。

接下来到了H文中篇幅最大,也是问题最多的部分:HTML5的缺点。

作者主要描述了两类问题:一个是性能问题,一个是对HTML5支持度的问题。

H文的作者用大量文字来描写了关于线程的问题,主要想告诉读者“HTML5性能低,因为不支持多线程”。

关于这点网上已经有很多人指出了问题,作者也在后面加入了补充说明,但是我觉得作者可能还是没有理解到“HTML不支持多线程”的关键。

“HTML不支持多线程”绝对不是缺点,而是特点。关于HTML的单线程特点 以及工作原理网上有很多介绍文章,如果大家没时间看相关文档,没时间自己动手体会,可以看一下这个简短的slide (可以从第19页开始看).

简单来说,浏览器运行时,就好像(只是好像)下面这个无限循环:

  1. while(true){    
  2.     1 更新数据和对象状态    
  3.     2 渲染可视化UI    
  4. }    
  5. ( 而在需要异步的地方,HTML是提供了异步机制的,例如网络传输 事件响应 )   

1 2这两项工作,浏览器同一时间只能做一件。这种单线程模型在满足用户使用需求的同时,也保证了开发方式的最简化,总的说来就是“简单够用”。

也许有人会质疑,怎么可能够用? 可能对于大多数人来说,都会觉得多线程很牛逼,单线程很无力,其实不然,举个简单的例子:目前大家玩到的大多数游戏(甭管它多华丽)的主体部分都是单线程编写的。事实上,在开发游戏时,很少用到多线程技术。

游戏的核心逻辑其实也是一个循环体:

  1. while(true){    
  2.     处理用户输入    
  3.     更新数据和对象状态    
  4.     渲染游戏画面    
  5. }   

我们玩游戏时,满屏幕的敌人,乱飞的子弹,天空飘过的白云…这一切的一切都是在一个线程里,这个线程同样是同一时刻只做一件事。

华丽流畅的游戏单线程模型都ok,一个区区的网页和应用有何不可?而且,其实很多原生技术在处理数据的更新和渲染时,用的也是类似的单线程方式(即使这个语言或技术支持多线程)。

所以,HTML5性能确实是低(其实也没想象的低,所以才有那么多的HTML5游戏诞生),但是造成这个问题的原因不是单线程,而是在主循环体内

  1. while(true){    
  2.     1 更新数据和对象状态    
  3.     2 渲染可视化UI    
  4. }   

这两项的性能还不够高。

我觉得要提高HTML5的性能,不应该靠“引入多线程”来实现,应该靠“提升单线程内处理每一项时的性能”(以及如何将大量的第一项里的工作分解)来实现。

而WebWorker的引入,其实就是为了提高第1项的性能。

WebWorker本身并不是传统的Thread模型,虽然底层是多线程实现的,但是它并没有引入同步锁 线程调度一类高级特性,而是用简单的消息机制尽可能的保持了和单线程之间的匹配度。

换言之,WebWorker并不是给单线程的HTML带来的多线程特性,而是给单线程的HTML带来了后台计算的能力。

我的核心观点就是:HTML5性能虽然低,但和多线程、单线程什么的无关,单线程也绝对不是HTML5的致命伤,而是即有好处也有坏处的一个特性。

再来说说HTML5特性的普及度,WebWorker WebSocket(iOS 6的Safari已经支持这两个特性了)一类的HTML5特性其实正在被越来越多的浏览器支持,在移动端也是如此。相信未来这个不会是大的问题。

<

p >H文最后关于未来那段说的也没什么问题。但我个人更倾向于“]
]>