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的性能问题，适用场景和它的未来呢？