Нативная разработка Android-приложений на Kotlin

Нативная разработка Android-приложений на Kotlin

Заказчик приходит к нам с готовым дизайном, иногда с прототипом на Figma, и спрашивает: «Почему нельзя просто взять React Native?» Ответ зависит от того, что именно нужно приложению. Если это работа с Bluetooth LE, сложная навигация по стеку экранов, фоновая геолокация или запись экрана — нативный Android на Kotlin избавляет от целого класса проблем, которые в кросс-платформе решаются через костыли и нативные модули, то есть фактически тем же самым кодом, только скрытым за абстракцией.

Kotlin — основной язык Android-разработки с 2019 года. Google переписывает собственные библиотеки с Java на Kotlin, Jetpack Compose существует только на Kotlin, и новые API вроде kotlinx.coroutines или Flow просто не имеют полноценных аналогов для Java-стека. Выбор Kotlin — это не предпочтение, а следование экосистеме.

Почему Kotlin и Jetpack Compose — стандарт индустрии?

Jetpack Compose — это не новомодная технология, а уже стандарт для UI в Android. Compose убирает разрыв между состоянием и UI: нет notifyDataSetChanged(), нет ViewHolder бойлерплейта, нет синхронизации между XML и кодом. @Composable-функция просто описывает, как выглядит UI при данном состоянии, и Compose сам пересчитывает то, что изменилось, через smart recomposition. По производительности рендеринга Compose в 2–3 раза быстрее React Native при работе с анимациями.

Из чего на самом деле состоит современный Android-проект

Архитектура типового коммерческого приложения выглядит так: Clean Architecture с разбивкой на слои data / domain / presentation, MVVM как паттерн presentation-слоя, Hilt для dependency injection. Навигация — через Navigation Component с NavGraph или более гибкий Decompose для сложных вложенных стеков.

UI строится на Jetpack Compose. Для управления состоянием используем StateFlow + ViewModel. Для сложных UI с shared state между несколькими экранами — MVI-паттерн с единым UiState и UiEffect. Бизнес-логика живёт в UseCase-классах, которые не знают про Android-специфику и легко покрываются unit-тестами без Robolectric.

Сетевой слой: Retrofit 2 + OkHttp с цепочкой интерсепторов для авторизации, логирования и retry-логики. Сериализация — kotlinx.serialization или Moshi по предпочтениям команды. Локальное хранилище — Room с TypeConverters для кастомных типов и @Transaction для атомарных операций.

Фоновые задачи — WorkManager для отложенных и периодических операций, корутины с правильными CoroutineScope для одноразовых задач. Проблема «корутина запущена, Activity умерла, потёк поток» решается через viewModelScope и repeatOnLifecycle.

Как предотвратить типичные ошибки при разработке?

Проблема не в написании кода — в решениях, которые принимаются в первые две недели. Вот где возникают самые дорогие ошибки и как мы их избегаем:

Навигация без чёткой схемы. В Navigation Component соблазнительно добавлять фрагменты по мере необходимости. Через три месяца получается граф, в котором нельзя понять, откуда пришёл пользователь и куда вернётся после deep link. Мы проектируем NavGraph заранее, выделяем вложенные графы для каждого feature-модуля, и backstack не превращается в загадку.

Неправильный lifecycle. collectAsStateWithLifecycle() вместо collectAsState() — казалось бы, мелочь. Но без правильного lifecycle-aware collection Flow продолжает работать, когда приложение в фоне, и батарея садится. Краши из Firebase Crashlytics с IllegalStateException: Cannot collect flow on a dead lifecycle говорят именно об этом.

Многопоточность на главном потоке. Доступ к базе данных Room на main thread в debug-сборке бросает IllegalStateException — это хорошо, сразу видно. Но декодирование Bitmap 4K-фото в onBindViewHolder при использовании старого RecyclerView-подхода не бросает исключений, просто дропает фреймы. Coil и Glide решают это через корутины и worker threads, но только если правильно настроен ImageLoader.

Неправильные scope у Hilt-компонентов. @Singleton репозиторий с @ActivityScoped зависимостью внутри — и Hilt честно падает с [Dagger/MissingBinding] на сборке. Не в рантайме — на сборке. Это хорошо, но разобраться в длинном stack trace Dagger-кодогенерации умеет не каждый.

Почему нативный Kotlin выгоднее для сложных проектов?

Сравнение нативного подхода с кросс-платформенными фреймворками показывает: для проектов с высокой нагрузкой на графику, сложной анимацией или специфическими аппаратными функциями (Bluetooth, NFC, камера) нативный код обеспечивает 100% стабильность. Кросс-платформа даёт экономию времени на старте, но затем требует постоянных доработок нативных модулей. На практике команда тратит до 40% времени на обходные пути в React Native, которых в нативном коде просто не существует.

Как строится работа

Начинаем с технического аудита требований: список экранов, интеграции (API, SDK третьих сторон, push через FCM, аналитика через Firebase/Amplitude), требования к offline-режиму, минимальная поддерживаемая версия API (обычно API 24 / Android 7.0, реже API 21).

Дальше — архитектурное решение: монолитный модуль или multi-module project. Multi-module ускоряет инкрементальные сборки Gradle и обеспечивает изоляцию feature-команд, но добавляет сложность в настройке зависимостей между модулями. Для проектов до 5-7 feature-команд монолит с чёткими package-boundaries практичнее.

Разработка идёт спринтами по 1-2 недели с демо в конце каждого. CI настраивается с первого дня: GitHub Actions или GitLab CI, сборка + unit-тесты + lint на каждый PR, Firebase App Distribution для дистрибуции тестовых сборок.

Тестирование: unit-тесты на UseCase и ViewModel (покрытие 95%), UI-тесты через Compose Testing API. Для сложных flow — интеграционные тесты с in-memory Room database.

Перед публикацией — обфускация через R8, проверка android:exported для всех компонентов (требование Google Play с API 31), тестирование на нескольких устройствах разных производителей через Firebase Test Lab.

Что входит в работу

• Детальный технический аудит требований и составление ТЗ
• Проектирование архитектуры (Clean Architecture + MVVM/MVI)
• Разработка с использованием Jetpack Compose, Hilt, Retrofit, Room
• Написание unit-тестов и UI-тестов (покрытие >90%)
• Настройка CI/CD (GitHub Actions/GitLab CI + Firebase App Distribution)
• Оптимизация сборки и обфускация (R8)
• Публикация в Google Play Console с прохождением всех проверок
• Документация по архитектуре и деплою
• Техническая поддержка после релиза

Ориентиры по срокам

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

Что влияет на сложность больше всего?

Не количество экранов — а интеграции. FCM с rich notifications и custom sounds — три дня. Биометрическая авторизация через BiometricPrompt API с fallback на PIN — день-два. Работа с Bluetooth LE через BluetoothGatt на нескольких устройствах одновременно — отдельный проект внутри проекта, потому что производители по-разному реализуют GATT-стек.

Карты: Google Maps SDK подключается за час, но кастомные маркеры с кластеризацией, полигоны и оффлайн-тайлы — это уже несколько дней. In-app purchases через Google Play Billing Library 6.x с подписками, промо-кодами и graceful degradation при недоступности Play Store — легко неделя работы.

Весь этот scope нужно понимать до начала разработки. Поэтому первый шаг — детальное ТЗ, а не оценка «на глаз».