Почему одно и тоже приложение на разных смартфонах весит по разному
. на разных носителях.
Дело в том, что раз в полгода-год я делаю архивные дубликаты на пару переносных своих ЖД, один просто по юсб врубается, второй ещё к сети подключать надо. Архив на стационарнике, там ХР уже более 8 лет работает безукоризненно превосходно, хотя ЖД уже показывает неисправимые ошибки секторов. Но т.к. у меня занято менее 100 гб из терры, то я продолжаю, разумеется, сделав дубликаты, пользоваться стационаром, просто продолжая наводить порядок. Ещё процентов 30-40, и я добьюсь своего идеалистического порядочка во всём! А даже с подпорченными уже секторами ЖД ещё лет 10 может отработать, но гарантий нет, посему, имея дубликаты, буду пока что продолжать его эксплуатировать до своего абсолютного максимума (покамест проработал немногим более 2 лет по часам).
Возник вопрос. Почему общий размер данных в цифрах не совпадает, ведь, казалось бы, сего быть не должно? То, что на диске размер иной, это я читал о ячейках, ок. Но сам по себе просто размер - отчего всюду разнится? Всего моего компьютерного имущества, на данный момент, каких-то 96 гб. В сравнении я просто одну папку не затронул, которую уже продолжил и далее обновлять, наводя порядок.
Ежели это косяки системы, то хотелось бы узнать, в чём они проявляются и, быть может, общий вес стоит смотреть какой-то иной специальной программой, или он действительно немного будет всюду отличаться?
То, что на D - это на ЖД стационара. Другие две - это уже внешние ЖД. Хотелось бы разобраться, идеалисты такие идеалисты. хотят всё понимать до мелочей.
Контрабасист-солист, композитор, иногда пишу стихи.
. на разных носителях.
Дело в том, что раз в полгода-год я делаю архивные дубликаты на пару переносных своих ЖД, один просто по юсб врубается, второй ещё к сети подключать надо. Архив на стационарнике, там ХР уже более 8 лет работает безукоризненно превосходно, хотя ЖД уже показывает неисправимые ошибки секторов. Но т.к. у меня занято менее 100 гб из терры, то я продолжаю, разумеется, сделав дубликаты, пользоваться стационаром, просто продолжая наводить порядок. Ещё процентов 30-40, и я добьюсь своего идеалистического порядочка во всём! А даже с подпорченными уже секторами ЖД ещё лет 10 может отработать, но гарантий нет, посему, имея дубликаты, буду пока что продолжать его эксплуатировать до своего абсолютного максимума (покамест проработал немногим более 2 лет по часам).
Возник вопрос. Почему общий размер данных в цифрах не совпадает, ведь, казалось бы, сего быть не должно? То, что на диске размер иной, это я читал о ячейках, ок. Но сам по себе просто размер - отчего всюду разнится? Всего моего компьютерного имущества, на данный момент, каких-то 96 гб. В сравнении я просто одну папку не затронул, которую уже продолжил и далее обновлять, наводя порядок.
Ежели это косяки системы, то хотелось бы узнать, в чём они проявляются и, быть может, общий вес стоит смотреть какой-то иной специальной программой, или он действительно немного будет всюду отличаться?
То, что на D - это на ЖД стационара. Другие две - это уже внешние ЖД. Хотелось бы разобраться, идеалисты такие идеалисты. хотят всё понимать до мелочей.
Парадоксально: несмотря на развитие технологий и возросшие объёмы памяти смартфонов, на современный гаджет вы можете установить приложений меньше, чем несколько лет назад. Хватит это терпеть! Разбираемся в причинах и ищем методы борьбы с раздутыми программами.
Размер десяти самых популярных приложений на iOS за 5 лет вырос в 9 раз
Согласно статистике, собранной компанией Sensor Tower, пять лет назад набор из 10 наиболее популярных приложений для платформы iOS занимал всего 200 МБ. Сегодня они же весят уже больше 1,8 ГБ. Их аппетит вырос в невероятные девять раз, в то время как минимальный объём внутренней памяти новых iPhone — всего в четыре раза (с 16 до 64 ГБ). Программы увеличились по-разному: если Spotify «растолстела» всего в шесть раз, то Snapchat — в рекордные 51. И дело не только в гигабайтах. Разросшиеся приложения начинают тормозить. Почему так происходит? Есть несколько причин.
Причина 1. Метрики и трекинг
Казалось бы, новые функции — это всегда хорошо. Так и есть, когда речь идёт о новых возможностях для пользователей. Но с каждым днём в приложениях появляется всё больше кода, реализующего сомнительную функциональность. Любая программа для заказа бургеров отслеживает, сколько времени вы провели в том или ином разделе, сколько раз нажали на определённую кнопку, и даже записывает экран во время работы. За желание разработчиков знать о нас всё мы с вами расплачиваемся не только снижением приватности и мобильным трафиком, но и сокращением свободного места в памяти смартфона.
График времени, проведённого пользователем в разных разделах приложения, построенный на основе внутренних метрик
Причина 2. Лишние ресурсы
С предыдущим пунктом тесно связано дублирование ресурсов: в крупных фирмах над разными частями приложения трудятся разные люди, использующие одни и те же файлы для модулей. При подготовке релизных версий об этом просто-напросто забывают. Как результат — 40 МБ «избыточного веса» в клиенте Facebook. Компания время от времени чистит установочные пакеты от мусорных файлов, но эта музыка будет вечной, а батареек у них хватит надолго.
Внутренняя структура приложения Facebook в апреле 2017 года с указанием дублированных ресурсов
На удивление нерационально реализована работа с ресурсами в приложениях для iOS: в файлы программ (.ipa) попадают иконки сразу для всех устройств, начиная от iPod Touch и заканчивая iPad Pro. В то же время в Android принято добавлять всего один набор графики для всех аппаратов, который затем будет отмасштабирован для разных разрешений и размеров экранов. Чтобы улучшить ситуацию, Apple пару лет назад представила технологию App Thinning — она позволяет гаджетам скачивать только необходимый набор графики. Однако описанная ситуация нередко встречается и сейчас.
Сравнение размеров универсального приложения для iOS (серый столбец) и программ, собранных под конкретные устройства
Причина 3. Неоптимальный код
Существует распространённое выражение, известное во множестве вариаций: «железо стоит дешевле времени разработчика». К сожалению, это действительно так. Пользователь рано или поздно купит новый смартфон, куда установят ещё более мощный процессор и ещё больше памяти. Так зачем вкладывать усилия в качество кода, когда «и так схавают»?
Главный бич современной разработки прикладного ПО — сторонние повторно используемые подпрограммы и «костяки» приложений (библиотеки и фреймворки). Само собой, в них как в инструментах, облегчающих написание кода, нет ничего плохого. Но нередко бывает, что программа тянет библиотеку весом несколько мегабайт ради единственной функции. А если таких функций и, соответственно, библиотек много? Это разработчикам для iPhone хорошо — у них новые релизы iOS приходят разом на все аппараты, вышедшие за последние годы. А в Android актуальных версий системы всегда по нескольку штук, и приложения должны уметь работать со всем этим зоопарком. Код, обеспечивающий совместимость, отнюдь не добавляет программе «лёгкости».
Диаграмма распределения версий Android на конец октября 2018 года
В мире iOS тоже не всё гладко: переход на язык программирования Swift увеличил объём тех же программ в три-четыре раза. Виноваты не только внутренние особенности языка (большие типы данных по умолчанию, увеличенный размер стандартных библиотек, дополнительные тесты и проверки, попадающие в финальную версию). Сыграла злую шутку и лень разработчиков, которые не хотят задумываться о выборе правильных типов данных и других методах оптимизации.
Сравнение размеров шаблонных приложений для iOS на языках Swift и Objective-C
Причина 4. Бесполезные функции
Неприятная тенденция последних лет — появление огромного количества «велосипедов». Вместо стандартных возможностей, предоставляемых системой, разработчики добавляют такие же, но собственные — например, браузеры или фотогалереи. И если есть настройка «Открывать ссылки в браузере», то спрятана она далеко в меню. А стоит в каждый мессенджер встроить по веб-просмотрщику или камере — и никакой памяти в смартфоне не хватит.
Ещё один популярный тренд: производители стремятся сделать из программ комбайны и добавляют в них новые функции, которые почему-то считают очень полезными. Пользователи-то думают иначе: зачем, скажем, файловому менеджеру «ES Проводник» диспетчер задач, анализатор SD-карты и аудиоплеер? Или вот бенчмарк AnTuTu: он не только получил целый набор дополнительных тестов, которыми почти никто не пользуется, но ещё и надоедает виджетом в панели уведомлений, пока не отключишь его вручную.
Слева — «ES Проводник», справа — AnTuTu
Причина 5. Рост требований к приложениям
Технический прогресс стремителен. Уже свершился переход на 64-битные чипсеты, а рост разрешений экранов и не думает останавливаться — куда-то же нужно девать возросшие процессорные мощности? И если с переходом на архитектуры большей разрядности размер программ изменился единовременно и сравнительно немного, то дальнейшее увеличение ppi в смартфонах сделает приложения заметно крупнее. Проблема не возникла бы при рациональном использовании ресурсов, но это, как мы уже выяснили, не всегда бывает так.
Все размеры иконок, необходимые для поддержки iOS-устройств
Как усмирить разжиревшие приложения
Увы, мы не в силах заставить разработчиков писать качественный код и тратить время на оптимизацию. Однако пара способов увеличить объём свободной памяти всё-таки есть.
Перенос приложений на карту памяти. Если ваш смартфон оснащён специальным слотом, вы можете установить карточку microSD и использовать её для хранения программ. Процесс переноса приложений в Android не изменялся с незапамятных времён. Достаточно найти нужное в настройках и нажать кнопку «Перенести на карту памяти» или «Изменить место хранения» (в зависимости от модели гаджета).
Несмотря на то, что карты памяти бывают весьма вместительными, у способа есть ряд недостатков. Некоторые программы в принципе не могут быть перенесены (за это отвечают их создатели), а какие-то после переноса теряют часть функциональности или начинают работать нестабильно. Можно обойти ограничения, применив опцию объединения внутренней и внешней памяти в Android, но тогда не получится использовать карту в других устройствах, а её извлечение запросто лишит вас части установленных приложений.
Использование веб-версий. Изрядная часть привычных нам приложений — не более чем веб-клиенты сайтов. Сюда относятся среди прочего клиенты социальных сетей и приложения вроде YouTube. Понятно, что нативные программы обычно имеют большую функциональность. Но если вы готовы от неё отказаться (предположим, вам не нужны мгновенные уведомления из соцсети), то браузер станет вполне неплохим вариантом.
Использование облегчённых приложений. «Ожирение» некоторых программ уже настолько велико, что владельцы бюджетных смартфонов попросту не могут ими нормально пользоваться — не только из-за большого объёма, но и медленной работы. Поразительно, но многие разработчики решили не оптимизировать существующие программы, а сделать их облегчённые версии. Сначала речь шла только о собственных инициативах создателей (так появилось приложение Facebook Lite), но затем Google представила Android Go — сборку операционной системы для недорогих устройств. Помимо общей оптимизации Android Go открывает в Google Play доступ к облегчённым версиям более чем полусотни популярных программ как от самой Google, так и от сторонних компаний.
Google Maps Go почти не отличается от обычного приложения, но занимает в памяти смартфона считаные килобайты и использует Chrome в качестве движка
Если же на вашем гаджете установлена обычная версия Android, то загрузить Go-версии приложений можно вручную из apk-файлов. Найти их удастся, например, на нашем форуме.
Совсем недавно в интернете появилось несколько интересных инфографик, о том, что популярные приложения для телефонов за пару лет выросли в размере в 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, по которой на конкретный телефон скачивается адаптированная версия приложения без избыточных ресурсов для других версий телефонов.
Идея материалов этого цикла появилась после того, как меня попросили проанализировать приложение «Мой МТС». Приложение вроде бы не очень сложное, а объем вызывал искреннее недоумение. Основным потребителем места тогда оказалась банальная реклама – в виде изображений и видео. Но случаи, как известно, бывают разные. Поэтому посмотрим, что еще может занимать драгоценные мегабайты внутри apk-файлов.
Как получить APK
Как ни банально звучит, но для этого его необходимо скачать. Например, установить приложение из Google Play. Но после этого потребуется получить установленный APK. Самый простой способ для этого – файловый менеджер (например, ES Проводник) или другая утилита, умеющая передавать установленные приложения (например, ShareIT).
Но если хочется странного, то можно скопировать APK через TWRP или даже попробовать скачать APK через плагин к браузеру. При этом важно удостовериться, что архитектура пакета будет ARM, а не x86 (хотя, если интересен анализ пакета для x86, то наоборот – эта архитектура и нужна).
Как смотреть
APK представляет собой zip-файл, его можно просто переименовать и распаковать. Или воспользоваться инструментом «Analyze APK» из Android Studio. В этом случае сразу будет виден размер папок, и можно будет понять, что стоит детально проанализировать, а на что можно не обращать внимания.
Что значат папки
- assets и res/raw – бинарные ресурсы (там может быть что угодно, что для приложения выглядит просто как некий произвольный «файл»).
- lib – нативные библиотеки (на С++), скомпилированные для определенной архитектуры (ARM, x86).
- res/drawable* и res/mipmap* – изображения . Если в имени папки присутствует *dpi, то это изображения для указанного dpi (подробнее о dpi см. в статье «Почему большие устройства на самом деле маленькие»).
- res/layout – схемы экранов.
- classes.dex – скомпилированное приложение вместе с библиотеками на Java.
Конечно, в APK можно найти еще много разных файлов (а в папке res – много разных типов ресурсов), но основные здесь перечислены.
«Пожиратели» мегабайт
В случае с приложением «Мой МТС» все оказалось просто: больше всего объема уходит на банальную рекламу в виде картинок и видео.
Но бывают и другие «пожиратели» мегабайт:
- Внутренние справочники тех или иных данных. В том же приложении «Мой МТС» справочник тарифов занимает 4,6 Мб.
- Библиотеки. Например, разработчик приложения решил подключить для чатов библиотеку Hyphenate. И не посмотрел, что по умолчанию предлагается вариант с кодеками для голосовых звонков и видеовызовов. В итоге приложение получает в нагрузку несколько десятков мегабайт.
- Графика. Однажды я помогал дизайнеру участвовать в конкурсе компании Samsung. Разрабатываемое приложение представляло собой офлайн-справочник, довольно простой с точки зрения разработки (немного анимаций да простое перелистывание страниц), но очень насыщенный графикой. Было нарисовано больше сотни изображений в разрешении QHD. После одной из промежуточных версий (включавшей в себя далеко не все изображения) стало понятно, что приложение получается слишком большим. И было принято решение ограничить графику разрешением HD. Оценка результата на целевом планшете (Galaxy Tab S) дизайнера устроила, а объем при этом был уменьшен почти в 4 раза.
Что дальше?
Я планирую сделать несколько выпусков в этой рубрике. И в каждом выпуске рассматривать несколько приложений (либо от одного производителя, либо одной тематики) и рассказывать, чем в каждом конкретном случае обусловлен большой объем приложений.
Совсем недавно в интернете появилось несколько интересных инфографик ( 1 , 2 ), о том, что популярные приложения для телефонов за пару лет выросли в размере в 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 , по которой на конкретный телефон скачивается адаптированная версия приложения без избыточных ресурсов для других версий телефонов
Читайте также: