转载时请注明出处和作者联系方式
文章出处：http://www.limodev.cn/blog
作者联系方式：李先静
原文发表于《程序员》2007第5期
Firefox的横空出世在很多人的意料之外，其体积小巧功能强大，在安全性、扩展性和可移植性上都有惊人的表现。这样优秀的软件，实在想不出是在 mozilla这棵老树上生出的新花。我们都认为mozilla老了，已经过时了，不是吗？如果不是firefox，我们还记得mozilla吗？
最近因为工作需要，我花了不少时间去研究Mozilla。才知道我的想法错了，mozilla的架构设计非常优秀，不但没有老，而且在持续的焕发出生机。不是别的，正是它优秀的架构孕育了firefox的诞生。
浏览器的复杂度可以和操作系统相提并论，mozilla有数百万行的C++代码。这样复杂的软件，其中到底使用了那些秘技呢？其实,好的设计总是遵 循一些众所周知的设计准则，套句俗语说，差的设计千差万别，好的设计都一个样。Mozilla当然也是遵循了这些设计准则，不过，在实现方法上却有很多创 新之处,让人惊叹不已。
本文就以这些设计准则为主线，来分析一下Mozilla的架构设计:
1. 分离界面和实现。
我们知道，用户界面是最容易变化的，也是最难于自动测试的，分离用户界面和内部逻辑是设计的主要目标之一。在这一方面，mozilla算是非常前卫了：用
标记语言(XUL)开发界面，用编程语言来实现(C++)内部逻辑，再用脚本语言(javascript)把两者胶合起来。XUL的界面描述能
力，javascript的简洁性和C++的性能完美的结合在一起了，mozilla把三者的长处发挥到了极致。它们的关系如下图所示：
o XUL 这是一种用XML来描述用户界面的语言。用XML描述用户界面已经不是什么新鲜事了，像Qt designer和Glade都是用XML文件格式来存放用户界面描述的，但它们都只是纯粹的界面描述。而XUL同时描述了事件处理、风格(style) 和字符串国际化等信息，可以直接被mozilla layout引擎解析执行。
o XBL 这种称为扩展绑定语言(Extensible Binding Language)的东东也是mozilla的一大特色，现在已经被W3C作为标准了。作为程序员，我们都知道公共函数库的重要性，公共函数库可以反复重 用，从而提高开发效率。在开发用户界面时，也会遇到同样的问题，很多界面都比较类似，拷贝/粘贴当然很容易，但以后维护起来就麻烦了。而XUL并没有提供 重用机制，XBL刚好弥补了它的不足。在XUL中可以只描述具有共性的部分，而由XBL对它进行扩展。XBL的功能强大，自身也有组合和继承机制，这大大 提高了可重用性。
o CSS 我们知道Cascading Style Sheets在网页中已经应用多年了，而在浏览器本身实现中使用倒是很少听说。这也没有什么奇怪的，像GTK+中的RC和CSS功能都差不多， 也就是说GNOME应用程序一直都在使用类似于CSS的东西。有了CSS，把应用程序的界面视感(look and feel)与功能独立开来，让两者可以独立变化，这是非常自然的事了。不过CSS在这里，除了可以修改界面风格外，还可以把XBL和XUL关连起来，以完 成对XUL的扩展。
o DTD DTD (Document Type Definition)常用来定义标记(Markup Langugae)语言的语法，功能上与BNF是等价的。不过它在这里，不是为了定义某种语言的语法，而是完成字符串的本地化，只是借了DTD中的实体 (Entity)展开机制罢了。这看起来有些大材小用，不过在XML中使用DTD实体来替换要翻译的字符串，没有比这更好的办法了。
o property 在XUL中用DTD来做字符串本地化，虽然是妙着一招，可是在javascript里它就没有用武之地了。这回该轮到property上场了，在 nsIStringBundle接口的帮助下，javascript可以方便的从property文件中取到所要的字符串。
o Javascript 在XPConnect的支持下，Javascript也可以用来开发COM组件，可以实现任何功能。不过胶合用户界面(XUL)和内部逻辑才是它最拿手的 好戏。当然，其中文档对象模型(DOM)起了非常关键的作用，Javascript通过文档对象模型(DOM)来操作XUL中的元素。
我们以minimo为例，来看看它的实现方法：
上面的代码指明了CSS的文件名和路径。global.css是控制应用程序整体风格的，minimo.css是控制minimo主界面风格的。 CSS的语法很简单，不需要任何编程知识就可以修改它。只要一个文本编辑器，你就可以根据你的爱好，去修改它的字体、颜色和背景图片等风格元素，而且无需 重新编译就可以看到调整后的效果。
%minimoDTD;
%brandDTD;
]>
上面的代码指明了DTD的文件名和路径。正如前面所说的，DTD是用来做字符串本地化的，而不是用来描述当前文件语法的。
上面的代码指明了properties的文件名和路径。正如前面所说的，properties文件是用来处理javascript里字符串的本地化问题的。
要本地化吗？好办，把这两类文件交给翻译人员就行了。如果你还在把字符串放在可执行文件中，甚至直接嵌到代码里，还在为不同的语言各编译一个版本，那就太老土了，向mozilla学学吧。
contentcontextmenu="contentAreaContextMenu"
disablehistory="false"
accessrule="access_content"
src="about:blank"
flex="1"
autocompletepopup="PopupAutoComplete"
onnewtab="BrowserOpenTab()"/>
上面的代码就是真正的界面描述了。我们知道mozilla里面，它也像IE一样，把浏览器核心做成了一个控件，可以嵌入到应用程序自己的窗口 中，minimo就是利用这种机制实现的。这段代码完成了浏览器控件的创建、属性设置和事件关联。简单吧，更重要的是，无须重新编译就看到效果。
上面的代码指明了javascript的文件名和路径。按照分层原则，上层可以调用下层的函数，用户界面（XUL）在上层，它可以调用javascript函数的，所以这里需要指明javascript文件的位置。
上面几行代码是Back和Forward菜单的界面描述和事件处理。这是一个典型的例子：用XUL描述用户界面，用XPCOM组件完成内部逻辑 (gBrowser是通过DOM接口取得的：gBrowser = document.getElementById(”content”))，用javascript完成对用户界面和内部逻辑的胶合。
2. 针对接口编程。
Mozilla整个设计是基于组件对象模型(COM)的，而组件对象模型(COM)的主要特点就是针对接口编程。在《设计模式》中，作者把针对接口编程作
为设计的首要准则。针对接口编程，把模块的使用者和实现者之间的耦合降到最小，以达到信息隐藏和隔离变化的目的。而且在XPCOM的帮助下，组件可以动态
替换或者增加，具有更强的灵活性。其中各个角色的关系如下图所示：
工厂(Factory) 我们知道，可以通常接口指针调用接口的实现，这样调用者就不必了解实现者的细节了。然而创建接口的实例时，只有知道接口的实现才能创建接口的实例。这是一 个矛盾，如何才能把使用者和实现者完全隔离开来呢？那就要靠工厂(Factory)，它把接口的实现和创建独立开来了。可以说工厂(Factory)是针 对接口编程的基本条件之一，这就是为什么《设计模式》把工厂(Factory)模式放在前面介绍的原因了。
在Mozilla中，每个组件都要实现工厂(Factory)接口，才能被使用者调用。考虑到实现Factory的代码极为类似，为了避免重 复，Mozilla实现了一个称为GenericFactory的通用Factory。在GenericFactory的帮助下，各个组件只要实现一个简 单的结构ComponentInfo就行了。
组件管理器 工厂(Factory)虽然把组件的创建分离了，但使用者与实现者的工厂却又耦合起来了。这样看来，我们似乎又回到了起点，不过这次不一样了，各个组件的 Factory都实现了IFactory接口，可以由一个专门的管理器来管理。通过组件名称或ID可以找到组件的Factory，通过接口ID又可以让 Factory创建接口的实例。
IDL IDL是接口定义语言 (Interface Definition Language) 的简称，它在组件对象模型(COM)中也起着重要的作用。在C语言中，我们可以用结构(Struct)来描述接口，一个只包含函数指针的结构 (Struct)可以看作一个接口。在C++中，我们可以用类来描述接口，一个只包含纯虚函数的类可以看作一个接口。既然每种语言都有自己描述接口的方 法，为什么还要IDL呢？答案正是因为每种语言描述接口的方式不一致，所以才要需要一个独立于任何编程语言接口定义语言(IDL)。
IDL是一个中间语言，它不能直接被编程语言使用，但在IDL的编译器的支持下，它可以被转换成不同的形式，在多种语言中使用。比如转换成头文件， 可以在C/C++中使用，可以转换成类型库，可以在javascript等解释语言中使用。IDL在XPCOM实现语言无关性中，起了不可或缺的作用。
3. 分层设计
分层设计是常用的架构设计手法之一，它基于分而和治之的思想，可以有效的降低系统复杂度。分层设计同时还可以隔离变化，让上层模块不受到底层模块变化的影响，是开发跨平台软件的最强有力武器。在mozilla中，其分层架构视图如下所示:
NSPR是一套跨平台的运行库，实现了诸如线程、事件、信号量和文件等依赖于具体操作系统API的抽象，让上层模块不受具体操作系统的影响。其下有基于Linux、Windows和Mac等多种操作系统的实现。
o Gfx 是一套图形处理程序库，实现了诸如画线、多边形、填充、颜色、字体和打印等功能，让上层模块不受具体GUI的影响。其下有基于GTK、QT和Win32等多种GUI的实现。
o Widget 是一套窗口/控件程序库，实现了诸如窗口，事件、拖放、剪切板等功能,让上层模块不受具体GUI的影响。其下有基于GTK、QT和Win32等多种GUI的实现。
o XPCOM 实现了跨平台的组件对象模型（COM），这是mozilla的核心模块。
o JSEngine实现了javascript的解释器，以及与XPCOM组件之间的互相调用机制。
o ML Parser实现了各种标记语言的解析器，比如HTML、XUL、XBL、SVG和其它XML文件解析器。
o DOM 实现了文档对象模型接口，javascript可以通过这套接口操作文档。DOM是W3C定义的标准，支持DOM接口才能保证和其它浏览器的兼容性，让同样的javascript可以在不同的浏览器中运行。
o Network 实现了各种本地/远程协议，比如HTTP、FTP、about和file等协议。Mozilla还实现了SSL协议，保证数据传输的安全性。
o Layout Engine实现了界面的排版布局，支持HTML、XUL和SVG等文档的排版布局。它不但支持网页浏览，而且支持网页编辑。
o 最上层是用XUL和JS等界面元素开发出来的应用程序，像firefox和Thunderbird等。
4. 可扩展性。
对于浏览器来说，可扩展性也是非常重要的。由于它涉及的东西太多，专业的功能应该由专业的厂商去做，而不是全部由浏览器来实现。比如像flash播
放器、视频播放器和pdf阅读器等等都应该从浏览器中分离出来。Mozilla提供了两种扩展机制，一种称为plugin，另外一种称为
extension。这可能有点让人混淆，我是这样理解的：
o plugin用来增强现有功能，比如PDF plugin可以阅读PDF文件，而media player plugin可以播放音/视频文件。Plugin都要求实现特定的接口。
o extension用来扩展新功能，这些功能可能与浏览器有关，也可能无关，像help extension就是用来实现帮助功能的。Extension不要求实现特定的接口。
5. 可移植性。
Mozilla是一套跨平台的系统，它可以运行在linux、windows和mac等操作系统上,可以运行在QT、GTK和Win32等GUI系统上。可移植性是mozilla是主要目标之一，开发人员在为此可谓费尽苦心：
o 实现了一套跨平台的组件对象模型(XPCOM)，这使得mozilla可以利用组件对象模型(COM)的好处，又不局限于windows平台。
o 实现了一套可移植运行库,对各种操作系统的接口作了抽象，隔离上层模块对操作系统的依赖。
o 实现了widget和gfx两个库，前者负责窗口/控件的处理，后者负责图形/图像的绘制，对各种GUI系统作了抽象，隔离了上层模块对GUI的依赖。
o 实现了自己的国际化机制，包括编码转换、编码检测和字符串翻译等等。
6. 稳定性(内存问题检测)。
用C/C++开发应用程序，最麻烦的就是内存泄露和内存越界，即使有多年开发经验的老手也可能在此栽了跟头。有人说，有很多工具可以帮助检测内存问 题啊。没错，但有两种情况可能让这些工具失效，一是GUI系统，它们通常使用了共享内存，大多数工具对此都无能为力。不信的话，你可以用valgrind 检查一下GTK应用程序试试。二是自己管理了内存，大型系统中，为了高效的使用内存，往往实现了自己的内存管理器，工具对此一无所知，自然帮不上忙。
Mozilla实现了自己的内存管理器，同时还实现多种内存问题检查机制，比如用boehm垃圾回收机制来检查内存泄露问题。当然，对于C/C++这个毛病，也是迫不得已，大家都在重复实现这些东西，却没有好的重用办法，这不怪mozilla。
Mozilla可以说是架构设计的典范，值得我们反复观摩和学习。但它规模庞大，深入研究需要大量的精力，笔者花了近两个月时间，所了解的内容仍然很有限，本文算是抛砖引玉吧，欢迎大家指正。