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