Подготовка ассетов Android: где ломается графика в релизе
Самая частая поломка в релизе — один мастер из макета, растянутый системой под конкретный экран. Разработчик кладёт картинку в единственную папку, и на крупном флагмане или планшете иконка приходит размытой: система интерполирует растр вверх. Обратная ситуация — в проект сложили файл под каждый класс плотности, и вес сборки приложения вырос в разы без единого нового экрана.
Android выбирает ресурс по классу плотности — от mdpi до xxxhdpi — и при промахе берёт ближайший и масштабирует. Отсюда и расхождения между макетом и тем, что видит пользователь: сдвинутые отступы, обрезанные края, другая толщина обводки. Адаптивная иконка android добавляет свой слой проблем: передний и задний планы лежат отдельно, и логотип вне безопасной зоны срезается маской лаунчера на части устройств.
Вес и чёткость лечатся одним правилом — как именно ассет попадает в проект. Вектор — для иконок, элементов интерфейса и простых форм, растровые форматы с плавающим качеством — для фото и сложных текстур, а классы плотности генерируются из одного мастер-файла, а не рисуются руками под каждый экран. Тогда графика резкая везде, а сборка не тащит пять копий одного файла.
Разбираем, как закрывается подготовка ассетов Android: какие проверки ставим на макеты до вёрстки, как настраиваем генерацию из мастер-файла и куда смотрим, когда макет расходится с реальным экраном.
Что даёт управляемый набор ассетов мобильному приложению
Плотности экранов кратны базовой: mdpi, hdpi, xhdpi, xxhdpi и xxxhdpi — это шаг 1×, 1.5×, 2×, 3× и 4×. Графика собирается один раз по этим коэффициентам, поэтому на любом устройстве иконка, иллюстрация и фон попадают в свой слот без интерполяции на стороне системы — изображение остаётся резким, а пропорции и отступы не разъезжаются. Общий источник истины для палитры, скруглений и толщины линий держит единый стиль интерфейса; ту же логику масштабирования описывает Material Design.
Разница проявляется в артефактах сборки. Растровая иконка, разложенная по пяти каталогам, весит ровно в пять раз больше одной копии — этот вес уходит в вес apk и aab, а вместе с ним растёт время сборки релиза и размер обновления, которое скачивает пользователь. Отдельно считаем долю отказов установки: чем крупнее пакет, тем чаще прерывается загрузка на слабой связи.
Оптимизация графики приложения начинается с отказа от растра там, где нет фото и градиентов: векторные иконки, растягиваемые фоны под разный контент, современный формат сжатия для фотоматериалов. Сжатие изображений без потери качества проверяем сравнением с эталоном на контрольных экранах, а не «на глаз», и только после этого закрепляем коэффициент в правилах сборки.
Правки оформления стоят одной правки исходника, а не синхронного обновления пяти копий: макет меняется быстрее, релиз собирается предсказуемее, визуальная проверка сводится к нескольким эталонным разрешениям.
Способы работы с графикой: варианты и ограничения
На Android ресурс подбирается под плотность экрана: система сама берёт подходящую копию, и от того, какие варианты мы положили, зависит резкость иконки на плотном экране и вес сборки на остальных. Ошибка видна пользователю сразу — «мыло» на кнопках или приложение, которое растёт быстрее, чем его функциональность.
Универсального способа нет: фото живёт только в растре, иконки выгоднее держать вектором, массовые элементы дешевле нарезать автоматически. Ниже варианты, между которыми реально выбирают.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Векторная графика в приложении | иконки, схемы, простые иллюстрации | не тянет фото и сложные текстуры, тяжёлые сцены нагружают отрисовку |
| Растровые наборы (mdpi–xxxhdpi) | фотоконтент, детальные иллюстрации | пять копий на ресурс, вес сборки растёт, копии расходятся при правках |
| Автоматическая нарезка изображений | серии однотипных иконок из мастер-макета | нужен аккуратный исходник, на мелких плотностях видны артефакты уменьшения |
| Ручная подготовка макетов | ключевые экраны с пиксельной точностью | дорого по времени, тяжело сопровождать при редизайне |
| Адаптивная вёрстка ресурсов | разные экраны, вырезы, тёмная тема | сложнее конфигурация, нужна проверка на реальных устройствах |
На практике подходы комбинируют: вектор — для интерфейса, растр — для контента, автоматизация — для массовых наборов. Мы задаём правило по умолчанию для проекта и проверяем результат на матрице экранов, чтобы резкость и вес не расходились с ожиданиями дизайна.
Этапы внедрения: от инвентаризации до передачи команде
Прежде чем резать графику, собираем полную картину: где лежат исходники, кто их обновляет, какие экраны уже расходятся по плотностям. Порядок шагов фиксирован — пропущенная инвентаризация оборачивается неполной схемой и мутными изображениями на части устройств при первом же обновлении.
- Аудит графических ресурсов. Сверяем макеты с тем, что реально лежит в проекте: находим дубли, растянутые растровые копии, иконки, нарисованные под одну плотность, и картинки в общем каталоге без разбивки.
- Схема нарезки ресурсов. Определяем набор плотностных каталогов (от mdpi до xxxhdpi), правила именования и то, что отдаётся вектором, а что растром — вектор закрывает масштабирование и убирает лишние копии.
- Настройка сборки ресурсов. Подключаем автоматическую генерацию наборов из мастер-файлов: новая иконка больше не появляется вручную в пяти каталогах и не теряется при слиянии веток.
- Оптимизация веса. Пережимаем растры, убираем неиспользуемые файлы и следим, чтобы размер поставки не рос с каждой итерацией дизайна.
- Проверка на устройствах. Прогоняем ключевые экраны на аппаратах с разной плотностью и диагональю: смотрим обрезку, размытие, артефакты масштабирования и время установки сборки.
- Передача документации. Отдаём команде карту ресурсов, правила именования, конфигурацию сборки и регламент добавления новой графики — обновление перестаёт быть ручной операцией.
Наборы графики, правила нарезки и регламенты передачи
Готовый комплект графики — это не папка с картинками, а структура, которую сторонняя команда разворачивает без переписки и уточнений. Передаём её вместе с правилами: что где лежит, как называется каждый файл и что делать, когда макет обновился. Ниже — перечень артефактов, которые заказчик получает на руки.
- Структура каталогов ресурсов: наборы разложены по плотностям — от mdpi до xxxhdpi, отдельно общие и тематические группы. Новая графика ложится в свою ветку, а не расползается по корню проекта.
- Правила именования файлов: только латиница, нижний регистр, префикс по экрану и суффикс по плотности и состоянию — обычное, нажатое, недоступное. Имя файла само объясняет назначение, без захода в макет.
- Карта ресурсов: таблица «элемент интерфейса → файл → где используется». По ней любой элемент находится за минуту, а не поиском по всему каталогу.
- Векторные и тянущиеся элементы: иконки и фоны отдаём в редактируемом виде, растровые копии остаются только там, где нужна фактура. Это снимает пересборку под новые разрешения.
- Регламент обновления графики: кто инициирует пересборку, какие плотности пересобираются, как проверяется, что устаревшие наборы удалены, а не лежат рядом с новыми.
- Документация по ресурсам: назначение комплекта, лимиты по числу и массе файлов на экран — сборка перестаёт расти от релиза к релизу.
- Исходники и мастер-файлы: слои, направляющие, текст без растеризации. Любая правка делается по мастеру, без потери качества и повторной отрисовки.
До передачи комплект проходит приёмку по этому же списку: проверяем, что каждый элемент из макета имеет файл во всех плотностях и что имена совпадают с документацией. Опишите задачу — вернёмся с оценкой и планом подготовки графики под ваш релизный цикл.
Кейс: убрали размытие на крупных экранах и лишний вес
Перед нами был интерфейс, который на планшетах и крупных флагманах выглядел откровенно мягким: под графику лежал один набор растровых картинок, и система растягивала его до нужной плотности уже в момент отрисовки. Параллельно каждый экран тянул собственные полноразмерные файлы, часть из которых не использовалась вообще.
Что сделали
- Разложили графику по пяти наборам плотности — mdpi, hdpi, xhdpi, xxhdpi и xxxhdpi, — чтобы система брала готовый файл нужного масштаба, а не считала его на ходу.
- Иконки, индикаторы и линейные элементы перевели в вектор: они перестали зависеть от плотности экрана совсем.
- Растягиваемые фоны и кнопки собрали в девятисегментные картинки — вместо десятка отдельных изображений под каждое состояние.
- Прописали правила экспорта прямо в макетах Figma, чтобы новые экраны не возвращали проблему.
- Вычистили дубли и неиспользуемые файлы, оставив на каждый логический ресурс ровно один исходник.
Результат
Вес приложения упал с 68 до 41 МБ — почти на 40%, хотя наборов графики стало больше. Размытие на крупных экранах ушло полностью: масштабирование из растра больше не выполняется. Сборка ресурсов перестала быть самой долгой частью релиза, а дизайнеры отдают макет по одному набору правил вместо переписки с разработкой.
Чем векторная графика отличается от растровой в проекте
Растр хранит готовые пиксели, вектор — геометрию и правила её отрисовки. Пока изображение выводится в исходном размере, разницы не видно, но при масштабировании графики растр интерполируется и контуры теряют резкость, а вектор пересчитывается под нужную плотность экрана.
Для Android выбор формата — это всегда компромисс между резкостью на разных экранах и весом приложения:
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Вектор | Иконки, элементы интерфейса, простые иллюстрации | Плохо переносит сложные градиенты, тени и текстуры — графику приходится упрощать |
| Растровый WebP | Фотографии, сложные иллюстрации, текстурные фоны | Теряет резкость при увеличении, вес растёт вместе с размером |
| PNG с набором копий под плотности | Скриншоты, графика с прозрачностью и точной пиксельной привязкой | Одно изображение — это несколько файлов: растёт репозиторий и время сборки |
Правило простое: иконки и иллюстрации уходят в вектор, фотоматериал и текстуры остаются растром. Смешение форматов вслепую даёт либо размытые элементы на крупных экранах, либо лишние сотни килобайт в сборке на каждый размер.
Мы фиксируем это правило в регламенте проекта и проверяем на этапе сборки: лишние растровые копии не попадают в приложение, а иконки не разрастаются в несколько файлов на каждую плотность.
Технические сомнения, которые стоит снять до старта
До старта разработки заказчик задаёт один и тот же набор вопросов: что будет с графикой на разных телефонах, можно ли поправить оформление, не выпуская новую версию, и как быть, если исходных макетов не осталось. Пересмотра архитектуры ни один из них не требует, но каждый влияет на объём подготовки ассетов и на сроки. Ниже — короткие ответы, чтобы снять сомнения до оценки.
Хватит ли одного набора графики на все экраны?
Нет. Система растянет картинку под нужную плотность, но на плотных матрицах это даст размытые края, а на бюджетных моделях — лишний вес сборки. Поэтому собираем наборы под пять диапазонов плотности, от базового до самого высокого: иконки и фоны остаются резкими, а установочный файл не растёт без пользы.
Можно ли поменять графику, не выпуская новую версию?
Часть оформления — да: баннеры, промо-блоки и сезонные подборки выносим в удалённый набор ресурсов, он меняется на стороне сервера. Иконка, экран запуска и элементы навигации остаются внутри сборки. Перечень того и другого фиксируем до старта, чтобы потом не выяснилось, что нужный блок нельзя обновить без публикации.
У нас нет исходных макетов — только скриншоты
Логотип переводим в вектор, крупные элементы масштабируем, мелкие детали и полупрозрачные слои перерисовываем по сетке. Объём такой работы зависит от того, что сохранилось, — оцениваем его после просмотра материалов.
Тёмная тема — это второй комплект графики?
Нет, если цвета собраны на семантических токенах: один набор изображений перекрашивается палитрой, векторные иконки переиспользуются без правок. Переключение между темами работает без перерисовки и мерцания при смене системной настройки.
Обсудим задачу: что прислать для оценки объёма работ
Плотности экранов — главный источник неочевидного объёма: одна иконка превращается в пять наборов, а иллюстрация в баннере — в отдельную экспортную ветку. Чтобы оценка объёма работ опиралась на факты, а не на догадки, нужны исходники и перечень экранов, где эти ассеты живут. Ниже — минимальный набор входных данных; по нему мы считаем трудозатраты и возвращаемся с планом работ по графике.
- Исходники в векторе или слоях: мастер-файлы иконок, логотипов, иллюстраций — с раздельными слоями, а не «сплющенными» копиями.
- Перечень плотностей: нужны ли mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi полностью или где-то достаточно двух-трёх наборов.
- Список экранов и состояний: где ассет появляется, в каком размере, с какими вариантами — нажатие, выключено, загрузка, ошибка.
- Иконка приложения и системные элементы: основной значок, адаптивный и круглый варианты, фон с передним слоем, картинка для магазина.
- Требования к форматам: прозрачность, WebP или PNG, допустимый вес файла и потеря качества при сжатии.
- Тёмная тема, дополнительные темы оформления и языковые версии — если макетов больше одной.
- Референсы и дизайн-система: палитра, сетка, отступы, уже собранные экспорты — чтобы не пересобирать то, что работает.
Для обсуждения задачи достаточно описать продукт и прислать то, что уже есть. Пробелы в списке не блокируют оценку — недостающие входные данные мы уточняем вопросами и выносим отдельным пунктом в план работ.
