Mozilla 的 Gecko 引擎有哪些优势和问题

作者：米嘉

链接：/question/20193935/answer/15010924

来源：知乎

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

当年Firefox从Mozilla项目中涅槃而出的时候，第一个要解决的问题就是Layout，而Layout是Gecko的核心组件，从那时到现在Gecko经历了超过十年的进化时间，所以，先说最大的问题就是他已经变的异常庞大，代码结构非常复杂，基本上到现在很少有人还能够清楚的知道gecko的每一个细节。

我个人觉得Gecko的魅力存在于他的架构设计上，现在可能已经没有清楚的界限分隔，所以下面提供的内容在某个时期不一定是属于Gecko部分的，不过从现在的角度来说Gecko代表Firefox整个的内核引擎。

XUL提供统一的界面描述语言，对于控件的制作完全使用描述性/解释性的语言就可以完成，并且由于XUL提供的超强描述能力，基本可以在任何有XUL的地方进行扩展，所以理论上Firefox的Addon可以插到系统的任何地方，这个跟Chrome的扩展API是有本质区别的，XUL在这些年也发展的越来越庞大，最后核心部分提取为XULRunner，Firefox/Thunderbird或者任何基于Mozilla/Gecko技术的应用都可以理解为是运行在XULRunner这个虚拟机上的。而Mozilla也希望有开发人员基于XULRunner直接开发桌面应用。

XPCOM是Gecko中又一个利器，本身概念等同于甚至超越同期的COM/DCOM等组件技术的，浏览器中大量的基础组件都是通过XPCOM的方式提供的，从文件系统到网络访问，从书签访问到外观控制，没有统计过Gecko中提供的XPCOM一***有多少，估计数量一定很多，而XPCOM也是提供Gecko扩展能力的超强武器，是软件复用的有力封装工具，扩展本身接入到平台上之后提供的XPCOM服务可以被其他扩展使用，大大提供软件复用能力。

XPConnect提供了多语言的接入能力，你可以使用XUL/JavaScript，可以使用C/C++、Java、Python来实现XPCOM、Module等，将这些语言制作的二进制扩展接入到平台中，当然他是从属于XPCOM的。

我觉得阻挡Gecko前进的最大问题就是复杂度的与日俱增，太多的东西没有被隔离而直接被接入平台，在提供超强的扩展能力同时，也带入了更多的复杂度——可阅读能力差、代码复杂、维护难度高。从渲染角度我觉得差距不一定很大，现在对于Render/Layout的实现大家的实现基础基本是一致的，但是能够看到Webkit对于新CSS标准的实现很快，代码进化很快能够完成，而Gecko就显得老态龙钟。而从JavaScript角度来说，Google V8的绝密飞行领先所有浏览器厂商两年多，这个大家都不太好追，Chrome内核优势大大的。