基于Linux的源代碼開放瀏覽器

Linux在嵌入式系統(tǒng)中的應用正在迅速擴大,，這意味著軟件開發(fā)工程師必須弄懂如何將為資源豐富的臺式PC和服務器開發(fā)的源代碼開放軟件,，應用于資源有限的嵌入式系統(tǒng),。

現(xiàn)在PC機上具備上百兆字節(jié)RAM和幾十GB的硬盤資源已很普遍,，但對嵌入式系統(tǒng)的開發(fā)者來說通常是不可能的,。而且,，運行在可隨意重啟動系統(tǒng)中的桌面和企業(yè)級軟件很容易經(jīng)常升級,，但是安裝在工業(yè)現(xiàn)場的嵌入式應用系統(tǒng)就不太容易，而且理想狀態(tài)下這種系統(tǒng)會一直運行下去,，根本不存在重新啟動的問題,。因此，開發(fā)工程師們應當研究如何在一個只有數(shù)兆存儲器資源的嵌入式設計中,，充分利用過去十年來開發(fā)的桌面軟件資源,？

現(xiàn)有的基于Linux操作系統(tǒng)的桌面瀏覽器家族已經(jīng)發(fā)展到了相當?shù)囊?guī)模，目前市面上可供用戶選擇的桌面瀏覽器超過20種,，那么為什么還要引入另外一種呢,？在做了哪一種現(xiàn)有的桌面瀏覽器適合用于開發(fā)嵌入式瀏覽器的調(diào)查之后，我們發(fā)現(xiàn)沒有一個網(wǎng)絡客戶端的桌面瀏覽器滿足嵌入式系統(tǒng)的要求,。這些瀏覽器不是象Netscape的Mozilla那樣太大而導致沒法在大多數(shù)嵌入式系統(tǒng)上運行,，就是太小,，其HTML功能很不完整，因此我們決定自己設計一種新型瀏覽器,，一種專門適用于嵌入式Linux設備的瀏覽器,。


我們有五個最初的設計目標。首先,，希望創(chuàng)建盡可能小的瀏覽器,，不過這種瀏覽器要保持與HTML 100%的標準兼容性。這種瀏覽器可以應用于很多應用設備,，從嵌入式設備文檔顯示到因特網(wǎng)電器設備和機頂盒,，而且我們必須確信這種瀏覽器總能正確地顯示網(wǎng)頁。其次,，同樣重要的是,，希望采用現(xiàn)有的用于HTML語法分析和顯示引擎的開放式源代碼,，我們不想再從零開始編寫HTML引擎代碼,，這是實現(xiàn)大多數(shù)小型瀏覽器時最常見的一個毛病，因為正確地顯示所有的HTML文件需要大量的知識和經(jīng)驗,，尤其是現(xiàn)在很多的HTML文件仍然是手寫的,。

第三，希望采用已選定的HTML窗口部件代碼,，我們不想改變?nèi)魏魏诵腍TML顯示引擎代碼,，盡管它的源代碼是開放的。這樣做將帶來兩大主要好處：一是不用操心HTML顯示引擎功能的升級,，因為HTML專家已經(jīng)優(yōu)化了HTML分析引擎的代碼設計,；二是不會有設計缺陷被直接引入到核心顯示子程序中，從而可保證很高的代碼質(zhì)量,。

小型窗口部件

第四,，我們想要使用一套適用于小環(huán)境的用戶界面窗口部件，為此,，決定利用Fast Light工具套件(FLTK)應用框架,。FLTK可從www.fltk.org獲得，它能提供一套理想的適用于小型應用環(huán)境的用戶界面窗口部件,。

最后,，我們認為為了使這種瀏覽器被市場廣泛接受，應使它具有足夠的靈活性,，即既可以運行在新型嵌入式Microwindows圖形窗口環(huán)境中（www.microwindows.org）,，也可以運行在標準的X Windows系統(tǒng)中。此外,，我們希望確保這兩種視窗操作系統(tǒng)都可以與該軟件設計進行無縫集成,，而且不會對該瀏覽器的體系結構產(chǎn)生任何影響,。

第一個主要的決定是選擇源代碼開放的HTML語法分析和顯示引擎。我們從KDE桌面的kmf文件管理器中選擇了KDE 1.0 HTML窗口部件（KDE可在www.kde.org獲得）,，這一選擇引出了至少三個問題：為什么不使用KDE更新的v2.0 Konqueror窗口部件,？Mozilla 和 Gecko 搜索引擎怎樣?為什么不使用QT(它是挪威Trolltech AS公司的C++跨平臺GUI開發(fā)系統(tǒng))？

對于第一個問題,，我們是這樣考慮的:KDE 1.0 HTML窗口部件在大多數(shù)網(wǎng)站上都能正確顯示,，這一點我們已經(jīng)通過運行桌面kfm文件管理器得到驗證。KDE窗口部件工作穩(wěn)定,，支持全部HTML 3.2功能,，相對較小，而且其代碼可讀性好,，易于再利用,。那么為什么不使用可支持HTML 4.0和JavaScript 1.4的KDE 2.0窗口部件呢？這里至少有兩個問題：首先,，KDE 2.0在我們設計工作開始的時候還不成熟,，缺少很多功能，而且在實際運作工程中的表現(xiàn)還不夠穩(wěn)定?，F(xiàn)在它已經(jīng)改進了很多,，但仍缺乏實際驗證。與此相反,，KDE 1.0窗口部件已經(jīng)推出了一年多,，實踐證明是比較成熟的；第二,，KDE 2.0窗口部件幾乎比它的1.0版本大四倍,。我們認為對第一版來說，其功能與大小的折衷是可以接受的,，尤其是由于該設計的可擴展性好,，即便在其設計定型以后仍允許添加新的功能。

有段時間,，我們還曾考慮過Mozilla, 它是繼網(wǎng)景瀏覽器之后推出的一種源代碼開放瀏覽器,，但最終因反對聲過多而放棄了它，只因為Mozilla過于龐大了,。Mozilla 版本的GTK+窗口部件（不包括郵件,、新聞等）在不裝入任何網(wǎng)頁的情況下需要多達12M字節(jié)，這比目前的ViewML瀏覽器要大6倍,。GTK+窗口部件集合也很大,，與FLTK的100k相比，它至少有2M字節(jié)。

易置換的類集

到目前為止,，在考慮使用那一種窗口部件時,，爭論最多的是KDE 1.0窗口部件使用的QT窗口部件集合（QT可從www.trolltech.com 獲得）。如果我們可以對最初的設計目標做一些妥協(xié),，那么QT窗口部件將由于好幾種理由而成為這一方案的一個合乎邏輯的選擇,。其中之一是，尚沒有Microwindows版本的QT采用了一種獨特的編碼風格,，它允許用運行在另一工具套件上的改進版類方便地置換原有的類,，這一工具套件具有Microwindows和X版本。

這一事實降低了QT API的總體大小,，因為我們不再需要所有的類,。你可得到一個免費的QT版本作為編碼參考。

我們最終選擇的是可同時在Microwindows和X上運行的唯一窗口部件集合FLTK,，這一工具套件也采用C++編寫,。選擇它的另外一個好處是這一工具套件在對QT API和后端FLTK進行集成時相對較簡單。

在選擇了核心顯示引擎之后,，我們創(chuàng)建了一個分層軟件體系結構,，這一結構嚴格地定義了每一個瀏覽器模塊以及每一模塊應該完成的功能。為了滿足不改變顯示引擎編碼的設計目標,，該體系結構是必需的,。我們也必須定義一些新模塊,，一旦開發(fā)出更小的模塊,，或因采用圖形化視窗系統(tǒng)而需要對某些模塊進行更改，就可以置換舊模塊,。我們集成的模塊包括：瀏覽器應用層,、萬維網(wǎng)的WWWLib庫、KHTML View和窗口部件模塊,、QT兼容層,、IMLIB 圖形庫和FLTK應用框架。

ViewML瀏覽器應用層很小,，并完全用C++ FLTK應用框架編寫,，它提供了基本的圖形用戶界面布局。我們盡量將這一層做得很小,，以便應用工程師能夠很容易地為某個特定嵌入式應用環(huán)境修改ViewML瀏覽器,，而無需深入了解整個瀏覽器。在一些嵌入式應用環(huán)境中,，可能根本沒有用戶界面,，只顯示一個全屏幕的瀏覽器頁面。這一層也可以處理網(wǎng)絡和本地文件存取需求。

我們選用了萬維網(wǎng)協(xié)會的WWWLib庫來執(zhí)行所有的異步網(wǎng)絡輸入/輸出和HTTP獲得(HTTP get)功能,，因為它比較容易使用,。我們發(fā)現(xiàn)WWWLib庫基本上要比實際所需要的大，因此它可能將被改寫,。不過,，就目前而言，它使我們不必在這一專門領域花費太多精力就可迅速獲取初始版瀏覽器的功能,。

KHTML View和窗口部件模塊由原始的未經(jīng)修改的KDE 1.0 HTML窗口部件代碼構成,，這一未經(jīng)修改的源代碼被上層的用戶界面應用層調(diào)用，仍認為是在和下層的QT應用框架通信,。KHTML窗口部件處理所有的HTML語法分析,、作圖和基本的布局操作，它并不直接處理屏幕滾動或顯示框架的操作,，而是把這些任務授權給KHTML View去做,。KHTML View是ViewML中功能最全面的一種窗口部件，它管理一個或多個KHTML窗口部件,，并執(zhí)行屏幕滾動和HTML框架顯示操作,。

QT兼容性層提供未經(jīng)修改的HTML窗口部件和FLTK應用框架(而不是QT框架)之間的接口。C++ QT類在這一層被改寫,，以保持相同的公共接口,，這些類包括圖形窗口部件（編輯控制、按鈕等）,、類集及字符串類,、以及實現(xiàn)一些特定QT功能的通用功能類。所有的圖形類采用FLTK提供的功能實現(xiàn),，這使得所有標準控制和大多數(shù)作圖功能相對比較容易實現(xiàn),，不過，用于窗口部件內(nèi)部通信的非標準QT信號機制不得不從零開始進行編碼,。所有的類集和字符串類在標準C++庫中實現(xiàn),，這些庫包括：堆棧、列表,、字典（哈希表）和常見字符串類,，除了QT在其類集合中使用的新型自動刪除機制以外，這些類完全是標準的,。

對圖象而言,，Gnome項目中的IMLIB曾用于X視窗系統(tǒng)，IMLIB庫允許實現(xiàn)QT類型圖象的顯示功能,，包括自動檢測圖象類型,、自動縮放圖象,、以及將圖象顯示在屏幕上。盡管IMLIB庫也有一些不足之處,，例如大小,，但最主要的缺點是它不適用于Microwindows。因此,，對于該環(huán)境,，我們直接將圖形圖象支持功能增加到Microwindows中，這樣就較好地解決了這一問題,，同時使該模塊仍保持較小的尺寸,，并且允許增加新的圖像解碼器。

根據(jù)視窗系統(tǒng)的不同,，可以采用兩個不同版本的FLTK應用框架,。標準版本的FLTK包括對Win32和X的支持。我們和Microwindows項目開發(fā)人員一起將FLTK移植到Microwindows已有的Nano-X　API中,，這一技術支持允許與Microwindows服務器進行客戶-服務器交互,，就如同采用Xlib模型一樣。由于FLTK和Microwindows都能支持X Window系統(tǒng),，因此它是一個很不錯的選擇,。

通過直接采用帶FLTK的X Windows系統(tǒng)，或在X Windows系統(tǒng)上運行Microwindows服務器,，ViewML瀏覽器就可在Linux平臺上進行調(diào)試和改進,。用這種方法，不管運行的Microwindows還是X Windows系統(tǒng),，目標環(huán)境的確切特性都可以被仿真出來,。Microwindows系統(tǒng)允許在臺式機上仿真目標設備的準確顯示特性，我們也希望能夠在臺式機上運行與目標設備基本相同的代碼路徑,，這可極大地改善質(zhì)量控制,。

ViewML項目已經(jīng)在短時間內(nèi)開發(fā)出了一種高品質(zhì)的網(wǎng)絡瀏覽器,，它直接針對嵌入式Linux環(huán)境,。通過包含源代碼開放的核心部件，我們已經(jīng)能夠在不占用多少RAM和ROM資源的情況下使用一個高品質(zhì)的顯示引擎,。

ViewML瀏覽器的運行大概需要2M字節(jié)的RAM,，代碼文件的大小大約是800k。在Microwindows系統(tǒng)環(huán)境下運行時,，對RAM的需求不超過2.5M字節(jié),，這使它可用在大多數(shù)帶圖象顯示功能的32位嵌入式Linux系統(tǒng)上。由于整個ViewML項目的源代碼是開放的,，因此其他開發(fā)者可以迅速理解ViewML并進一步將它加以完善,。