HTML5 与 ”性工能“障碍

HTML5 与 ”性工能“障碍



最近看了@王淮Harry 的文章《HTML5的明天--局部有小雨》http://www.nonoidea.com/2012/12/12/html5%E7%9A%84%E6%98%8E%E5%A4%A9-%E5%B1%80%E9%83%A8%E6%9C%89%E5%B0%8F%E9%9B%A8/，由于作者本身并不是专业搞HTML5的技术专家，而且他自己也很坦诚的说了这文章是在【最近对HTML5产生兴趣, 做了粗浅的研究, 并和硅谷的两位玩弄此道多年的技术大佬电话交流】之后写下的，所以我看后第一时间也没有太去较真，只是在微博上说了一句“精神可嘉”。
而且客观来说，这篇文章写的真的很不错，文中的结论（或称作观点）很多我也是非常认可，例如

引用

* 在移动端是否采用HTML5技术, 取决于你的产品形态
* 将来可能90%的应用会是HTML5, 而那10%, 可能永远也不适合HTML5
* HTML5性能的提升很大程度上将取决于低耗电高性能CPU/内存的出现, 或者电池技术的极大改善。

但是不错的结论 却掩盖不了得出这个结论的过程（论据和原因）中所出现的一些疏漏和错误。
而后来看到很多转发和评论的人在认可结论的时候，连带那些错误的东西也一并认同（甚至主要就是认同那些错误的东西）， 我觉得我不能再沉默了，因为人们对HTML5的误解已经很多，不能再多下去啊。


首先声明，我不是HTML5黑，也绝对不是HTML5红橙黄绿青蓝紫什么乱七八糟的东西，我就是一个靠写代码吃饭的人，什么代码我写着顺手，我就用什么。我用HTML5开发应用或游戏，绝对不是HTML5有多牛逼，而是因为目前我用JS+HTML+CSS这个组合最熟练，仅此而已。另外，我在后面不会详细去区分HTML JS CSS, 都统一叫做HTML或HTML5了,请咬文嚼字党放我一条生路，夹着鸡鸡跪谢了。声明完毕，正文开始。

=============================



《HTML5的明天--局部有小雨》（以下简称 H文，请读者将其和H文学相区分）一文的内容大体如下：

引用

1 HTML5是什么
2 HTML5的现状和优劣
3 HTML5的明天会如何

这个基本上是任何介绍、点评、分析HTML5的（或其他任何技术）文章的标准结构，无任何不妥。
但是H文中每一部分都有一些值得商榷的地方。


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

网页里用很清晰明了的说明了什么是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 [url]http://www.slideshare.net/nzakas/high-performance-javascript-capitoljs-2011
[/url] (可以从第19页开始看).

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

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

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

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

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

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

我们玩游戏时,满屏幕的敌人,乱飞的子弹, 天空飘过的白云...这一切的一切都是在一个线程里,
这个线程同样是同一时刻只做一件事.
华丽流畅的游戏 单线程模型都ok, 一个区区的网页和应用有何不可?

而且,其实很多原生技术在处理数据的更新和渲染时, 用的也是类似的单线程方式(即使这个语言或技术支持多线程)。

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

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

这两项的性能还不够高.
我觉得要提高HTML5的性能,不应该靠"引入多线程"来实现, 应该靠"提升单线程内处理每一项时的性能"（以及如何将大量的第一项里的工作分解）来实现.
而WebWorker 的引入, 其实就是为了提高 第1项的性能.

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

有点说远了,回到主题。我的核心观点就是：HTML5性能虽然低，但和多线程 单线程什么的无关，单线程也绝对不是HTML5的致命伤，而是即有好处也有坏处的一个特性。

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

H文最后关于未来那段说的也没什么问题。但我个人更倾向于“即使这一天到来了, 仍然会有至少10%的APP无法应用HTML5来实现”。


=============================



说了这么多我对H文的看法， 那么我再补充两句，来说说我个人对HTML5技术的看法吧。
简单说来，我觉得HTML5面临的主要问题就是： ”性工能“障碍。所谓“性工能”即：【性】能、【工】具、【能】力。



性能低下，这个事情基本上大家能够达成共识，至少和各种强大的Native展现层技术相比，确实有差距。但是这个问题不是致命的根本性问题。
当年Doom3 孤岛危机1 这些游戏出来时，也都是当时的硬件杀手，但是后来随着硬件的提升，性能问题也渐渐不再是核心问题了（这两个游戏在FPS游戏里，是真不好玩啊）。
换言之，当市场上对性能要求高的 好的产品和应用越来越多时，那些底层（浏览器 os 硬件）厂商不会坐视不理的，因为这对于他们来说 也是机会。
所以作为HTML前端工程师，我们所要做的就是尽可能的优化自己的代码，但不要被性能束缚了产品的手脚，同时在保证自己代码质量和算法没问题的情况下，行动+呼吁+等待就OK了。
当然,不要强迫HTML5去做不应该它来做的事情。

工具匮乏，从开发调试到测试维护整个过程中，确实缺少强有力的工具。这个问题在可预见的未来，应该还是比较难解决，不过对成熟的HTML开发团队而言，似乎也不是大问题，因为大家已经比较习惯和适应现在的开发环境和方式了。但是对于围绕上层应用所需要的辅助工具确实欠缺。拿HTML5游戏来说：地图编辑器、精灵编辑器、粒子效果、游戏脚本编辑器、音效管理工具、性能监控...等等,虽然理论上开发这些并不难,很多公司也都在尝试开发自己的基础架构,但是和unity3d flash这些比起来,还是太弱了.期待 cocos2d-x能够为我们带来不一样的局面(此处为植入广告,请林顺 王哲自行考虑所需费用)。
总之，HTML5为web应用带来了更多新的形式，不过围绕这些新形式的相关辅助工具确实还很欠缺。但是，未来可期。

能力不足，这个主要是指HTML5本身的定位和它的原则导致有很多事情是它根本做不了的。举个极端点的例子，你希望在网页里借助HTML5技术来格式化你的U盘、刻录一张CD几乎是不可能的（谁知道 HTML6789时会不会提供一组Disk API呢？）。因为很多事情根本就不在HTML的发展蓝图里。而且浏览器根本的目的是为了保证用户可以高效便捷安全的网上冲浪，这个根本目的导致了浏览器本身会存在一些制约，例如安全性上的。所以，指望HTML5能完全取代Native是不可能的，至少我觉得在我退休之前是不可能的。

在一些WebOS里，js似乎很强大，能做很多底层的事情，但是其实这些东西本质上已经不是标准化的HTML技术了，而是通过WebOS厂商定制的特殊环境和专有API实现的，这些东西显然超出了本文的讨论范围之内。



以上不难看出， 当未来性能和工具都不是问题时， ”能力“依然会是制约HTML5应用的一道枷锁，而且是最顽固的一个。
JS作为一种脚本语言, 本身对使用场景并没有什么限制, 它可以出现在浏览器里, 也可以出现在server后台,甚至有一天出现在智能电器 嵌入式设备里也都完全正常, 但是这不意味着HTML(HTML CSS JS)就能做所有事情,就能够取代Native.
所以我个人反复强调过我的一个观点： Hybrid技术绝对不是过渡技术, 它的生命力会很强.因为它是一个兼容并包的技术,是一个真正可以沟通起HTML和Native的桥梁. 只要Native和HTML不完全相同,那么Hybrid就有存在的价值.

=============================



我发现这篇文章我又写散了, 主题凌乱, 难以总结出中心思想，那我自己来总结一下吧：
HTML5技术本身确实还有很多问题，但是未来值得期待————只是这种期待要适当，否则最后的失望不可避免。HTML5是一场伟大的技术变革，也许真的可以改变世界，但是在改变世界之前，先试着改变自己，而改变自己，先从改变自己对待HTML5的态度开始吧。


-- OVER --

评论

9 楼 prepoet 2013-11-28  

客观

8 楼 shadowninja 2012-12-17  

多线程不是有web work么.....

http://www.ibm.com/developerworks/cn/web/1112_sunch_webworker/

不过还是得说html5跨平台开发还是很烦,,至于性能啥的,js真的要费很多事去优化,说实话.....和mozilla hacks上的一篇文章一样,的确是一种方案,但这方案不一定就简单.....,不过更希望大大你分享一些游戏编程的东西(比如等角地图游戏的排序问题之类的....

7 楼 乐邪鬼 2012-12-14  

我们客户还真提出格式化优盘的功能

6 楼 cuixiping 2012-12-14  

80houzhu 写道

看看这个养养眼http://119.57.100.27:8888/第四个连接。战斗吧，兄弟们

有点意思，解放思想，提高生产力

5 楼 cuixiping 2012-12-14  

纯运算量偏大的web应用中，多线程比较有用。
我做一个在线绘图的应用，打开文件时，是从服务端取回压缩数据，用js解压，保存时用js压缩再传上服务器，不用多线程的情况下，上兆字节的压缩文件就很卡了。还有一些几何运算， 图元多了也有压力。

至少百分之八九十的游戏，不用多线程都可以无障碍的。

你在杭州上次D2上讲的那个HTML5现状的文，也可以分享到这里来，贴个链接啥的吧至少。

4 楼 80houzhu 2012-12-13  

看看这个养养眼http://119.57.100.27:8888/第四个连接。战斗吧，兄弟们

3 楼 luolonghao 2012-12-13  

能力不足是无解啊，又想安全，又想什么都想做。

2 楼 fins 2012-12-13  

懒得自己搭建博客啊 呵呵. 不过这个博客的功能现在看来真的太弱了.

支持markdown 和潜入js html css代码就好了 (类似博客园那种)

1 楼 elementstorm 2012-12-13  

平台差异也很愁人啊

小胖咋还用鸡眼的博客啊...