进来忽然发现各个常去的中文论坛里都不约而同的转载并热论着同一篇文章：“Chrome居心叵测”。看来看去，看着越来越多的朋友踏出了铬粉的行列心里很不是滋味。Google一查居然转载有700多篇，经过半天的研究，最终决定写点什么。

这篇叵测论文章的主要观点主要是 Chrome
磁盘I/O过高，并且Chrome常有加密的出站链接。这里我来试着解释一下。与大家共同接着原作者进一步分析。

出站连接的问题由于之前国外有过相当多的报道，并且Google也给出过正面回应，所以不想多讲，不过值得补充的是Google在最新声明里表态在返回的地址栏数据中将不会再记录客户端IP。也算是一点点进步吧。反正是拨号上网动态IP，况且我还是CB良民也不上什么不良的网站随他记录吧。

这里主要说说磁盘I/O流量的问题，原文给出了截图但是并没有深入的分析，这里我使用的是Process
Monitor，对Chrome进行长时间的监视，然后做出文件操作的统计，得出结果如下图：



从图中大家可以看到操作次数（第二列）最多，时间最长的操作(Read)对象是SafeBrowsing
文件夹，即安全浏览。而整个过程中我并没有进入隐身模式怎么会出安全浏览呢？估计这里指的是钓鱼和恶意网站拦截功能。
紧随其后的是History Index
既然是索引，就应该都是名字或地址，而且读操作大大多于写，自然让人联想到了Chrome聪明绝顶的地址栏提示功能。
再向下排在第三位的是Chrome的Cache系统的一部分，浏览器的正常部分不做分析。
相信向下已经不用分析了，很明显，前两项的I/O操作次数与时间跟后面的各项有着数量级上的不同，差10倍之多。

对于地址栏Google并没有给出特别的设置，我们实在无能为力，但是排在第一位的安全浏览功能确实可以在设置中关闭的。是不是关闭了就不会出现高I/O了呢？我们来试验一下。

用Chrome打开一个常去的国外论坛，用Proc
Explorer观察，等待固定的一段时间后截图，关闭Chrome。得出如图所示的结果：



再次打开Chrome 关闭其中的反钓鱼功能，退出Chrome。
第三次打开Chrome，进入相同的页面，打开Proc Exp
中的记录图表，等待与第一次相同的时间。截图关闭Krome。得到下面的结果；



从上面两张图的对比可以看出Chrome的读盘I/O流量 下降了1/2以上。
估计Google的这个恶意网址库肯定小不了，瞬间比照上千个参差不齐的网址，要狂占多少CPU还难说。不过，过去FF恶意网址功能也有提高硬盘活动的倾向，只是没有这么严重。这也算是安全的代价吧。

但即使是12，443，352这样的流量，比起IE6
可能仍会有人感觉不正常。好的我的手头正好有开发版的Safari4，开发版的Safari4使用和我现在所使用的Chromium
版本相差不是很多的WebKit内核，有一定的可比性。
与上面相似的方法相同的网址，得到截图如下：



这里不知为什么Safari在等待的过程中出现了页面载入后的第二个I/O峰值。估计也与开发版有关吧。大家可以看到Safari4的I/O
读取流量是32，583，312，比去掉安全功能的Chromium还要高一倍以上。

由于Chrome的每个标签页就是一个进程而每个进程都要载入一个WebKit，加之沙盒功能砍去了Chrome的一些本地系统的访问能力，所以Chrome的WebKit实际上严重瘦身过的WebKit。较Safari产生的流量小也在情理之中。两者的I/O水平较IE6
高于WebKit的缓存文件的存取有关系，有些跑题了这里就不举例子了。

经过前面的一系列实验可以看出，Chrome的高磁盘I/O是由于安全浏览功能造。其次就可能是地址栏提示相关的历史功能的内存缓冲较弱，造成的读盘I/O偏高。
通过禁用Chrome的反钓鱼功能可以很好的改善Chrome磁盘读盘表现。

至于居心叵测论，就留给众多CB读者们分析吧。