新时代新潮流 WebOS【18】假如浏览器离开了 JavaScript

假如浏览器离开了 JavaScript，那么互联网上绝大多数网页就无法展示。但是激进的主张并非一无是处，至少它能否促进我们对熟视无睹的事物，换一个角度做进一步思考。假如用 Java 替换 JavaScript，会有什么好处？好处或许有三个层面，对于手机应用而言，这些优点尤其可贵。

1. 预先编译，事件响应速度快

JavaScript 之所以被广泛应用在网页设计中，一个重要原因是它能够捕捉事件，并相应处理。譬如看下面一段简短的实例，

<html>
<head>
<script type=”text/javascript”>
function focusEventHandler(x) {
document.getElementByIdx(x).style.background=”yellow”;
}
</script>
</head>
<body>
<p> Focus here, see the color changed to yellow: </p>

</body>
</html>

在这个例子中，“onfocus” 指的是当用户在输入框中点击鼠标的事件，而 “focusEventHandler(this.id)” 指的是处理这个事件的相应的 JavaScript 代码。

处理事件的代码不一定非要用 JavaScript 不可，譬如在微软 IE 浏览器里，可以用 VBScript。如果深究一下，不用 JavaScript，VBScript 等等脚本语言，而直接用 Java，C/C++等等高级语言，去实现 focusEventHander 这样的事件处理逻辑，是否可行？理论上是可行的，但是目前的实际情况是，大多数浏览器不支持。不支持的原因，并非是因为技术上难以实现，事实上，如果改变一下浏览器的源码，这个目标并不难实现。不支持的原因主要是出于商务上的考虑，详情参阅前两节文章。

假如用 Java 这样的高级语言替代 JavaScript 这样的脚本语言，去响应和处理浏览器事件，在通常情况下，用户体验不一定会有明显改善。但是对于处理逻辑相当复杂的情景，用 Java 会使事件的响应处理速度大大提高。譬如有些网页，在打开前会预先 loading 一段时间。所谓 loading，通常是对网页附带的 JavaScript 做 JIT 编译。相比之下，Java 之所以比 JavaScript 反应速度快，原因在于网页打开之际，浏览器直接从网站下载 Java bytecode，避免了 JIT 现场编译这个过程。

2. 简化本地应用程序开发

大多数应用程序都需要有 UI 界面，Java Swing 已经很方便了，但是如果用浏览器来负责 UI 的渲染和事件捕捉，那么应用程序的开发将比使用 Java Swing 更简单，而且渲染效果更丰富。譬如，只要改写 CSS，就可以轻松提供个性化的皮肤。

事实上，2007 年以前版本的微软 email 软件，Outlook，渲染部分的实现就是通过调用 IE 的相关模块来实现的。2007 年以后，据悉 Outlook 决定不再使用 IE 模块负责渲染 Outlook 的 UI，而是改用 Office Word 的相应模块。但是不管怎么说，用浏览器的渲染模块，来处理本地应用的 UI 部分，不仅理论上成立，实际中也是可行的。

但是不管怎么说，用浏览器中的渲染模块，来处理应用程序的 UI 部分，可以让应用程序开发者，把精力集中到应用逻辑的实现上去。这是一个非常可取的发展方向。尤其对于手机应用开发而言，由于手机平台众多，一个开发商完成了一个应用程序的开发以后，需要适配到不同平台，不同型号的形形色色的手机上去，开发任务十分繁重。而不同平台不同型号的适配，往往与 UI 有关。如果浏览器承担了跨平台的 UI 实现，那么就可以大大降低应用开发商适配不同平台的负担。

之所以现在大多数应用程序没有使用浏览器渲染模块，而是用 Java Swing 等等工具开发 UI，主要障碍是大家不熟悉浏览器渲染模块的使用方法。不熟悉的原因有两条，1. 缺乏相应的文档，说明如何使用浏览器渲染模块，2. 缺乏简介但是灵活的 APIs，以函数库的方式调用这些渲染模块，并且改造它的行为模式。

3. BAE，基于浏览器的应用环境

前一段讲了，浏览器的功能并不仅仅限于浏览远程的网页，而且也可以用来处理本地应用的 UI。更进一步拓展，围绕浏览器我们可以构建一个环境，这个环境可以提供类似于 iPhone AppStore 那样的功能，方便手机用户订购下载更多的应用程序，运行并监控，维护程序版本的更新以及内容的更新。

长远来看，未来的手机 OS 或许可以分成三个层面，底层是 Kernel，中间是 Java 虚拟机，上层是基于浏览器的应用环境，（Browser-based Application Environment，BAE）。BAE 的架构设计，我们将在后续的文章中详细讨论。

总之，乐观的估计是，浏览器失去的仅仅是 JavaScript，而得到的将是手机 BAE。

Figure 1. The zoom and selection of the WebKit rendering engine.

实现这个远景的关键，是深入了解浏览器的内部架构，尤其是渲染机（Rendering Engine）和图形库（Graphics Library）。但是如同前文所述，渲染机的内部工作机制非常复杂，但是文档非常不齐全，所以极大地阻碍了渲染机的广泛使用。要深入了解渲染机，目前除了反复咀嚼网络上零零散散的片言只语以外，最主要的手段是查阅源代码。

当今技术最出色，代码结构最清晰的渲染机，很多人认为是 WebKit。幸运的是，WebKit 是开源项目。我们研究 WebKit，不妨以理解四个方面为切入点，1. 布局，2. 事件捕捉及相应，3. 线程控制，4. 绘制。至于其它方面，譬如安全，历史缓存等等，或许可以适当延后，逐步研究。

譬如 Figure-1 图中有三个图，上图是 webkit.org 的网页快照。由于 iPhone 的屏幕小，如果显示整个页面，那么字体太小无法辨认，所以可以采取局部放大的做法。左下图和右下图分别显示了选择不同区域，缩放比例不同的显示效果。这种效果是如何实现的呢？

一个很朴素的想法是，下载整个网页，生成一幅清晰度很高的照片，当用户选择不同区域和不同缩放比例的时候，截取照片中不同区域，调整缩放比例，显示在手机屏幕上。这个办法很直观，可惜行不通。因为网页上有很多控件，譬如 hyperlink，点击 hyperlink 浏览器就自动下载并显示其它网页。所以浏览器必须记住网页中每个成份的位置和大小，才能支持与用户的准确互动。

iPhone 的浏览器的核心是 WebKit 渲染机。WebKit 是如何完成网页中不同区域，不同缩放比例的渲染的呢？