深入微型浏览器 (Micro Browser) 三之一
前言
  微型浏览器 (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 内容自行作运算产生动态网页的效果，来减少服务器的负担。
xml技术的主要应用● 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 语言来实作对象导向观念所设计的项目。这样不但可以制作快速而小的程序，同时也具备了较高的移植性。
● 数组堆栈：
在微型浏览器中，数组堆栈是一个经常被使用的组件，因此这部分的效能会影响整个微型浏览器的效能。所谓的数组堆栈是指先配置一块内存，用来存放每次推入（push）和取出（pop）的数据，可是这样有个先天的缺点就是必须是固定长度的堆栈，若是超过堆栈的长度，程序就很可能出问题。所以我们使用 realloc 的方式来改善这个缺点。底下的程序代码是我们实作的原理，我们将每个堆栈的数据当成只有四个字节：
  我们在开始处先判断堆栈的指针是否为真，若为空的，先配置一块预设大小的内存，下次
再有数据需要推入时，我们会去检查他的大小，若是配置的内存超过他所能够推入的数据，那我们就利用 realloc 重新配置一块大小为两倍内存空间在同一个指针位置。观念很简单，主要的用意是要达成利用数组的方式实作堆栈，如此存取快速，又可以克服数组只能用在固定大小的堆栈，而取出数据时只需要将内存空间写成默认值，不需要将内存释放。我们测试效能之后，发现和一般利用动态配置内存串成堆栈的方式相比，存取 1000000 比数据快了将近有 40 倍之多。因篇幅有限，整套API实作程序代码的，也就不再详述。
可移植性
  以可移植性而言，在微型浏览器的设计中，我们将微型浏览器中与平台相关的部分切割出来成为单一模块。当微型浏览器需要被移植到各种不同平台时，只要修改该模块即能移植至其它异质平台上来达到微型浏览器的高移植性，减少软件移植的时间。这些模块包括：
● 使用者接口方面：
微型浏览器所使用到的使用者界面会依据不同的窗口操作系统而被更动。如按钮键 (Button) 的产生等窗口组件的绘制，或是窗口组件的事件产生，都会随着不同的窗口操作
系统而不同。因此在微型浏览器的设计中，为了高移植性需要将这部分的处理单一模块化。
● 操作系统相关方面：
如 Thread、Socket、File 等跟系统相关的运作，通常这些操作会随着平台的操作系统不同而改变其使用方式或是行为的动作，因此这部分也需要单一模块化。
● 工具接口方面：
像是 List、String 等常使用的公用工具，将它单一模块化除了为了移植性的考虑，也可独立出来供其它应用程序使用。
微型浏览器的架构
  以下将为读者开始讲述我们独力开发的微型浏览器 Rock Browser。下图为微型浏览器的架构图：
图1：Rock Browser 架构图
  我们将微型浏览器切割成五大模块，分别叙述如下：
● 可移植性 (Portable Interface) 模块
将跟系统平台有关的程序，切割成 Portable Interface 模块，以便微型浏览器能在最短时间能移植至异质平台上。因此这部分的模块程序多为与系统平台相关操作，包含了：GUI Interface、Thread Interface、Network Interface、Storage Interface、Utility Interface 等。
● 使用者接口 (Browser main and User Interface) 模块
此模块主要负责与使用者间的互动讯息以及使用者接口的呈现与管理。这部分包含了 Skin Manager (管理浏览器的使用者接口的样式) 、Bookmark Manager (管理使用者所设定的 Bookmark) 、Browser User Interface (微型浏览器的使用者接口)、Browser Main (使用者的事件处理)等。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。