Как Chrome обновляет дополнения в строке URL?
Мне действительно нравится использовать адресную строку Chrome, потому что она запоминает часто посещаемые сайты и часто предлагает хорошее завершение на основе того, что я набрал и / или посетил ранее. Так, например, я могу напечатать t в строке URL, и Chrome автоматически заполнит его twitter.comили я могу напечатать maps и Chrome заполнит .google.com, Это дает мне удобство управляемых данными ярлыков доменных имен без необходимости вести явный список.
Что мне интересно, так это то, как Chrome определяет, что старый ярлык должен быть заменен новым. Например, если я посещаю twitter.com часто, тогда это становится завершением, когда я печатаю t, Но если я тогда начну посещать twilio.com достаточно часто, затем, через некоторое время, Chrome начнет заполнять это как завершение по умолчанию для t, Что я не могу понять, так это как и когда происходит этот переход. Также кажется, что есть (по крайней мере) два случая: один для доменных имен, а другой для строк пути, потому что, если я часто посещаю определенный полный URL, а затем хочу попасть в корень того же домена, я заканчиваю до того, как нужно было ввести полное доменное имя, чтобы Chrome игнорировал завершение полного URL-адреса.
Если бы мне пришлось угадывать, я бы предположил, что Chrome хранит вещи, которые я печатаю в строке URL, в виде дерева, значения которого - количество раз, которое была напечатана (и / или посещена) определенная строка?). Тогда я предположил бы, что у него есть какая-то модель экспоненциального затухания для "числа" в три. Но это всего лишь предположение. Кто-нибудь знает, как происходит этот процесс обновления?
1 ответ
Что ж, в итоге я нашел некоторые ответы, посмотрев на исходный код Chromium; Я полагаю, что сам Chrome использует этот код без особых изменений.
Когда вы вводите что-либо в строку поиска /URL (которая, по-видимому, называется "омнибокс"), Chrome начинает поиск предложений и дополнений, соответствующих введенному вами. Для этого в браузере зарегистрировано несколько "провайдеров", каждый из которых знает, как составить конкретный тип предложения. Поставщик истории URL является одним из них.
Процесс запросов довольно крутой, на самом деле. Все это происходит асинхронно, с особым вниманием к тому, какая активность происходит в каком потоке (основной поток особенно важен, чтобы не блокировать). Когда провайдеры находят предложения, они перезванивают в омнибокс, который объединяет и сортирует вещи перед обновлением виджета пользовательского интерфейса.
Провайдер истории
Оказывается, URL-адреса в Chrome хранятся как минимум в одной, а возможно, и в двух базах данных sqlite (одна находится на диске, а вторая, о которой я знаю меньше, кажется, находится в памяти). Этот комментарий в верхней части HistoryURLProvider объясняет процесс поиска, в комплекте с многопоточным искусством ASCII!
Sqlite поиск
По сути, ввод в омнибоксе заставляет sqlite запускать этот SQL-запрос для поиска URL-адресов по префиксу. Предложения упорядочены по количеству посещений URL-адреса, а также по количеству попыток ввода URL-адреса.
Интересно, что это не три! Поиск действительно основан на префиксе, но оценка этих поисков, по-видимому, не агрегирована по префиксу, как я себе представлял.
У меня было немного меньше успеха в определении того, как обновляются результаты в базе данных. Эта часть кода обновляет URL после посещения, но я еще не сталкивался с тем, где уменьшилось количество (если вообще?).
Обновление предложений
Я думаю, что происходит с обновлением предложений - и это пока только предположение - то, что база данных sqlite в памяти имеет приоритет над дисковой БД, а затем всякий раз, когда Chrome перезапускает или иным образом сбрасывает содержимое базы данных в памяти на диск, количество посещений и набранные значения для каждого URL обновляются в это время. Опять же, только предположение, но я буду продолжать искать, когда у меня будет время.
Код действительно приятно читать, на самом деле. Я определенно рекомендую его, если у вас есть похожие вопросы о Chrome.