Разработка Android-приложений: от основ до публикации

Введение в экосистему Android: установка Android Studio, основы Kotlin и структура проекта

Добро пожаловать в курс «Разработка Android-приложений: от основ до публикации». Это первая статья, с которой начнется ваше путешествие в мир мобильной разработки. Сегодня мы не просто напишем «Hello World», но и разберемся, как устроена экосистема Android изнутри, настроим профессиональные инструменты и изучим фундамент языка Kotlin.

Почему Android и Kotlin?

Android — это самая популярная мобильная операционная система в мире, установленная на миллиардах устройств: от смартфонов и планшетов до часов, телевизоров и автомобилей. Для разработчика это означает огромный рынок и бесконечные возможности для реализации идей.

Долгое время основным языком разработки был Java. Однако в 2017 году Google объявила Kotlin официальным языком для Android, а в 2019 году разработка стала Kotlin-first. Это значит, что все новые функции и библиотеки создаются в первую очередь с учетом возможностей Kotlin.

Kotlin — это современный, лаконичный и безопасный язык программирования, который работает поверх виртуальной машины Java (JVM). Он убирает множество «лишнего» кода, свойственного Java, и защищает разработчика от частых ошибок.

Шаг 1: Установка и настройка Android Studio

Для создания приложений нам понадобится IDE (Integrated Development Environment) — интегрированная среда разработки. Официальным и самым мощным инструментом является Android Studio, построенная на базе IntelliJ IDEA.

Процесс установки

1. Перейдите на официальный сайт Android Developers.
2. Скачайте установочный файл для вашей операционной системы (Windows, macOS или Linux).
3. Запустите установщик. В процессе установки убедитесь, что отмечены галочки Android SDK (Software Development Kit — набор инструментов разработчика) и Android Virtual Device (эмулятор).

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

Настройка эмулятора (AVD)

Чтобы тестировать приложения, не обязательно иметь физическое устройство под рукой. Android Studio включает в себя мощный эмулятор.

1. Откройте Android Studio.
2. В меню выберите Tools > Device Manager.
3. Нажмите Create Device.
4. Выберите модель (например, Pixel 6) и версию Android (System Image).
5. Нажмите Finish.

Теперь у вас есть виртуальный смартфон прямо на компьютере.

Шаг 2: Создание первого проекта

Давайте создадим каркас нашего будущего приложения.

1. На стартовом экране нажмите New Project.
2. Вам предложат выбрать шаблон. Для начала выберите Empty Views Activity (или просто Empty Activity в старых версиях). Это создаст пустой экран.
3. Name: Введите имя приложения, например, MyFirstApp.
4. Package name: Уникальный идентификатор приложения (обычно в формате com.example.myfirstapp).
5. Language: Обязательно выберите Kotlin.
6. Build configuration language: Рекомендуется выбрать Kotlin DSL.

Нажмите Finish и подождите, пока система сборки Gradle скачает библиотеки и настроит проект. Это может занять несколько минут.

Шаг 3: Структура Android-проекта

Когда проект откроется, слева вы увидите дерево файлов. По умолчанию выбран режим просмотра Android, который группирует файлы логически, а не так, как они лежат на диске. Это удобно.

Разберем ключевые элементы:

1. manifests/AndroidManifest.xml

Это «паспорт» вашего приложения. Здесь описываются:

• Название и иконка приложения.
• Список экранов (Activity).
• Разрешения (например, доступ к интернету или камере).

2. java/com.example.myfirstapp

Здесь живет исходный код на Kotlin. Вы увидите файл MainActivity.kt. Это точка входа в ваше приложение — класс, который управляет первым экраном.

3. res (Resources)

Папка для статических ресурсов. Код и дизайн в Android разделены.

• drawable: Изображения и векторные иконки.
• layout: XML-файлы, описывающие внешний вид экранов (интерфейс). Например, activity_main.xml.
• values: Цвета (colors.xml), строки текста (strings.xml) и темы.

4. Gradle Scripts

Gradle — это система автоматической сборки. Файл build.gradle.kts (Module: :app) самый важный. В нем указываются:

• applicationId (тот самый уникальный идентификатор).
• minSdk (минимальная версия Android, на которой запустится приложение).
• dependencies (список используемых библиотек).

Шаг 4: Основы Kotlin для Android

Прежде чем писать логику, нужно понять базовый синтаксис Kotlin. Он сильно отличается от Java своей лаконичностью.

Переменные: val и var

В Kotlin есть два типа объявления переменных:

• val (от value) — неизменяемая переменная (константа). После присвоения значения изменить его нельзя.
• var (от variable) — изменяемая переменная.

val appName = "MyFirstApp" // Нельзя изменить
var userAge = 25           // Можно изменить
userAge = 26               // OK
// appName = "NewName"     // Ошибка компиляции!

Всегда используйте val по умолчанию. Используйте var только тогда, когда это действительно необходимо. Это делает код безопаснее и предсказуемее.

Типы данных и вывод типов

Kotlin умный. Вам не обязательно явно указывать тип переменной, если он очевиден из контекста. Это называется выводом типов (Type Inference).

val count: Int = 10 // Явное указание типа
val name = "Alex"   // Kotlin сам понял, что это String

Функции

Функции объявляются ключевым словом fun.

fun greetUser(name: String): String {
    return "Привет, $name!"
}

Обратите внимание на символ $ внутри строки. Это интерполяция строк — удобный способ вставлять переменные прямо в текст без конкатенации (плюсиков).

Null Safety (Безопасность от null)

Одна из главных фишек Kotlin — защита от ошибки на миллиард долларов (NullPointerException). В Kotlin переменные по умолчанию не могут хранить null (пустоту).

var text: String = "Hello"
// text = null // Ошибка компиляции!

Если вам нужно, чтобы переменная могла быть пустой, нужно добавить вопросительный знак ? к типу:

var nullableText: String? = "Hello"
nullableText = null // Теперь это допустимо

Немного математики: Плотность экрана

При разработке интерфейсов вы столкнетесь с единицами измерения dp (density-independent pixels). Почему нельзя использовать обычные пиксели? Потому что у разных телефонов разная плотность пикселей (PPI — Pixels Per Inch).

Формула расчета плотности пикселей выглядит так:

$$PPI = \frac{\sqrt{w^2 + h^2}}{d}$$

Где:

• $PPI$ — плотность пикселей на дюйм (Pixels Per Inch).
• $w$ — ширина экрана в пикселях (width).
• $h$ — высота экрана в пикселях (height).
• $d$ — диагональ экрана в дюймах (diagonal).
• $\sqrt{w^2 + h^2}$ — вычисление длины диагонали в пикселях по теореме Пифагора.

Если мы зададим кнопку шириной 100 пикселей, на старом телефоне она будет огромной, а на современном флагмане с высоким $PPI$ — микроскопической. Использование dp позволяет элементам выглядеть одинаково физически на любых экранах.

Запуск приложения

Теперь, когда мы разобрались с теорией, давайте запустим то, что создала Android Studio по умолчанию.

1. Найдите зеленую кнопку Run (треугольник) на верхней панели инструментов.
2. Убедитесь, что рядом выбран ваш созданный эмулятор.
3. Нажмите кнопку и подождите.

Gradle соберет проект, запустит эмулятор, установит туда приложение и откроет его. Вы увидите белый экран с надписью «Hello World!» (или аналогичной, в зависимости от шаблона).

Заключение

Поздравляю! Вы настроили рабочее окружение, создали свой первый проект и познакомились с базовым синтаксисом Kotlin. Вы узнали, что AndroidManifest.xml — это паспорт приложения, ресурсы лежат в папке res, а код — в java. Также мы затронули важную тему безопасности типов в Kotlin.

В следующей статье мы углубимся в создание пользовательского интерфейса: изучим Layouts, View-элементы и научимся верстать красивые экраны.

Пользовательский интерфейс: создание макетов, работа с ресурсами и введение в Jetpack Compose

В предыдущей статье мы настроили Android Studio и изучили структуру проекта. Теперь пришло время наполнить наше приложение жизнью — создать его внешний вид. В Android разработке пользовательский интерфейс (UI) — это то, с чем взаимодействует пользователь: кнопки, тексты, изображения и списки.

Сегодня мы стоим на стыке двух эпох. С одной стороны — классическая система верстки на основе XML, которая использовалась более 10 лет. С другой — современный декларативный подход Jetpack Compose, который стремительно становится стандартом индустрии. В этом уроке мы разберем оба подхода, чтобы вы чувствовали себя уверенно в любом проекте.

Часть 1: Классическая система View (XML)

В классическом подходе интерфейс описывается в XML-файлах (тех самых, что лежат в папке res/layout), а логика пишется на Kotlin. Вся система строится на иерархии классов.

Концепция View и ViewGroup

Все элементы интерфейса в Android являются наследниками базового класса View.

1. View (Вид) — это прямоугольная область на экране, которая отвечает за отрисовку и обработку событий (нажатий). Примеры: кнопка (Button), текстовое поле (TextView), картинка (ImageView).
2. ViewGroup (Группа видов) — это невидимый контейнер, который управляет расположением вложенных в него View. Это основа верстки.

Основные Layouts (Контейнеры)

Чтобы расположить элементы на экране, нам нужны специальные ViewGroup, называемые макетами (Layouts).

1. LinearLayout

Самый простой контейнер. Он выстраивает элементы в одну линию: либо по горизонтали, либо по вертикали.

<LinearLayout
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView android:text="Заголовок" ... />
    <Button android:text="Нажать" ... />

</LinearLayout>

2. ConstraintLayout

Это самый мощный и гибкий контейнер, используемый по умолчанию в новых проектах. Он позволяет располагать элементы относительно друг друга или границ экрана с помощью «привязок» (constraints).

Представьте, что вы крепите картину на стене с помощью пружин. Если прикрепить кнопку пружиной к левому краю экрана и пружиной к правому — она окажется ровно посередине.

Единицы измерения и отступы

Вспомним математику из прошлого урока. Элемент на экране занимает место, которое складывается из его содержимого и отступов. Это называется Box Model (блочная модель).

Формула расчета полной ширины элемента:

$$W_{total} = W_{content} + P_{start} + P_{end} + M_{start} + M_{end}$$

Где:

• $W_{total}$ — полная ширина, занимаемая элементом на экране.
• $W_{content}$ — ширина самого контента (например, текста внутри кнопки).
• $P_{start}$ и $P_{end}$ — внутренние отступы (Padding) слева и справа (расстояние от границы элемента до контента).
• $M_{start}$ и $M_{end}$ — внешние отступы (Margin) слева и справа (расстояние от границы элемента до соседей).

В Android принято использовать start и end вместо left и right для поддержки языков с письмом справа налево (RTL), например, арабского.

Часть 2: Работа с ресурсами

В Android принято отделять код от ресурсов. Текст не должен быть «зашит» внутри Kotlin-файла или XML-разметки. Почему?

1. Локализация: Чтобы перевести приложение на другой язык, достаточно создать отдельный файл со строками, не меняя код.
2. Поддержка тем: Легко менять цвета для темной и светлой темы.

Основные файлы ресурсов (папка res)

• res/values/strings.xml — здесь хранятся все тексты.
• res/values/colors.xml — палитра цветов приложения.
• res/drawable — иконки и картинки.

Пример strings.xml:

<resources>
    <string name="app_name">Мое Приложение</string>
    <string name="welcome_message">Привет, пользователь!</string>
</resources>

Использование в XML:

<TextView
    android:text="@string/welcome_message" ... />

Использование в Kotlin: Для доступа к ресурсам из кода используется автоматически генерируемый класс R.

val message = getString(R.string.welcome_message)

Часть 3: Введение в Jetpack Compose

В 2021 году Google выпустила Jetpack Compose — новый набор инструментов для создания UI. Это декларативный подход. Если в XML мы говорили «создай кнопку, потом найди её и поменяй текст», то в Compose мы говорим «нарисуй кнопку с таким-то текстом».

Почему Compose — это будущее?

• Меньше кода: Нет дублирования между XML и Kotlin.
• Только Kotlin: Весь UI пишется на одном языке.
• Интуитивность: Интерфейс обновляется автоматически при изменении данных.

Основы синтаксиса

В Compose интерфейс строится из обычных функций, помеченных аннотацией @Composable. Эти функции могут вызывать другие Composable-функции, формируя иерархию.

Пример простого экрана на Compose:

import androidx.compose.material3.Text
import androidx.compose.runtime.Composable

@Composable
fun Greeting(name: String) {
    // Text - это аналог TextView
    Text(text = "Привет, $name!")
}

Базовые элементы Compose

Вместо классов View и ViewGroup здесь используются функции:

• Text(...) — выводит текст.
• Button(onClick = { ... }) { ... } — кнопка.
• Image(...) — изображение.
• Column { ... } — аналог LinearLayout (вертикальный).
• Row { ... } — аналог LinearLayout (горизонтальный).

Управление состоянием (State)

Главная магия Compose — это State (состояние). Интерфейс в Compose неизменяем. Чтобы обновить текст на экране, нужно вызвать функцию заново с новыми данными. Compose делает это сам, когда видит, что изменилась переменная состояния.

@Composable
fun Counter() {
    // remember сохраняет значение при перерисовке
    // mutableStateOf сообщает Compose, что при изменении нужно обновить UI
    var count by remember { mutableStateOf(0) }

    Button(onClick = { count++ }) {
        Text(text = "Нажато раз: $count")
    }
}

В этом примере, как только count увеличится, Compose автоматически перерисует кнопку с новым текстом. Вам не нужно вручную искать TextView и вызывать setText.

Что выбрать: XML или Compose?

• Новые проекты: Однозначно Jetpack Compose. Это современный стандарт, который рекомендует Google.
• Старые проекты: Скорее всего, вы встретите XML. Вам нужно уметь его читать и поддерживать.

В нашем курсе мы будем делать упор на современные практики, поэтому в следующих уроках мы будем активно использовать Jetpack Compose, но понимание того, как работают ресурсы и базовые принципы UI, универсально для обоих подходов.

Заключение

Сегодня мы разобрали фундамент построения интерфейсов в Android. Мы узнали, что UI — это иерархия элементов, изучили разницу между классическим XML-подходом и современным Jetpack Compose. Также мы научились правильно работать с ресурсами, вынося текст и цвета в отдельные файлы.

В следующей статье мы оживим наше приложение: разберем жизненный цикл Activity и научимся переключаться между экранами (Навигация).

Архитектура приложения и работа с данными: жизненный цикл, MVVM, Room и Retrofit

В предыдущих статьях мы научились создавать красивые интерфейсы с помощью XML и Jetpack Compose. Однако красивый интерфейс без данных — это просто пустая оболочка. Настоящее приложение должно уметь загружать информацию из интернета, сохранять её на устройстве и грамотно обрабатывать действия пользователя, не теряя состояние при повороте экрана.

Сегодня мы переходим к «мозгам» и «сердцу» Android-приложения. Мы разберем, как живет приложение (жизненный цикл), как правильно организовать код (архитектура MVVM) и как работать с данными (Room и Retrofit).

Жизненный цикл Activity (Lifecycle)

Представьте, что вы пишете письмо, и вдруг вам звонят. Вы откладываете ручку, говорите по телефону, а затем возвращаетесь к письму. Если звонок был долгим, вы могли забыть, на чем остановились. Android работает похожим образом.

Activity — это не просто окно, которое «открыто» или «закрыто». Оно проходит через серию состояний, называемых жизненным циклом. Система вызывает специальные методы (колбэки) при смене этих состояний.

Основные методы жизненного цикла:

1. onCreate(): Вызывается при создании компонента. Здесь мы инициализируем переменные и загружаем интерфейс (setContentView). Это происходит один раз.
2. onStart(): Activity становится видимой пользователю, но с ней еще нельзя взаимодействовать.
3. onResume(): Activity находится на переднем плане, пользователь может нажимать кнопки. Это «рабочее» состояние.
4. onPause(): Пользователь начинает покидать Activity (например, всплыло полупрозрачное уведомление). Нужно остановить анимации или видео.
5. onStop(): Activity полностью скрыта (пользователь свернул приложение или открыл другой экран).
6. onDestroy(): Финальный аккорд. Activity уничтожается системой для освобождения памяти.

Проблема поворота экрана

В Android есть нюанс, который пугает новичков: при повороте экрана Activity уничтожается и создается заново. Система делает это, чтобы загрузить ресурсы для новой ориентации (например, другой макет XML).

Если вы хранили данные просто в переменных внутри Activity, они исчезнут. Именно здесь нам на помощь приходит правильная архитектура.

Архитектура MVVM (Model-View-ViewModel)

Чтобы код не превратился в «спагетти», где логика, данные и отрисовка смешаны в одну кучу, Google рекомендует использовать архитектурный паттерн MVVM.

Он разделяет приложение на три слоя:

1. Model (Модель): Отвечает за данные. Это базы данных, сетевые запросы и бизнес-логика. Модель ничего не знает об интерфейсе.
2. View (Представление): Это наш UI (Activity, Fragment, Composable). Она только отображает данные и перехватывает нажатия. View ничего не знает о логике, она просто «слушает» ViewModel.
3. ViewModel: Посредник. Она берет данные из Model, обрабатывает их и подготавливает для View. Главная фишка ViewModel в Android — она переживает поворот экрана.

Пример ViewModel на Kotlin

class UserViewModel : ViewModel() {
    // LiveData - хранилище данных, за которым следит View
    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadUserData() {
        // Имитация загрузки данных
        _userName.value = "Алексей"
    }
}

В Activity мы просто подписываемся на userName. Как только данные изменятся, текст на экране обновится автоматически.

Работа с сетью: Retrofit

Практически любому приложению нужен интернет. В Android стандартом индустрии для работы с REST API является библиотека Retrofit от Square.

Почему нельзя просто скачать файл как в браузере? Потому что сетевые операции занимают время. Если мы попытаемся скачать картинку в главном потоке (Main Thread), интерфейс «зависнет», и система предложит закрыть приложение (ошибка ANR — Application Not Responding).

Рассчитаем примерное время блокировки, если бы мы делали это в главном потоке:

$$T = \frac{S}{V} + L$$

Где:

• $T$ — общее время выполнения запроса (Time).
• $S$ — размер загружаемых данных (Size), например, 2 Мб.
• $V$ — скорость соединения (Velocity), например, 1 Мб/с.
• $L$ — задержка сети (Latency), время на установку соединения (ping).

Даже при идеальных условиях задержка будет заметна глазу (более 16 мс). Поэтому Retrofit работает асинхронно.

Настройка Retrofit

1. Интерфейс API: Мы описываем запросы как функции.

interface ApiService {
    @GET("users/{id}")
    suspend fun getUser(@Path("id") userId: String): User
}

2. Создание клиента:

val retrofit = Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .addConverterFactory(GsonConverterFactory.create())
    .build()

val service = retrofit.create(ApiService::class.java)

Ключевое слово suspend означает, что функция будет выполняться в корутинах (Coroutines) — легких потоках, не блокируя интерфейс.

Локальное хранение данных: Room

Что делать, если интернета нет? Хорошее приложение должно показывать кэшированные данные. Для этого используется Room — библиотека поверх SQLite, которая позволяет хранить объекты прямо в телефоне.

Room состоит из трех компонентов:

1. Entity (Сущность): Класс данных, который станет таблицей в базе.

@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    val name: String,
    val email: String
)

2. DAO (Data Access Object): Интерфейс для управления данными (INSERT, DELETE, SELECT).

@Dao
interface UserDao {
    @Query("SELECT * FROM users")
    fun getAll(): List<User>

    @Insert
    fun insert(user: User)
}

3. Database: Абстрактный класс, объединяющий всё вместе.

Связываем всё вместе: Repository

В архитектуре MVVM часто выделяют еще один слой — Repository (Репозиторий). Это класс, который решает, откуда брать данные: из базы (Room) или из сети (Retrofit).

• Если есть интернет -> качаем через Retrofit -> сохраняем в Room -> отдаем ViewModel.
• Если нет интернета -> берем из Room -> отдаем ViewModel.

Таким образом, ViewModel (и тем более View) даже не знает, откуда пришли данные. Это делает код чистым и тестируемым.

Заключение

Сегодня мы сделали огромный шаг вперед. Мы превратили наше приложение из простой «картинки» в сложную систему, которая:

• Учитывает жизненный цикл Android и не падает при повороте экрана.
• Использует архитектуру MVVM для разделения ответственности.
• Умеет ходить в сеть с помощью Retrofit.
• Сохраняет данные локально с помощью Room.

В следующей статье мы займемся «полировкой»: изучим Dependency Injection (Hilt) для еще более гибкой архитектуры и настроим фоновую работу с помощью WorkManager.

Асинхронность и фоновые задачи: использование Coroutines, Flow и WorkManager для оптимизации работы

Добро пожаловать на четвертый этап нашего курса «Разработка Android-приложений». В прошлой статье мы построили надежную архитектуру MVVM и научились получать данные из сети (Retrofit) и базы данных (Room). Но мы лишь вскользь коснулись того, как именно эти операции выполняются, не замораживая экран смартфона.

Сегодня мы погрузимся в мир асинхронного программирования. Мы разберем, как выполнять тяжелые задачи параллельно, как обрабатывать потоки данных в реальном времени и как гарантировать выполнение задачи, даже если пользователь закрыл приложение.

Главный поток и проблема блокировки

В Android существует понятие Main Thread (главный поток), также известный как UI Thread. Он отвечает за отрисовку интерфейса и обработку нажатий. Этот поток работает как бесконечный цикл, обновляющий экран 60 (или более) раз в секунду.

Если вы запустите тяжелую задачу (например, скачивание файла или сложный расчет) в главном потоке, он «застрянет». Интерфейс перестанет реагировать, анимации застынут, и через несколько секунд система покажет диалог ANR (Application Not Responding).

Чтобы этого избежать, мы должны выносить работу в фоновые потоки. В современном Android для этого используются Kotlin Coroutines.

Часть 1: Kotlin Coroutines (Корутины)

Корутины — это шаблон проектирования, который позволяет писать асинхронный код так же просто, как обычный синхронный. Часто их называют «легковесными потоками».

Ключевое слово suspend

Основа корутин — функции с модификатором suspend. Такая функция может приостановить выполнение кода, не блокируя поток, и возобновить его позже.

// Обычная функция
fun simpleFunction() { }

// Приостанавливаемая функция
suspend fun fetchUserData(): User {
    // Имитация долгой работы
    delay(1000)
    return User("Alex")
}

Когда Kotlin встречает suspend функцию, он «замораживает» состояние текущей функции, освобождает поток для других задач (например, отрисовки UI), а когда результат готов — возвращается к выполнению.

CoroutineScope и Dispatchers

Корутины не могут жить в вакууме. Им нужна область видимости (Scope) и диспетчер (Dispatcher), который решает, на каком потоке выполнять код.

Основные Dispatchers:

1. Dispatchers.Main: Главный поток. Используется только для обновления UI и быстрых операций.
2. Dispatchers.IO: Оптимизирован для ввода-вывода (сеть, база данных, чтение файлов). Именно его используют Retrofit и Room под капотом.
3. Dispatchers.Default: Оптимизирован для нагрузок на процессор (CPU intensive). Используется для сложных вычислений, обработки изображений, парсинга больших JSON.

Structured Concurrency (Структурированная конкурентность)

В Android мы редко создаем Scope вручную. Архитектурные компоненты предоставляют готовые решения:

• viewModelScope: Корутина живет, пока жива ViewModel. Если пользователь уходит с экрана, и ViewModel очищается, все запущенные здесь корутины автоматически отменяются. Это предотвращает утечки памяти.
• lifecycleScope: Привязан к жизненному циклу Activity или Fragment.

Пример запуска корутины во ViewModel:

class UserViewModel : ViewModel() {
    fun loadData() {
        viewModelScope.launch {
            // Мы в главном потоке (Main)
            try {
                // Переключаемся на IO для загрузки
                val user = repository.getUser()
                // Автоматически вернулись в Main для обновления UI
                _userLiveData.value = user
            } catch (e: Exception) {
                // Обработка ошибок
            }
        }
    }
}

Эффективность параллелизма: немного математики

Представьте, что нам нужно загрузить данные профиля пользователя и список его друзей. Это два независимых запроса.

Если выполнять их последовательно (синхронно), общее время $T_{seq}$ будет равно сумме времени каждого запроса:

$$T_{seq} = t_{profile} + t_{friends}$$

Где:

• $T_{seq}$ — общее время последовательного выполнения.
• $t_{profile}$ — время загрузки профиля.
• $t_{friends}$ — время загрузки друзей.

Если же мы запустим их параллельно с помощью функции async, общее время $T_{par}$ будет определяться самым медленным запросом:

$$T_{par} = \max(t_{profile}, t_{friends})$$

Где:

• $T_{par}$ — общее время параллельного выполнения.
• $\max(...)$ — функция выбора максимального значения из аргументов.

Пример на Kotlin:

viewModelScope.launch {
    val profileDeferred = async { api.getProfile() }
    val friendsDeferred = async { api.getFriends() }

    // Ждем оба результата
    val profile = profileDeferred.await()
    val friends = friendsDeferred.await()

    updateUi(profile, friends)
}

Это позволяет существенно ускорить загрузку данных на экране.

Часть 2: Kotlin Flow (Потоки данных)

suspend функции отлично подходят для разовых операций (запрос -> ответ). Но что, если данные меняются со временем? Например, мы хотим получать обновления геолокации, статус загрузки файла или сообщения из чата в реальном времени.

Для этого используется Kotlin Flow. Это асинхронный поток данных, который выдает значения последовательно.

Холодные потоки (Cold Streams)

Обычный Flow является «холодным». Это значит, что код внутри него не выполняется, пока кто-то не начнет «собирать» (collect) данные.

fun getTimerFlow(): Flow<Int> = flow {
    for (i in 1..10) {
        delay(1000) // Ждем секунду
        emit(i)     // Выдаем значение (эмиссия)
    }
}

StateFlow и SharedFlow

В современной Android-разработке LiveData постепенно вытесняется специальными видами Flow:

1. StateFlow: Хранит состояние. Всегда имеет начальное значение. Это идеальная замена LiveData во ViewModel. Он «горячий» — хранит значение, даже если никто не слушает.
2. SharedFlow: Используется для разовых событий (например, показать всплывающее сообщение Toast или навигация). В отличие от StateFlow, он не хранит последнее значение для новых подписчиков по умолчанию.

Пример использования StateFlow во ViewModel:

private val _uiState = MutableStateFlow(MyUiState.Loading)
val uiState: StateFlow<MyUiState> = _uiState.asStateFlow()

fun updateData() {
    _uiState.value = MyUiState.Success(data)
}

Сбор данных в Activity/Fragment (с учетом жизненного цикла):

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.uiState.collect { state ->
            // Обновляем UI
        }
    }
}

Часть 3: WorkManager — гарантированное выполнение

Корутины и Flow привязаны к жизненному циклу приложения. Если пользователь смахнет приложение из списка запущенных, все корутины будут отменены. Но что, если нам нужно отправить важную аналитику, загрузить фото на сервер или синхронизировать базу данных, и это должно произойти обязательно, даже если приложение закрыто?

Здесь на сцену выходит WorkManager.

WorkManager — это библиотека для планирования отложенных асинхронных задач, которые должны быть выполнены гарантированно.

Когда использовать WorkManager?

• Отправка логов или аналитики.
• Резервное копирование данных.
• Периодическая синхронизация с сервером.
• Загрузка больших файлов.

Не используйте WorkManager для задач, результат которых нужен пользователю «прямо сейчас» (для этого есть Coroutines).

Основные компоненты

1. Worker: Класс, где описывается сама работа.
2. WorkRequest: Запрос на выполнение (разовый или периодический).
3. WorkManager: Системный сервис, который ставит задачу в очередь.

Пример реализации

Создадим Worker для загрузки логов:

class UploadWorker(context: Context, params: WorkerParameters) :
    CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            // Имитация отправки данных
            uploadLogs()
            Result.success()
        } catch (e: Exception) {
            // Если ошибка, WorkManager попробует позже
            Result.retry()
        }
    }
}

Запуск задачи с условиями (Constraints):

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.UNMETERED) // Только Wi-Fi
    .setRequiresCharging(true)                     // Только на зарядке
    .build()

val uploadRequest = OneTimeWorkRequestBuilder<UploadWorker>()
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context).enqueue(uploadRequest)

В этом примере задача запустится только тогда, когда телефон подключится к Wi-Fi и будет стоять на зарядке. Система сама разбудит приложение для выполнения кода.

Заключение

Сегодня мы разобрали три кита асинхронности в Android:

1. Coroutines — для выполнения операций здесь и сейчас без блокировки UI.
2. Flow — для работы с потоками данных и реактивного обновления интерфейса.
3. WorkManager — для надежных фоновых задач, которые должны пережить закрытие приложения.

Понимание этих инструментов критически важно для создания плавных и энергоэффективных приложений. В следующей статье мы перейдем к теме, которая делает архитектуру по-настоящему гибкой и модульной — Внедрение зависимостей (Dependency Injection) с помощью Hilt.

Дополнительные материалы:

• Официальная документация по Coroutines
• Гайд по WorkManager

Завершение разработки: тестирование, отладка, сборка приложения и публикация в Google Play

Поздравляю! Если вы читаете эту статью, значит, вы прошли долгий путь. Мы начали с установки Android Studio, изучили Kotlin, сверстали интерфейс, настроили архитектуру MVVM и научились работать с сетью и базами данных. Ваше приложение почти готово. Но «почти» в разработке — это самый коварный этап.

Написание кода — это лишь половина дела. Вторая половина — это обеспечение качества, оптимизация и доставка продукта пользователю. Сегодня мы превратим ваш проект из «рабочего прототипа» в профессиональный продукт, готовый к загрузке в Google Play.

Часть 1: Отладка и поиск ошибок (Debugging)

Даже опытные разработчики пишут код с ошибками. Это нормально. Главное — уметь их находить. В Android Studio есть мощные инструменты для этого.

Logcat: Глаза разработчика

Самый простой способ понять, что происходит в приложении — это логирование. Класс Log позволяет выводить сообщения в системную консоль Logcat.

Log.d("UserProfile", "User id: $id loaded successfully")
Log.e("UserProfile", "Error loading user", exception)

Уровни логирования (по возрастанию важности):

• Verbose (v): Все подряд.
• Debug (d): Отладочная информация (полезна при разработке).
• Info (i): Информационные сообщения.
• Warning (w): Предупреждения (что-то пошло не так, но не критично).
• Error (e): Ошибки (приложение может упасть).

Breakpoints (Точки останова)

Логи — это хорошо, но иногда нужно остановить время. Нажав на поле слева от строки кода, вы поставите красную точку — Breakpoint. Запустив приложение в режиме Debug (значок жука), выполнение программы остановится в этом месте.

Вы сможете:

• Посмотреть текущие значения всех переменных.
• Выполнять код пошагово (Step Over, Step Into).
• Изменять значения переменных «на лету», чтобы проверить гипотезы.

Часть 2: Тестирование приложения

Многие новички пропускают этот этап, считая, что «я и так проверил руками». Но ручное тестирование не масштабируется. При добавлении новой фичи вы можете случайно сломать старую (это называется регрессией).

В Android существует пирамида тестирования.

1. Unit-тесты (Модульные тесты)

Это фундамент. Они проверяют отдельные классы и функции (например, ViewModel или математические вычисления) в изоляции. Они работают быстро, так как запускаются на компьютере (JVM), а не на эмуляторе.

Для оценки покрытия кода тестами часто используют метрику Code Coverage. Она рассчитывается по формуле:

$$C = \frac{L_{exec}}{L_{total}} \times 100\%$$

Где:

• $C$ — покрытие кода в процентах (Code Coverage).
• $L_{exec}$ — количество строк кода, выполненных во время тестов (Lines executed).
• $L_{total}$ — общее количество строк кода в проверяемом модуле (Total lines).

Если $C < 80\%$, считается, что проект протестирован недостаточно хорошо, хотя стремление к 100% часто экономически нецелесообразно.

Пример теста на JUnit:

@Test
fun `addition is correct`() {
    val calculator = Calculator()
    assertEquals(4, calculator.add(2, 2))
}

2. UI-тесты (Инструментальные тесты)

Они запускаются на реальном устройстве или эмуляторе и имитируют действия пользователя: нажатия, свайпы, ввод текста. Основная библиотека — Espresso.

@Test
fun checkTextOnScreen() {
    // Найти кнопку с ID button_login и нажать её
    onView(withId(R.id.button_login)).perform(click())
    // Проверить, что появился текст "Welcome"
    onView(withText("Welcome")).check(matches(isDisplayed()))
}

Часть 3: Подготовка к сборке (Build Configuration)

Перед публикацией нужно настроить файл build.gradle.kts (Module :app).

Версионирование

Google Play различает версии вашего приложения по двум параметрам:

1. versionCode: Целое число (1, 2, 3...). Оно должно увеличиваться с каждым обновлением. Если вы загрузили сборку с кодом 5, загрузить код 4 уже нельзя.
2. versionName: Строка для пользователей (например, "1.0" или "2.1.5-beta"). Не влияет на логику магазина.

Обфускация и минификация (R8)

В Android встроен инструмент R8 (ранее ProGuard). Он выполняет три задачи:

1. Shrinking (Сжатие): Удаляет неиспользуемый код и ресурсы.
2. Obfuscation (Обфускация): Переименовывает классы и методы в короткие бессмысленные имена (a.b.c()), чтобы затруднить реверс-инжиниринг (взлом) приложения.
3. Optimization (Оптимизация): Улучшает байт-код для более быстрой работы.

Чтобы включить R8 для релизной сборки:

buildTypes {
    release {
        isMinifyEnabled = true // Включает R8
        isShrinkResources = true // Удаляет лишние картинки и файлы
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}

Часть 4: Подписание приложения (App Signing)

Android требует, чтобы все APK/AAB были подписаны цифровым сертификатом. Это гарантирует, что обновление приложения пришло именно от вас, а не от злоумышленника.

Для этого создается Keystore (хранилище ключей) — файл с расширением .jks.

Критически важно: Никогда не теряйте файл Keystore и пароль от него. Если вы его потеряете, вы никогда не сможете обновить свое приложение в Google Play. Вам придется создавать новое приложение с другим именем пакета и терять всех пользователей.

В Android Studio процесс создания подписи автоматизирован через меню Build > Generate Signed Bundle / APK.

Часть 5: Android App Bundle (AAB) против APK

Раньше мы собирали APK (Android Package) — один большой файл, который содержал ресурсы для всех экранов и языков. Пользователь скачивал лишние мегабайты.

С 2021 года Google Play требует формат AAB (Android App Bundle).

Преимущества AAB:

• Dynamic Delivery: Google Play сам собирает APK под конкретное устройство пользователя (нужное разрешение экрана, нужная архитектура процессора, нужный язык).
• Меньший размер: Пользователь скачивает в среднем на 15-20% меньше данных.

Часть 6: Публикация в Google Play Console

Финальный шаг — выложить ваше творение в магазин.

1. Регистрация аккаунта разработчика

Вам нужно зайти на Google Play Console и оплатить единоразовый взнос (обычно $25). После этого вы можете публиковать неограниченное количество приложений.

2. Создание страницы приложения

Вам нужно заполнить:

• Название и краткое описание.
• Полное описание (важно для ASO — поиска в магазине).
• Графика: иконка (512x512), картинка для описания (1024x500), скриншоты телефона (минимум 2) и планшета.
• Политика конфиденциальности (ссылка на документ).

3. Треки выпуска (Release Tracks)

Не обязательно сразу выкатывать приложение на миллиард пользователей. Google Play предлагает систему треков:

1. Internal Testing (Внутреннее тестирование): Доступно только вам и вашей команде (до 100 человек). Сборка появляется почти мгновенно.
2. Closed Testing (Закрытое тестирование / Alpha): Для ограниченного круга приглашенных пользователей.
3. Open Testing (Открытое тестирование / Beta): Любой желающий может присоединиться к тесту со страницы магазина.
4. Production (Продакшн): Релиз для всех.

4. Проверка (Review)

После отправки приложения на проверку, модераторы Google (и боты) будут его тестировать. Это занимает от нескольких часов до 7 дней (для новых аккаунтов дольше). Они проверяют соответствие правилам: отсутствие вредоносного кода, корректность возрастного рейтинга, соблюдение авторских прав.

Заключение курса

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

Разработка под Android — это непрерывный процесс обучения. Google выпускает новые библиотеки, меняются подходы (как переход с XML на Compose), появляются новые форм-факторы устройств. Но фундамент, который вы получили в этом курсе — понимание Kotlin, жизненного цикла, работы с данными и архитектуры — останется актуальным всегда.

Удачи в публикации вашего первого проекта! Мир ждет ваши идеи.