В попытке уменьшить размер пакета, возможно ли (и хорошая идея) добавлять только изображения @3x?
Чтобы уточнить, я не имею в виду значок приложения, изображение запуска и т.д. Но изображения, которые являются внутренними для приложения, например, фоновые изображения UIButton.
Я видел Разрешение изображения для новых iPhone 6 и 6+, поддержка 3x добавлена?, но это не отвечало на мой вопрос.
Да, вы можете, но не должны.
Если вы добавите только изображения @3x, это уменьшит размер пакета и совместим со всеми плотностями экрана.
Однако я не рекомендую это делать так. Вложение только изображений @3x приведет к тому, что ваши изображения будут уменьшены каждый раз, когда приложение будет запущено. Этот подход имеет следующие недостатки:
Если вы заботитесь о том, чтобы ваши приложения выглядели четкими и четкими на большинстве устройств, я бы настоятельно рекомендовал вам, по крайней мере, экспортировать изображения с изображениями @2x и @3x. В зависимости от требований совместимости проекта я иногда предпочитаю не экспортировать @1x.
Если вы нацелены только на iPhone iOS 7+, то вам определенно не нужно экспортировать @1x. Все устройства iPhone @1x не поддерживают iOS 7+. Единственные устройства, которые вам нужно беспокоиться, - это iPad 2 и iPad mini (без сетчатки).
Еще одно замечание: при исследовании вашего вопроса я слышал слухи, что Apple может отклонить ваши приложения за отсутствие изображений при каждой плотности. Я никогда не испытывал этого. Это правило было единственным, что я смог найти в руководстве разработчика.
2.10 Приложения для iPhone также должны работать на iPad без изменений, при разрешении iPhone и при разрешении 2X iPhone 3GS
Для меня это, по-видимому, подразумевает, что, пока это работает, вы хороши. Но давай, человек, сделай это красивым!
В моем тестировании я обнаружил, что @3x не распознается на iOS 7 и ниже. Поэтому, если вы планируете поддерживать iOS 7 и 8, вы обязательно захотите включить изображения @2x.
Что касается разрешения указанных изображений, я пока не нашел удовлетворительного ответа. Для приложения, над которым я работаю, на примере полноэкранного jpg (скорее всего, фотографии), я бы сэкономил на 1242x2208 для @3x и 750x1334 для @2x, чтобы соответствовать наивысшему разрешению этих изображений на iPhone. Это не идеальное решение для пикселов, так как изображения нужно будет уменьшить на не-iPhone 6 (+), но я думаю, что это хорошая промежуточная площадка, которая не требует слишком большой дополнительной работы, если утверждения диктуют, какое изображение на основе экрана размер (ть) и 5 различных изображений.
Одна вещь, которую следует отметить в отношении производительности, которую приводит dfmuir, заключается в том, что во многих случаях эти изображения будут уменьшаться во многих случаях, 4/4S, 5/5S, 6/6 + в режиме масштабирования изображения, даже если вы идете с яблочным предпочтительным методом включения 3-х изображений в @1x, @2x и @3x, так как теперь у нас есть 5 (или 6 в том числе 3gs) разных разрешений (см. строку рендеринга пикселей в этой таблице для получения дополнительной информации: http://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions)
Единственный способ, которым вы не получаете эти проблемы с фотоподобными изображениями (так что не рассматривайте элементы пользовательского интерфейса), - это то, что вы создаете его так, чтобы ваши изображения были связаны с точками (поэтому оставаясь таким же размером относительно вашего thumb, а не относительно размера экрана телефона), но это не всегда имеет смысл для дизайна приложения. Примером может быть обрезка на телефонах с более низким разрешением, а не на уменьшение.
Следует отметить, что @3x уже отключен устройством. 3 - шкала UIDevice, тогда как экран фактически находится в некотором смысле nativeScale. Таким образом, если аргумент имеет значение, он должен делать правильную работу для других плотностей, а также из @3x.
Конечно, если изображение имеет довольно много острых углов с одним пикселем, сидящим в углах, можно хотеть точно позиционировать его, а не позволять ОС выбирать его с помощью любого непрерывного фильтра, который он будет применять для уменьшение масштаба.