Експорт 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-асети коректно збираються і відображаються на всіх конфігураціях;
- варіант поетапного запуску, якщо реліз не можна зупиняти на час перебудови;
- термін за кожним етапом і вимоги до доступів, які знадобляться на старті.
Опишіть задачу у вільній формі — з посиланням на проєкт або прикладом проблемного асета. Повернемося з оцінкою та планом робіт, а спірні місця розберемо на дзвінку з інженером, який вестиме проєкт.
