对Firefox启动速度的分析

　　论坛上很多朋友都曾经诟病过Firefox的启动速度，得到的解决办法，比较切实有效的也就只有prefetch这一种办法，不管是使用单独的软件如：Firefox Preloader，还是使用Windows自带的功能。我也没有解决这个问题的办法，但是我想要分析一下Firefox的启动速度为什么会慢。
　　看了一些相关资料，在我的理解，Firefox的体系是这样的，首先建立一个运行环境，可以执行XUL和JavaScript代码，然后用XUL构建程序的界面，用JavaScript构建程序的功能。所谓的插件是对运行环境的完善，而扩展则同Firefox一样是运行在上述的运行环境之上的。
　　这样构建Firefox的好处就在于可以实现很大程度上的跨平台，在这个体系中，只有涉及到运行环境的才与平台有关，别的部分则是跨平台的。其实这种方式和Java语言的工作方式很相似。那个运行环境也就相当于Java中的虚拟机，只不过这个虚拟机是可以通过插件扩展的。
　　而这种工作方式也不可避免的带来了启动方面的问题。大家都知道运行速度最快的是二进制代码，而Firefox只有底层的运行环境采用了二进制代码，上层的XUL和JavaScript都是解释执行的，效率比二进制代码自然慢了很多。而Firefox本身有很大的一部分正是这种解释执行的代码。相对于IE和Opera的全面二进制化，启动速度自然要受影响。这是Firefox启动慢的一个原因。
　　打开Firefox、IE和Opera的安装目录,有什么感觉？我想大家肯定会发现，Firefox的安装目录相对来说十分复杂，充斥着各种各样的文件，这就是Firefox启动慢的第二个原因。
　　大家都知道，打开很多小文件的速度要远远大于打开一个大文件。这是因为打开小文件时，寻址定位所花费的时间要远远超过读取所需的时间。而Firefox的组成很大程度上都是些小文件，这非常影响加载速度。
　　也许是Mozilla也意识到了文件过多造成的效率损失，也许是为了组织起来更方便，Firefox的文件有很大部分是打包的，采用了Zip的压缩格式。这样可以减少文件数量（相对而言），提高载入速度。但是这同样是一把双刃剑。Zip既然是压缩格式，那在使用的过程中就要解压缩，这必然会提高CPU的占用率,同时延长Firefox的启动时间。
　　同时，解压缩之后的文件需要写入磁盘，这进一步加剧了延长了启动时间。当然解压缩Zip文件的问题可能会由于临时文件夹的存在而有所缓解，但是这样依然会回到文件过多影响启动速度的范畴。总的来说，这两个因素的共同作用就是Firefox启动缓慢的第二个原因。
　　写过Firefx扩展的朋友应该知道Firefox的扩展中的文件的具体位置是不需要明确指出的，只要给一个大致的位置即可，Firefox会帮我们找到。这无疑是一个方便开发的举措，但是从时间上，这涉及到一个搜索的过程，肯定会影响加载的速度。这是我发现的认为影响Firefox启动速度的第三个原因。
　　从上面这三个原因可以看出，Firefox启动慢是体系造成的，不改变这个体系，很难有根本的好转。
　　其实提高Firefox启动速度的办法就是最大程度地减少文件数量，进行二进制化。最好的方式自然是把Firefox编译成一个可执行文件，推出针对各个操作系统的版本。同时扩展也应当改变代码包的发行方式，推出针对各个操作系统的二进制版本，甚至于Firefox集成扩展的功能。这样Firefox就和IE、Opera在体系上没有什么太大的差别了，而后果就是牺牲了跨平台性、提高了开发和使用难度。这无疑与Firefox的理念是不相符。
　　在尽量不改变体系的情况下，个人认为可以在Firefox的运行环境中增加一个编译器，把XUL、JavaScript这类的代码编译成二进制代码或类似Java中的字节码。当然编译成的文件能少一些更好。这样只有在第一次使用的时候，需要进行编译，在之后的使用过程中Firefox的启动、运行速度、乃至CPU占用率都会有很大的改善。

恩，不错，除非专门针对windows平台开发一个版本：）

最好的办法是加大内存和CPU，呵呵

web123lai说的非常的精彩啊！赞一个！
在我看来，除了启动时候解释执行xul和js以外，扩展也是一个很大的因素，浏览器启动的时候首先会读取extension.rdf等文件，获取扩展信息，如果没有信息则重新建立，然后再载入语言包等，还要从火狐本身获取扩展是使用什么语言以便载入，这从修改about:config的界面语言以后，启动后扩展变成相应语言可以看的出来。而且启动的时候还要检查扩展的更新，这从我们启动的时候有扩展更新的话先弹出的是更新对话框可以看出来，而且某些real time的的扩展需要启动时候连接到网络获取信息，如gmail manager，forecastfox等扩展。这无疑对启动有所延迟。主题也是如此，因为是用css写的，浏览器启动的时候先载入的是默认主题，后来才在他基础上加载主题，我记得有一次启动比较慢的时候界面先出来部分的默认主题，后来才变成我设置的主题，所以我这么认为。

和web123lai说的一样，短时间内不可能改变启动慢这个事实，从1.0出来就被人诟病，到3.0仍没有很大改观就可以看出，并不是它们不想做到，也并不是它们没有能力做到（此乃废话），只是由于多方面的考虑，而且我认为它们有它们的道理，只是我们不是开发者不怎么明白罢了（此亦废话，请无视之）。

不知道能否举一些FFzip压缩格式的例子，我所看到的FF的一些格式应该是采用存储打包方式，而未进行任何压缩

鱼与熊掌不可兼得，这是无可奈何的事情。但只要想想firefox能为我们做到的事情，这一切也就值得了。
二进制休也再提。firefox runtime还不现实。

能通过楼主的解释知道为什么慢就已经很好了，我也不希望为了快那几秒改变Firefox的开发重心，真的。

官方应该有明确的答复的好像。。。。

不知道能否举一些FFzip压缩格式的例子，我所看到的FF的一些格式应该是采用存储打包方式，而未进行任何压缩

CrossBud好仔细，我只是看到Firefox的压缩包，没检查压缩率，不过既然是压缩包那其实都是一样的，不过是CPU占用多少和耗时的问题，都是需要解压缩的。其实我说的Firefox有很大程度上包含扩展，Firefox的上层和扩展基本没有两样。Firefox本身只打包不压缩的主意不错，可以缓解解压缩和文件零碎的问题，不过如果涉及到解压缩之后的写磁盘，那效果应该不会特别明显。

并不是它们不想做到，也并不是它们没有能力做到

的确如此，比如我在最后提的那个办法，开发一个编译器，看上去不错，可真要开发的话，恐怕难度不会比开发Firefox低。Mozilla的开发团队都要改行了

官方应该有明确的答复的好像。。。。

个人的分析，不一定准确，在搜索的过程中没发现，也许藏在浩瀚的网络里了

是的，如果没有进行压缩，那么是不会进行解压缩动作的。所以这个因素的影响应该没有你文中说的那么大（可能多少会有一点点，但如果机器不属于古董级，可以忽略）

components目录下面很多文件可以删除。例如speel*.*文件，不清楚可不可以有帮助，但是我看见的是Firefox运行JS才调用js3250.dll
可能直接把Firefox放进内存运行才是启动速度的解决方法

现在的机器都是很强的，那一点时间

我把所有JAR用最大压缩重压后在PII上运行，启动速度不变。体积少了近1M

預編譯的想法不錯!
但是,跨平台的如何編譯?FX還要帶XUL編譯器?

szBobby：預編譯的想法不錯!
但是,跨平台的如何編譯?FX還要帶XUL編譯器?回到原帖

只能开发针对各个平台的编译器，不过可以采用Java的方式，各个平台都编译成字节码，底层的运行环境添加运行字节码的功能，应该会牺牲一点儿运行效率，降低开发难度。不过，这种方式从人力上不现实，把解释执行的语言变成编译执行，我看基本等同于全新的语言了。开发难度太大，Mozilla很难有那个精力。
如果采用附带字节码的方式发行扩展，那么Firefox就不需要自带编译器，如果只提供源代码包，那似乎只能自带编译器了。

给我的感觉则是，ff现在的启动速度则是大部分取决于扩展的读取。安全模式运行的话，感觉跟ie差不多的