Chrome如何更新URL栏完成？ [英] How does Chrome update URL bar completions?
问题描述
我非常喜欢使用Chrome浏览器的网址栏，因为它记得常访问的网站，并且经常会根据我之前输入和/或访问过的内容提出完善的建议。因此，例如，我可以在网址列中键入 t ，Chrome会自动填写 twitter.com ，或者我可以输入 maps ，Chrome会填写 .google.com 。这为我提供了数据驱动的域名快捷方式的便利，而无需维护明确的列表。
我想知道的是，Chrome如何确定旧快捷方式应该换成新的。例如，如果我经常访问 twitter.com ，那么当我键入 t 时，就会成为完成。但是，如果我经常开始访问 twilio.com ，那么在一段时间后，Chrome将开始填写 t的默认完成时间。我无法弄清楚的是如何或何时发生这种转变。它似乎还有（至少）两种情况：一个用于域名，另一个用于路径字符串，因为如果我经常访问某个完整的URL，然后想要到达同一个域的根目录，我会结束必须键入整个域名才能让Chrome忽略完整的URL完成。
如果我不得不猜测，我会想象Chrome存储了这些东西我在URL中键入一个trie，其值是特定字符串输入（和/或访问？）的次数。然后我会想象它对于trie中的计数有某种指数衰减模型。但这只是一个猜测。有谁知道这个更新过程是怎么发生的？
好吧，我最终通过查看Chromium源代码找到了一些答案代码;我可以想象，Chrome本身没有太多的修改就使用这个代码。
当你在search / URL栏中输入内容（显然叫做Omnibox）时， ，Chrome开始寻找与您输入内容相匹配的建议和完成内容。为此，有几个提供商在浏览器中注册，每个提供商都知道如何提出特定类型的建议。 URL历史记录提供程序就是其中之一。
实际上，查询过程非常酷。这一切都是异步发生的，特别注意哪个线程发生哪种活动（主线程特别重要，不要阻塞）。当提供者找到建议时，他们会调用多功能框，在更新UI小部件之前它似乎会合并和排序。
历史记录提供程序
事实证明，Chrome中的URL存储在至少一个，可能是两个sqlite数据库中（一个在磁盘上，另一个我不太了解，似乎在内存中） 。
HistoryURLProvider顶部的注释解释了查找过程，完成了多线程ASCII艺术！
Sqlite查找
基本上，输入多功能框会导致sqlite运行这个用于通过前缀查找URL的SQL查询。这些建议按网址访问次数以及网址输入次数排序。
有趣的是，这不是一个trie ！查找的确是基于前缀，但这些查找的得分似乎并不像前缀那样被聚合，就像我想象的那样。
我的成功少一点在确定如何更新数据库中的分数。这部分代码在访问后更新了一个网址，但是我还没有跑过计数递减的位置（如果有的话）？
更新建议
我认为关于更新建议的事情 - 这现在还只是一个猜测 - 是内存中的sqlite数据库本质上优先于磁盘上的数据库，然后每当Chrome重新启动或以其他方式将内存数据库的内容刷新到磁盘时，每个URL的访问次数和类型计数都会在此时更新。再次，只是一个猜测，但我会继续寻找时间。
实际上，代码真的很棒。如果您有关于Chrome的类似问题，我肯定会推荐它。
I really enjoy using Chrome's URL bar because it remembers commonly-visited sites and often suggests a good completion based on what I've typed and/or visited before. So, for example, I can type t in the URL bar and Chrome will automatically fill it in with twitter.com, or I can type maps and Chrome will fill in the .google.com. This gives me the convenience of data-driven domain name shortcuts without having to maintain an explicit list.
What I'm wondering, though, is how Chrome determines that an old shortcut should be replaced with a new one. For example, if I visit twitter.com often, then that becomes the completion when I type t. But if I then start visiting twilio.com often enough, then, after some time, Chrome will start to fill that in as the default completion for t. What I can't figure out is how or when that transition takes place. It also seems that there are (at least) two cases involved : one for domain names, and another for path strings, because if I visit a certain full URL often, and then want to get to the root of the same domain, I end up having to type the entire domain name out to get Chrome to ignore the full-URL completion.
If I had to guess, I'd imagine that Chrome stores the things that I type in the URL bar in a trie whose values are the number of times that a particular string has been typed (and/or visited ?). Then I'd imagine it has some sort of exponential decay model for the "counts" in the trie. But this is just a guess. Does anyone know how this updating process happens ?
Well, I ended up finding some answers by having a look at the Chromium source code ; I'd imagine that Chrome itself uses this code without too much modification.
When you type something into the search/URL bar (which is apparently called the "Omnibox"), Chrome starts looking for suggestions and completions that match what you've typed. To do this, there are several "providers" registered with the browser, each of which knows how to make a particular type of suggestion. The URL history provider is one of these.
The querying process is pretty cool, actually. It all happens asynchronously, with particular attention paid to which activity happens in which thread (the main thread being especially important not to block). When the providers find suggestions, they call back to the omnibox, which appears to merge and sort things before updating the UI widget.
History provider
It turns out that URLs in Chrome are stored in at least one, and probably two, sqlite databases (one is on disk, and the second, which I know less about, seems to be in memory). This comment at the top of HistoryURLProvider explains the lookup process, complete with multithreaded ASCII art !
Sqlite lookup
Basically, typing in the omnibox causes sqlite to run this SQL query for looking up URLs by prefix. The suggestions are ordered by the number of visits to the URL, as well as by the number of times that a URL has been typed.
Interestingly, this is not a trie ! The lookup is indeed based on prefix, but the scoring of those lookups does not appear to be aggregated by prefix, like I'd imagined.
I had a little less success in determining how the scores in the database are updated. This part of the code updates a URL after a visit, but I haven't yet run across where the counts are decremented (if at all ?).
Updating suggestions
What I think is happening regarding the updating of suggestions -- and this is still just a guess right now -- is that the in-memory sqlite database essentially has priority over the on-disk DB, and then whenever Chrome restarts or otherwise flushes the contents of the in-memory DB to disk, the visit and typed counts for each URL get updated at that time. Again, just a guess, but I'll keep looking as I get time.
The code is really nice to read through, actually. I definitely recommend it if you have similar questions about Chrome.
这篇关于Chrome如何更新URL栏完成？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
