HTML5 性能之争 —— 单线程：缺点还是特点？

2012 年对 HTML5 是多事的一年。年初各界人士对 HTML5 进行了乐观的畅想。而 Facebook 在进行了长时间的尝试之后，8 月份发表声明，在 iOS 平台转向 native 开发。昨天（12 月 14 日），facebook 发布了 Android 平台的原生应用。Facebook 在官方博客中表示，新版 Android 应用在显示照片和加载时间线条目时速度是此前版本的 2 倍。

Facebook 的早期员工，中国籍第二位工程师和第一位研发经理王淮 Harry（微博）在他的博客文章《 HTML5 的明天， 局部有小雨》中谈到了该不该给 HTML5 投怀送抱这个问题。他表示，这个问题需要分两步：

• 你在 WEB 端还是移动端?

对于 Web 端而言， HTML5 将是一个完整的操作系统。 它在不同的底层系统之上， 借助于浏览器的实现， 封装了统一标准的 API 允许开发的程序跨设备 (PC or Mac or Smart Phone)， 跨平台 (Windows， MacOS， iOS， Android， whatsoever) 的运行。最大的好处， 就是一处开发， 多处使用。审核新版本的发布也不用看苹果爷爷的脸色。 直接在服务器端推送新代码就好了。 对于开发人员而言， 这对效率的提高， 有着致命的诱惑。 像”你们是先开发 Web， 还是移动”之类的问题， 将愉快的失去意义。对于 Web 端的开发而言， 你可以尽情的享受 HTML5 这种统一封装带来的好处， 唯一要等待的就是浏览器对其支持的完善。 但这种完善的到来， 无疑是确定的。

• 如果是移动端， 取决于你的产品形态。

因为你的产品需要的功能可能永远也无法在移动端的浏览器的 HTML5 实现中被很好的实现。

Harry 表示：

App Store 上超过 50% 的应用已经是用 HTML5 来开发， 将来可能 90% 的应用会是 HTML5， 而那 10%， 可能永远也不适合 HTML5。

在分析情况之后，他介绍了一个动态检测浏览器对 HTML 支持程度的测试工具 ringmark.io 来帮助大家判断自己的位置，并道出了为什么 HTML5 在移动端不适用的原因：

照片分享， 浏览相关的功能极度依赖 CSS Overflow Scrolling， 这一点， iOS 上的浏览器支持极度不给力。 而换成 Object C 的 Native Implementation 之后， 速度快上了 2 倍之多。

最后，Harry 从浏览器的编程模型阐述了问题的成因，并给出了技术选型的策略。

浏览器的编程模型还是 90 年代流行的单进程单线程 (single process single thread)， 但原生实现 (比如用 Object C) 的 APP 可以用多线程。 这一点带来的作用是致命的。

移动端编写 APP， 可以使用多个线程， 第一个线程， 被称作主线程 (main thread)， 编程的第一原则是 don’t do heavy work on main thread。 通常只让它处理 UI 事件等， 其他重度的工作让其他背景线程来做。

但浏览器只有一个线程， 所有的事情都是它干。移动浏览器编程一上来就破了第一原则。

在台式机上， 浏览器编程还没有太多问题， 因为够快 (此外， 桌面浏览器对于 Web Worker 的支持也比较完善); 但在移动端， 这个弊端很明显。

我来举个例子， 比如你在用浏览器看朋友的照片， 你发的评论被发到服务器端， 此时你接着用手指往下拉屏 ; 此时， 服务器端返回信息， 评论发布成功， 浏览器中唯一的线程可能停止处理屏幕滚动 (scrolling) 而来处理服务器的返回信息， 由于移动设备的处理器 (尤其单进程浏览器只能用上单核， 即使是多核手机!) 和内存 (处于省电原因使用低耗电的 DDR1， 这一点和现在 PC 使用的 DDR3 相差甚远) 的不给力， 完全可能造成滚动处理的不连续。 通常手机的刷新率是 60MHZ， 即每一帧不超过 15ms; 如果处理的延时大大超过 15ms， 那么就会出现跳帧， 肉眼就能看出来。

这是交互操作 (比如拉动， 滚动等) 很多的 APP， 如果是由 HTML5 实现， 出现拉动的时候停在那里一个很重要的原因。

所以， 如果你的 APP 是相对静态的， 不需要很多对于照片， 多点触摸， 多向拉动的处理， 那完全可以用 HTML5 来实现 ; 如果不是， 比如信息流的展示， 游戏等等， 还是乖乖的用原生的去实现。

故事到这里还没有结束。HTML5 开发专家大城小胖（微博）专门撰问《 HTML5 与 ”性工能“障碍 》回应了 Harry。在文中他赞同了 Harry 的观点：

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

但他认为，HTML 不支持多线程不是缺点，而是特点。

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

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

最后，大城小胖指出了 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 是不可能的，至少我觉得在我退休之前是不可能的。

各位读者，你们怎么看待 HTML5 的性能问题，适用场景和它的未来呢？