Возможно ли расширение Chrome MV3 с большим постоянным использованием ОЗУ?

Question

Я работаю над расширением Chrome, которое предназначено для проверки содержимого любой веб-страницы, на которую переходит пользователь, а затем предупреждает пользователя об определенных «функциях» этого содержимого. (Возможно, проще всего представить себе большое количество строк, которые ищутся в текстовых данных веб-страницы, хотя это довольно большое упрощение.) По дизайну существует очень большой набор (десятки миллионов) строк функции, которые расширение обнаруживает и на которые может реагировать. Каждая такая функция может быть представлена ​​как номер JS (8 байтов), поэтому общий объем данных может быть порядка 100 МБ или более.

Эти данные могут храниться в IndexedDB, но чтобы иметь возможность быстро анализировать данные страницы (отправленные сценарием содержимого), скрипт фоновой страницы (в MV2) или сервисный работник (в MV3) действительно должен иметь функции (которые проверяются на наличие), хранящегося в ОЗУ, чтобы иметь возможность быстро проверить гораздо меньшее, но все же большое количество функций с веб-страницы, чтобы увидеть, присутствуют ли какие-либо из них в его собственном наборе данных.

Эта настройка действительно отлично работала в созданном мной расширении манифеста прототипа версии 2 (MV2). Фоновый скрипт начнется с первоначального получения данных из IndexedDB и помещения их в структуру в ОЗУ. На моем ноутбуке это занимает немного времени (некоторое количество секунд, у меня нет точных цифр), но это нужно сделать только один раз при запуске браузера. После этого фоновый сценарий может быстро реагировать на запросы сценария содержимого для проверки содержимого веб-страницы.

Теперь, когда мы пытаемся перейти на манифест версии 3 (MV3), проблема в том, что сервис-воркеры не являются постоянными и даже не очень долгоживущими. Таким образом, при прямом преобразовании сервисный работник будет выполнять дорогостоящую и медленную загрузку из IndexedDB в оперативную память при каждом перезапуске. Это явно не рабочая установка.

Возникает очевидный вопрос: есть ли способ избежать остановки работника службы Chrome (и, таким образом, сохранить работника службы расширений в течение длительного периода)? Если нет, есть ли способ, чтобы данные в ОЗУ могли оставаться в памяти, и работник службы мог получить к ним доступ при запуске? (Я далек от эксперта по расширениям Chrome и работникам служб, поэтому прошу прощения, если мои вопросы наивны.) Я читал некоторые обсуждения, которые, казалось, предполагают, что, возможно, ни одно из вышеперечисленных в настоящее время невозможно, но если это так, это в основном сделало бы весь концепт не стартер под МВ3. Есть ли обходные пути? (Если да, приемлемы ли эти обходные пути в процессе проверки в Интернет-магазине Chrome?)

Буду очень признателен за любые указатели!

Answer 1

Я столкнулся с похожей ситуацией, когда расширение основано на журнале только для добавления CRDT, который используется в режиме p2p. Этот журнал станет слишком большим, если будут добавлены повторяющиеся или ненужные данные.

Первый дизайн

Сначала я хотел, чтобы фоновый сценарий хранил журнал в памяти, а контентный сценарий уведомлял фоновый сценарий, когда он встречал что-то интересное. Таким образом, фоновый скрипт мог бы сравнить новую информацию с тем, что уже есть в журнале, и решить, добавлять/обновлять информацию или нет. Я посмотрел на обходной путь поддержания активности и у меня были аналогичные оговорки в отношении процесса проверки Chrome Web Store.

МВ3 Дизайн

Чтобы избежать архитектуры MV2 в памяти, я обновил дизайн, чтобы использовать больше памяти и вычислительной мощности вместо памяти. Сценарий содержимого просто записывает все, что он обычно отправляет фоновому сценарию в localStorage. Когда сервис-воркер просыпается:

1. Считывает весь журнал в память
2. Читает все элементы, зарегистрированные сценарием содержимого.
3. Выполняет ту же логику, что и при получении сообщения от скрипта содержимого.

Приведенный выше дизайн использует больше памяти для хранения всего, с чем сталкивается сценарий контента. Он также должен считывать весь журнал в память всякий раз, когда он запускается. Это позволяет избежать подключения памяти в 100% случаев.

Эта архитектура напоминает мне о компромиссах, сделанных при разработке мобильных приложений для Android или iOS, где, за исключением очень немногих обстоятельств, ваша задача может быть заархивирована в любой момент. MV3 нужно добавить что-то похожее на Android AcquireWakeLock() , но я не сомневаюсь, что это произойдет в ближайшее время.