Экспорт PDF ассетов для iOS: где ломается отрисовка
Растровая иконка хранится в фиксированной сетке пикселей, а экраны различаются плотностью. Один и тот же файл, растянутый под другой масштаб, интерполяция размывает: края теряют резкость, тонкие штрихи сливаются, и на части устройств получаются мыльные иконки на разных экранах. Поэтому подготовка графики для iOS начинается не с нарезки, а с выбора формата хранения.
Ручная нарезка размеров закрывает это лишь внешне. Дизайнер отдаёт несколько кратностей на каждый значок, множители пересчитываются вручную, а добавление одной иконки повторяет весь цикл. Изменилась толщина линии в макете — сетка пересобирается заново, и расхождение между кратностями ловят уже на живом устройстве.
Вес сборки приложения при таком подходе растёт линейно от числа кратностей. Один и тот же символ лежит в дистрибутиве несколько раз, каталог ассетов разрастается, а новых экранов не появляется. Экспорт PDF ассетов снимает оба ограничения: векторный контур хранится один раз и рендерится под нужную плотность экрана на месте. Иконка остаётся резкой и на компактном, и на крупном дисплее, а в проекте лежит одно исходное изображение вместо набора файлов.
Ниже разбираем, где именно ломается отрисовка при переносе вектора в каталог, как настраивается правило рендеринга и какие огрехи исходного контура всплывают уже после сборки.
Что меняется после перехода на векторные наборы графики
Раньше каждая иконка жила в проекте набором растровых нарезок под разные плотности экрана: отдельно для компактных устройств, отдельно для крупных. Замена одной детали означала новый экспорт всего набора, риск забыть размер и рассинхрон между макетом и приложением. С векторными наборами графики единый исходник иконки — PDF в каталоге ассетов, а нужные масштабы система строит сама при отрисовке.
Отсюда стабильная отрисовка интерфейса: вектор не «мылится» и не обрезается на дробных масштабах, одинаково выглядит на текущих и будущих устройствах. Заодно уходит целый класс дефектов вёрстки — разъехавшиеся отступы после правки макета, разные версии одного элемента на соседних экранах, потерянная резкость у мелких пиктограмм.
Снижение веса сборки — следствие того же порядка. Вместо четырёх-пяти растровых файлов на элемент остаётся один компактный вектор, и на большой библиотеке иконок это заметная доля артефакта, а хранилище исходников перестаёт разрастаться копиями под каждый размер.
Мы держим правило разделения: вектор — для иконок, пиктограмм и линейной графики, растр — для фотографий и сложных эффектов с тенями и режимами наложения, которые в PDF передаются непредсказуемо. Дизайнеры отдают исходники из Figma уже в нужном формате, а сборка проверяет каталог на битые и лишние элементы — расхождения видны до релиза, а не в готовом приложении.
Способы подготовки графики: сравнение рабочих вариантов
Когда макет строится из иконок и простых форм, способ хранения графики определяет, сколько весит сборка и сколько ручной работы уйдёт на каждое изменение. Вектор, набор растровых размеров и отрисовка кодом дают одинаковый результат на экране, но расходятся в поддержке: один вариант переживает смену плотностей без новых файлов, другой — нет.
Что выбирают на практике
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Вектор в каталоге ассетов | Иконки, логотипы, линейная графика, элементы, которые масштабируются под любую плотность | Не тянет фотореализм, мягкие тени, растровые текстуры и сложные градиенты — растеризуется на этапе сборки, а не при запуске |
| Набор растровых размеров | Фото, скриншоты, иллюстрации с шумом и полупрозрачностью | Каждая новая плотность — отдельный файл и отдельная выгрузка; вес сборки растёт кратно числу вариантов |
| Отрисовка кодом | Простые формы, индикаторы, элементы, меняющие цвет и размер по состоянию | Ограничена возможностями отрисовки; сложную форму дублировать кодом дороже, чем один раз выгрузить исходник |
Разница проявляется на правках: в векторном варианте меняется один исходник, растр требует пересобрать всю линейку размеров, а код — синхронизировать форму с макетом вручную. Поэтому смешанный набор — норма: вектор для иконок, растр для контента, код для динамических элементов.
Этапы внедрения: от аудита исходников до передачи
Порядок работ выстроен так, чтобы дефекты графики находились на ранних шагах, где правка занимает часы, а не превращается в повторную сборку релиза. Сначала фиксируем текущее состояние каталога, затем задаём правила и только после этого запускаем пакетную конвертацию.
Порядок работ
- Аудит каталога ассетов. Инвентаризируем исходники, отмечаем дубли, устаревшие состояния кнопок и элементы без прозрачного фона. На выходе — карта: что уходит в вектор, что остаётся растром и почему.
- Схема именования графики. Задаём единый формат имён по роли элемента, размеру и состоянию, чтобы дизайнер и разработчик обращались к одному и тому же ресурсу. Это убирает ручной поиск и рассинхрон между макетом и кодом.
- Конвертация в вектор. Переводим подходящие элементы в PDF с сохранением слоёв и прозрачности, убираем лишние поля. Каталог перестаёт хранить несколько растровых копий под разные размеры экрана.
- Проверка на устройствах. Прогоняем ключевые экраны на реальных аппаратах разных поколений: смотрим резкость при увеличении, точность цветов и поведение в тёмной теме.
- Регламент обновления графики. Описываем, как добавлять элементы, кто отвечает за конвертацию и какие проверки проходят до релиза.
- Передача. Отдаём проект, схему именования и короткую инструкцию, чтобы команда дальше работала с графикой без нас.
Что передаём на руки: каталог, схемы и регламенты
Передача графики — это не папка с картинками, а комплект, по которому команда воспроизводит сборку без устных договорённостей. Ниже — что именно уходит заказчику вместе с приложением и по каким документам потом живёт графика.
- Собранный каталог ассетов. Векторные PDF-исходники, разложенные по наборам с корректными масштабами и режимами отрисовки; сборка берёт графику прямо из него, без промежуточных выгрузок и ручной подстановки файлов.
- Структура каталога. Дерево папок по модулям и назначению, с разделением общих и экранных ресурсов: видно, что можно менять, не задевая остальные экраны.
- Правила именования. Единая схема вида «назначение_состояние_масштаб», запрет на пробелы и разный регистр, защита от дублей — имена совпадают с именами в макетах, и поиск ресурса занимает секунды.
- Схема связей экранов и графики. Карта, где отмечено, какой ресурс используется на каких экранах, — перед правкой сразу видно радиус изменений.
- Документация по графике. Палитра, сетки и отступы, размеры активных зон, состояния кнопок и полей, правила тёмной темы: разработчик не восстанавливает это по макету.
- Инструкция для дизайнеров. Как выгружать вектор, какие слои объединять, как проверять контуры и заливки, что сверить перед передачей в сборку.
- Регламент добавления иконок. Кто инициирует, через какую ветку идёт правка, кто проверяет, как обновляется каталог ассетов и как вернуться к предыдущей версии графики.
Комплект закрывает типовой риск: дизайн уходит на сторону или меняется подрядчик, а графика продолжает собираться по документу, а не по памяти конкретного человека.
Кейс: убрали размытые иконки и ускорили сборку
Что было до
Клиент — сервис доставки с приложением на iOS. В наборе ресурсов лежало около 60 иконок и иллюстраций, каждая выгружалась в пяти размерах под разные плотности экрана — больше 280 файлов, связанных с кодом вручную. Правка одного значка означала повторный экспорт всего набора, а на новых дисплеях часть картинок выглядела размытой: растянутый растр давал неровные края и замытые скругления.
Что изменили
Перевели графику в вектор: один PDF-файл на элемент, итоговый размер система подбирает сама при отрисовке. В настройках набора включили сохранение векторных данных и режим, при котором иконка остаётся резкой на любой плотности. Дизайнеры отдают по одному файлу вместо пяти — Xcode собирает из них единый каталог без ручной привязки каждого размера.
Метрики до и после
- Файлов в наборе: 280+ → 60, один источник правды на иконку.
- Время сборки приложения на сборочном сервере: сократилось примерно на треть — из обработки ушли сотни лишних копий ресурсов.
- Обращения по дефектам отрисовки: с 10–12 в месяц до 1–2, и те не про графику.
- Правка иконки: одна замена файла вместо пяти экспортов и ручной сверки связей.
Через месяц после перехода команда клиента убрала отдельный этап выгрузки графики из релизного процесса. Освободившееся время ушло на функциональность, а не на разбор артефактов и повторные проверки на устройствах.
Чем отличается PDF-контур от растрового набора при масштабировании?
PDF-контур хранит геометрию: линии, кривые, заливки и порядок их наложения. Фиксированной сетки точек в нём нет, поэтому при масштабировании система пересчитывает форму под нужный размер и только затем отрисовывает её. Иконка попадает в целевое число точек — а не получается растягиванием соседнего варианта.
Растровый набор размеров устроен иначе: это заранее нарезанные картинки под каждую кратность плотности экрана. Пока запрошенная плотность совпадает с заготовкой, резкость иконок идеальная. Но на промежуточном режиме — увеличенный системный масштаб, нестандартный размер интерфейса — подходящего файла нет, и берётся ближайший. Интерполяция размывает края, тонкие обводки и мелкие детали сливаются.
Вес — следствие той же природы данных. Контур обслуживает все плотности одним файлом: новый экран не увеличивает пакет. Растровый набор растёт линейно, каждая кратность лежит отдельной копией, и вырезание лишних вариантов — компромисс между весом и резкостью на конкретных устройствах.
У контура тоже есть цена: он отрисовывается на устройстве, а мягкие тени, градиенты и полупрозрачность при векторизации ведут себя непредсказуемо — и часто их всё равно переводят в растр. Отсюда смешанная практика: простая геометрия, логотипы и значки интерфейса выигрывают от контура, фотореалистичные иллюстрации стабильнее в растровом наборе. Проверять стоит на всех плотностях, которые поддерживает приложение.
Технические сомнения: разбираем частые вопросы
Тонкие линии, иконки и тёмная тема — то, на чём чаще всего спотыкается перевод графики в векторный PDF. Ниже — вопросы, которые задают до старта работ, и наши ответы по каждому.
Почему на тонких линиях появляются артефакты?
Линии тоньше экранного пикселя растеризуются при отрисовке. Мы задаём обводки в векторных единицах и проверяем результат при разных масштабах — контуры остаются ровными.
У нас уже есть растровые наборы — всё переделывать?
Нет. Каталог расширяется поэтапно: сначала переводим иконки, где масштабирование заметнее всего, остальные наборы работают рядом и снимаются по мере готовности.
Как графика ведёт себя в тёмной теме оформления?
Нужны отдельные варианты: автоматическая инверсия ломает многоцветные иконки. Собираем обе версии в одном наборе, система подставляет нужную без участия кода.
Многоцветные иконки переживут масштабирование?
Да, если каждый цвет заведён отдельным слоем, а не смешан в один контур. Тогда оттенки не «плывут» на крупных размерах — частая причина возвратов на доработку.
Чьи исходники нужны для замены графики в каталоге?
Работаем и с исходниками от заказчика, и с макетами в кривых. Если есть только растровые файлы, наши инженеры перерисовывают контуры — это отдельный этап оценки.
Обсудим задачу: вернёмся с оценкой и планом работ
Чтобы оценка объёма работ была предметной, а не приблизительной, для старта хватит доступа к репозиторию или архиву проекта, набора исходников ассетов и списка поддерживаемых устройств и версий системы. Если экспорт уже настроен — покажите текущий путь: как векторный макет превращается в PDF и попадает в каталог ассетов.
Дальше уточним детали: на каком шаге сборки формируются ассеты, кто владеет исходниками, какие требования к масштабированию под разные экраны и как устроен релизный цикл. Отдельно проговорим откат — что происходит с иконками и изображениями, если сборку вернут на предыдущую версию.
- оценку объёма работ по этапам: инвентаризация ассетов, настройка экспорта, проверка на целевых устройствах;
- план внедрения с порядком шагов и точками, где нужна обратная связь вашей команды;
- состав работ с границей ответственности: что закрываем мы, что остаётся на стороне ваших разработчиков;
- схему каталога ассетов и правила именования, чтобы новые макеты ложились в него без ручной правки;
- перечень проверок: как убедиться, что PDF-ассеты корректно собираются и отображаются на всех конфигурациях;
- вариант поэтапного запуска, если релиз нельзя останавливать на время перестройки;
- срок по каждому этапу и требования к доступам, которые понадобятся на старте.
Опишите задачу в свободной форме — со ссылкой на проект или примером проблемного ассета. Вернёмся с оценкой и планом работ, а спорные места разберём на созвоне с инженером, который будет вести проект.
