3

我真的很喜欢使用 Chrome 的 URL 栏，因为它会记住经常访问的网站，并且经常根据我之前输入和/或访问过的内容建议一个好的完成。因此，例如，我可以在tURL 栏中输入，Chrome 会自动将其填入. 这为我提供了数据驱动的域名快捷方式的便利，而无需维护明确的列表。twitter.commaps.google.com

不过，我想知道的是 Chrome 如何确定应该用新快捷方式替换旧快捷方式。例如，如果我twitter.com经常访问，那么当我输入t. 但是，如果我开始twilio.com经常访问，那么一段时间后，Chrome 将开始将其填充为t. 我无法弄清楚这种转变是如何或何时发生的。似乎还涉及（至少）两种情况：一种用于域名，另一种用于路径字符串，因为如果我经常访问某个完整的 URL，然后想到达同一个域的根目录，我结束必须输入整个域名才能让 Chrome 忽略完整的 URL 完成。

如果我不得不猜测，我会想象 Chrome 将我在 URL 栏中输入的内容存储在一个 trie 中，其值是特定字符串被输入（和/或访问？）的次数。然后我会想象它有某种指数衰减模型用于特里树中的“计数”。但这只是一个猜测。有谁知道这个更新过程是如何发生的？

4

1 回答 1

6

好吧，我最终通过查看 Chromium 源代码找到了一些答案；我想 Chrome 本身无需太多修改即可使用此代码。

当您在搜索/URL 栏（显然称为“多功能框”）中输入内容时，Chrome 会开始寻找与您输入的内容相匹配的建议和补全。为此，在浏览器中注册了几个“提供者”，每个“提供者”都知道如何提出特定类型的建议。URL 历史提供者就是其中之一。

实际上，查询过程非常酷。这一切都是异步发生的，特别注意哪个活动发生在哪个线程中（主线程特别重要，不要阻塞）。当提供者找到建议时，他们会回调多功能框，该多功能框似乎在更新 UI 小部件之前合并和排序内容。

历史提供者

事实证明，Chrome 中的 URL 至少存储在一个，可能是两个 sqlite 数据库中（一个在磁盘上，第二个我不太了解，似乎在内存中）。HistoryURLProvider 顶部的这条评论解释了查找过程，并带有多线程 ASCII 艺术！

Sqlite 查找

基本上，在多功能框中键入会导致 sqlite 运行此SQL 查询，以通过 prefix 查找 URL。这些建议按对 URL 的访问次数以及 URL 被键入的次数排序。

有趣的是，这不是一个尝试！查找确实是基于前缀的，但这些查找的评分似乎并不像我想象的那样按前缀聚合。

在确定如何更新数据库中的分数方面，我的成功率稍低。这部分代码在访问后更新 URL，但我还没有遇到计数减少的地方（如果有的话？）。

更新建议

我认为在更新建议方面正在发生的事情——现在这仍然只是一个猜测——内存中的 sqlite 数据库基本上优先于磁盘数据库，然后每当 Chrome 重新启动或以其他方式刷新内存数据库的内容到磁盘时，每个 URL 的访问和键入计数都会在那时更新。同样，只是一个猜测，但我会在有时间的时候继续寻找。

实际上，该代码非常易于阅读。如果您对 Chrome 有类似的问题，我绝对推荐它。

于 2013-08-29T15:48:18.750 回答