Експорт SVG для мобільних застосунків: де втрачається якість
Дизайнер віддає іконку, вивантажену з редактора як є, — і вона перестає збігатися із сіткою. Причина зазвичай у монтажній області: файл несе фіксовану ширину й висоту замість viewBox, координати шляхів приходять із чотирма знаками після коми, а сама група піднята над полотном.
Під час вбудовування така іконка обрізається то праворуч, то знизу й стає в розмітці на півпікселя повз сусідні елементи.
Втрата якості графіки рідко пов’язана із самим форматом.
Вектор ламають обведення, які під час масштабування перетворюються на волосяну лінію; текст, залишений текстовим блоком і потребує шрифту, якого немає на пристрої; растрові вставки всередині файлу; маски, фільтри й розмиття, які частина платформ не відтворює. Усе це випливає на збірці, а не в макеті, тому й виявляється пізно.
Темна тема — окрема точка відмови. Іконка з жорстко прописаним темним заповненням на темному тлі стає невидимою, а світла плашка всередині неї ламає композицію.
Закривається це не другим набором файлів, а заповненням, що успадковує колір інтерфейсу, і узгодженою товщиною обведень.
Третя стаття витрат — вага збірки застосунку. У файлах залишаються приховані шари, службові метадані редактора, невикористані обрізки; під час об’єднання кількох десятків іконок в один набір повторюються ідентифікатори, і частина платформ мовчки відмальовує не ту форму.
Тому підготовка іконок перетворюється на регулярний процес: єдина сітка, нейтральний колір заповнення, вичищення зайвих контурів і автоматична перевірка на розбіжності під час кожного оновлення набору, а не разове ручне вивантаження.
Нижче розбираємо, як вибудувати цей процес так, щоб результат не залежав від акуратності окремого дизайнера.
Що змінюється після чистої підготовки векторної графіки
Чистка починається з інвентаризації: що реально йде у збірку — метадані редактора, приховані шари, дублювальні групи, невикористані визначення, дробові координати.
Оптимізатор на кшталт SVGO знімає більшу частину автоматично, але частина правок залишається ручною — інакше спрощення з’їдає впізнаваність іконки на малих розмірах. Після стиснення кількість вузлів у дереві шляхів падає у 2-3 рази, а набір графіки у збірці — на 40-60%.
Другий ефект — адаптивна графіка. Коли в іконки немає жорстко прописаних розмірів, а пропорції тримає єдина сітка, вона однаково чітко малюється і на компактному екрані, і на планшеті, і за системного збільшення шрифту.
Растрові копії під окремі роздільні здатності не потрібні — збірка не зростає з кожною новою щільністю екрана.
Третій шар — продуктивність інтерфейсу й стабільність рендерингу. Менше шляхів — швидший перший показ екрана, плавніші переходи й анімації, холодний запуск віддає графіці помітно менше часу.
Частка відмов рендерингу — зникла іконка, чорний квадрат замість значка, зірвана анімація на слабкому пристрої — прямує до нуля: у макеті не залишається структур, які платформи підтримують по-різному.
Правило просте: вектор перевіряють до того, як він потрапив у макет, а не після збою в релізі. Тоді вага, швидкість і передбачуваність графіки видно у звіті збірки, а не у відчуттях.
Оптимізація SVG: геометрія, палітра та обведення
Експорт із графічного редактора майже завжди віддає більше, ніж потрібно: вкладені групи, приховані шари, службові метадані й обведення різної товщини.
На боці застосунку це перетворюється на зайву вагу збірки й на іконки, які за однієї й тієї самої ролі виглядають по-різному — частина контурів тонша, частина зміщена на частки сітки, частина не перефарбовується під час зміни теми.
Різниця між варіантами підготовки — не в акуратності виконання, а в тому, як набір поводиться, коли продукт розширюється.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Прямий експорт із редактора | Разові іконки та ранній прототип | Метадані, вкладені групи й різні товщини обведень ідуть у збірку |
| Ручне чищення контурів | Невеликий набір і є дизайнер у команді | Години на кожну іконку; правки повторюються під час кожного оновлення |
| Автоматична оптимізація скриптом | Десятки іконок із різних джерел | Знижує вагу, але не вирівнює геометрію: сітка й товщина залишаються різними |
| Єдиний набір із палітрою та обведеннями в кривих | Набір живе й зростає разом із продуктом | Потрібна дисципліна: правила фіксуються, нові іконки проходять перевірку |
Оптимізація SVG упирається в обмеження на боці застосунку: обведення доводиться переводити в криві, інакше рендер залежить від реалізації й іконка «пливе» на різних платформах, а палітра зводиться до короткого набору кольорів — тоді тема перемикається заміною однієї змінної, без другого комплекту файлів.
Тому чищення контурів і палітра іконок робляться один раз як правило, а не як разове прибирання перед релізом.
Як ми готуємо графику: етапи інженерної роботи
Порядок робіт однаковий і для нового застосунку, і для проєкту, який розвивається роками: спочатку фіксуємо, що вже лежить у репозиторії, потім змінюємо, і тільки потім передаємо правила команді. Так графику можна правити без страху, що роз’їдеться верстка або загубиться частина іконок.
- Аудит графіки. Рахуємо всі векторні файли в проєкті, позначаємо дублі під різними іменами, вбудовані растрові картинки всередині вектора, іконки без єдиного стилю. Підсумок — карта набору з переліком проблем по кожному екрану.
- Схема іменування. Іконка отримує ім’я за роллю в інтерфейсі, розмірною групою та темою оформлення. Це прибирає правки «на око» й конфлікти під час злиття гілок.
- Чищення файлів. Прибираємо приховані шари, порожні групи, вбудовані зображення й стилі, обрізаємо полотно за фактичним рисунком. Файл зменшується в рази, вигляд не змінюється.
- Конвеєр збірки ресурсів. Оптимізація й приведення до єдиного вигляду запускаються автоматично під час додавання файлу, а не руками. На виході — готові варіанти під темну тему та різні щільності екрана.
- Перевірка іконок. Прогін по наборах екранів і станів елемента: заповнення, обведення, поведінка під час перефарбовування, оптичні розміри. Помилки спливають до релізу, а не за скаргами користувачів.
- Передача регламенту. Правила іменування, вимоги до вихідників, порядок впровадження й команда збірки описуються коротко й однозначно. Нова іконка проходить той самий шлях без участі розробника.
Комплект передачі: вихідники, правила, регламент оновлень
Комплект передачі — це не архів із картинками, а робочий набір правил: за ним ваш дизайнер або сторонній підрядник додасть іконку, не ламаючи верстку й не перепитуючи нас.
Збираємо його так, щоб будь-яка правка графіки була передбачуваною операцією, а вихідники у Figma залишилися у вашому акаунті, а не тільки в нашому.
- Очищені вихідники: у кожного файлу знято зайве — приховані шари, метадані редактора, вкладені маски, дублювальні обведення. Залишається контур, який однаково відтворюється і розміткою, і векторним рушієм платформи.
- Структура папок проєкту: ресурси розкладено за модулями та щільностями екрана, імена папок збігаються з іменами екранів у макетах — новий файл потрапляє на очевидне місце.
- Правила іменування ресурсів: схема «модуль_функція_стан», лише нижній регістр, без пробілів і трансліту; за іменем файлу відразу зрозуміло, де він використовується.
- Карта відповідності: таблиця «вихідник → ресурс у застосунку → екран», за нею потрібна правка знаходиться за хвилину, а не за годину пошуків у коді.
- Регламент оновлення графіки: описано, хто, коли і в якому вигляді надсилає нові іконки, як узгоджується заміна і що відбувається зі старими наборами.
- Перевірки під час збірки: контроль валідності розмітки, розміру й дублів — битий або роздутий ресурс падає на збірці, а не в релізі.
- Версіонування набору: попередній комплект іконок можна повернути без перезбирання макетів, відкат не перетворюється на окрему задачу.
Регламент оновлення — найбільш недооцінений пункт: без нього за пів року в проєкті сусідять три різні стилі однієї й тієї самої іконки, і кожна нова правка коштує дедалі дорожче. Комплект закриває це заздалегідь — графіка перестає бути вузьким місцем під час передачі задач.
Кейс: як чищення вектора скоротило вагу збірки
До: як накопичувалася вага
До нас прийшов застосунок із великим каталогом: набір іконок і дрібних ілюстрацій збирався роками, і кожен реліз додавав свіжі експорти з макетів у Figma.
Файли тягнули за собою вкладені групи, приховані шари, обведення, обрізані маски й вбудований растр — на частині екранів це давало видимі артефакти й зайву роботу під час рендерингу.
Заміри до роботи: набір графіки важив більше, ніж уся інша графіка застосунку разом узята, розділ каталогу відкривався помітно довше за сусідні, а частка звернень до підтримки про кривий рендеринг — зрізані краї, розмиті контури, поїхала геометрія — трималася на рівні кожного четвертого.
Після: що змінилося у збірці
Розбір показав, що причина не в самому векторі, а в тому, як він потрапляє у збірку.
Ми зафіксували єдине правило експорту: одна іконка — одна група без вкладеності, криві в спільному контейнері, обведення переведені в заповнення, зайві вузли зрізані, растрові вставки або векторизовані, або винесені окремим ресурсом.
Поверх поставили перевірку, яка не пропускає файл із прихованими шарами, вкладеними масками або іменем поза шаблоном.
Вага ресурсів скоротилася приблизно в шість разів, каталог відкривається нарівні з іншими розділами, звернення щодо кривого рендерингу зійшли до поодиноких випадків.
Побічний ефект виявився важливішим за самі цифри: нова іконка додається одним експортом без ручної правки, а розмір збірки перестав зростати від релізу до релізу.
Що робити, якщо графіка вже розійшлася по збірках
Якщо набір іконок уже розійшовся по збірках, переписати його одним заходом не можна: на пристроях у користувачів живуть попередні версії застосунку, і вони продовжують запитувати старі імена ресурсів. Задача розпадається на дві незалежні — розчистити вихідники й не зламати вже випущений застосунок.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Чистити лише нові іконки | Верстка стабільна, релізи рідкі | Борг накопичується, дублі залишаються в наборі |
| Поступова заміна з аліасами | Застосунок оновлюється регулярно | Потрібен шар сумісності й урахування часток версій |
| Повна заміна у великому релізі | Старих активних версій майже немає | У частини користувачів графіка «стрибне» між екранами |
| Тримати два набори паралельно | Триває зміна візуального стилю | Зростає вага збірки, довший прогін перевірок |
Робоча схема — поступова заміна: нові іконки додаємо під новими іменами, старі залишаємо як посилання на них. Шар сумісності знімаємо, коли частка встановлень на версіях без оновлення падає нижче узгодженого порога, — зазвичай це два-три релізи.
Обмеження тут не в самих файлах, а в кеші й вазі збірки: поки живуть обидва набори, застосунок важчий, а скриншотні перевірки доводиться ганяти на обох гілках інтерфейсу.
Сумісність перевіряємо на матриці версій, які ще тримають користувачі, — тоді розчищення не перетворюється на регрес на живих установках.
Порядок робіт вибираємо за даними з пристроїв: спочатку дивимося, які версії ще активні, потім фіксуємо графік видалення старих імен. Так набір розходиться по збірках керовано, а не залишається «як є» на роки.
Технічні сумніви: формати, сумісність, строки
Заперечення щодо графіки зводяться до трьох пунктів: чи переживе вектор старі версії системи, як віддавати растровий резерв, і що буде з іконками у випущеному застосунку. Розбираємо, як кожен закривається на рівні збірки й правил видачі ресурсів.
Ми не переводимо візуальний шар наосліп. Фото, текстури й складні ефекти залишаються растровими; інтерфейсні іконки, індикатори, логотип і схеми йдуть у контури. На виході — два набори ресурсів і правило вибору за версією системи та щільністю екрана.
Вектор не відмалюється на старих версіях системи — застосунок зламається?
Ні, якщо резервний набір передбачено заздалегідь. Растрові версії тих самих елементів збираються в потрібних щільностях і підключаються за умовою: стара версія системи отримує підготовлений набір, нова — вектор. Обидва варіанти перевіряємо на матриці реальних пристроїв.
Скільки займає заміна набору іконок у живому застосунку?
Зазвичай один-два цикли випуску, без заморожування решти роботи. Ресурси змінюються адресно: інвентаризація й чищення вихідників, експорт, підключення, прогін інтерфейсу та перевірка розміру збірки. Екрани переписувати не потрібно, якщо структура набору зберігається.
Чи не втратимо якість під час зміни формату графіки?
Вектор не втрачає чіткість — контури, градієнти й маски не залежать від щільності екрана. Прибрати потрібно вбудовані растрові вставки: вони додають вагу й артефакти під час масштабування. Тому перед передачею в проєкт іде чищення — зайві групи, приховані шари, невикористані визначення.
Обговоримо задачу: надішліть набір іконок і макет
Щоб обговорити задачу предметно й дати оцінку робіт, а не вилку «від і до», потрібен вхідний набір. Чим повніші вихідники, тим менше припущень у кошторисі й тим менше правок на етапі, коли застосунок уже збирається, а графіка йде в реліз.
- Іконки та ілюстрації у векторних вихідниках — файл Figma, Illustrator або Sketch, а не експорт SVG площинами, де фігури втратили імена й зв’язки.
- Перелік екранів і місць, де трапляється графіка: нижня навігація, статуси, порожні стани, онбординг, темна тема.
- Стани кожної іконки — звичайний, активний, неактивний, натиснутий, — якщо вони відрізняються візуально.
- Правила іменування й структура папок, ухвалені в проєкті, або дозвіл запропонувати свої, щоб імена збігалися з кодом.
- Як графіка потрапляє у збірку зараз: вручну, через спільний репозиторій або бібліотеку компонентів.
- Обмеження: де потрібна анімація, де іконка зобов’язана збігатися на обох платформах, де допустимі відмінності.
- Контакт дизайнера або розробника, який відповість на уточнення щодо шарів, масок і груп.
Розбір займає небагато часу: наші інженери дивляться, де у вихідниках залишилися приховані шари, зайві обведення й маски, як влаштовані заповнення і що з цього потрапить у вагу застосунку.
За підсумками повертаємо оцінку робіт, план підготовки графіки з порядком кроків — нормалізація імен, чищення, оптимізація, перевірка на зібраній збірці, — склад команди й дату старту проєкту.
