Пупупу, давай начинать с начала! Зачем тебе BDUI? Какую задачу решаешь? BDUI можно готовить по разному.

Самый экстримальный вариант - DivKit, в нем можно достаточно гибко рисовать любой интерфейс, его можно воспринимать как HTML/CSS на джейсонах. С ним можно даже не думать про нативную разработку во многом. Но он ощущается "не нативно", такова цена гибкости. DivKit к слову есть под Flatter.

Если хочется нативный опыт, то приходится ограничивать гибкость, собирать экраны из нативных кусков управляя наполнением с бекенда. Тут важно сделать переход в проектировании API от "возвращает доменные модели" к "возвращает абстрактные данные для отображения". В случе с Музыкой этот переход выглядил так: вместо списка альбомов мы получаем карусель блоков с круглой картинкой, заголовком и подзаголовком.

Когда совершите этот переход - получить большую часть профита от BDUI.

По поводу того, нужно ли разбираться в бекенде - было бы неплохо. Думаб просто BDUI можно собрать и без глебоких знаний. Если вы например раздаете всем клиентам одинаковую статическую верстку. Но если есть BDUI - можно деать персональные экраны, с сдожными админками или например рекомендательным контентом =) Тут уже навыки потребуются

Да, можно во Flutter, вот даже открытое решение от Яндекса https://habr.com/ru/companies/yandex/articles/814187/

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

Чтобы верстать на DivKit, в бэкенде разбираться не нужно: это просто ещё один способ верстки как виджеты во Flutter, HTML и т. д. Однако нужно поднять бэкенд-сервис, в котором будет писаться эта верстка.

На практике обычно получается так: — Команда бэкенда поддерживает сервис, настраивает мониторинги и алёрты — Мобильные разработчики пишут ручки, отдающие BDUI, а также переиспользуемые UI-компоненты