Подготовка и чистка SVG для мобильных приложений

Экспорт SVG для мобильных приложений: где теряется качество

Дизайнер отдаёт иконку, выгруженную из редактора как есть, — и она перестаёт совпадать с сеткой. Причина обычно в монтажной области: файл несёт фиксированную ширину и высоту вместо viewBox, координаты путей приходят с четырьмя знаками после запятой, а сама группа поднята над холстом. При встраивании такая иконка обрезается то справа, то снизу и встаёт в разметке на полпикселя мимо соседних элементов.

Потеря качества графики редко связана с самим форматом. Вектор ломают обводки, которые при масштабировании превращаются в волосную линию; текст, оставленный текстовым блоком и требующий шрифта, которого нет на устройстве; растровые вставки внутри файла; маски, фильтры и размытия, которые часть платформ не воспроизводит. Всё это вылезает на сборке, а не в макете, поэтому и находится поздно.

Тёмная тема — отдельная точка отказа. Иконка с жёстко прописанным тёмным заполнением на тёмном фоне становится невидимой, а светлая плашка внутри неё ломает композицию. Закрывается это не вторым набором файлов, а заливкой, наследующей цвет интерфейса, и согласованной толщиной обводок.

Третья статья расходов — вес сборки приложения. В файлах остаются скрытые слои, служебные метаданные редактора, неиспользуемые обрезки; при объединении нескольких десятков иконок в один набор повторяются идентификаторы, и часть платформ молча отрисовывает не ту форму. Поэтому подготовка иконок превращается в регулярный процесс: единая сетка, нейтральный цвет заливки, вычистка лишних контуров и автоматическая проверка на расхождения при каждом обновлении набора, а не разовая ручная выгрузка.

Ниже разбираем, как выстроить этот процесс так, чтобы результат не зависел от аккуратности отдельного дизайнера.

Что меняется после чистой подготовки векторной графики

Чистка начинается с инвентаризации: что реально уходит в сборку — метаданные редактора, скрытые слои, дублирующие группы, неиспользуемые определения, дробные координаты. Оптимизатор вроде SVGO снимает большую часть автоматически, но часть правок остаётся ручной — иначе упрощение съедает узнаваемость иконки на малых размерах. После сжатия число узлов в дереве путей падает в 2-3 раза, а набор графики в сборке — на 40-60%.

Второй эффект — адаптивная графика. Когда у иконки нет жёстко прописанных размеров, а пропорции держит единая сетка, она одинаково чётко рисуется и на компактном экране, и на планшете, и при системном увеличении шрифта. Растровые копии под отдельные разрешения не нужны — сборка не растёт с каждой новой плотностью экрана.

Третий слой — производительность интерфейса и стабильность отрисовки. Меньше путей — быстрее первый показ экрана, отзывчивее переходы и анимации, холодный запуск отдаёт графике заметно меньше времени. Доля отказов отрисовки — пропавшая иконка, чёрный квадрат вместо значка, сорванная анимация на слабом устройстве — уходит к нулю: в макете не остаётся структур, которые платформы поддерживают по-разному.

Правило простое: вектор проверяют до того, как он попал в макет, а не после сбоя в релизе. Тогда вес, скорость и предсказуемость графики видно в отчёте сборки, а не в ощущениях.

Оптимизация SVG: геометрия, палитра и обводки

Экспорт из графического редактора почти всегда отдаёт больше, чем нужно: вложенные группы, скрытые слои, служебные метаданные и обводки разной толщины. На стороне приложения это превращается в лишний вес сборки и в иконки, которые при одной и той же роли выглядят по-разному — часть контуров тоньше, часть смещена на доли сетки, часть не перекрашивается при смене темы. Разница между вариантами подготовки — не в аккуратности исполнения, а в том, как набор ведёт себя, когда продукт расширяется.

Оптимизация SVG упирается в ограничения на стороне приложения: обводки приходится переводить в кривые, иначе рендер зависит от реализации и иконка «плывёт» на разных платформах, а палитра сводится к короткому набору цветов — тогда тема переключается заменой одной переменной, без второго комплекта файлов. Поэтому чистка контуров и палитра иконок делаются один раз как правило, а не как разовая уборка перед релизом.

Как мы готовим графику: этапы инженерной работы

Порядок работ одинаков и для нового приложения, и для проекта, который развивается годами: сначала фиксируем, что уже лежит в репозитории, потом меняем, и только затем передаём правила команде. Так графику можно править без страха, что разъедется вёрстка или потеряется часть иконок.

1. Аудит графики. Считаем все векторные файлы в проекте, отмечаем дубли под разными именами, встроенные растровые картинки внутри вектора, иконки без единого стиля. Итог — карта набора с перечнем проблем по каждому экрану.
2. Схема именования. Иконка получает имя по роли в интерфейсе, размерной группе и теме оформления. Это убирает правки «на глаз» и конфликты при слиянии веток.
3. Чистка файлов. Убираем скрытые слои, пустые группы, встроенные изображения и стили, обрезаем холст по фактическому рисунку. Файл уменьшается в разы, вид не меняется.
4. Конвейер сборки ресурсов. Оптимизация и приведение к единому виду запускаются автоматически при добавлении файла, а не руками. На выходе — готовые варианты под тёмную тему и разные плотности экрана.
5. Проверка иконок. Прогон по наборам экранов и состояний элемента: заливки, обводки, поведение при перекраске, оптические размеры. Ошибки всплывают до релиза, а не по жалобам пользователей.
6. Передача регламента. Правила именования, требования к исходникам, порядок внедрения и команда сборки описываются коротко и однозначно. Новая иконка проходит тот же путь без участия разработчика.

Комплект передачи: исходники, правила, регламент обновлений

Комплект передачи — это не архив с картинками, а рабочий набор правил: по нему ваш дизайнер или сторонний подрядчик добавит иконку, не ломая вёрстку и не переспрашивая нас. Собираем его так, чтобы любая правка графики была предсказуемой операцией, а исходники в Figma остались в вашем аккаунте, а не только в нашем.

• Очищенные исходники: у каждого файла снято лишнее — скрытые слои, метаданные редактора, вложенные маски, дублирующиеся обводки. Остаётся контур, который одинаково отрисовывается и разметкой, и векторным движком платформы.
• Структура папок проекта: ресурсы разложены по модулям и плотностям экрана, имена папок совпадают с именами экранов в макетах — новый файл попадает на очевидное место.
• Правила именования ресурсов: схема «модуль_функция_состояние», только нижний регистр, без пробелов и транслита; по имени файла сразу понятно, где он используется.
• Карта соответствия: таблица «исходник → ресурс в приложении → экран», по ней нужная правка находится за минуту, а не за час поисков по коду.
• Регламент обновления графики: описано, кто, когда и в каком виде присылает новые иконки, как согласуется замена и что происходит со старыми наборами.
• Проверки при сборке: контроль валидности разметки, размера и дублей — битый или раздутый ресурс падает на сборке, а не в релизе.
• Версионирование набора: предыдущий комплект иконок можно вернуть без пересборки макетов, откат не превращается в отдельную задачу.

Регламент обновления — самый недооценённый пункт: без него через полгода в проекте соседствуют три разных стиля одной и той же иконки, и каждая новая правка стоит всё дороже. Комплект закрывает это заранее — графика перестаёт быть узким местом при передаче задач.

Кейс: как чистка вектора сократила вес сборки

До: как накапливался вес

К нам пришло приложение с большим каталогом: набор иконок и мелких иллюстраций собирался годами, и каждый релиз добавлял свежие экспорты из макетов в Figma. Файлы тянули за собой вложенные группы, скрытые слои, обводки, обрезанные маски и встроенный растр — на части экранов это давало видимые артефакты и лишнюю работу при отрисовке.

Замеры до работы: набор графики весил больше, чем вся остальная графика приложения вместе взятая, раздел каталога открывался заметно дольше соседних, а доля обращений в поддержку про кривую отрисовку — срезанные края, размытые контуры, поехавшая геометрия — держалась на уровне каждого четвёртого.

После: что изменилось в сборке

Разбор показал, что причина не в самом векторе, а в том, как он попадает в сборку. Мы зафиксировали единое правило экспорта: одна иконка — одна группа без вложенности, кривые в общем контейнере, обводки переведены в заливки, лишние узлы срезаны, растровые вставки либо векторизованы, либо вынесены отдельным ресурсом. Поверх поставили проверку, которая не пропускает файл со скрытыми слоями, вложенными масками или именем вне шаблона.

Вес ресурсов сократился примерно в шесть раз, каталог открывается наравне с остальными разделами, обращения по кривой отрисовке ушли до единичных случаев. Побочный эффект оказался важнее самих цифр: новая иконка добавляется одним экспортом без ручной правки, а размер сборки перестал расти от релиза к релизу.

Что делать, если графика уже разошлась по сборкам

Если набор иконок уже разошёлся по сборкам, переписать его одним заходом нельзя: на устройствах у пользователей живут прежние версии приложения, и они продолжают запрашивать старые имена ресурсов. Задача распадается на две независимые — расчистить исходники и не сломать уже выпущенное приложение.

Рабочая схема — постепенная замена: новые иконки добавляем под новыми именами, старые оставляем как ссылки на них. Слой совместимости снимаем, когда доля установок на версиях без обновления падает ниже согласованного порога, — обычно это два-три релиза.

Ограничение здесь не в самих файлах, а в кеше и весе сборки: пока живут оба набора, приложение тяжелее, а скриншотные проверки приходится гонять на обеих ветках интерфейса. Совместимость проверяем на матрице версий, которые ещё держат пользователи, — тогда расчистка не превращается в регресс на живых установках.

Порядок работ выбираем по данным с устройств: сначала смотрим, какие версии ещё активны, потом фиксируем график удаления старых имён. Так набор расходится по сборкам управляемо, а не остаётся «как есть» на годы.

Технические сомнения: форматы, совместимость, сроки

Возражения по графике сводятся к трём пунктам: переживёт ли вектор старые версии системы, как отдавать растровый резерв, и что будет с иконками в выпущенном приложении. Разбираем, как каждый закрывается на уровне сборки и правил выдачи ресурсов.

Мы не переводим визуальный слой вслепую. Фото, текстуры и сложные эффекты остаются растровыми; интерфейсные иконки, индикаторы, логотип и схемы уходят в контуры. На выходе — два набора ресурсов и правило выбора по версии системы и плотности экрана.

Сколько занимает замена набора иконок в живом приложении?

Обычно один-два цикла выпуска, без заморозки остальной работы. Ресурсы меняются адресно: инвентаризация и чистка исходников, экспорт, подключение, прогон интерфейса и проверка размера сборки. Экраны переписывать не нужно, если структура набора сохраняется.

Не потеряем ли качество при смене формата графики?

Вектор не теряет чёткость — контуры, градиенты и маски не зависят от плотности экрана. Убрать нужно встроенные растровые вставки: они добавляют вес и артефакты при масштабировании. Поэтому перед передачей в проект идёт чистка — лишние группы, скрытые слои, неиспользуемые определения.

Обсудим задачу: пришлите набор иконок и макет

Чтобы обсудить задачу предметно и дать оценку работ, а не вилку «от и до», нужен входной набор. Чем полнее исходники, тем меньше допущений в смете и тем меньше правок на этапе, когда приложение уже собирается и графика уходит в релиз.

• Иконки и иллюстрации в векторных исходниках — файл Figma, Illustrator или Sketch, а не экспорт SVG плоскостями, где фигуры потеряли имена и связи.
• Перечень экранов и мест, где встречается графика: нижняя навигация, статусы, пустые состояния, онбординг, тёмная тема.
• Состояния каждой иконки — обычное, активное, неактивное, нажатое, — если они отличаются визуально.
• Правила именования и структура папок, принятые в проекте, либо разрешение предложить свои, чтобы имена совпадали с кодом.
• Как графика попадает в сборку сейчас: вручную, через общий репозиторий или библиотеку компонентов.
• Ограничения: где нужна анимация, где иконка обязана совпадать на обеих платформах, где допустимы различия.
• Контакт дизайнера или разработчика, который ответит на уточнения по слоям, маскам и группам.

Разбор занимает немного времени: наши инженеры смотрят, где в исходниках остались скрытые слои, лишние обводки и маски, как устроены заливки и что из этого попадёт в вес приложения. По итогам возвращаем оценку работ, план подготовки графики с порядком шагов — нормализация имён, чистка, оптимизация, проверка на собранной сборке, — состав команды и дату старта проекта.