Разрыв между макетом в Figma и реальной версткой на Android может достигать 15-20% по визуальному весу элементов из-за разницы в рендеринге пикселей и плотности DPI. Использование только одного инструмента проверки гарантирует пропуск ошибок в отступах и кликабельных зонах, что ведет к дорогостоящим итерациям правки кода на этапе QA.
Figma Mirror: мгновенный визуал против точности
Figma Mirror — это инструмент быстрой визуальной сверки, который транслирует векторный рендеринг из облака на экран смартфона. Он идеален для проверки цветовых акцентов и общей композиции, но бесполезен для замера точных dp (density-independent pixels), так как Mirror масштабирует макет под разрешение экрана устройства, а не имитирует системный рендеринг Android.
Кейс: при проверке кнопки высотой 48dp на устройстве с высокой плотностью пикселей (xxhdpi), Mirror может визуально «сгладить» границы, создав иллюзию правильного размера. Однако при реальной верстке выясняется, что из-за системных отступов Material Design 3 в Figma кнопка выглядит крупнее, чем должна быть по гайдлайнам. Экспертный вывод: Mirror дает 80% понимания эстетики, но 0% уверенности в технической точности верстки.
Android Emulator: имитация среды и системных ограничений
Эмулятор в Android Studio позволяет загрузить скриншот макета или использовать инструменты инспекции для проверки реального поведения элементов. В отличие от Mirror, здесь мы видим, как интерфейс взаимодействует с системным статус-баром (высотой обычно 24-32dp) и навигационной панелью, которые в Figma часто игнорируются или рисуются «на глаз».
Пример: при создании меню с использованием Auto Layout возникает проблема «обрезанного» контента на экранах с соотношением сторон 20:9. Эмулятор выявляет это сразу, в то время как Mirror на тестовом девайсе с другим соотношением сторон может скрыть проблему. Экспертный вывод: Эмулятор необходим для верификации Safe Areas и проверки того, как элементы ложатся в сетку конкретной версии ОС (например, Android 14).
Методика верификации размеров и отступов
Для достижения точности 99% я использую метод перекрестного замера. Сначала создается создание адаптивных макетов под разные разрешения Android-экранов с помощью Auto Layout, затем макет выводится на Mirror для проверки «ощущения» размера пальца (touch target). Согласно стандартам Google, минимальная зона нажатия должна быть 48x48dp; в Mirror это проверяется субъективно, а в Эмуляторе через Layout Inspector — математически.
Сравнение: в Mirror проверка отступа 16dp занимает 2 секунды (визуально), в Эмуляторе — 30 секунд (замер через координаты). Но цена ошибки в 4dp на критически важном экране оплаты может увеличить время разработки на 4-8 рабочих часов из-за переделки XML-файлов или Compose-функций. Экспертный вывод: используйте Mirror для итераций дизайна, а Эмулятор — для финального утверждения спецификаций перед передачей разработчику.
Подводные камни переноса: шрифты и рендеринг
Одна из главных проблем — разница в рендеринге шрифтов (Antialiasing). В Figma текст выглядит идеально гладким, но на реальном Android-устройстве (особенно на бюджетных моделях с низким DPI) шрифт может «поехать» или стать слишком тонким. Это приводит к тому, что текст, который в Figma занимал 120px в ширину, в реальности занимает 128px, вызывая перенос строки и развал всего блока.
Мини-кейс: при проектировании темного режима (Dark Mode) для Android в Figma через переменные (Variables) контрастность текста кажется достаточной. Однако на OLED-экранах через Mirror заметен эффект «ореола» вокруг белого текста на черном фоне, что заставляет снижать яркость белого с #FFFFFF до #E1E1E1 для комфорта пользователя. Экспертный вывод: никогда не утверждайте типографику только по монитору или Mirror — проверяйте её на реальном железе или в Эмуляторе с включенным рендерингом конкретного API уровня.
Вывод
Мой вердикт: Figma Mirror — это инструмент дизайнера для быстрой правки, а Android Emulator — инструмент инженера для верификации. Чтобы сократить количество правок после верстки на 30-40%, внедрите двухэтапную проверку: сначала Mirror для оценки эргономики и UX-жестов, затем Эмулятор для сверки технических отступов и Safe Areas. Избегайте полной верстки без проверки на Эмуляторе, особенно если в проекте используются сложные сетки или нестандартные разрешения экранов.