Почему приложения не обновляются, вычисляя разницу?

Почему приложения не обновляются, вычисляя разницу?

У меня есть компьютеры Ubuntu и телефон Android, и меня всегда озадачивало, почему менеджер обновлений по умолчанию в Ubuntu и Google Play на телефоне не обновляют существующие версии приложений, вычисляя разницу между ними и новыми версиями. Я уверен, что это касается и других операционных систем (поэтому этот вопрос не в Ask Ubuntu или Android энтузиастов)

Рассмотрим, например, последнее обновление (незначительный релиз)Карты Гугл(по состоянию на 18 апреля 2012 г.). В разделе «Что нового» говорится, что в него включено исправление критической ошибки. Можно с уверенностью предположить, что большая часть кода не была изменена, и все же, когда вы обновляете приложение, оно загружает более 6 МБ, как будто это новая установка.

Почему серверы обновлений не могут вычислить разницу (a la git) с установленными версиями и отправить только разницу? Неужели так сложно сделать это со всеми версиями? Разве сэкономленная пропускная способность не станет основной мотивацией?

Редактировать 6 декабря 2016 г.: Google только что объявила, что собирается использовать пофайловое исправление для обновлений Android APK -Экономия данных: уменьшение размера обновлений приложений на 65%

решение1

Существует три уровня, на которых вы можете оптимизировать размер загрузки, передавая только разницу.

Уровень пакетаПередавать только обновленные пакеты. Это уже сделано. Если вы посмотрите на размеры загружаемых пакетов, то увидите, что большинство из них действительно малы. Таким образом, это экономит большую часть полосы пропускания.

Файлы в пакетеПередавать только измененные файлы в пакете. Управление пакетами — это больше, чем просто копирование файлов в фиксированные расположения. Существуют файлы конфигурации, которые могли быть автоматически адаптированы к вашей системе. Могут быть ручные изменения. Было бы трудно достоверно определить разницу, не загрузив предварительно установленные файлы.

Внутренние различия файловБольшинство, и особенно большие файлы, являются бинарными. Трудно представить надежный алгоритм исправления для двоичных файлов, если файл, который нужно исправить, имеет небольшое изменение, например, другую метку времени сборки. С другой стороны, для текстовых файлов старые алгоритмы diff и patch, применяемые git, вероятно, будут работать хорошо, но, вероятно, не стоит усилий.

Другая проблема заключается в том, что вы не знаете, какая старая версия будет обновлена. Пользователи могли пропустить промежуточные обновления. Конечно, менеджер пакетов может запросить сервер отправить diff для определенной версии, но это создаст огромную нагрузку на сервер для генерации diff. Я сомневаюсь, что разработчики сервера позволят это.

Краткое содержание: То, что можно было сделать легко и надежно, уже сделано. Остальное — дело менеджеров пакетов, которые должны делать небольшие пакеты, чтобы обновления оставались небольшими.

решение2

В принципе, это технически сложно для разработчиков. А пропускная способность дешевая — точнее, ее оплачивают пользователи.

Google Chrome вложил много усилий в разработку дополнительных обновлений для двоичных файлов Chromehttp://blog.chromium.org/2009/07/smaller-is-faster-and-safefer-too.html.

Fedora разработала 'delta rpm' для отправки инкрементальных обновлений пакетов. Забавно, что поскольку у моего компьютера быстрое сетевое соединение, но медленный процессор, они на самом деле устанавливаются у меня медленнее.

Связанный контент