Какие ошибки делают команды, когда строят приложение на Jetpack Compose как web/backend-проект без учёта mobile constraints?

Ошибка 1: слишком крупные ViewModel

Backend-разработчики привыкли к Service/Repository классам с десятками методов. В мобильном приложении один ViewModel на весь экран, содержащий 500+ строк и 20 UseCase-зависимостей, делает тестирование невозможным и замедляет компиляцию.

// Плохо: monolith ViewModel
class ProfileViewModel(
    private val getUser: GetUserUseCase,
    private val updateAvatar: UpdateAvatarUseCase,
    private val loadPosts: LoadPostsUseCase,
    private val loadFollowers: LoadFollowersUseCase,
    // ... ещё 10 use case
) : ViewModel()

// Лучше: разделить на ProfileInfoViewModel и ProfileFeedViewModel

Почему mobile — не маленький backend

Команды с бэкенд- или веб-фоном часто переносят привычные паттерны на мобильную разработку: толстые ViewModel, синхронные операции, игнорирование жизненного цикла. В Jetpack Compose это приводит к специфическим проблемам, которые сложно отлаживать без понимания mobile constraints.

Ошибка 2: игнорирование lifecycle и памяти

В backend-мире процесс живёт долго и имеет предсказуемую память. На Android Activity пересоздаётся при повороте, процесс убивается системой. Хранение тяжёлых объектов в ViewModel без учёта onCleared() создаёт утечки.

class BadViewModel : ViewModel() {
    // Утечка: Bitmap не освобождается
    var cachedBitmap: Bitmap? = null

    override fun onCleared() {
        super.onCleared()
        cachedBitmap?.recycle() // Обязательно!
        cachedBitmap = null
    }
}

Ошибка 3: избыточные рекомпозиции из-за нестабильных параметров

Команды, не понимающие Compose Compiler, передают в composable нестабильные типы (List, обычные классы без @Stable), что приводит к рекомпозиции всего экрана при любом изменении состояния.

// Нестабильный параметр — List не отслеживается стабильно
@Composable
fun ItemsList(items: List<Item>) { ... }

// Лучше: обернуть в @Immutable
@Immutable
data class ItemsState(val items: List<Item>)

@Composable
fun ItemsList(state: ItemsState) { ... }

Ошибка 4: работа с IO в Main-потоке

На backend асинхронность часто подразумевается фреймворком. В Android попытка прочитать SharedPreferences или БД в Main-потоке из LaunchedEffect без явного Dispatchers.IO вызывает StrictMode violation или ANR на медленных устройствах.

// Плохо: блокирующий вызов в LaunchedEffect
LaunchedEffect(Unit) {
    val prefs = context.getSharedPreferences("app", Context.MODE_PRIVATE)
    // На медленном устройстве это ANR
}

// Правильно: через ViewModel с Dispatchers.IO
viewModelScope.launch(Dispatchers.IO) {
    val value = dataStore.data.first()
    _state.update { it.copy(setting = value) }
}

Ошибка 5: игнорирование WindowInsets и системных наложений

Веб-разработчики привыкли к полному контролю над viewport. В Android статус-бар, навигационная панель и IME перекрывают контент. Не используя Modifier.windowInsetsPadding() или consumeWindowInsets(), команды получают кнопки, скрытые за клавиатурой.

Ошибка 6: отсутствие обработки process death

Backend не перезапускается неожиданно в середине операции. На Android процесс может быть убит системой. Критические состояния (форма с введёнными данными, корзина) должны сохраняться через rememberSaveable или Repository с персистентностью.

Подводные камни

• Передача нестабильных типов (List, Map, обычные data class без @Immutable/@Stable) в composable-параметры ломает skip-оптимизацию Compose Compiler.
• Запуск корутин в composable без правильного scope: использование GlobalScope вместо rememberCoroutineScope() или viewModelScope создаёт утечки.
• Не использовать SavedStateHandle в ViewModel — после process death все in-memory состояния теряются, и пользователь видит пустой экран.
• Копирование HTTP-timeout-логики на мобильный: на Android сеть может пропасть в любой момент, нужны retry с exponential backoff и offline-режим.
• Создавать одну крупную NavHost-компонент вместо разбивки на feature-модули — это замедляет сборку и нарушает принципы модульности Android-архитектуры.
• Игнорировать тёмную тему и системный font scale: на Android пользователи часто ставят крупный шрифт или тёмную тему, и UI ломается, если он не тестировался с этими настройками.
• Забывать про Back Stack: в вебе браузер управляет историей, в мобильном приложении неправильная настройка backStackEntry в Navigation Compose приводит к созданию нескольких копий экрана.

• Перечислять ошибки без объяснения причин
• Не отличать beginner mistakes от production failure modes
• Не предлагать процесс, который предотвращает повторение ошибок

• Знает типичные ошибки при работе с Jetpack Compose
• Понимает причины ошибок
• Предлагает практики prevention и early detection