Вчора в блозі Android був опублікований запис, в якому розробники розповідають про свою роботу над зменшенням розміру оновлень. Як наголошується в тексті, щодня мільйони користувачів оновлюють свою систему і додатки, і багато з них уважно стежать за тим, скільки мобільного трафіку на це йде.
Для того, щоб зменшити розмір оновлень, розробники Android ще в червні 2016 року почали застосовувати алгоритм bsdiff за авторством Коліна Персіваля для патчу бінарних файлів. Тоді це допомогло знизити розмір додатків і оновлень до них, в середньому, на 47% відносно повного APK.
Тепер же команда Android хоче поділитися новим рішенням, яке дозволяє знизити обсяг оновлень на, в середньому, 65% від початкового розміру. Мова йде про File-by-file patching.
Підхід досить простий. Замість того, щоб завантажити повний APK і перевстановлювати всі файли програми, система оновлення проводить звірку користувацьких файлів і завантажених. Це дозволяє завантажувати лише ті файли, які зазнали якихось змін під час розробки.
За словами розробників Android цей простий, але ефективний підхід дозволяє скоротити трафік оновлень на 6 петабайт щодня.
Але є й деякі підводні камені. Стиснення APK-файлів відбувається майже так само, як і ZIP, з використанням Deflate. Це дозволяє значно зменшити розмір, але в той же час ускладнює визначення того, в які саме файли були внесені зміни:
Демонстрація Deflate
Як видно з зображення вище, внесення навіть одного символу повністю змінює структуру пережатого файлу. Отже, file-by-file patching ґрунтується на порівнянні незжатих файлів між собою. У процесі оновлення відбувається звірка розпакованих файлів, як старих, так і нових. На цьому етапі все ще використовується bsdiff. Потім, при застосуванні патчу виявляються файли, які потребують заміни і скачуються саме вони. Після цього APK знову перезбирається вже на боці пристрою. Як докази розробники наводять зведену таблицю по ряду найбільш популярних додатків для Android:
Ці програми вже використовують систему оновлення file-by-file.
У даного підходу є кілька мінусів. Перше - кінцевий APK повинен повністю збігатися з вихідним, байт в байт. На цей параметр впливає збирання Deflate (найчастіше використовується зібрана на основі Zlib) і її налаштування.
Як виявилося в ході аналізу, всі розробники використовують тільки два параметри стиснення за допомогою Deflate: або типово (6), або максимальний (9). Будь-яких інших параметрів розробники Android не виявили.
Інший мінус підходу - вимоги до обчислювальних потужностей на кінцевому пристрої, конкретно, до процесора. Процеси розпакування, звірки і зворотного складання в APK вимагають значних потужностей від пристрою користувача, і не всі існуючі девайси зможуть впоратися з цією процедурою в рівній мірі успішно. Це призводить до більш тривалого застосування патчу на старих і малопотужних пристроях. Крім того, час обробки збільшується пропорційно, виходячи з розмірів оновлення.
