基于Linux的源代码开放浏览器

基于Linux的源代码开放浏览器

Linux在嵌入式系统中的应用正在迅速扩大，这意味着软件开发工程师必须弄懂如何将为资源丰富的台式PC和服务器开发的源代码开放软件，应用于资源有限的嵌入式系统。

现在PC机上具备上百兆字节RAM和几十GB的硬盘资源已很普遍，但对嵌入式系统的开发者来说通常是不可能的。而且，运行在可随意重启动系统中的桌面和企业级软件很容易经常升级，但是安装在工业现场的嵌入式应用系统就不太容易，而且理想状态下这种系统会一直运行下去，根本不存在重新启动的问题。因此，开发工程师们应当研究如何在一个只有数兆存储器资源的嵌入式设计中，充分利用过去十年来开发的桌面软件资源？

现有的基于Linux操作系统的桌面浏览器家族已经发展到了相当的规模，目前市面上可供用户选择的桌面浏览器超过20种，那么为什么还要引入另外一种呢？在做了哪一种现有的桌面浏览器适合用于开发嵌入式浏览器的调查之后，我们发现没有一个网络客户端的桌面浏览器满足嵌入式系统的要求。这些浏览器不是象Netscape的Mozilla那样太大而导致没法在大多数嵌入式系统上运行，就是太小，其HTML功能很不完整，因此我们决定自己设计一种新型浏览器，一种专门适用于嵌入式Linux设备的浏览器。


我们有五个最初的设计目标。首先，希望创建尽可能小的浏览器，不过这种浏览器要保持与HTML 100%的标准兼容性。这种浏览器可以应用于很多应用设备，从嵌入式设备文档显示到因特网电器设备和机顶盒，而且我们必须确信这种浏览器总能正确地显示网页。其次，同样重要的是，希望采用现有的用于HTML语法分析和显示引擎的开放式源代码，我们不想再从零开始编写HTML引擎代码，这是实现大多数小型浏览器时最常见的一个毛病，因为正确地显示所有的HTML文件需要大量的知识和经验，尤其是现在很多的HTML文件仍然是手写的。

第三，希望采用已选定的HTML窗口部件代码，我们不想改变任何核心HTML显示引擎代码，尽管它的源代码是开放的。这样做将带来两大主要好处：一是不用操心HTML显示引擎功能的升级，因为HTML专家已经优化了HTML分析引擎的代码设计；二是不会有设计缺陷被直接引入到核心显示子程序中，从而可保证很高的代码质量。

小型窗口部件

第四，我们想要使用一套适用于小环境的用户界面窗口部件，为此，决定利用Fast Light工具套件(FLTK)应用框架。FLTK可从www.fltk.org获得，它能提供一套理想的适用于小型应用环境的用户界面窗口部件。

最后，我们认为为了使这种浏览器被市场广泛接受，应使它具有足够的灵活性，即既可以运行在新型嵌入式Microwindows图形窗口环境中（www.microwindows.org），也可以运行在标准的X Windows系统中。此外，我们希望确保这两种视窗操作系统都可以与该软件设计进行无缝集成，而且不会对该浏览器的体系结构产生任何影响。

第一个主要的决定是选择源代码开放的HTML语法分析和显示引擎。我们从KDE桌面的kmf文件管理器中选择了KDE 1.0 HTML窗口部件（KDE可在www.kde.org获得），这一选择引出了至少三个问题：为什么不使用KDE更新的v2.0 Konqueror窗口部件？Mozilla 和 Gecko 搜索引擎怎样?为什么不使用QT(它是挪威Trolltech AS公司的C++跨平台GUI开发系统)？

对于第一个问题，我们是这样考虑的:KDE 1.0 HTML窗口部件在大多数网站上都能正确显示，这一点我们已经通过运行桌面kfm文件管理器得到验证。KDE窗口部件工作稳定，支持全部HTML 3.2功能，相对较小，而且其代码可读性好，易于再利用。那么为什么不使用可支持HTML 4.0和JavaScript 1.4的KDE 2.0窗口部件呢？这里至少有两个问题：首先，KDE 2.0在我们设计工作开始的时候还不成熟，缺少很多功能，而且在实际运作工程中的表现还不够稳定。现在它已经改进了很多，但仍缺乏实际验证。与此相反，KDE 1.0窗口部件已经推出了一年多，实践证明是比较成熟的；第二，KDE 2.0窗口部件几乎比它的1.0版本大四倍。我们认为对第一版来说，其功能与大小的折衷是可以接受的，尤其是由于该设计的可扩展性好，即便在其设计定型以后仍允许添加新的功能。

有段时间，我们还曾考虑过Mozilla, 它是继网景浏览器之后推出的一种源代码开放浏览器，但最终因反对声过多而放弃了它，只因为Mozilla过于庞大了。Mozilla 版本的GTK+窗口部件（不包括邮件、新闻等）在不装入任何网页的情况下需要多达12M字节，这比目前的ViewML浏览器要大6倍。GTK+窗口部件集合也很大，与FLTK的100k相比，它至少有2M字节。

易置换的类集

到目前为止，在考虑使用那一种窗口部件时，争论最多的是KDE 1.0窗口部件使用的QT窗口部件集合（QT可从www.trolltech.com 获得）。如果我们可以对最初的设计目标做一些妥协，那么QT窗口部件将由于好几种理由而成为这一方案的一个合乎逻辑的选择。其中之一是，尚没有Microwindows版本的QT采用了一种独特的编码风格，它允许用运行在另一工具套件上的改进版类方便地置换原有的类，这一工具套件具有Microwindows和X版本。

这一事实降低了QT API的总体大小，因为我们不再需要所有的类。你可得到一个免费的QT版本作为编码参考。

我们最终选择的是可同时在Microwindows和X上运行的唯一窗口部件集合FLTK，这一工具套件也采用C++编写。选择它的另外一个好处是这一工具套件在对QT API和后端FLTK进行集成时相对较简单。

在选择了核心显示引擎之后，我们创建了一个分层软件体系结构，这一结构严格地定义了每一个浏览器模块以及每一模块应该完成的功能。为了满足不改变显示引擎编码的设计目标，该体系结构是必需的。我们也必须定义一些新模块，一旦开发出更小的模块，或因采用图形化视窗系统而需要对某些模块进行更改，就可以置换旧模块。我们集成的模块包括：浏览器应用层、万维网的WWWLib库、KHTML View和窗口部件模块、QT兼容层、IMLIB 图形库和FLTK应用框架。

ViewML浏览器应用层很小，并完全用C++ FLTK应用框架编写，它提供了基本的图形用户界面布局。我们尽量将这一层做得很小，以便应用工程师能够很容易地为某个特定嵌入式应用环境修改ViewML浏览器，而无需深入了解整个浏览器。在一些嵌入式应用环境中，可能根本没有用户界面，只显示一个全屏幕的浏览器页面。这一层也可以处理网络和本地文件存取需求。

我们选用了万维网协会的WWWLib库来执行所有的异步网络输入/输出和HTTP获得(HTTP get)功能，因为它比较容易使用。我们发现WWWLib库基本上要比实际所需要的大，因此它可能将被改写。不过，就目前而言，它使我们不必在这一专门领域花费太多精力就可迅速获取初始版浏览器的功能。

KHTML View和窗口部件模块由原始的未经修改的KDE 1.0 HTML窗口部件代码构成，这一未经修改的源代码被上层的用户界面应用层调用，仍认为是在和下层的QT应用框架通信。KHTML窗口部件处理所有的HTML语法分析、作图和基本的布局操作，它并不直接处理屏幕滚动或显示框架的操作，而是把这些任务授权给KHTML View去做。KHTML View是ViewML中功能最全面的一种窗口部件，它管理一个或多个KHTML窗口部件，并执行屏幕滚动和HTML框架显示操作。

QT兼容性层提供未经修改的HTML窗口部件和FLTK应用框架(而不是QT框架)之间的接口。C++ QT类在这一层被改写，以保持相同的公共接口，这些类包括图形窗口部件（编辑控制、按钮等）、类集及字符串类、以及实现一些特定QT功能的通用功能类。所有的图形类采用FLTK提供的功能实现，这使得所有标准控制和大多数作图功能相对比较容易实现，不过，用于窗口部件内部通信的非标准QT信号机制不得不从零开始进行编码。所有的类集和字符串类在标准C++库中实现，这些库包括：堆栈、列表、字典（哈希表）和常见字符串类，除了QT在其类集合中使用的新型自动删除机制以外，这些类完全是标准的。

对图象而言，Gnome项目中的IMLIB曾用于X视窗系统，IMLIB库允许实现QT类型图象的显示功能，包括自动检测图象类型、自动缩放图象、以及将图象显示在屏幕上。尽管IMLIB库也有一些不足之处，例如大小，但最主要的缺点是它不适用于Microwindows。因此，对于该环境，我们直接将图形图象支持功能增加到Microwindows中，这样就较好地解决了这一问题，同时使该模块仍保持较小的尺寸，并且允许增加新的图像解码器。

根据视窗系统的不同，可以采用两个不同版本的FLTK应用框架。标准版本的FLTK包括对Win32和X的支持。我们和Microwindows项目开发人员一起将FLTK移植到Microwindows已有的Nano-X　API中，这一技术支持允许与Microwindows服务器进行客户-服务器交互，就如同采用Xlib模型一样。由于FLTK和Microwindows都能支持X Window系统，因此它是一个很不错的选择。

通过直接采用带FLTK的X Windows系统，或在X Windows系统上运行Microwindows服务器，ViewML浏览器就可在Linux平台上进行调试和改进。用这种方法，不管运行的Microwindows还是X Windows系统，目标环境的确切特性都可以被仿真出来。Microwindows系统允许在台式机上仿真目标设备的准确显示特性，我们也希望能够在台式机上运行与目标设备基本相同的代码路径，这可极大地改善质量控制。

ViewML项目已经在短时间内开发出了一种高品质的网络浏览器，它直接针对嵌入式Linux环境。通过包含源代码开放的核心部件，我们已经能够在不占用多少RAM和ROM资源的情况下使用一个高品质的显示引擎。

ViewML浏览器的运行大概需要2M字节的RAM，代码文件的大小大约是800k。在Microwindows系统环境下运行时，对RAM的需求不超过2.5M字节，这使它可用在大多数带图象显示功能的32位嵌入式Linux系统上。由于整个ViewML项目的源代码是开放的，因此其他开发者可以迅速理解ViewML并进一步将它加以完善。