Отрисовка экранов мобильного приложения под Android (Material Design)

Material Design 3: почему вёрстка расходится с макетом

Макет в Material Design 3 — это не картинка, а набор правил: цветовые роли, типографическая шкала, шаг сетки, состояния компонентов. Пока экран живёт в редакторе, всё сходится. Расхождение начинается там, где отрисовка экранов Android воспроизводит только «идеальное» состояние элемента, а остальные дорисовывает по интуиции.

Состояния кнопок и полей — первое место разрыва. У поля ввода есть покой, фокус, заполненное значение, ошибка, недоступность; у кнопки — покой, нажатие, удержание, недоступность, ожидание ответа. Если в макете нарисован только покой, разработчик подбирает оттенки и толщины обводок сам, и на живом экране подсказка об ошибке выглядит иначе, чем в прототипе.

Второе — отступы. Дизайнер выравнивает по оптическому центру, инженер — по числовому значению. Без общей шкалы кратности и без размерных токенов, привязанных к ролям, между блоками появляются разъезжающиеся зазоры, а заголовок «плывёт» относительно подписи.

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

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

Единая библиотека компонентов: что это ускоряет

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

Скорость сборки нового экрана

Библиотека на Material Design 3 — это компоненты с заранее описанными состояниями: цвета, типографика и отступы берутся из одного источника, а не подбираются под каждый макет. Новый экран собирается из готовых блоков: у нас типовой раздел каталога или профиля проходит путь от макета до сборки за 1-2 дня вместо недели, а правок по вёрстке после проверки становится примерно втрое меньше — меняется один компонент, а не десять его копий.

Единый набор состояний

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

Для сроков выпуска это даёт предсказуемость: обновление с новым разделом уходит в релиз за один цикл, а не растягивается на несколько итераций согласования вёрстки.

Способы отрисовки экранов: сравнение подходов

Способ отрисовки определяет не внешний вид, а то, какие требования платформы закрываются готовыми средствами, а какие команда тянет на себе годами. Ниже — четыре варианта отрисовки интерфейса, между которыми реально выбирают на старте или при переписывании экранов под ограничения платформы Android.

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

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

Этапы внедрения: от аудита экранов до передачи команде

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

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

2. Схема компонентов. Сводим повторы к базовому набору: кнопка, поле ввода, карточка, список, диалог, навигационная панель. Для каждого описываем состояния — обычное, нажатое, недоступное, загрузка, ошибка — и правила вложенности с отступами, чтобы новые экраны собирались без изобретательства.

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

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

5. Поэтапная замена на живых экранах. Не переписываем приложение целиком: переносим экран за экраном, релизы продолжают выходить, а откат на предыдущую сборку остаётся возможным.

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

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

Результаты работ: библиотека компонентов и документация

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

• Библиотека компонентов для Android — кнопки, поля ввода, карточки, списки, диалоги, навигация и состояния загрузки собраны в отдельный модуль. Экран собирается из готовых блоков, поэтому один и тот же элемент не расходится по отступам и поведению на разных экранах.
• Тема оформления приложения — цвета, типографика, скругления, тени и шаг сетки вынесены в общие наборы значений поверх Material Design 3. Смена оттенка бренда или плотности интерфейса делается в одном месте и расходится по всем экранам сразу.
• Правила состояний элементов — для каждого компонента зафиксировано, как он выглядит и ведёт себя в покое, при нажатии, в фокусе, в загрузке, при ошибке и при недоступности данных. Это убирает разнобой, из-за которого одинаковые списки на разных экранах реагируют по-разному.
• Документация по интерфейсу — каталог компонентов с примерами использования, ограничениями и антипримерами: где блок применять нельзя и чем его заменить.
• Регламент правок вёрстки — порядок изменения общего компонента: кто согласует, как оценивается влияние на уже выпущенные экраны, в каких случаях правка уходит в отдельный блок, а не в общий.
• Инструкции для команды — как поднять проект, где лежат значения темы, как добавить экран по шаблону и какие проверки проходят перед выпуском.

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

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

До: каждый экран собирали заново

Продукт с еженедельным релизом и несколькими командами в одной кодовой базе. Каждый новый экран верстался с нуля: отступы, радиусы, состояния кнопок и подсветка полей при ошибке задавались заново. Сборка типового экрана занимала 3–4 дня, и примерно половина времени уходила на выравнивание по макету после первой проверки. Дизайн-проверка стабильно возвращала 12–15 расхождений на экран, а уже после релиза приходили повторные правки.

После: общая библиотека компонентов

Мы описали повторяющиеся элементы один раз — темы, токены цвета и типографики, состояния компонентов: обычное, нажатое, загрузка, ошибка, пустой список. Основой взяли актуальную ветку Material Design 3, чтобы сетки и поведение совпадали у всех команд. Сборка нового экрана превратилась в композицию готовых блоков и заняла 1–1,5 дня. Расхождений с макетом на проверке осталось 2–4, и почти все — про паттерны, которых в библиотеке ещё не было.

Что изменилось по метрикам

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

Material Design или своя дизайн-система: что выбрать

Выбор сводится к тому, кто платит за отрисовку. Material Design даёт готовые компоненты, состояния нажатия и фокуса, светлую и тёмную тему, поведение при жестах и доступность — это уже отлажено, и команда не тратит недели на переизобретение.

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

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

Ограничения платформы и частые сомнения по вёрстке

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

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

Нужен ли отдельный макет под тёмную тему?

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

Что входит в доступность интерфейса?

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

Что произойдёт при обновлении платформы?

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

Обсудим задачу: что нужно от вас для старта

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

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

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