谷歌浏览器盔甲的破绽在哪里？答案

【问题标题】：Where is the chink in Google Chrome's armor?谷歌浏览器盔甲的破绽在哪里？
【发布时间】：2010-09-07 18:13:59
【问题描述】：

在使用 Chrome 浏览时，我注意到它在渲染页面（包括 gmail 等 JavaScript 重度网站）方面响应非常快（与我笔记本电脑上的 IE 和 Firefox 相比）。

这就是 Chrome 上的 googlebook 所说的

选项卡托管在进程而不是线程中。
使用 V8 引擎编译 javascript，而不是解释。
引入新的虚拟机支持javascript重度应用
引入“隐藏类转换”并应用动态优化来加快速度。
用更精确的垃圾收集方案替换低效的“保守垃圾收集”方案。
引入自己的任务调度器和内存管理器来管理浏览器环境。

这一切听起来都很熟悉，而且微软已经做了很长时间了。Windows os、C++、C# 等编译器、CLR 等等。

那么，为什么微软或任何其他浏览器供应商不采用 Chrome 的方法呢？ Chrome 的方法有缺陷吗？如果没有，浏览器供应商社区的其他成员是否对 Google 的做法一无所知？

【问题讨论】：

老实说，我不知道为什么 Chrome 会提到他们的任何方法，因为它们似乎都非常独特，我认为他们应该保密以便更容易主宰使用他们的浏览器访问网络 ;)
@baeltazor - 我的猜测：他们不在乎他们是否主宰网络。他们希望人们拥有更好、更快的浏览器，以便他们更多地使用网络（尤其是网络应用程序）。无论是 Chrome 还是竞争对手都无关紧要，而且他们越是讲述他们是如何做到的，就会有越多的人要求其他浏览器采用相同的技术。它已经全面提升了 Javascript 的性能。
同意速度。随着 3.0 的发布，Chrome 火了一把。
Chrome 也作为开源 Chromium 发布，所以这并不重要，因为人们无疑会发现它是如何工作的。
@Nathan Long：这是一张值得一千字的图片来支持您的观点，即 chrome 旨在推动网络向前发展，而不是超越它。 google.com/googlebooks/chrome/images/big/38.jpg

标签： google-chrome

【解决方案1】：

Chrome 的方法很难编写，需要开发人员深思熟虑。 IE 和 Firefox 都在尝试迁移到每个标签进程的模型，但由于向后兼容性，无法快速过渡。 Chrome 是基于干净的渲染引擎 (WebKit) 构建的全新浏览器，以这种方式编写更容易。

【讨论】：

换句话说，Chrome 是从“白板”开始的，而其他浏览器正在努力使现有代码库适应新概念而不破坏它们。
实际上，IE8 是第一个 浏览器，它使用了每标签进程模型。但是，兼容性点通常是正确的。
IE8 于 2009 年 3 月 19 日发布，Chrome 于 2008 年 12 月 11 日发布。

【解决方案2】：

他们已经从作为查看网页工具的 Web 浏览器转变为针对 Web 应用程序进行优化的工具。这个初始版本可能存在一些缺陷，但它们正在改变游戏规则。

【讨论】：

【解决方案3】：

IE8 对每个选项卡模块使用类似的单独进程，尽管它们不使用每个选项卡的单个进程，而是将所有选项卡分布在一个进程池中。

【讨论】：

这就是为什么在 IE8 中打开一个新的空白标签需要很长时间的原因！任何其他浏览器都没有这个问题......
真正的原因是IE在每个标签页上都初始化了新的扩展。有关更多信息，请参阅blogs.msdn.com/ieinternals/archive/2009/07/20/…。

【解决方案4】：

@pix0r 但他们在右下角添加了一个小东西，这样你就可以将文本框扩展到任何你想要的方向，我喜欢这个，因为我使用宽屏并且更喜欢在更宽的屏幕上打字。

这实际上是 WebKit 的一个特性，Chrome 只是继承了它。

【讨论】：

【解决方案5】：

几乎所有这些功能都存在于 Chrome 之前的其他浏览器中。 IE8 有标签的进程隔离。 Firefox / Safari 拥有大部分 JavaScript 内容。大多数浏览器都有自己的内存管理。

Chrome 有一些独特的功能（超限制的渲染进程等），由于插件/应用程序兼容性问题，这些功能很难融入其他浏览器。

Chrome 的首要目标是极其注重极简主义和高性能。通过将这些作为他们的竞争优势，他们可以吸引那些认为该关注领域具有吸引力的用户。

【讨论】：

【解决方案6】：

随着时间的流逝，我相信您会看到功能的同质化，因为浏览器试图相互结合。

与此同时，我仍然坚持使用 Firefox 而不是 Chrome，原因很简单，因为 Firefox (i) 是非营利性的，并且 (ii) 拥有庞大的插件社区。 NoScript 和 AdBlockPlus 等插件对我来说几乎是必不可少的。

【讨论】：

附加组件对我来说比我想象的更重要。我在 Chrome 刚推出时试用了它，并立即注意到 FlashBlock 多年来一直对我隐藏的恼人的 Flash 广告。这足以让我放弃 Chrome。从那以后，我还没有再次查看该功能是否已添加。
Chrome 的开发者版本中现在提供了插件支持。我怀疑它很快就会被带到整个社区，这将迅速推动优秀插件的开发。

【解决方案7】：

Chrome 盔甲的一个破绽是，它在 StackOverflow 上渲染这些该死的文本区域是如此之小，以至于我的眼睛都在流血！

【讨论】：

【解决方案8】：

Chrome 盔甲的一个破绽是，它在 StackOverflow 上渲染这些该死的文本区域是如此之小，以至于我的眼睛都在流血！

是的。我在 uservoice 上提到了这一点并被拒绝了，因为当前的大小显然是 webkit 下的默认值。我用 Chrome 尝试过的所有其他使用文本框来撰写内容的网站都设法拥有合适大小的字体。默认值肯定不起作用，但显然有一些方法可以覆盖它。杰夫需要解决这个问题！

编辑： Jeff 很好地指出了如何fix this problem yourself。

【讨论】：

也许他做到了；但你的链接已经死了！ :) 你有机会在这里重复解释吗？
这就是你得到的，你不应该在没有内容解释的情况下发布链接

【解决方案9】：

@pix0r 但他们在右下角添加了一个小东西，这样你就可以将文本框扩展到任何你想要的方向，我喜欢这个，因为我使用宽屏并且更喜欢在更宽的屏幕上打字。

我还想指出，除了使用 webkit 之外，Google 完全从头开始构建 Chrome，因此它们具有不必处理旧代码的一些优点。当然还有非常酷/聪明的开发人员。

【讨论】：

“完全从头开始，但不完全从头开始的东西除外”

【解决方案10】：

与 IE、FF 和 Opera 相比，我发现最大的缺陷是它对代理的支持很糟糕。所以它在工作中几乎没用，随机渲染页面，并为代理请求身份验证，其他人无缝地通过它。

也就是说，在我的家用机器上它工作得很好，如果不是 OTT EULA 我现在会使用它。

thing2k

【讨论】：

【解决方案11】：

Chrome 的一个“缺陷”是它使用的内存比所有其他浏览器都多。我只是猜测这是由于与所有单独的选项卡管理相关的开销。

然而，在它打开一段时间后，它并不比其他浏览器使用更多的内存。

【讨论】：

【解决方案12】：

许多公司都在玩“我们至少可以做些什么才能站稳脚跟？”的游戏。营销创建了一个比竞争对手更好的功能清单。项目管理确保工程师坚持使用这些功能，以免项目超出分配的时间……当然会。在这样一个系统中，没有足够的空间来实现大的跨越。您在产品和浏览器中看到的增量改进是结果。

【讨论】：

【解决方案13】：

您必须记住，Microsoft 的主要业务是富环境 (GUI) 应用程序。 Web 工具对他们构成威胁，因为它独立于平台（不推广他们的主要产品）。

当然，IE 团队可能已经想到了类似的东西，但是……如果微软出售的是富应用程序平台，他们肯定不会在 IE 上投入大量资金。

【讨论】：

不真实。微软出售大量 HTML/CSS/JS 开发工具。