Совсем недавно в интернете появилось несколько интересных инфографик, о том, что популярные приложения для телефонов за пару лет выросли в размере в 12 раз. В этой заметке делается попытка разъяснить некоторые неочевидные причины роста размера мобильных приложений.
Авторы инфографик в оригинальных статьях выделяют две причины такого роста:
- повышение максимального допустимого размера приложений AppStore
- оснащение телефонов все большим объемом памяти
На мой взгляд, указанные тезисы являются только предпосылками и до конца не отвечают на вопрос "почему приложения становятся больше?".
Конечно, в первую очередь дело в добавлении новых функций. Развитие функциональности приложений требует большего размера.
Вот только размер приложений в отличие от их функциональности растет в десятки раз и обычно у этого роста совсем другие причины. Далее на базе разных источников с конкретными примерами я попробую систематизировать разные причины:
Лишние копии ресурсов в приложении
Как ни банально звучит, но в приложениях часто сохраняются одни и те же внутренние ресурсы (картинки, библиотеки, и так далее) по нескольку копий. Это происходит из-за того, что крупные приложения разрабатываются несколькими командами разработчиками, отвечающими за свой конкретный функционал программы. Бывает так, что команда тащит для своего модуля те же ресурсы, что и другая, вызывая задвоение.
В одной из статей автор решил детально разобрать внутреннее строение приложения Facebook для iOS после того, как оно увеличилось за полгода с 165 до 253 мегабайт. Он обнаружил, что в приложении содержалось свыше 40 мегабайт избыточных дублирующих данных. В основном это были картинки, но также были и абсолютно идентичные внутренние программные файлы. Таким образом, просто удалив дубликаты, можно было бы уменьшить размер приложения на 15% процентов. Что, кстати, Facebook впоследствии и сделал.
А/Б тестирование и внедрение новых функций
Распространенной практикой при разработке приложения является добавление новой функциональности и по умолчанию отключение ее. Это позволяет в дальнейшем постепенно включать ее для тестовых или пилотных групп и по необходимости корректировать или обратно выключать. Но даже по прошествии длительного времени, как правило, возможность отключить новый функционал и восстановить старый не убирается и все равно остается в приложении на всякий случай и для экономии времени.
Переход на более комфортные языки программирования
В случае с приложениями под iOS переход с Objective-C на Swift может дать увеличение размера скомпилированного кода приложения в 3-4 раза. Это происходит из-за того, что ради удобства и скорости разработки новые языки могут:
- использовать большие типы данных по умолчанию, которые занимают больше места
- вводить дополнительные тесты и проверки в код при компиляции
- использовать большую стандартную библиотеку функций
Сюда же можно отнести переход приложений на новые фреймворки, которые тащат с собой много необходимых им файлов.
Включение в программы собственных функций, заменяющих стандартные операционной системы
Одним из трендов мобильной разработки под несколько платформ является стремление минимизировать зависимость от конкретной операционной системы. У этого подхода есть свои плюсы. Во-первых, это позволяет не переписывать много кода при изменении внешних системных библиотек. Во-вторых, это позволяет удержать пользователя в своем приложении и обеспечить более консистентный пользовательский опыт (хотя часто бывает так, что своя реализация визуально не отличима от стандартной).
Среди наиболее популярных "велосипедов", заменяющих стандартные средства ОС, можно выделить:
- Браузеры
- Работа с камерой
- Ввод текста и обработка жестов
- Проверка орфографии
Рост требований к приложениям
По мере развития телефонов владельцы экосистем (Apple, Google) начинают предъявлять к программам новые требования по поддержке системных появляющихся возможностей телефонов, которые требуют больше места:
- После появления Retina разработчиков обязали добавлять картинки с большей детализацией и соответственно размеров.
- Переход iOS с 32 на 64 бита впоследствии заставил всех разработчиков выпускать именно 64-битные приложения.
К слову в AppStore для борьбы с ростом размера приложений по таким требованиям потом была представлена технологий App thinning, по которой на конкретный телефон скачивается адаптированная версия приложения без избыточных ресурсов для других версий телефонов.
Комментарии (28)
SLASH_CyberPunk
07.07.2017 11:56Все бы хорошо, но большинство приложений из списка выше строятся на веб-технологиях, которые тянутся при необходимости из интернета…
Ожидал прочитать, как добавляют тонны различных метрик для сбора данных…bopoh13
07.07.2017 12:18… у меня в теле почти все. Причем пользователь не нуждается в постоянном обновлении данных.
Нужно будет удалить половину.
alexeykuzmin0
07.07.2017 11:57-1Размер потихоньку растет сам по себе, ведь добавляются новые функции, изменяется дизайн и тд. А вот чтобы сделать приложение меньше, нужно затратить некие усилия. Учитывая, что телефоны сейчас поддерживают довольно большой объем памяти, это никому не нужно, вот никто этого и не делает.
Вот и ответ, и не нужно никаких исследований.
svistkovr
07.07.2017 11:58Еще можно добавить средства кросс-платформенной разработки например: unity, xamarin, robovm и т.д.
Каждый кросс-платформенный инструмент тянет в приложение кучу своих собственных либ и биндингов.
dom1n1k
07.07.2017 12:16+6Ладно еще сами приложения. Шестой Андроид отказывается скачивать и обновлять приложение весом 5 мб при свободном месте в телефоне >300 мб — потому что ему, видите ли, места нет для этой операции!
den_golub
07.07.2017 13:06Это нормальная практика, потому как возможно два варианта:
- Приложение при установке распаковывается из 5 Mb в больший объем и как следствие ограничение в 300 Mb, уж не знаю каким путем выяснили они эту цифру
- Многие приложения с таким весом, как правило помимо приведенного выше после установки скачивают доп. файлы весом от 20 Mb до 2Gb
schetilin
07.07.2017 13:34Нет. Именно до скачивания обновления говорит о нехватке места. Как я понимаю, Android резервирует какой то процент от памяти под свои нужды, но при этом показывает его как свободный.
dom1n1k
07.07.2017 14:25+1Опытным путем я выяснил, что лимит около 400 мб. С учетом того, что всего в телефоне 8 гб — возможно, они резервируют 5%.
Но работает этот лимит очень тупо. Если места хоть насколько-то больше лимита — оно даст обновить и большое приложение (по личному опыту, порядка 50-70 мб). Но если места хоть чуть-чуть меньше лимита — оно не даст обновить даже самую крошечную апликуху.
tmpuser
07.07.2017 14:49Android считает что памяти мало если её остается меньше некоего процента от общего объема, вроде 5%.
Поэтому если раздел /data, скажем, на 12 Гб (вполне реально), то обновления будут невозможны уже при 500 Мб, что абсурдно.
При наличии рута должно помочь указание порога в 0%:
http://4pda.ru/forum/index.php?showtopic=468961&view=findpost&p=37448420khim
08.07.2017 00:10Поэтому если раздел /data, скажем, на 12 Гб (вполне реально), то обновления будут невозможны уже при 500 Мб, что абсурдно.
Это не абсурдно, а правильно и логично. Если забить файловую систему «под завязку», то она будет работать в 10 раз медленнее. Таким простым и нехитрым способом Android этого не допускает и всё работает достаточно быстро.
Объяснять что-либо пользователям при этом бесполезно, увы.myazinn
08.07.2017 15:52Тогда почему бы просто не зарезервировать место, чтобы оно не отображалось как свободное? Раз уж им всё равно пользоваться нельзя.
А объяснять пользователям надо, в конце концов, телефоны покупают они, а не разработчикиkhim
08.07.2017 19:24Тогда почему бы просто не зарезервировать место, чтобы оно не отображалось как свободное? Раз уж им всё равно пользоваться нельзя.
Маркетинг? Или, может, какие-то специфические особенности системы. В «обычном» GNU/Linux зарезервированное место не отображается как свободное и использовать его может толькоroot. Скорее всего с последним возникли проблемы…
<blockquote.>А объяснять пользователям надо, в конце концов, телефоны покупают они, а не разработчикиДа — но зачем оно им? Все системы пытавшиеся что-там пользователям обьяснять — вымерли, однако…
mishast
10.07.2017 17:57У меня как-то закончилось место на телефоне, я стал его пытаться освободить,
стал смотреть, может данные приложений много место занимают, вроде все данные поудалял, но все равно места нет, а приложения, казалось бы, весят 5-60Мб, места — 6 гб было на чистой системе. Куда делось все место?
После рутования выяснилось вот что:
Очень много места съедается на dalvik кэш (сейчас уже art), т.е ставишь приложение в 20Мб, а съедается 200Мб. И главное нигде это в файловом менеджере не увидишь, если у вас нет рута, да и если есть надо еще догадаться, куда заглянуть…
apk — это архив, при установке он распаковывается, а потом еще и компилируется.
serg_p
07.07.2017 14:26Тенденция — Нужен анализ по пунктам, и не только в мобиле. А есть просто фиксация факта = пичаль.
goodhoopoe
07.07.2017 14:49Тут ещё фактор самих ресурсов, которые используются в приложении. Можно нарисовать визуальную часть контрола программно, а можно загрузить картинку, разница может доходить до порядков. Я всегда привожу 2 примера, которому я не перестаю удивляться и в какой-то мере даже восхищаться, потому что я считаю к такому нужно стремиться. Фейсбук больше 100мб, вконтакте 21.4мб(айфон, для айпэда 15.4(!!)). Фейсбук мессенджер 139мб, телеграм 47мб.
man55
07.07.2017 18:18+2Я вам больше скажу, ВКонтакт 3.12 под Андроид весит 9.7М (версия июнь 2015) и имеет всю основную функциональность. И сдается мне, что в текущих версиях новой функциональности и нету.
Когда исчерпан функционал, начинаются свистелки и перделки
pawellrus
08.07.2017 16:12Запланированное устаревание же. Дополнительная причина пойти и купить новый смартфон, где встроенной памяти наконец-то хватит под все приложения и игры с кэшем. А через пару лет снова и снова.
Movimento5Litri
11.07.2017 10:35Берримор,
Почему мобильные приложения занимают все больше места?
— Говнокодеры, сер
dmitry_dvm
Пишем одно приложеньице под все платформы. Под айос оно весит 70Мб, а UWP — 3Мб. Мне кажется большая часть веса — это неоптимизированные пнг всевозможнных кнопок. В UWP такого нет потому что все иконки шрифтовые. По-моему вес любого айос приложения можно сократить в разы просто прогнав все картинки через какой-нибудь tinypng.
kekekeks
Так вы поди на Xamarin его пишете. И в случае с iOS оно внутри себя содержит цельнотянутый Mono-рантайм.
dmitry_dvm
Никаких замаринов, нативненько пишем.