Привет, Хабр! В России набирает популярность новый подход к созданию пользовательских интерфейсов — Backend Driven UI (BDUI). В нём сервер задаёт структуру и поведение интерфейса, а приложение просто отображает его на экране.

BDUI уже используют в своих приложениях многие коллеги из индустрии. Меня зовут Елена Зеликсон, я старший инженер по тестированию в VK. О том, какие преимущества у этого решения и как его применять, подробнее расскажу в этой статье.

BDUI и нативная разработка: в чём разница?

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

В этом случае обновлять приложение нужно при любом изменении экрана. Например, чтобы поменять цвет кнопки придётся собрать новую версию продукта, отправить её на модерацию в App Store или Google Play и дождаться, пока пользователи установят обновление. Это может занять несколько недель.

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

Ключевая роль в системе отведена BDUI-фреймворку — именно он отвечает за правильную интерпретацию и применение команд сервера. По сути, фреймворк состоит из нескольких связанных компонентов:

• JSON-парсер. Принимает от сервера структуру и определяет, что выводить в интерфейс, например кнопку, текст или виджет.

• UI-рендерер. Использует нативную библиотеку компонентов и собирает экран «на лету»: размещает элементы, подключает нужные стили, задаёт размеры и позиционирование. 

• Обработчик событий. Делает UI интерактивным: пользователь может нажимать кнопки, запускать действия или использовать навигацию.

• Механизм кеширования. Ускоряет повторную загрузку экранов и улучшает работу приложения при нестабильном соединении.

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

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

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

Разберём отличия нативной разработки от BDUI-подхода на примере двух JSON-структур: 

Нативный подход

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

BDUI-подход

Вместо «сырых» данных сервер возвращает описание целого экрана: список компонентов, порядок их отрисовки, содержание и стиль. Здесь есть текст с заголовком, изображение с заданными размерами и кнопка для перехода на экран оформления заказа — то есть всё для отрисовки полноценной страницы.

Достоинства и недостатки BDUI

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

• три дня на разработку;

• две недели, чтобы собрать все изменения от команды в основную версию проекта;

• два дня на регрессионное тестирование.

И только после этого можно публиковать в App Store или Google Play, ждать модерацию, при необходимости вносить правки и отправлять проект на повторную проверку.

Работа с BDUI намного проще. Сроки разработки и тестирования не меняются, но в остальном релиз сильно ускоряется. Изменения сразу вносят в backend-интерфейс, поэтому ждать финальную сборку и модерацию в магазинах приложений больше не нужно. Достаточно активировать переключатель, и функцию увидят все пользователи. 

Преимущества запуска BDUI хорошо видно на диаграмме:

Из других преимуществ BDUI можно отметить:

• Широкие возможности для A/B-тестирования. С BDUI приложение обновляется гибко и быстро. Например, чтобы протестировать новый виджет, достаточного показать его выборке пользователей, и если результат не устроит, то просто отключить функцию через параметр на сервере.

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

  С BDUI эта проблема решается иначе: сервер отправляет один и тот же экран на все платформы, и тот рендерится максимально похоже. 

• Единая кодовая база. BDUI использует для iOS и Andriod общий код, поэтому экраны автоматически адаптируются под обе системы. Это отчасти сокращает человеческие, временные и финансовые затраты на разработку.

Но, при всех преимуществах, у BDUI есть и недостатки. Вот некоторые из них:

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

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

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

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

Кроме того, приложение на основе BDUI зависит от сети, так как его интерфейс загружается с сервера. Поэтому в местах с плохим интернетом, например в метро или лифте, отклик экрана может заметно ухудшиться.

Почему не WebView?

У BDUI и WebView много общего — например, кастомизация интерфейса и показатели time-to-market. Но так как WebView, по сути, браузер, встроенный в приложение, то у обоих решений есть ряд различий:

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

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

• Работа с архитектурой. WebView сильно зависит от браузерного движка. Чтобы синхронизировать веб-контент и нативный код, приходится использовать специальные мосты — это усложняет архитектуру, увеличивает риски багов и затрудняет отладку. BDUI взаимодействует с ОС напрямую и отрисовывает экран через её нативные UI-компоненты.   

Поэтому с BDUI работать проще и удобнее — он ускоряет рендеринг экрана, снижает количество ошибок и лучше интегрируется с ОС устройства.

Особенности тестирования BDUI-решений

Любую задачу в BDUI нужно проверять и на iOS, и на Android. Поскольку это разные системы, даже при одинаковом сценарии результаты могут отличаться. Здесь нужно обращать внимание на следующее: 

• Отрисовка уникальных компонентов. Нативные части приложений в BDUI-фреймворке могут некорректно обрабатывать шрифты, и в итоге возникают визуальные артефакты. Например, из-за несовместимости между системными шрифтами и JSON-структурой вёрстки в приложении могут появиться лишние пробелы или смещение текста.

• Отображение визуальных эффектов. В BDUI анимации используют редко, так как их нужно отрисовывать через сервер. В отдельных случаях можно создать нативную анимацию поверх BDUI-экрана или встроить её в отдельный BDUI-компонент. Но даже тогда результат на iOS и Android может различаться: эффекты могут накладываться друг на друга, срабатывать с задержкой или вовсе не воспроизводиться.

• Особенности навигации. Например, на Android есть системные кнопки «назад» и «свернуть», а в iOS чаще используют жесты, вроде свайпа вправо для возврата. Поэтому экран, который на iOS успешно закрывается свайпом, при нажатии кнопки «назад» в Android может наслаиваться на предыдущую страницу.

В BDUI можно применять E2E-, Unit-, UI- и другие виды тестирования. При этом тесты пишутся один раз и работают сразу на двух платформах. Это упрощает поддержку, ускоряет разработку и сохраняет единую логику экрана для всех устройств.

Заключение

BDUI помогает централизованно управлять как содержимым, так и структурой интерфейса — это делает приложение универсальным исполнителем, которому достаточно отправить JSON и оно покажет нужный экран. 

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