WWDC 2015: Apple уменьшила приложения

Астрологический прогноз на май 2024 года

Stellar Blade оскорбила игроков, игра от авторов Don’t Starve, новые правила рефанда в Steam…

Конец ретроградного Меркурия: знаки зодиака, которые окажутся неуязвимыми перед проблемами с 25 апреля

WWDC 2015: Apple уменьшила приложения
🕑 14.06.2019 Общее 👀 45 просмотров

Если бы пользователи iOS-устройств обращали внимание на “всякую ерунду”, они были бы шокированы: начиная с осени 2015 года приложения для iOS стали вдруг худеть. Как если бы в Apple появилось подразделение магов, не иначе.

Но пользователи, как правило, до цифровой прозы не опускаются. Особенно владельцы устройств с 128 или 256 Гигабайтами флэш-памяти. Apple именно этого и добивалась, в течение многих лет. Компанию (еще во времена первых Mac’ов) критиковали за глупое потакание пользователям, утверждая что пользование Mac’ами отупляет.

Но по-настоящему серьезные проблемы у Apple начались в 1995 году, когда Microsoft создала что-то очень похожее на систему Mac’ов и назвала это Windows 95. Mac’и все еще были лучшими, но неизбалованным отупляющим Mac’овским интерфейсом пользователям PC было все-равно.

Кстати, вам не кажется что пользователи и в самом деле отупели за последние годы? Уж не Mac’и ли виноваты в этом? Сегодня не это наша тема, увы. Как-нибудь?

Операционная система (любая) – это, по сути, огромное приложение, состоящее из кода и ресурсов, в особо крупных размерах. Это миллионы строк нетривиального исходного кода, и много всякой всячины разного назначения. Мода на похудение коснулась и iOS.

iOS 8 “весила” 4,6 Гигабайта. Это была совершенная ОС, отвечающая требованиям своего времени, в чем-то даже лучшая в мире, гигантский размер объясним и понятен.

iOS 9 не уступала предшественнице по части функциональных возможностей, наоборот – она умела работать с еще большим разнообразием устройств, при этом для её установки требовалось всего от 1,3 до 1,8 Гигабайта флэш-памяти.

Магия?

Продолжение мини-серии про WWDC 2015, предыдущие части здесь:

Первая часть: WWDC 2015: Никаких сенсаций;
Вторая часть: WWDC 2015: Назад, к Mac, iPhone и iPad.

Откуда “лишний вес”?

iOS-приложение – это исполняемый код и ресурсы. В частности, графические файлы. Их, как правило, очень много. Графика добавляет приложению яркости и выразительности, а чтобы чего-то достичь эти качества абсолютно необходимы.

Разработчики графических форматов (таких как JPEG, PNG или TIFF) вложили немало сил в разработку алгоритмов сжатия изображений, но когда их сотни (а то и десятки тысяч), места в флэш-памяти устройства они занимают много. Чем “тяжелее” приложение, тем больше времени (и трафика) требуется на его загрузку.

С появлением Retina-дисплеев графические файлы в iOS-приложениях стали занимать в разы большие пространства памяти. Совместимость с Retina-дисплеями – это добавление в ресурсы приложения графических файлов с 2-кратной высотой и шириной. Естественно они намного тяжелее 1-кратных. В зависимости от разрешения устройства на котором запускалась программа, использовались либо 1-кратные, либо 2-кратные варианты.

Размер исполняемого кода тоже рос как на дрожжах: чтобы приложение работало на всех устройствах способных работать в заявленных при отправке в App Store версиях iOS, кода требовалось в несколько раз больше, чем прежде.

Код и графика были не единственными “пожирателями памяти”, были и другие: аудио, видео, все что угодно. Код для Open GL ES, код для Metal и тому подобное.

Надо было что-то делать, и к этому что-то уже готовились. В iOS 7 появились Image Assets (Asset переводится как “актив”), для графических файлов с определенными именами (в строках) для разной кратности разрешения (в столбцах). По запросу из приложения возвращались файлы нужного разрешения,

Скорее всего, предпринимались и другие меры по подготовке решительных перемен. Тем временем, для iPhone 6 Plus потребовались графические файлы 3-кратного размера. В том же, естественно, количестве что и 1- и 2-кратных. Только еще более тяжелых.

Проблема стала нестерпимой.

Как решать эту проблему?

Я видел (примерно в то же самое время) как подобная проблема решалась в одном из Store одного из ведущих производителей телефонов и планшетов для Android. Не скажу какого, мы работали с несколькими. Store, также как и “яблочный” App Store, тщательно проверял предлагаемые ему приложения, а среди требований было ограничение на размер сборки, в разы меньшее чем размер приложения которое уже не первый год размещалось в Google Play.

В документации нашелся и ответ, по сути “делайте что хотите”. Размещайте все ресурсы на своем сервере, и загружайте их оттуда, по мере необходимости, когда приложение будет установлено на устройстве. Так и поступили.

На сервере компании место было, без нервотрепки не обошлось, но его нам выделили.

Едва ли не самая типичная реакция на инновации Apple: “это уже делали до них, много раз, ничего нового они не придумали”. Но в том-то и дело что, как правило, главный вопрос не “что?” а “как?”.

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

Путь Apple – правильно делать правильные вещи (Гай Кавасаки)

Решение Apple было частью iOS 9. Решений было несколько, большую часть трудозатрат Apple брала на себя.

Разработчик, как и прежде, отправлял на проверку и размещение в App Store программу с полным набором всех ресурсов, необходимых ей для нормальной работы на всех типах iOS-устройств.

При установке приложения на устройство пользователя, автоматически, с участием LLVM, из приложения удалялось все что на целевом устройстве не понадобится.

Устанавливался только исполняемый код соответствующий целевому устройству, и только графические файлы требуемого размера. Из тех которые размещались в Image Assets. Все это делало программное обеспечение App Store.

К Image Assets в iOS 9 добавили Data Assets, для размещения любых ресурсов для разных типов устройств. С ними поступали точно также. Кроме разрешения экрана для выбора какие именно ресурсы устанавливать использовались самые разные критерии: объем оперативной памяти, тип графического процессора и другие.

В зависимости от технических возможностей устройства на которое устанавливалось приложение, App Store автоматически выбирал нужное.

В распоряжении разработчика было еще одно средство: установка приложения по частям, с последующей загрузкой (из App Store) других частей – по запросу приложения. А когда доступной памяти становилось слишком мало, части которые дольше не использовались удалялись (на устройстве). По запросу приложения удаленная часть возвращалась на её место.

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

На WWDC в качестве примера приводила игра с несколькими уровнями. Скорее всего, при установке приложения будет установлен первый уровень, когда возникнет потребность во втором уровне, по запросу приложения, будет загружен и установлен второй. При острой нехватке памяти первый уровень (поскольку его не использовали дольше) будет удален, но по первому же требованию App Store его восстановит.

Продолжение следует

Обсудить историю Apple вы можете в нашем Telegram-чате.

👍 0 👎 0