微浏览器技术详解-simple

深入微型浏览器 (Micro Browser) 三之一

信息工业策进会嵌入式系统实验室

WAP 技术小组

前言

微型浏览器 (Micro Browser) 主要的应用层面，是在嵌入式系统中，如信息家电、PDA 等。现今由于行动通信的蓬勃发展，在行动通信上也开始有微型浏览器的相关应用出现，使得行动电话使用者也能够透过无线宽带网络尽情浏览网络，使用因特网上的信息与服务。本文将以一个实际运作的微型浏览器 Rock Browser 为主轴，介绍微型浏览器的设计理念与方法，同时讲述微型浏览器中各个模块如何互相协同运作，来完成一个呈现网页的工作。

现况分析

近年来，行动电话和因特网应用的整合，带来了无限商机。包括 Microsoft、IBM、Oracle 等软件大厂，以及许多新兴业者，无不竞相投入无线网络应用服务器 (Wireless Application Server)、网关器 (Wireless Application Gateway) 等伺服端相关软件平台的开发。就其中微型浏览器软件开发而言，我们列出几家知名的微型浏览器厂商与 Rock Browser，就其所支持的规格作为比较分析：

表1：微型浏览器功能支持 ( 注：O 表示支持，X 表示未支持 )

就各家微型浏览器支持规格上来看，其规格支持差异不大，主要以 XHTML Mobile Profile 和 WML 2.0 为主要支持内容，搭配 WCSS 加以变化，其中又以 Openwave 和Teleca 的支持最完整。而近来，打得火热的 MMS 也因各家厂商为争取大中华地区的订单而新增的功能。

就微型浏览器的市场来说，目前是各家微型浏览器各占一方，尚无一家独大的趋势。例如邻近的日本，ACCESS 由于 i-mode 的经营成功而拥有大半的日本市场；而全球行动电话的领导厂商 Nokia，则采用知名浏览器公司 Opera 所提供的微型浏览器；Openwave 更是因为已被多家行动电话厂商所采用而占有一块不小的市场；以大陆市场而言，Teleca 近日(6/18) 和中国行动电话制造商 Levono (前身为 legend)签署了一份合作同意书，未来将在大陆市场上协同作战。其中还有可怕的敌人--微软，微软虽然目前并没有倾全力抢占微型浏览器市场，但是随着 WinCE 操作系统的畅销，其它微型浏览器似乎也只能在『非 WinCE』的市场上争个长短，谁也不敢妄想在 WinCE 上动脑筋。

系统需求

根据上述的结果，我们整理出一个微型浏览器所该具备的基本功能，包含:

● XML 的支援

XML「可扩展标示语言」(eXtensible Markup Language) 是用于标示具有结构性信息的子文件的标示语言。XML 的规格是由『全球信息网标准制定组织』 (W3C) 制定，并于1998 年 2 月成为推荐规格。目前已有许多家厂商采用，且视为关键性技术。例如：Adobe，IBM，微软，Netscape，Oracle，Sun 及这个领域中的重要厂商。。XML 与 HTML 都是从 SGML 衍生出来的语言，因此它们两者在某些特性上看起来都很相似，例如类似的语法，全部都使用成对的标签等等。然而一个很重要的差异是，HTML 是 SGML 的一种应用系统（application），而 XML 则是 SGML 的子集（subset）。XML 主要提供网页编辑上的可携带性与平台发展的独立性。

● DOM 的支援

DOM 是一个跨平台的应用程序接口。当微型浏览器加载一个标准的 XML 的网页时，微型浏览器会根据其网页内容建立一个文件对象的相关模块即 DOM，来作为标准化的存取与操作。

● Script 的支援

Script 主要用来提供动态网页与网页的互动效果。以往这些网页上的互动效果需要透过 CGI 的方式交由网页服务器来运作，往往会造成服务器得负担。而 Script 将这些动态网页的互动效果放入 XML 网页中，当微型浏览器加载 XML 网页时，能由网页中的Script 内容自行作运算产生动态网页的效果，来减少服务器的负担。

● Plug-in 的支援

提供一个标准接口，供其它 Three Party 协助开发其它应用软件如 Flash 等应用与微型浏览器作结合，提高微型浏览器的功能与兼容性。

● CSS 的支援

CSS「串联式排版样式」(Cascading Style Sheets)为 W3C 在 1996 年底所提倡使用的，其为一群模板样式，依序为定义 HTML 组件如何出现在浏览器上的属性；比方说字型颜色的变化、大小或是斜体、粗体等。主要的功能是让 Web 建置者利用link or import a Style Sheet 的方式一次控制一份或多份网页的呈现配置及样式。

由上述的技术要项中，读者或许会觉得微型浏览器的技术要项与桌上型浏览器似乎是大同小异。事实上，微型浏览器异于桌上型浏览器的最大不同在于发展平台上。通常微型浏览器是被烧录在行动电话或个人数字助理 (PDA) 这一类的机器上，使用者无法或根本不会主动去更换这类程序，因此这些浏览器厂商主要关心的是制造商和内容供货商需求，例如能否浏览内容供货商自己开发的网站取得服务或是产品能否快速整合及所占内存的大小等等，因此这些浏览器开发厂商在推销产品时，通常都以支持规格为辅，主要推销产品的诉求是在于微型浏览器是否能够存取特定的服务网站、可移植性、效能

及在内存中动态和静态所占的空间，用来获取制造商和内容供货商的青睐。因此在微型浏览器的设计上，除了考虑浏览器的功能外，还需要在有限的硬件资源下发展具高性能，高效能，低耗电的设计。

技术上的挑战

Memory的限制

由于非 PC 平台的内存，扣除掉操作系统所需的内存，其它应用程序的可用内存都相当有限，因此在开发微型浏览器时，要降低程序代码本身（Code Storage）的大小，以及执行时期对内存的需求（Run-time Memory Requirement），同时兼顾到浏览器执行时与系统的整体效能。因此需要考虑到以下两点。

● 微型浏览器的数据结构

在制订浏览器所需的数据结构时，考虑各个字段的必要性，并选择语言层次（C 语言）中「得以包含该字段信息」的最小数据型别，使得编译器能以最少量的内存空间来编译程序。

● 对象的重复使用 (Reuse)

由于浏览器执行时的某些对象（或数据结构）是数个内部组件都需使用到的，为避免同一份信息被产生出多份复本，因此我们让所有需要用到该份对象的组件，都共享同一份对象（仅配置一块内存），并利用 Reference Counting 的方法对每个共享对象保留一个「参用计数」，当有组件欲使用/释放该共享对象时，就将参用计数的值加/减 1，只有在参用计数的值为 0 时，才会真的删除该共享对象，避免共享对象在仍有组件使用时，就被其它组件给删除。倘若有某个组件想更改共享信息的内容，才需要再另外复制一份信息供组件修改使用。

另外，在浏览器的网络传输与 Script Interpreter 执行过程中，经常会需要产生大量的相似对象，然而频繁的配置内存会造成程序执行效能的降低。为提升程序执行效能且节省内存的使用，我们有限度的使用 Object Reuse的技巧，来重复利用这些相似对象。把使用完毕的相似对象暂存于一个Free-Object List 中，当需要产生新的相似对象时，就可以直接取用 Free-Object List 中的对象，而不用再配置新的内存。

速度的限制

在非 PC 平台上，处理器的效能不若 PC 平台上强大。因此，微型浏览器的效能必须要被提升。就这方面来说，我们设计两个能够提升整体效能的方法：

● 以C语言实作核心：

Rock Browser 是以 UML 的观点设计，因此在架构上是以对象导向为概念，但是在实作之初，考虑到对象导向语言在实作继承、多形和封装时，额外的机制会造成程序代码变大变慢，且在移植平台的语言支持上，C 语言是较常被支持的。因此决定以 C 语言来