Блог

Я работаю над проектом, построенным на электроне. Мы настроили дифференциальные обновления через electron-builder (с nsis-web и отдельной ветвью дифференциального обновления для mac) и ожидали, что он будет загружать небольшие обновления.

Теперь мы понимаем, что дифференциальные обновления для нашего приложения (когда оно упаковано/заархивировано, объем приложения составляет в общей сложности ~100 МБ), как правило, колеблются в пределах ~20-40 МБ загрузок, при этом где-то около ~1000 измененных блоков, даже в тех случаях, когда мы изменили только 1 символ в строке в нашем исходном коде. По мере роста нашей базы пользователей и предвидения необходимости быстрого развертывания обновлений это может очень быстро покрыть расходы на наши серверы. Мы ожидали, что загрузка дельты будет довольно низкой, надеюсь

Мы создали наше приложение на основе шаблона Electron React, который использует webpack для упаковки исходного кода.

В настоящее время мы запутываем наш пакет webpack, хотя такое поведение также отслеживалось до добавления запутывания, поэтому мы исключили бы его как причину.

Мне не ясно, будет ли подход 7z к блокам/файловым дельтам означать, что одно изменение в файле может повлиять на все его блоки, и если да, то его разбиение будет означать, что блоки для незатронутых файлов сами по себе не будут затронуты. (Я все еще пытаюсь

В настоящее время у нас есть ряд модулей, импортируемых в наш проект для различных целей, которые упаковываются в окончательный пакет webpack. Я обсуждаю попытку сохранить модули внешними по отношению к пакету webpack, но страница производительности Electron, похоже, выступает за объединение всего кода воедино, чтобы избежать дорогостоящих require() вызовов. Я все еще пытаюсь придумать и провести эксперименты, чтобы понять поведение.

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

Правка: Предпринята попытка теста, в котором я изменил только версию приложения, а программа дифференциального обновления все равно вышла из системы:

 [2021-10-14 18:29:34.046] [info] File has 2092 changed blocks
[2021-10-14 18:29:34.058] [info] Full: 95,995.56 KB, To download: 42,767.89 KB (45%)
 

Изменить: Это решение не полностью решает проблемы для mac. Похоже, что собственные компоненты изменяются даже при изменении только версии пакета mac, в результате чего они генерируют большое количество измененных блоков.

Оригинальный ответ ниже:

Короче говоря: отключите Asar для пакета.

Я выявил некоторые проблемы, главной из которых было то, что программа дифференциального обновления в electron-builder использует 7zip для создания дифференциального файла, и, насколько я понимаю, изучая его, 7zip генерирует внутреннее представление структуры файла.

Принимая это во внимание, оказалось, что отключение файла ASAR, который является стандартным и рекомендованным в Electron, означало, что все исходные файлы больше не объединялись внутри него, позволяя 7zip индивидуально отслеживать их. Это означает, что любой измененный файл, по-видимому, влияет только на блоки для него в блок-карте. Файл ASAR, являющийся единственным файлом, по-видимому, создавал такое впечатление, что любое изменение в исходном коде изменит большинство блоков для файла ASAR после 7-кратной архивации.

Кроме того, это, по-видимому, подразумевает, что более детализированная структура файлов в пакете Electron приведет к уменьшению дельт для дифференциального автоответчика.