3

Chrome の URL バーは、頻繁にアクセスするサイトを記憶しており、以前に入力したりアクセスしたりした内容に基づいて適切な補完を提案してくれることが多いため、Chrome の URL バーをとても気に入っています。たとえば、 URL バーに入力tすると、Chrome が自動的に. これにより、明示的なリストを維持する必要がなく、データ駆動型のドメイン名のショートカットの利便性が得られます。twitter.commaps.google.com

しかし、私が疑問に思っているのは、古いショートカットを新しいものに置き換える必要があることを Chrome がどのように判断するかということです。たとえば、twitter.com頻繁にアクセスする場合は、入力するとそれが完了になりtます。しかし、私twilio.comが十分に頻繁にアクセスし始めると、しばらくすると、Chrome は のデフォルトの補完としてそれを入力し始めますt。私が理解できないのは、その移行がいつ、どのように行われるかです。また、(少なくとも) 2 つのケースが関係しているようです: 1 つはドメイン名用、もう 1 つはパス文字列用です。これは、特定の完全な URL に頻繁にアクセスしてから、同じドメインのルートにアクセスしたい場合に終了するためです。 Chrome に完全な URL 補完を無視させるには、ドメイン名全体を入力する必要があります。

推測する必要がある場合、Chrome は URL バーに入力した内容を、特定の文字列が入力された (および/またはアクセスされた) 回数を値とするトライに格納していると思います。次に、トライの「カウント」にある種の指数関数的減衰モデルがあると思います。しかし、これは単なる推測です。この更新プロセスがどのように行われるか知っている人はいますか?

4

1 に答える 1

6

さて、Chromiumのソースコードを見て、いくつかの答えを見つけました。Chrome 自体はこのコードをあまり変更せずに使用していると思います。

検索/URL バー (「オムニボックス」と呼ばれているようです) に何かを入力すると、Chrome は入力内容に一致する候補と補完を探し始めます。これを行うために、ブラウザーに登録されているいくつかの「プロバイダー」があり、それぞれが特定の種類の提案を行う方法を知っています。URL 履歴プロバイダーはその 1 つです。

実際、クエリのプロセスはかなりクールです。すべてが非同期で発生し、どのアクティビティがどのスレッドで発生するかに特に注意が払われます (メイン スレッドはブロックしないことが特に重要です)。プロバイダーが提案を見つけると、オムニボックスにコールバックします。オムニボックスは、UI ウィジェットを更新する前に、物事をマージして並べ替えているように見えます。

履歴プロバイダー

Chrome の URL は、少なくとも 1 つ、おそらく 2 つの sqlite データベースに保存されていることがわかりました (1 つはディスク上にあり、もう 1 つはメモリ内にあるようです)。HistoryURLProvider の上部にあるこのコメントは、ルックアップ プロセスを説明し、マルチスレッドの ASCII アートを完備しています。

Sqlite ルックアップ

基本的に、オムニボックスに入力すると、sqlite はこのSQL クエリを実行して、プレフィックスで URL を検索します。候補は、URL へのアクセス数と、URL が入力された回数によって並べ替えられます。

興味深いことに、これは trie ではありません! ルックアップは確かにプレフィックスに基づいていますが、私が想像していたように、これらのルックアップのスコアはプレフィックスによって集計されているようには見えません。

データベース内のスコアがどのように更新されるかを判断するには、少し成功しませんでした。コードのこの部分は、訪問後に URL を更新しますが、カウントが減少する場所にまだ出くわしていません (もしあったとしても?)。

提案を更新しています

提案の更新に関して私が考えているのは、これはまだ推測にすぎませんが、メモリ内の sqlite データベースは基本的にディスク上の DB よりも優先され、Chrome が再起動するか、その他の方法でフラッシュされるたびに、インメモリ DB のコンテンツをディスクに保存すると、各 URL の訪問数と入力数がその時点で更新されます。あくまで推測ですが、時間があれば探してみます。

実際、このコードは読み通すのに非常に適しています。Chrome について同様の質問がある場合は、ぜひお勧めします。

于 2013-08-29T15:48:18.750 に答える