我真的很喜欢使用Chrome的网址栏，因为它会记住常去访问过的网站，并且通常根据我之前输入和/或访问过的内容建议完成。因此，例如，我可以在网址栏中输入t，Chrome会自动将其填入twitter.com，或者我可以输入maps，Chrome会填写.google.com }。这使我方便了数据驱动的域名快捷方式，而无需维护明确的列表。
但我想知道的是Chrome如何确定旧的快捷方式应该替换为新的快捷方式。例如，如果我经常访问twitter.com，那么当我输入t时，这就完成了。但是，如果我开始经常访问twilio.com，那么，经过一段时间后，Chrome会开始将其填入t的默认完成时间。我无法弄清楚这种转变是如何或何时发生的。似乎还有（至少）涉及两种情况：一种用于域名，另一种用于路径字符串，因为如果我经常访问某个完整的URL，然后想要到达同一域的根，我结束必须输入整个域名才能让Chrome忽略完整的网址完成。
如果我不得不猜测，我会想象Chrome会将我在URL栏中输入的内容存储在trie中，其值是特定字符串键入（和/或访问？）的次数。然后我想象它对于特里的“计数”有某种指数衰减模型。但这只是猜测。有谁知道这个更新过程是如何发生的？
答案 0 :(得分：6)
好吧，我最后通过查看Chromium源代码找到了一些答案;我认为Chrome本身使用此代码而不需要太多修改。
当您在搜索/网址栏中输入内容时（显然称为“Omnibox”），Chrome会开始寻找符合您输入内容的建议和完成情况。为此，在浏览器中注册了几个“提供者”，每个“提供者”都知道如何提出特定类型的建议。 URL历史记录提供程序就是其中之一。
实际上，查询过程非常酷。这一切都是异步发生的，特别注意哪个线程中发生了哪些活动（主线程特别重要，不要阻塞）。当提供者找到建议时，他们会回调多功能框，它似乎在更新UI小部件之前合并和排序。
事实证明，Chrome中的URL存储在至少一个，可能是两个sqlite数据库中（一个在磁盘上，第二个，我知道的更少，似乎在内存中）。 这个comment at the top of HistoryURLProvider解释了查找过程，完成了多线程ASCII艺术！
基本上，输入多功能框会导致sqlite运行此SQL query for looking up URLs by prefix。建议按网址访问次数以及输入网址的次数排序。
有趣的是，这不是特里！查找确实基于前缀，但这些查找的评分似乎没有按前缀聚合，就像我想象的那样。
我在确定如何更新数据库中的分数方面取得了一些成功。这部分代码updates a URL after a visit，但我还没有遇到计数递减的地方（如果有的话）。
我认为有关更新建议的事情 - 现在仍然只是猜测 - 是内存中的sqlite数据库本质上优先于磁盘数据库，然后每当Chrome重新启动或否则，将内存数据库的内容刷新到磁盘，此时每个URL的访问和键入计数都会更新。再一次，只是一个猜测，但我会继续看，因为我有时间。
实际上，代码非常适合阅读。如果您对Chrome有类似疑问，我绝对会推荐它。