微浏览器技术详解simple.docx

《微浏览器技术详解simple.docx》由会员分享，可在线阅读，更多相关《微浏览器技术详解simple.docx（27页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、深入微型浏览器 (Micro Browser) 三之一信息工业策进会 嵌入式系统实验室 WAP 技术小组 前言微型浏览器 (Micro Browser) 主要的应用层面，是在嵌入式系统中，如信息家电、PDA 等。现今由于行动通信的蓬勃发展，在行动通信上也开始有微型浏览器的相关应用出现，使得行动电话使用者也能够透过无线宽带网络尽情浏览网络，使用因特网上的信息与服务。本文将以一个实际运作的微型浏览器 Rock Browser 为主轴，介绍微型浏览器的设计理念与方法，同时讲述微型浏览器中各个模块如何互相协同运作，来完成一个呈现网页的工作。现况分析近年来，行动电话和因特网应用的整合，带来了无限商机。包

2、括 Microsoft、IBM、Oracle 等软件大厂，以及许多新兴业者，无不竞相投入无线网络应用服务器 (Wireless Application Server)、网关器 (Wireless Application Gateway) 等伺服端相关软件平台的开发。就其中微型浏览器软件开发而言， 我们列出几家知名的微型浏览器厂商与 Rock Browser，就其所支持的规格作为比较分析：表1：微型浏览器功能支持 ( 注：O 表示支持，X 表示未支持 )就各家微型浏览器支持规格上来看，其规格支持差异不大，主要以 XHTML Mobile Profile 和 WML 2.0 为主要支持内容，搭配

3、WCSS 加以变化，其中又以 Openwave 和 Teleca 的支持最完整。而近来，打得火热的 MMS 也因各家厂商为争取大中华地区的订单而新增的功能。就微型浏览器的市场来说，目前是各家微型浏览器各占一方，尚无一家独大的趋势。例如邻近的日本，ACCESS 由于 i-mode 的经营成功而拥有大半的日本市场；而全球行动电话的领导厂商 Nokia，则采用知名浏览器公司 Opera 所提供的微型浏览器；Openwave 更是因为已被多家行动电话厂商所采用而占有一块不小的市场；以大陆市场而言，Teleca 近日(6/18) 和中国行动电话制造商 Levono (前身为 legend)签署了一份合作

4、同意书，未来将在大陆市场上协同作战。其中还有可怕的敌人-微软，微软虽然目前并没有倾全力抢占微型浏览器市场，但是随着 WinCE 操作系统的畅销，其它微型浏览器似乎也只能在非 WinCE的市场上争个长短，谁也不敢妄想在 WinCE 上动脑筋。系统需求根据上述的结果，我们整理出一个微型浏览器所该具备的基本功能，包含: XML 的支援XML可扩展标示语言(eXtensible Markup Language) 是用于标示具有结构性信息的子文件的标示语言。XML 的规格是由全球信息网标准制定组织 (W3C) 制定，并于 1998 年 2 月成为推荐规格。目前已有许多家厂商采用，且视为关键性技术。例如：

5、Adobe，IBM，微软，Netscape，Oracle，Sun 及这个领域中的重要厂商。XML 与 HTML 都是从 SGML 衍生出来的语言，因此它们两者在某些特性上看起来都很相似，例如类似的语法，全部都使用成对的标签等等。然而一个很重要的差异是，HTML 是 SGML 的一种应用系统（application），而 XML 则是 SGML 的子集（subset）。XML 主要提供网页编辑上的可携带性与平台发展的独立性。 DOM 的支援DOM 是一个跨平台的应用程序接口。当微型浏览器加载一个标准的 XML 的网页时，微型浏览器会根据其网页内容建立一个文件对象的相关模块即 DOM，来作为标准化

6、的存取与操作。 Script 的支援Script 主要用来提供动态网页与网页的互动效果。以往这些网页上的互动效果需要透过 CGI 的方式交由网页服务器来运作，往往会造成服务器得负担。而 Script 将这些动态网页的互动效果放入 XML 网页中，当微型浏览器加载 XML 网页时，能由网页中的 Script 内容自行作运算产生动态网页的效果，来减少服务器的负担。 Plug-in 的支援提供一个标准接口，供其它 Three Party 协助开发其它应用软件如 Flash 等应用与微型浏览器作结合，提高微型浏览器的功能与兼容性。 CSS 的支援CSS串联式排版样式(Cascading Style S

7、heets)为 W3C 在 1996 年底所提倡使用的，其为一群模板样式，依序为定义 HTML 组件如何出现在浏览器上的属性；比方说字型颜色的变化、大小或是斜体、粗体等。主要的功能是让 Web 建置者利用link or import a Style Sheet 的方式一次控制一份或多份网页的呈现配置及样式。由上述的技术要项中，读者或许会觉得微型浏览器的技术要项与桌上型浏览器似乎是大同小异。事实上，微型浏览器异于桌上型浏览器的最大不同在于发展平台上。通常微型浏览器是被烧录在行动电话或个人数字助理 (PDA) 这一类的机器上，使用者无法或根本不会主动去更换这类程序，因此这些浏览器厂商主要关心的是制

8、造商和内容供货商需求，例如能否浏览内容供货商自己开发的网站取得服务或是产品能否快速整合及所占内存的大小等等，因此这些浏览器开发厂商在推销产品时，通常都以支持规格为辅，主要推销产品的诉求是在于微型浏览器是否能够存取特定的服务网站、可移植性、效能及在内存中动态和静态所占的空间，用来获取制造商和内容供货商的青睐。因此在微型浏览器的设计上，除了考虑浏览器的功能外，还需要在有限的硬件资源下发展具高性能，高效能，低耗电的设计。技术上的挑战Memory的限制由于非 PC 平台的内存，扣除掉操作系统所需的内存，其它应用程序的可用内存都相当有限，因此在开发微型浏览器时，要降低程序代码本身（Code Storag

9、e）的大小，以及执行时期对内存的需求（Run-time Memory Requirement），同时兼顾到浏览器执行时与系统的整体效能。因此需要考虑到以下两点。 微型浏览器的数据结构在制订浏览器所需的数据结构时，考虑各个字段的必要性，并选择语言层次（C 语言）中得以包含该字段信息的最小数据型别，使得编译器能以最少量的内存空间来编译程序。 对象的重复使用 (Reuse)由于浏览器执行时的某些对象（或数据结构）是数个内部组件都需使用到的，为避免同一份信息被产生出多份复本，因此我们让所有需要用到该份对象的组件，都共享同一份对象（仅配置一块内存），并利用 Reference Counting 的方法对

10、每个共享对象保留一个参用计数，当有组件欲使用/释放该共享对象时，就将参用计数的值加/减 1，只有在参用计数的值为 0 时，才会真的删除该共享对象，避免共享对象在仍有组件使用时，就被其它组件给删除。倘若有某个组件想更改共享信息的内容，才需要再另外复制一份信息供组件修改使用。另外，在浏览器的网络传输与 Script Interpreter 执行过程中，经常会需要产生大量的相似对象，然而频繁的配置内存会造成程序执行效能的降低。为提升程序执行效能且节省内存的使用，我们有限度的使用 Object Reuse的技巧，来重复利用这些相似对象。把使用完毕的相似对象暂存于一个Free-Object List 中

11、，当需要产生新的相似对象时，就可以直接取用 Free-Object List 中的对象，而不用再配置新的内存。速度的限制在非 PC 平台上，处理器的效能不若 PC 平台上强大。因此，微型浏览器的效能必须要被提升。就这方面来说，我们设计两个能够提升整体效能的方法： 以C语言实作核心：Rock Browser 是以 UML 的观点设计，因此在架构上是以对象导向为概念，但是在实作之初，考虑到对象导向语言在实作继承、多形和封装时，额外的机制会造成程序代码变大变慢，且在移植平台的语言支持上，C 语言是较常被支持的。因此决定以 C 语言来实作对象导向观念所设计的项目。这样不但可以制作快速而小的程序，同时也

12、具备了较高的移植性。 数组堆栈：在微型浏览器中，数组堆栈是一个经常被使用的组件，因此这部分的效能会影响整个微型浏览器的效能。所谓的数组堆栈是指先配置一块内存，用来存放每次推入（push）和取出（pop）的数据，可是这样有个先天的缺点就是必须是固定长度的堆栈，若是超过堆栈的长度，程序就很可能出问题。所以我们使用 realloc 的方式来改善这个缺点。底下的程序代码是我们实作的原理，我们将每个堆栈的数据当成只有四个字节：我们在开始处先判断堆栈的指针是否为真，若为空的，先配置一块预设大小的内存，下次再有数据需要推入时，我们会去检查他的大小，若是配置的内存超过他所能够推入的数据，那我们就利用 real

13、loc 重新配置一块大小为两倍内存空间在同一个指针位置。观念很简单，主要的用意是要达成利用数组的方式实作堆栈，如此存取快速，又可以克服数组只能用在固定大小的堆栈，而取出数据时只需要将内存空间写成默认值，不需要将内存释放。我们测试效能之后，发现和一般利用动态配置内存串成堆栈的方式相比，存取 1000000 比数据快了将近有 40 倍之多。因篇幅有限，整套API实作程序代码的，也就不再详述。可移植性以可移植性而言，在微型浏览器的设计中，我们将微型浏览器中与平台相关的部分切割出来成为单一模块。当微型浏览器需要被移植到各种不同平台时，只要修改该模块即能移植至其它异质平台上来达到微型浏览器的高移植性，减

14、少软件移植的时间。这些模块包括： 使用者接口方面：微型浏览器所使用到的使用者界面会依据不同的窗口操作系统而被更动。如按钮键 (Button) 的产生等窗口组件的绘制，或是窗口组件的事件产生，都会随着不同的窗口操作系统而不同。因此在微型浏览器的设计中，为了高移植性需要将这部分的处理单一模块化。 操作系统相关方面：如 Thread、Socket、File 等跟系统相关的运作，通常这些操作会随着平台的操作系统不同而改变其使用方式或是行为的动作，因此这部分也需要单一模块化。 工具接口方面：像是 List、String 等常使用的公用工具，将它单一模块化除了为了移植性的考虑，也可独立出来供其它应用程序使

15、用。微型浏览器的架构以下将为读者开始讲述我们独力开发的微型浏览器 Rock Browser。下图为微型浏览器的架构图：图1：Rock Browser 架构图我们将微型浏览器切割成五大模块，分别叙述如下： 可移植性 (Portable Interface) 模块将跟系统平台有关的程序，切割成 Portable Interface 模块，以便微型浏览器能在最短时间能移植至异质平台上。因此这部分的模块程序多为与系统平台相关操作，包含了：GUI Interface、Thread Interface、Network Interface、Storage Interface、Utility Interfac

16、e 等。 使用者接口 (Browser main and User Interface) 模块此模块主要负责与使用者间的互动讯息以及使用者接口的呈现与管理。这部分包含了 Skin Manager (管理浏览器的使用者接口的样式) 、Bookmark Manager (管理使用者所设定的 Bookmark) 、Browser User Interface (微型浏览器的使用者接口)、Browser Main (使用者的事件处理)等。 核心(Browser Engine) 模块此为微型浏览器的核心部分，主要用来处理与管理微型浏览器所接收到的 XML 网页。包含有：XML Tag 处理、CSS 的S

17、tyle 处理、Script 的处理、网页图形处理，Layout Manager、Storage Manager、Parser、History Manager 等。 网络 (Network Protocol) 模块此为网络实际运作模块。如 HTTP， 等通讯协议。微型浏览器的运作方法在介绍完 Rock Browser 的架构后，接下来，我们将带领读者进入 Rock Browser 的运作流程。我们将从一个 XML 的网页的加载开始，一步一步带领读者进入微型浏览器的运作流程中，并于各个流程中探讨微型浏览器的设计秘辛。从微型浏览器的开启、网页的抓取、进入 Parser 的处理、Layout 的处理

18、、网页的呈现等程序来介绍微型浏览器的设计。开启微型浏览器乍看这个标题，读者或许会问，微型浏览器的开启会有什么的特别的技巧。事实上，在非 PC 平台上，嵌入式系统处理器效能不似PC平台上那样快速，往往为了加载一个应用程序而消耗一大段系统时间，有时甚至会让使用者误以为系统当机。在人机接口的设计上，为了解决这个问题，我们将微型浏览器的初始化步骤细分成几个部分：1.使用者接口初始化：为了让使用者能够有系统正在执行的感觉，我们先再画面上呈现微型浏览器的外框，包括一些基本的视觉对象，如标题列、工具列状态列等对象。如下图所示：2.载入首页：接下来，微型浏览器会处理一些跟使用者接口较无关系的动作。根据使用者所

19、设定的首页或经由别的程序传入值，决定要加载的首页，并执行抓取、编排和显示网页。这部分流程包含抓取网页内容等动作，还有一些必要的对象如快取机制（cache）和历史纪录（history）功能等。其结果如下面画面所示：3.使用者设定：一般而言，供使用者设定微型浏览器选项的接口画面，并不需要在微型浏览器被加载时，就被先计算且呈现在画面上。一般都是等到使用者点选某个按钮或功能才会处理画面的呈现。因此，我们将这部分的画面加载处理程序，移至使用者去触发时，才处理，以便增加为型处理器加载的速度。如下两图所示：对于这样的加载流程，可以减少使用者等待系统反应的等待时间，而使得整个微型浏览器的加载流程会更为流畅，产

20、生加速的效果。抓取网页浏览器最基本的功能，就是能够将因特网上的众多资源，例如网页上的内容与信息或是在线服务等，呈现给使用者并让使用者得以使用存在于因特网上的各项服务。因此透过网络传输数据对浏览器来说，是相当重要且必备的一项能力。为了让微型浏览器能够存取因特网上的各项资源并适应各种不同的网络环境，我们开发出 Protocol Stack 提供 WP-HTTP/WP-TCP 与 WSP/WTP/WDP 这两大网络通讯协议架构，让浏览器可以因应不同网络环境的需要，使用适当的网络通讯协议来抓取因特网上的数据。图6：微型浏览器利用 WP-HTTP/WP-TCP/IP 等通讯协议去抓取数据图7：微型浏览器

21、利用WSP/WTP/WDP等通讯协议去抓取数据浏览器除了要能透过网络去抓取数据外，亦需提供数据快取（Cache）功能，将抓回的网页数据选择性的储存在手持装置上，并提供快取管理机制，将已过时（expired）的网页数据从快取储存区中移除，避免让使用者浏览到无效的信息。然而快取在手持装置上的数据也应有总容量的限制，让使用者可以根据手持装置的配备能力，来决定可储存多少的快取数据。此外目前因特网上常用的 Cookie 机制，也是微型浏览器应支持的一项功能。Cookie 是使用者透过浏览器在网上浏览时，网络服务器要求浏览器所记录下来的数据，可以用来追踪使用者或对重返的使用者进行确认，而网络服务器也会告知

22、浏览器，有哪些人可以看到这个 Cookie，以及 Cookie 资料有效的时间长度。Cookie 的内容可储存使用者上网的许多个人信息，虽然可以让使用者浏览时更为方便，但也由于 Cookie 能够追踪使用者在网络上的许多动作，因此也有其安全上的顾虑。因此浏览器在提供 Cookie 功能的同时，也需提供一定程度的安全机制来保护使用者的个人信息不会被任意侵犯。待续截至目前为止，我们已经就微型浏览器的加载以及网页的抓取流程作简单的介绍，由于篇幅有限，我们将在下一篇中继续为读者剖析介绍微型浏览器的核心技术。深入微型浏览器 (Micro Browser) 三之二信息工业策进会 嵌入式系统实验室 WAP

23、技术小组 前言在上一篇的文章中，我们介绍了目前各家微型浏览器的现况，以及在嵌入式系统上开发微型浏览器所需要的考虑与技术上的挑战等等。并且简介了我们自行开发的微型浏览器的使用者接口以及初始化的运作流程。紧接着在本篇文章中，我们将以节录部分程序代码配合概念解说的方式，带领读者进一步的深入了解微型浏览器的核心技术。深入微型浏览器核心微型浏览器的最重要核心技术，便是将网页设计者撰写的 HTML、XML、WML等标示语言(Markup Language)，经过处理还原成具有多媒体呈现效果的网页。这个过程主要可以区分成两步骤，先将网页的原始码经由 Parser 处理成具有意义的数据结构，再由 Layout

24、 Manager 来进行网页页面的编排，将标示语言还原成原来的面貌。因此，本篇文章的前半部将先从 Parser 处理及数据结构的概念谈起，介绍标示语言的处理方法及需要特别注意的地方；后半部则从 C 仿真 C+ 语言谈起，以实作的方式介绍我们如何以 C 语言为核心，建构出 C+ 语言的继承关系，然后到整个网页的完整呈现，为读者做一个完整的介绍。微型浏览器核心运作流程微型浏览器从网络下载回数据后，首先会交由一个称为 Dispatcher 的对象来处理(图一)。Dispatcher 对象是由 Queue(队列)的数据结构所组成，当网络层有数据送回来的时候，会透过 Storage Manager 放进

25、 Dispatcher 的 Queue 中，再由 Dispatcher 分辨来源资料的 MIME Type。然后依据不同的 MIME Type 交由不同的组件进行处理。Dispatcher 会将 MIME Type 属于卷标语言类型的数据送至 Parser 进行处理。现今处理此种卷标语言的标准主要分为两大主流，其一是强调效能和使用简单的 Simple API for XML (SAX)，另一个是功能齐全且被广泛应用在 XML 和 HTML 文件的标准程序存取接口，Document Object Model (DOM)。SAX的好处在于只需较少的内存空间且具有较佳的执行效率。但是相对的，它在对于

26、数据结构存取方面的能力则比较不足，而微型浏览器这类型的应用程序又是属于需要频繁的存取文件以及相关的信息。所以我们在考虑设计的弹性和完整性后，决定采用 DOM 的存取接口。什么是 DOM ( Document object model )?DOM(文件对象模型)，顾名思义就是用对象的观念来描述一份文件，以便在内存中储存 XML、HTML 这类结构性文件，让应用程序能有效率的存取其中相关信息。它在 W3C 的建议案中，被定位为一种与语言和操作系统平台独立的对象模型。依据功能的完整性，DOM 可被分为 Level 1 Level 3 三种等级。Level 1 提供了最基本的对 XML、HTML文 件

27、浏览(Navigation)和操作的功能。Level 2 加入了 Style Sheet Object Model、Traversal Document 的支持，以及支持 XML 的 Namespace 属性。最新拟出草稿的 Level 3 加入了 Document Validate、和一些 Event 如 Key Event、Event Groups 的支持。DOM 最主要的功能是利用对象的观念，把结构性文件建立成类似 Tree (或是说 Forest)的数据结构，以便透过操作 Tree 结构的方式加速数据存取的速度。举例来说，图二(a)这个 HTML 文件，可以转换成为如图二(b)这样的一

28、个 Tree 的结构。在图二(b)中左边灰色的 TR 这个节点，我们可以透过 DOM 定义的 getParentNode()这个接口去找到它的父节点，用 getFirstChild()和 getLastChild()分别可以取得它的第一个子节点和最后一个子节点。其它详细有关 DOM 定义出的接口，读者可以到 W3C 的网站上找到需要的数据。DOM 在现今被广泛的应用在处理 HTML、XML 这类的结构性文件，同时也被实作成各种作业平台和程序语言的版本，尤其像是 Java/C+ 这种对象导向的程序语言，或是业界常用的 C 语言。(有兴趣的读者可以在下列的网址找到各种不同实做版本的 DOM API

29、。)微型浏览器主要应用的平台是在运算资源有限的嵌入式系统，为了执行效率和节省内存空间，我们采用的 DOM Package 只支持 DOM Level 1 和部分的 Level 2。但这也意味着在功能完整性上是较为不足的，如 Traversal Document、和 CSS(Cascading Style Sheet)部分的支持，这些部分则必须另外处理。DOM ParserDOM Parser 的主要功能，就是把文字型态的卷标语言经过 Tokenize、语法语意检查的过程后，转换成 DOM Tree 的数据结构，以利微型浏览器进行存取。以下就Parser的主要功能进行介绍：1.Tokenize：

30、Parser 在取得 Text Stream 型态的数据后，第一件要做的事是根据开头的 Starting Tag，如，和结尾的 End Tag，如，将整个字符串切成一个一个 Token。后续的动作才能根据切出来的 Token，做字码转换、建立 DOM Tree。2.字符集之间的转换：HTML 或 XML 文件都是可以支持多国语言编码的文件类型。甚至在同份文件中也可以透过 tag 的 xml:lang 属性指定不同的编码方式，使 HTML 文件中同时包含两种以上的编码方式。为达到这样的目的，parser 在建立 DOM tree 之前会依据文件中内定的编码方式( 的 charset 属性或是其它

31、 tag 的 xml:lang 属性)，将文件从 local 的编码方式(Big5 or GB 等)统一转为 UTF-8 的编码方式，然后再建立 DOM。如此一来 DOM tree 的编码方式就会统一是 UTF-8 码，方便微型浏览器程序对 DOM tree 做存取的动作。最后在 layout 阶段，才再转换成 UI介 面能显示的字符集。Entity Reference 是在处理 HTML 文件中，会遇到的另一个常见的转码问题。举例说，在 HTML 文件中，空白符号的 Entity Reference 表示方法有三种，第一种是十六进制 Numeric character references

32、表示法第二种是十进制表示法第三种是 Character entity references 的格式。第一和第二种的处理方法，无论是十进制或是十六进制，其数值代表都是 Unicode(UTF-16)的编码数值，所以我们只要把这个整数型态(integer)数值转成字符串文字型态(char *)，再转换成UTF-8编码就可以了。至于 Character entity references 这种方式的表示法，因为没有固定的规则可循，在实做上我们利用查表应对的方式，去转换成相对应的 UTF-8 编码。3.语法语意检查的容错机制(Error recover schema)：在一般网页中，常常会遇到网页原始

33、码有错误的情形发生，这些错误若不加以处理，轻则可能只是显示错误，重则可能导致微型浏览器当掉。其中最常发生的语法或是语意上的错误，可大略分为几项，如：缺少 End Tag、错误的语法(Syntax error)、语意不明(Ambiguous)、不符合标准或是某些浏览器自订支持的 Tag。在介绍我们的解决方法之前，我们先举例说明以上提到网页常犯的错误，可能造成的问题：图四是一个简单的 HTML 片段，网页设计者要表现出两个自动编号的超级链接，其中第一个超级链接 link1 以的格式显示。但是假设网页设计者不小心漏写了的 End Tag ，如此一来就会使得 Outside 这个字也会变成型态的黑体字

34、。这种漏写 End Tag 的例子，同时也会造成语意上的不明，使得 Tag 不知何时结束，导致显示结果错误。为了解决这样的问题，同时顾虑程序执行的效能，我们以实做一个纪录状态的机制来解决这个问题，我们称之为 Tag State Machine。Tag State Machine 机制的基本精神就是利用一个 State Stack 来纪录建立 DOM Tree 的过程中，目前 DOM Node 的位置，以决定下一个要加入的 Node 的 Parent Node 是谁。这个 State Stack 的运作方式就是当 Parser 遇到 Start Tag 型态的 Token，如，就会将这个 Tok

35、en Push 到State Stack中，当遇到End Tag 时，就会把 Token 一个一个 Pop 出来，直到 Pop 出来的 Token 是为止。如果遇到的是 Text 型态的 Node 的话，则不做动作。以图五的 HTML 文件为例，看看在缺少的 End Tag 的情况下，Tag State Machine 是如何运作，帮助我们建立一个正确的 DOM Tree。当 DOM Parser 处理完这个 Token 之后，State Stack 中的数据结构如图五(a)所示。此时 Stack 中最上层的 Token 会是，所以我们纪录的 Parent Node 指针会指向，如(b)所示。

36、接着将 link1 这个 Text Node 加入，使得 DOM Tree 中的数据结构形成(c)所示。由于网页设计者漏写了的 End Tag，所以接下来遇到的是这个 End Tag。此时根据我们的规则，必须从 State Stack 中 Pop 出这个 Token，所以 Parser 会先把给先 pop 出来，检查之后发现并不是我们要的 Token，就会继续 Pop 出下一个 Token 再做检查，发现是之后，这个动作才算完成。此时在 State Stack 中最上层的 Token 会变成，如(d)所示。之后遇到 Outside 这个 Token 的时候，就会被加入到这个 Node 后面，成

37、为的 Child Node，如(e)所示。4.Build DOM Tree:DOM Parser 就是利用 Tag State Machine 确认完语法和语意之后，呼叫 DOM 提供的标准 API 接口，将一个个 Token 加入到 DOM Tree 中，如此一来我们就会得到一个纪录完整文件信息的DOM Tree了，之后在 Layout 阶段需要用到的信息就可以从 DOM Tree 取得。这个例子在我们的微型浏览器展现出来的样子就如图六所示。以 C 模拟 C+ 的概念我们可以将网页上的文字、图片、按钮等等看成是一个一个的对象(Object)，然后设计一个可以容纳并且排列这些对象的组件(Com

38、ponent)，来进行 Layout。因此利用对象导向(Object-Oriented)的设计是很直觉的。这会使得我们自然而然想到使用 C+ 语言来进行实作。但是在之前的文章提到，在微型浏览器所处的平台大都有一些如 Memory 较少、Computing Power 较弱等资源上的限制。再加上很多嵌入式系统中对于 C+ 语言的发展环境支持性较为不足，为了考虑可移植性，以及保有 C 语言的高执行效能，因此我们选择以 C 语言来仿真 C+ 的对象继承关系，以下将配合程序原始码来说明以 C 语言仿真 C+ 语言继承的概念：1.Simple Way:当我们需要一个叫做 Parent 的对象时，使用C语

39、言可以宣告一个 Structure 来实作：其中 mClassID 是 structure 里的一个 Field，用途后面会说明。而 (*miFunc1)(void)则是一个 Function Pointer，可以指向某个实作的 Function。有了 Parent 对象之后，Child 对象要继承 Parent 对象，就可以这样宣告：则 Child 对象在内存里存在的形式就如同上方右图。当 new 出 Child 对象时，就可以利用强制型别转换(Type Casting)的方式使用 Parent 对象或是 Child 对象：这种做法的好处是简单明了，以宣告 Data Structure 的方

40、式即可完成继承；但是因为每个 Child 对象都包含了 Parent 对象，当使用量增加时，则不免浪费内存。2.Advanced Way:另一种较为进阶的方法则是将 Data Structure 中的 Object Structure 与 Object Class Structure 分开。Object Structure 指的是 Class 中的 Member Variable 的部分，而 Object Class Structure 则是指 Class 中 Member Function 的部分。以前面的例子来说，Parent 对象的 Structure 就可以区分成两部分：第一个 Obj

41、ect Structure，里面只有纪录 Parent Structure 中 mClassID 这个 Field，这个字段的数据由系统给予，第一次生成这种对象的时候，会给予一个唯一值。另一个 Object Class Structure 则纪录 miParentFunc 这个 Function Pointer。两个 Structure 之间的关系则是利用一个 Virtual Table 记录起来，这个 Virtual Table 纪录着每个 ClassID 所用到的 Object Class Structure 的指标。这样之后就可以利用 mClassID 来当作 Index 在 Virtu

42、al Table 里找到真正纪录 unction Pointer 的 Object Class Structure，如图七所示：那么这样做的目的是什么呢? 赶紧接着看下去：同样以之前的 Child 对象为例，要继承 Parent 对象时，则形成如图八所示的情形：Child 对象也分为 Object Structure 与 Object Class Structure 两类，在这种类型的 Child 对象第一次被 new 出来的同时，会被给予不同的 Class ID，而与 Child 对象的 Object Class Structure 被 new 出来之后，与 Object Structure

43、 的关系，也会一并纪录在 Virtual Table中。若是这个 Child 对象被大量使用的时候，这种做法的好处就彰显出来了，因为当同类型的 Child 对象再次被 new 出来时，由于它已经注册过相同类型的 ClassID，因此就不需要再 new 出重复的 Object Class Structure，只要 new 出 Object Structure，然后利用 ClassID 到 Virtual Table 里面去找，便可以找到 Object Class Structure 的指标，进而呼叫到正确的 Function，如图九：我们可以 Implement 一个 Macro 叫做 CALL

44、_METHOD(obj)，方便程序设计师不必每次要呼叫 Child 对象的 Member Function 都要自行到 Virtual Table 里去寻找。如此一来，程序代码的呼叫就如同下方所述：至于多重继承的问题，则 Virtual Table 里利用 ClassID 做 Index 的方式需要更复杂的处理，有兴趣读者，可以参考 Glibc 作更深入研究的研究。C语言实作有了概念之后，接下来我们以实作一个 Image 对象为例子来说明运作的情形：在我们的微型浏览器架构中，Image 对象继承自 Widget 对象，而 Widget 对象又继承自对象根源的 Object 对象，因此是两层的继

45、承关系。当外界需要一个 Image 对象时，可以这样呼叫:RWImage* pWidget= RWImage_miCreate();因此我们需要撰写一个 RWImage_miCreate()的 Function 让外面呼叫，其内容是这样的:其中第4行呼叫 gRObjectNew 函式的第一个参数 RWIMAGE 事实上是一个 Macro：#define RWIMAGE (RWImage_mfRegisterType ()这个 Macro 会呼叫 RWImage_mfRegisterType ()这个 Function，这个 Function 是撰写 Image 对象的设计者要实作的函式，内容的

46、部分程序代码(如程序代码一):其中第3行宣告一个 static 的变量 classid，这个 classid 在第一次被生成 Image 这种对象类型的时候，会透过程序代码第 814 行填写一个 info 的数据结构，然后透过第 15 行呼叫 gRegisterTypeInfo()来得到。第 16 行则是由于这种对象第一次被生成，所以也必须将 Object Class 给 new 出来，呼叫的方式是在程序代码第 18 行透过 info.mfClassInitFunc()来呼叫，事实上就是呼叫到第 13 行注册的 (RClassInitFunc) RWImageClass_mfInit 这个函式

47、。然后在第 17 行将 Image 对象的 classid 与 Object Class 一起注册到 Virtual Table 里面，以供之后的查询。第6行的判断式则是当有相同类型的对象被生成时，不需要再重复生成重复的 Object Class。第 11 行的程序代码指向了一个 RWImage_mfInit 的函式，这个函式的功能如同 C+ 语言里的 Constructor 函式一样，程序设计师可以将需要初始化的数据如 Class 里面的 Member Variable 等，写在这个函式中：第 12 行的程序代码则是指向 RWImageClass_mfInit 的函式，这个函式就是将真正在I

48、 mage 对象实作出来的函式指标填到 Object Class 里面，例如 Image 对象继承了 miDraw 这个函式，并且实作在 Image 对象里，这时候就要把指标指向这里实作的位置。程序代码实作如下：其中需要特别注意的是.程序代码一里面第 5 行的程序代码：RClassID parentclassid = ROCKWIDGET;因为 Image 对象是继承自 Widget 对象，因此等号右边的 ROCKWIDGET 也是一个 Macro，正如同 Image 对象一样，Widget 也会有相同的 RWidget_mfRegisterType ()的函式进行 Widget 对象的初始化，所以是一个递归生成的关系，而W idget 继承自 Object，同理 Object 对象也会被生成出来。也就是说：当