一种基于uCLinux的嵌入式Konqueor浏览器的插件开发方法

具体实施方式

下面结合附图以及以实现的一个基于uCLinux的嵌入式Konqueror浏览器的Flash插件为例对本发明做进一步的说明。

本发明提出的基于uCLinux的嵌入式Konqueror浏览器的三层插件开发模型基于KParts技术。移植并实现的基于uCLinux的嵌入式Konqueror浏览器修改并实现了最初用于KDE(K Desktop Environment，K桌面环境，一种自由图形工作环境)下的KParts机制，并且将该技术作为整合整个浏览器的核心，因此很容易地使用该机制来加载和卸载Part。该浏览器的基本框架示意图如图1所示。图中可以看出，浏览器为分层结构，最底层为KIO网络层和JavaScript解释器，中间层为KHTMLPart部件和DOM&Render渲染引擎，它们是整个浏览器的核心部件，最上层为用户接口层，负责浏览器和用户的交互。其中KHTMLPart部件可以嵌套其它的Part，如图中的文本编辑Part和视图Part等

在无MMU(Memory Management Unit，内存管理单元)支持的uCLinux平台上实现基于嵌入式Konqueror框架的浏览器所面临的问题有多种，除了修改嵌入式Konqueror浏览器的代码让其适应特定的嵌入式环境以外，还必须跟上不断发展的网络技术和网络标准，所以不可避免地要通过插件技术来扩展浏览器的功能。本发明提出的三层模型的插件开发方法正是为了解决这个问题，它基于上述的KParts技术和软件重用的思想。该模型的示意图如附图2所示。

在模型的上端是KHTMLPart部件，也是整个浏览器的核心。本发明利用KParts框架的可扩展性，将其作为插件开发的平台。

中间层为Part层。本发明将插件用传统的Part来表达，并且将传统的Part分为模型中的Part和Lib层。由于网络协议和网络标准的不断发展，传统的Part插件需要进行不断的更新，所以把易变的代码从Part中分离出来，组成一个或者多个Lib，从而构成一个Lib层。于是中间层Part和传统的旧Part从形式上和功能上便完全不同。传统的Part拥有自己的可视控件、功能实现和用户接口。而本发明中的Part除了提供基本的UI(User Interface，用户接口)功能外，主要还是作为浏览器和Lib之间的中间层而存在的，负责它们之间的通信和交互。

以发明人用该模型实现的Flash插件为例，该模型中的Part在Flash插件中所起的作用便是沟通Lib和浏览器。由于无MMU平台不支持多进程，而且Part的作用决定了它与主线程的交互会相当的频繁，而与数据下载所需的时间相比，渲染页面所需的时间是可以忽略的，所以将浏览器用多线程来实现，并且将Part与主线程整合在一起。Part充分利用了Qt/Embedded的Signal-Slot机制来进行时间响应。与Part相关的工作可以描述为：

1)主线程启动Dom&Render引擎，将下载完成的页面数据交付它们进行解析。当引擎从页面数据中了解到有flash元素存在的时候，便通知KHTMLPart部件，创建Flash插件的Part实例。

2)Flash插件的Part启动浏览器的下载部件KIO模块，对该flash文件进行下载。KIO下载完成后，通知Part。

3)Part将下载完的数据传递给Lib，后者用这些数据完成它的工作。

在这个过程中，Part实际上是一个协调Lib和浏览器以及传递数据的角色。当然，除此之外，开发插件的时候同样也可以根据需要给Part其它的职责。比如在Flash插件中，Part还起到控制Lib进行flash播放的作用。由于flash文件可能会比较大，而对于无MMU支持的嵌入式环境下，很容易引起堆栈溢出等致命错误，因此Part协调各方面工作，使得一次传递给Lib一小块数据。而当Lib通知Part解析完了flash文件之后，Part停止下载，并且设定计时器定时对flash进行循环播放。

Part除了作为信息和数据的传递者之外，对于嵌入式开发来说，还有一个更重要的功能。浏览器插件本身应该是一个功能比较独立、可以在不同浏览器之间进行方便地移植的软件模块。本发明提出的插件开发三层模型中，由于主要功能由Lib实现，故Part还可以作为一个adapter层而存在，使得插件能够适应不同宿主浏览器的接口要求，从而可以方便地进行跨浏览器的移植。

处于模型底层的是Lib层。从Part中划分出来的由易变的、功能性强的以及可复用的代码组成的比较独立的模块，实现了插件的主要功能。尤其在嵌入式环境中，它向上同Part进行交互，向下同硬件或底层驱动进行相关的操作。

同样用实现的Flash插件为例。对flash文件进行分析后知道，flash文件遵循SWF文件格式，故Lib的主要功能是分离和分类标签，并且渲染它们的内容。所以Lib被分为两个模块：标签解析模块Tag Parser和执行引擎Execute Engine。模块图如附图3所示。

Tag Parser是和上层Part交互的主要模块。这里引入一些定义来区分不同的flash标签：定义标签和控制标签，前者定义一个播放对象，后者控制播放的动作和流程。它解析并且用这些标签生成新的解码标签放入自己维护的字典中。这些解码标签分别被称为角色标签和动作标签，对应的字典便是角色字典和动作字典。标签解析的示意图如图4所示。

角色字典存在于每一层flash中，而动作字典则存在于每一层的每一帧中。当从Part接收到以Unicode字符流形式输入的flash文件后，解析器开始从文件体中分离和分类标签，将它们解码成解码标签并放入相应的字典中。如在图4中所示，文件体中存在一个定义标签为stagDefineSound类型。如果解析器得到这个标签，将会调用相应的函数生成一个Sound类型的角色对象，并且用由标签头所指示的文件体中相应的数据将该对象填充，然后包装成角色标签，放入角色字典中。对于控制标签而言，比如得到一个类型为stagStartSound的控制标签，解析器会调用相应的函数生成一个动作标签并且将该动作所操作的角色记录下来，放入动作字典中。当解析器处理完文件体中的所有标签后，标签解析的过程就算完成了。从对该模块简单的介绍中我们可以看到，Lib通过这一模块同Part进行着数据的交互，不断从Part中读取数据并进行解析。

在Tag Parser下面是Execute Engine。在Tag Parser解析完flash文件之后，Execute Engine开始渲染flash文件。它为每一层flash定义一个播放列表来维护准备被渲染的角色对象。执行引擎的工作工程可以简洁地描述为遍历动作标签的过程。如图5所示。为了将这个遍历的过程解释清楚，将动作标签又作出划分，分为行为标签和渲染标签。行为标签控制flash影片的播放流程。当引擎从动作字典中将行为标签释放出来时，它调用相应的处理函数进行处理。比如，当得到一个一个类型为ctrlStartSound的行为标签时，它调用底层的声音播放设备进行声音的播放。而渲染标签代表一个准备被播放的角色。拿类型为ctrlPlaceObject为例，当引擎拿到这个标签时，它将该标签中记录的处于角色字典中的角色对象放入相应层的播放列表中。当引擎处理完动作字典之后，便开始对每一层flash的播放列表进行扫描并且渲染其中记录的角色对象。考虑嵌入式环境的效率重要性，渲染的过程均需要和视频、音频设备进行交互。

在三层模型中，Lib负责的是实现插件的功能。Lib独立地实现了Flash插件的应有的功能，而且对于Part和底层来说，是完全透明的，只需知道Lib的应用接口。这样的设计也有利于对Lib进行模块的划分。

将Lib从传统形式的Part中划分出来，给基于uCLinux的嵌入式Konqueror浏览器插件开发带来了很多益处。如果整个插件需要彻底更新，也无需对Part进行修改，仅仅对Lib进行修改即可；由于Lib的功能相对比较独立，所以不同的Part可以使用相同的Lib，或者同一个Part可以同时使用多个Lib来组合完成一个插件的功能，这样一来，对于插件的设计便不应该单单停留在实现功能之上，还应该考虑功能上的可复用性、接口的通用性、功能划分的独立性以及可重入等问题，以便插件之间可以共享Lib，减少代码的冗余度，从而可以节省有限的嵌入式资源。

该模型基于KParts技术，而其一大特点便是可以动态地加载和卸载Part。当一个插件不再需要的时候，可以把它卸载掉，但如果它所提的很少数但很有用的插件功能仍然正被使用，那么就不得不将整个的插件保留起来，没办法对内存的使用进行优化。而将插件的功能从插件本身中划分出来成为组成插件的一个或多个相对独立的部分，即Lib，则Part的卸载并不影响插件的功能被使用。这样对于嵌入式浏览器这样一个对内存消耗相对较大的嵌入式应用来说，无疑是十分有益的。