Вчера в блоге 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 требуют значительных мощностей от устройства пользователя, и не все существующие девайсы смогут справиться с этой процедурой в равной степени успешно. Это приводит к более длительному применению патча на старых и маломощных устройствах. Кроме того, время обработки увеличивается пропорционально, исходя из размеров обновления.
