Asm.js和Blink

在沈阳不想睡,用手机看RSS,看到John Resig刚出炉的博客。记得前些天还在群里跟大家聊说觉得现在浏览器不该出各种新语言,每种都编译成Javascript,而是应该出一个字节码标准,各平台实现自己的优化解释器。出一个标准不容易,更实际的做法是选择Javascript的一个子集作为“字节码”(编译目标),这正是Asm.js干的。其实很多事不是想不到,而是想到了没有做——跟没想到一样。目前Firefox针对Asm.js做专门优化,速度只比C++慢两倍,应该慢慢可以与Java不相上下。将来各JS引擎跟进,Web平台的运行能力将大大加强,必将催生出更多可能性。

最近看各个项目,发现成功的软件在于雕琢。软件架构、性能、接口不一定要完美,但是一定要完善才有真正的用户,否则只是玩票。所以人们虽然热爱开源,仍旧会选择有商业支持的平台和软件包,因为真正做事的时候,需要完善的文档和稳定的系统,也没有时间和精力去修复Bug。如果没有商业软件,开源软件也很难精益求精。

第二天回家就看到Google宣布开发WebKit分支Blink。自从Google宣布要关闭Reader之后,就很难估计它会做什么,不会做什么。Chromium会fork掉webkit应该说不让人意外。WebKit对于各平台的支持方式有点古怪,每个平台都维护一个相当大的Port,功能各异;主流Port都在主干里;构建方式很多种;WebKit1不是multi-process架构,WebKit2没用Chromium的架构,Chromium也不会用WebKit2;一方面要增加自己的功能,一方面还要照顾情绪,不改变WebKit的Shape,于是抱怨说“This has slowed down the collective pace of innovation”,其实就是觉得WebKit拖后腿了。Chrome也一直认为多个产品解决相同问题可以促进竞争和创新。不过近来有点怀疑“公司意志”或“集体意志”这类东西,文化固然存在,但非终端用户产品的关键决策仍然是几个人的头脑风暴,跟这几个人当时的处境和心态密切相关,存在很多偶然性和非文化相关的必然性(比如WebKit和Chromium,Google和Apple)。

Offscreen WebKit Rendering

Overgrowth使用Awesomium做UI,Awesomium是无窗口WebKit,将HTML元素直接绘制到用户自己定义的视频缓冲区里。效果看起来很不错,使用HTML和CSS来做UI开发效率也很高,尤其网络游戏这种需要大量UI的系统,很适合人手有限的小团队。Awesomium基于Chromium,集成了V8,相当于在app里加入了完整的浏览器功能,充分使用可以发掘出很多潜能,绚丽的HTML5和CSS3的效果,免费的脚本调试功能。问题是Awesomium是闭源的,而且只支持Windows, MacOX, Linux,不支持iOS和Android,个头还比较大,Win版有数个DLL文件(超过20M)。理论上Awesomium支持Android是可以的,但是iOS不可能,因为V8无法在iOS的沙盒里运行。Chrome的iOS版也有这个问题,在iOS上甚至Webkit也不能用自己的,换句话说iOS版Chrome只是Safari一个壳。

除Awesomium,还有一个berkelium。它是开源的,支持完整的JS和Offescreen渲染,同样基于Chromium,也意味着对与iOS支持基本不可能。berkelium的功能没有Awesomium那么完善。有点奇怪为什么都使用Chromium版的Port,而不是只用WebKit,毕竟需要的只是UI功能。(使用Chromium的原因是Chromium有一个“WebKit Embedding Layer”,这种方式不用修改WebKit或Chromium的源代码。)。

看了几个Port的代码,包括WebKitSDL、Awesomium(1.08)和berkelium,看上去自己写一个Port并不会很困难,Awesomium最初的实现只用了一周(Awesomium和berkelium都不是Port。我猜我还是没有完全理解。)。

有几个问题让人犹豫:

  • WebKit和Chromium开发速度太快,如果想保证自己的Port与开发库同步不太可能。
  • 不能用V8,JSC有点慢。理论上Offscreen渲染只将WebKit作为一个渲染库,在iOS上可以运行,但是V8由于使用JIT,不大可能跑在iOS上。
  • WebKit不同平台的构建非常繁琐,尤其是如果想裁剪功能。我在Ubuntu12.04上将源改成raring才能将包更新到可以构建。
  • WebKit和Chromium的代码非常复杂庞大,且开发方式让人望而生畏(Very different than Mozilla and other more developer-friendly projects; It IS possible to fix bugs in WebKit, but it’s very difficult to track WebKit development)。
  • 如果想精简WebKit的功能需要对代码相对熟悉,可能会很耗时间,比如搞清楚两条渲染路径(软件和硬件)。
  • 对于硬件加速不熟悉,尤其是嵌入式平台上。

说句玩笑话,如果做一款大小十几M的手机游戏,却要搞个8G内存的PC编译一个多小时,实在难让人心安。