Меня зовут Родион, и я уже около 2,5 лет работаю в VK Android-разработчиком в крупном многомодульном проекте с сотнями экранов и довольно большой аудиторией. Когда я попал на проект, стек был классическим и проверенным: XML-вёрстка, навигация через Cicerone, Dagger 2 для DI, Coroutines и Flow для асинхронщины, а в качестве архитектурного паттерна — MVVM. 

Рано или поздно любая растущая кодовая база упирается в потолок своих архитектурных решений. У нас этот момент настал, когда количество экранов выросло до нескольких сотен и команда начала тратить больше времени на борьбу с неконсистентным состоянием UI. Классическая связка XML + ViewBinding + MVVM работала, но с каждым новым экраном мы всё острее чувствовали её ограничения: разрозненные StateFlow, дублирование кода во фрагментах, сложность переиспользования компонентов. 

Нужно было что-то менять — пересмотреть сам подход к построению UI. Так мы начали миграцию на Jetpack Compose (который на момент начала перехода уже был стабильным и самодостаточным). Полтора года спустя, пройдя через рефакторинг базовых классов, переход с MVVM на MVI и постепенную замену содержимого всех фрагментов, мы получили стек, на котором разработка ускорилась, а баги, связанные с состоянием экрана, практически исчезли. 

Полный переход на Jetpack Compose мы разделили на три больших этапа:

- переписываем содержимое всех фрагментов на ComposeView;

- переходим с Dagger2 на Koin;

- меняем навигацию с Cicerone на Compose-навигацию.

О втором и третьем этапах кратко расскажу ниже —  в главе стратегии перехода, а на первом этапе остановлюсь подробнее.

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