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

Совсем недавно в интернете появилось несколько интересных инфографик (1, 2), о том, что популярные приложения для телефонов за пару лет выросли в размере в 12 раз. В этой заметке делается попытка разъяснить некоторые неочевидные причины роста размера мобильных приложений.

Инфографика 1 Инфографика 2

Авторы инфографик в оригинальных статьях выделяют две причины такого роста:

На мой взгляд, указанные тезисы являются только предпосылками и до конца не отвечают на вопрос “почему приложения становятся больше?“. Конечно, в первую очередь дело в добавлении новых функций. Развитие функциональности приложений требует большего размера.

Инфографика 3

Вот только размер приложений в отличие от их функциональности растет в десятки раз и обычно у этого роста совсем другие причины. Далее на базе разных источников с конкретными примерами я попробую систематизировать разные причины:

Лишние копии ресурсов в приложении

Как ни банально звучит, но в приложениях часто сохраняются одни и те же внутренние ресурсы (картинки, библиотеки, и так далее) по нескольку копий. Это происходит из-за того, что крупные приложения разрабатываются несколькими командами разработчиками, отвечающими за свой конкретный функционал программы. Бывает так, что команда тащит для своего модуля те же ресурсы, что и другая, вызывая задвоение.

В одной из статей автор решил детально разобрать внутреннее строение приложения Facebook для iOS после того, как оно увеличилось за полгода с 165 до 253 мегабайт. Он обнаружил, что в приложении содержалось свыше 40 мегабайт избыточных дублирующих данных. В основном это были картинки, но также были и абсолютно идентичные внутренние программные файлы. Таким образом, просто удалив дубликаты, можно было бы уменьшить размер приложения на 15% процентов. Что, кстати, Facebook впоследствии и сделал.

А/Б тестирование и внедрение новых функций

Распространенной практикой при разработке приложения является добавление новой функциональности и по умолчанию отключение ее. Это позволяет в дальнейшем постепенно включать ее для тестовых или пилотных групп и по необходимости корректировать или обратно выключать. Но даже по прошествии длительного времени, как правило, возможность отключить новый функционал и восстановить старый не убирается и все равно остается в приложении на всякий случай и для экономии времени.

Переход на более комфортные языки программирования

В случае с приложениями под iOS переход с Objective-C на Swift может дать увеличение размера скомпилированного кода приложения в 3-4 раза. Это происходит из-за того, что ради удобства и скорости разработки новые языки могут:

Сюда же можно отнести переход приложений на новые фреймворки, которые тащат с собой много необходимых им файлов.

Включение в программы собственных функций, заменяющих стандартные операционной системы

Одним из трендов мобильной разработки под несколько платформ является стремление минимизировать зависимость от конкретной операционной системы. У этого подхода есть свои плюсы. Во-первых, это позволяет не переписывать много кода при изменении внешних системных библиотек. Во-вторых, это позволяет удержать пользователя в своем приложении и обеспечить более консистентный пользовательский опыт (хотя часто бывает так, что своя реализация визуально не отличима от стандартной).

Среди наиболее популярных “велосипедов”, заменяющих стандартные средства ОС, можно выделить:

Рост требований к приложениям

По мере развития телефонов владельцы экосистем (Apple, Google) начинают предъявлять к программам новые требования по поддержке системных появляющихся возможностей телефонов, которые требуют больше места:

К слову в AppStore для борьбы с ростом размера приложений по таким требованиям потом была представлена технологий App thinning, по которой на конкретный телефон скачивается адаптированная версия приложения без избыточных ресурсов для других версий телефонов.

PS. Это репост моей же статьи с Хабра, где ее также можно комментировать.


© 2016–2017 Creative Commons BY-NC-ND 4.0
Powered by GitLab and Hugo

comments powered by Disqus