Каждый год мобильные и десктопные приложения становятся тяжелее — будто наращивают массу быстрее, чем успевают меняться потребности пользователей. В итоге простое обновление вдруг занимает сотни мегабайт. Получается парадокс — чем активнее развивается приложение, тем больше оно обрастает библиотеками, временными решениями и забытыми модулями и тем тяжелее становится его поддерживать. Почему так происходит, что именно «раздувает» размер сборок и можно ли вновь сделать приложения легче — расскажем в статье.
Эффект домино
Приложения с каждым обновлением занимают всё больше места, а пользователи всё чаще сталкиваются с выбором: что удалить, чтобы освободить гигабайт? Ответ на вопрос «почему так происходит» — история о цепной реакции. Одна, казалось бы, небольшая и полезная фича запускает целый каскад последствий, «раздувающих» приложение до неприличных размеров.
Усложнение функциональности
Фактически мы наблюдаем системный эффект. Рост функциональности вызывает рост инфраструктуры, а рост инфраструктуры — удорожание поддержки. Каждый новый модуль требует собственных зависимостей, которые тянут за собой цепочку из десятков вспомогательных компонентов.
Чаты, аналитика, встроенные плееры, офлайн-режимы, ML-модули, WebView и все более сложный UI не существуют не сами по себе. Они приходят «пакетами» вместе с инструментами тестирования, профилировщиками, вспомогательными утилитами для логирования, fallback-реализациями, а иногда и с внутренними версиями библиотек, которые уже есть в проекте.
Из-за этого одно небольшое решение, например продвинутый плеер или ML-модель для рекомендаций, может внезапно увеличить сборку на десятки мегабайт, хотя сама функция кажется компактной:
«Это требует “тяжелых” библиотек, множества SDK и кучи дополнительных ресурсов. Вдобавок увеличивают вес платформенные требования Apple и Google: тяжелые фреймворки безопасности, мультиязычные ресурсы, поддержка разных архитектур и экранов. В итоге даже небольшие обновления приводят к накоплению ассетов и кода, а сами приложения постепенно разрастаются».
Андрей Кутепов, руководитель проектного офиса Centicore Group
Графика, шрифты, локализация
Но функциональность лишь часть. Визуальная составляющая тоже растет — высокодетализированная графика, несколько наборов шрифтов, полноценная мультиязычность, ассеты под каждую плотность экрана:
«Например, часть ресурсов заранее компилируют в готовые шейдеры, чтобы ускорить загрузку и отрисовку статических элементов. Это улучшает UX, но увеличивает итоговый размер приложения».
Антон Фокин, СЕО QTIM
С точки зрения практики, такой рост визуальной и мультиязычной части приложения создает эффект лавины. Даже если команда тщательно следит за кодом, каждый новый экран, иконка или набор шрифтов автоматически умножает размер сборки.
При этом многие ресурсы предназначены для редких сценариев, например, для специфических устройств или языков с малой аудиторией. Они почти не используются пользователями, но остаются в базовом пакете, увеличивая общий вес приложения.
Кроссплатформа добавляет удобства… и мегабайты
Не последнюю роль играют подходы к разработке. Как отмечает Николай Яковлев, директор направления цифровых платформ и мобильных решений «Лиги Цифровой Экономики», рост размеров — прямое следствие использования более тяжелых кроссплатформенных фреймворков и ужесточение требований к безопасности.
Именно кроссплатформенные фреймворки создают двойной эффект. С одной стороны, они ускоряют разработку и упрощают поддержку нескольких платформ, с другой — тащат за собой обширный рантайм и зависимости, которые остаются в сборке даже при минимальном использовании функционала.
Практика показывает, что команды часто не сегментируют эти библиотеки и не удаляют лишние модули. Из-за этого интерфейс, который изначально кажется «легким», на самом деле добавляет приложению заметный объем. На ранних этапах роста проекта это трудно заметить, но со временем такая нагрузка начинает влиять и на скорость сборки, и на то, как быстро приложение работает у пользователя.
Не только технологии, но и инженерные привычки
Несмотря на то, что технологии объективно утяжеляют приложения, «раздутие» гораздо чаще — результат инженерных компромиссов, дедлайнов и привычки:
«Сами по себе релизные механики не обязательно увеличивают размер билда, но организационно они почти всегда создают среду, в которой мы «ничего не удаляем, только отключаем».
Андрей Кутепов, руководитель проектного офиса Centicore Group
При этом современные механики релизов, дифф-пакеты, A/B-выкладки, фича-флаги сами по себе не утяжеляют сборку, но создают эту привычку. Приложение накапливает старые фичи, экспериментальные экраны и целые потоки данных для аналитики, а рефакторинг откладывается «на потом».
Модульные архитектуры вроде Jetpack, SwiftUI или Compose дают шанс уменьшить базовый пакет за счет on-demand модулей, но реально это работает только, если команда сознательно следит за весом. Пока старые ресурсы остаются, сборка продолжает разрастаться несмотря на все технические возможности оптимизации.
Виталий Янко, основатель бюро хайтек-маркетинга SoftwareLead.pro, уверен, что эта проблема особенно актуальна для российских разработчиков. Многие SDK по умолчанию тянут огромные зависимости, хотя сегодня значительную часть продуктовой аналитики можно фиксировать на стороне сервера с минимальным клиентским модулем.
Почему приложение не «худеет», даже если удалить код?
Удаление кода почти никогда не уменьшает размер сборки — это вызывает удивление особенно у тех, кто сталкивается с этим впервые. Основная причина в том, что вес приложения формируется не столько строками кода, сколько зависимостями и ресурсами, которые «застревают» внутри сборки:
- статические библиотеки тянутся целиком;
- фреймворки остаются из-за привязанных компонентов;
- ML-модели и текстуры занимают десятки мегабайт;
- медиа, графика для старых устройств, fallback-ассеты, локализации и «мертвые» элементы под фича-флаги продолжают жить даже после удаления логики;
- обширные SDK аналитики и реклама добавляют еще больше веса.
«Внутри пакета остаются “невидимые” тяжелые компоненты, которые иногда добавляют десятки мегабайт, хотя пользователь даже не замечает подобную функциональность. Например, это может быть аналитика, AR-модули, картографические движки».
Николай Яковлев, директор направления цифровых платформ и мобильных решений «Лиги Цифровой Экономики»
В командах разработчиков часто встречается парадокс: удаление нескольких экранов и модулей логики дает выигрыш всего в 1–2 МБ, тогда как общий размер сборки остается на уровне сотен мегабайт.
Без системного подхода к работе с зависимостями, ресурсами и архитектурой приложения продолжает накапливать лишний вес, несмотря на видимые усилия по оптимизации. Это объясняет, почему даже регулярная чистка кода не дает заметного эффекта без пересмотра всех SDK, фреймворков, тяжелых ресурсов и внедрения on-demand загрузки и модуляризации.
Предел еще не близок, но есть шанс переломить тенденцию
Рост приложений продолжится — смартфоны становятся мощнее, а производительность пока опережает реальные потребности софта и дает разработчикам свободу добавлять новые функции и визуальные эффекты.
Однако уже сейчас появляются технологии, которые минимизируют вес базового пакета и контролировать «раздувание». On-demand-архитектуры (Android App Bundles, iOS On-Demand Resources) позволяют держать базовую сборку компактной и догружать тяжелые ресурсы по мере необходимости.
«Сдерживать “раздувание” в будущем помогут общие системные библиотеки без дублирования, умное сжатие и адаптивная загрузка контента — только по мере необходимости».
Кирилл Гончаров, директор по продукту и цифровой трансформации в BusinessPad
Динамическая загрузка ML-моделей, системные AI-фреймворки Apple и Google, WebAssembly с оптимизированными рантаймами, продвинутые форматы сжатия (WebP, AVIF) и хранение части приложения в облаке также позволят экономить десятки мегабайт.
Внедрить эти подходы — значит изменить сам процесс. Оптимизация веса приложения должна стать частью регулярного цикла разработки, а не разовой задачей перед релизом. Только тогда компании смогут выпускать приложения, которые растут функционально, но при этом остаются легкими, быстрыми и удобными для пользователей.
С чего начать путь к «цифровой стройности»?
Чтобы продукт не превращался в «цифровую мясорубку», не стоит пытаться чинить отдельные проблемы руками, а лучше выстроить системный процесс. Во-первых, назначить ответственного за вес приложения — как за скорость или качество, эта метрика должна быть в поле зрения команды постоянно.
Регулярные «весовые аудиты» помогут держать ситуацию под контролем — проверять фича-флаги, удалять устаревшие A/B-ассеты, отслеживать актуальность SDK и убирать неиспользуемые локализации. Каждое новое решение о подключении сторонней библиотеки должно проходить фильтр, действительно ли она нужна и есть ли более легкая альтернатива.
Переход на on-demand-ресурсы особенно важен для тяжелых компонентов (ML-моделей, AR, видео и больших мультимедийных пакетов). Контролировать рост UI-слоя нужно еще на этапе проектирования. Особенно если вы используете кроссплатформенные фреймворки, где каждая библиотека добавляет килобайты или мегабайты в сборку. И главное — планировать рефакторинг как регулярную часть релизного цикла, а не оставлять его на потом.
Конечно, приложения будут продолжать расти вместе с функциональностью. Но компании, которые с самого начала позаботятся о легкости своих приложений и смогут контролировать «вес» сборки, получат продукты-долгожители — быстрее в загрузке, дешевле в поддержке и удобнее для пользователей.