Comments 5
В разделе «Графический контент» большая часть советов в лучшем случае бессмысленны, а некоторые даже вредны.
Во-первых, для устройств с iOS 9 и выше работает App slicing. iTunes Connect пересобирает загруженный архив в несколько вариантов для разных устройств. Таким образом, например, iPhone 6 при установке из апп стора будет тянуть только @2x ресурсы, а iPad mini 1 — только @1x. Поэтому если продукт поддерживает iOS 9+, то прислушивание к совету об оставлении только 3x ресурсов будет иметь строго обратный эффект — для айфонов+ ничего не изменится, а вот устройства с меньшим разрешением будут вынуждены тянуть себе 3x ресурсы, тогда как могли обойтись 2x или 1x.
Во-вторых — совет о переводе растровых изображений в вектор также не имеет смысла. Единственное, что вы таким образом можете сэкономить — это место на компьютере разработчиков. Xcode растеризирует векторные изображения при сборке билда, в чем несложно убедиться, к примеру, отмасштабировав «векторную» картинку на устройстве и увидев дико пикселизированное растровое изображение. Я не спорю, векторные ресурсы — это удобно: проще экспортировать дизайнерам, не нужно следить чтобы при изменении ресурса остались «синхронизированными» все его версии разных разрешений и т.п. Но перевод существующих растровых картинок в вектор именно с целью уменьшения размера билда не имеет никакого смысла.
Да, если приложение выпускается для старых версий iOS, а вектор — это не pdf-ки, кинутые в asset catalog, а формат, который парсится и отрисовуется своими силами и своим кодом, то да, эти советы могут быть полезными. Но в статье об этих «границах применимости» ни слова.
Во-первых, для устройств с iOS 9 и выше работает App slicing. iTunes Connect пересобирает загруженный архив в несколько вариантов для разных устройств. Таким образом, например, iPhone 6 при установке из апп стора будет тянуть только @2x ресурсы, а iPad mini 1 — только @1x. Поэтому если продукт поддерживает iOS 9+, то прислушивание к совету об оставлении только 3x ресурсов будет иметь строго обратный эффект — для айфонов+ ничего не изменится, а вот устройства с меньшим разрешением будут вынуждены тянуть себе 3x ресурсы, тогда как могли обойтись 2x или 1x.
Во-вторых — совет о переводе растровых изображений в вектор также не имеет смысла. Единственное, что вы таким образом можете сэкономить — это место на компьютере разработчиков. Xcode растеризирует векторные изображения при сборке билда, в чем несложно убедиться, к примеру, отмасштабировав «векторную» картинку на устройстве и увидев дико пикселизированное растровое изображение. Я не спорю, векторные ресурсы — это удобно: проще экспортировать дизайнерам, не нужно следить чтобы при изменении ресурса остались «синхронизированными» все его версии разных разрешений и т.п. Но перевод существующих растровых картинок в вектор именно с целью уменьшения размера билда не имеет никакого смысла.
Да, если приложение выпускается для старых версий iOS, а вектор — это не pdf-ки, кинутые в asset catalog, а формат, который парсится и отрисовуется своими силами и своим кодом, то да, эти советы могут быть полезными. Но в статье об этих «границах применимости» ни слова.
Спасибо за ценный комментарий, хоть я и не являюсь автором статьи. Больше бы таких в жизни! Зачастую в комментариях больше ценности, чем в самих статьях.
Тем не менее автору статьи отдельное спасибо!
Тем не менее автору статьи отдельное спасибо!
Очень верно подмечено, что в разделе графического контента описан способ экономии места для проекта, а не конечного приложения, что не особо имеет смысл.
А еще есть такая вещь как On Demand Resources хотя это подобие подгрузки с сервера, но я думаю это заслуживает как минимум отдельного раздела.
Привет из 2024; приложение сбербанк онлайн весит 600 мб
Sign up to leave a comment.
Уменьшаем размер приложения: проверенные способы