Нативная разработка Android-приложения на Kotlin
Заказчик приходит с готовым дизайном, иногда с прототипом на Figma, и вопросом: «Почему нельзя просто взять React Native?» Ответ зависит от того, что именно нужно приложению. Если это работа с Bluetooth LE, сложная навигация по стеку экранов, фоновая геолокация или запись экрана — нативный Android на Kotlin избавляет от целого класса проблем, которые в кросс-платформе решаются через костыли и нативные модули, то есть фактически тем же самым кодом, только скрытым за абстракцией.
Kotlin — основной язык Android-разработки с 2019 года. Google переписывает собственные библиотеки с Java на Kotlin, Jetpack Compose существует только на Kotlin, и новые API вроде kotlinx.coroutines или Flow просто не имеют полноценных аналогов для Java-стека. Выбор Kotlin — это не предпочтение, а следование экосистеме.
Из чего на самом деле состоит современный Android-проект
Архитектура типового коммерческого приложения на 2024 год выглядит так: Clean Architecture с разбивкой на слои data / domain / presentation, MVVM как паттерн presentation-слоя, Hilt для dependency injection. Навигация — через Navigation Component с NavGraph или более гибкий Decompose для сложных вложенных стеков.
UI строится на Jetpack Compose. Это не «новомодная технология» — это уже стандарт. Compose убирает разрыв между состоянием и UI: нет notifyDataSetChanged(), нет ViewHolder бойлерплейта, нет синхронизации между XML и кодом. @Composable-функция просто описывает, как выглядит UI при данном состоянии, и Compose сам пересчитывает то, что изменилось, через smart recomposition.
Для управления состоянием используем StateFlow + ViewModel. Для сложных UI с shared state между несколькими экранами — MVI-паттерн с единым UiState и UiEffect. Бизнес-логика живёт в UseCase-классах, которые не знают про Android-специфику и легко покрываются unit-тестами без Robolectric.
Сетевой слой: Retrofit 2 + OkHttp с цепочкой интерсепторов для авторизации, логирования и retry-логики. Сериализация — kotlinx.serialization или Gson/Moshi по предпочтениям команды. Локальное хранилище — Room с TypeConverters для кастомных типов и @Transaction для атомарных операций.
Фоновые задачи — WorkManager для отложенных и периодических операций, coroutines с правильными 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 решают это через coroutines и worker threads, но только если правильно настроен ImageLoader.
Неправильные scope у Hilt-компонентов. @Singleton репозиторий с @ActivityScoped зависимостью внутри — и Hilt честно падает с [Dagger/MissingBinding] на сборке. Не в рантайме — на сборке. Это хорошо, но разобраться в длинном stack trace Dagger-кодогенерации умеет не каждый.
Как строится работа
Начинаем с технического аудита требований: список экранов, интеграции (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 через JUnit5 + MockK, UI-тесты через Espresso или Compose Testing API. Для сложных flow — интеграционные тесты с in-memory Room database.
Перед публикацией — обфускация через R8, проверка android:exported для всех компонентов (требование Google Play с API 31), тестирование на нескольких устройствах разных производителей через Firebase Test Lab.
Ориентиры по срокам
| Тип проекта | Оценка |
|---|---|
| MVP с 5-8 экранами и REST API | 4-6 недель |
| Приложение со сложной бизнес-логикой, offline, push | 8-12 недель |
| Комплексный продукт с несколькими интеграциями | 3+ месяца |
Стоимость рассчитывается индивидуально после анализа требований и составления технического задания.
Что влияет на сложность больше всего
Не количество экранов — а интеграции. 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 нужно понимать до начала разработки. Поэтому первый шаг — детальное ТЗ, а не оценка «на глаз».