Jetpack — що це таке, компоненти архітектури

Автор: IT Sectr Опубліковано: 2026-05-01 Час читання: 9 хв

Jetpack — це набір бібліотек Android від Google, які спрощують розробку та прискорюють створення стабільних застосунків. Компоненти на кшталт ViewModel, Room та Navigation вирішують типові завдання: керування життєвим циклом, зберігання даних та навігація. За даними Android Developers (2026), Jetpack охоплює понад 50 бібліотек, кожна з яких зворотно сумісна з Android 5.0 (API 21) через AndroidX — бібліотеку сумісності, що замінила Support Library.

Головне

  • Android Jetpack — набір із 50+ бібліотек, що прискорюють розробку Android-застосунків та забезпечують зворотну сумісність через AndroidX.
  • ViewModel переживає повороти екрану та зберігає дані при перестворенні Activity, запобігаючи втраті введених користувачем даних.
  • Room — ORM-прошарок над SQLite з перевіркою SQL-запитів на етапі компіляції та підтримкою корутин.
  • Navigation Component керує переходами між екранами через графи навігації з типобезпечними аргументами.
  • Lifecycle дозволяє реагувати на події життєвого циклу Activity/Fragment без шаблонного коду в контролерах.

Що таке Android Jetpack?

Android Jetpack — це колекція бібліотек, інструментів та архітектурних рекомендацій від Google, представлена у 2018 році на Google I/O. Jetpack прийшов на зміну Support Library та Android Architecture Components, об'єднавши їх в єдину екосистему. До Jetpack кожна бібліотека Android оновлювалася незалежно, що створювало конфлікти версій. Jetpack синхронізував версії під єдиним ідентифікатором AndroidX та ввів модель стабільних мажорних версій з мінорними патчами.

Бібліотеки Jetpack поділяються на чотири категорії: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Кожна категорія вирішує завдання певного шару застосунку — від керування даними до інтерфейсу користувача.

Філософія Jetpack

Google просуває три принципи Jetpack: accelerate development (менше шаблонного коду, більше бізнес-логіки), eliminate boilerplate (ViewModel позбавляє від ручного збереження стану, Room — від написання SQLiteOpenHelper) та build with confidence (кожна бібліотека проходить 15+ тисяч тестів перед релізом). За даними Android Developers (2026), застосунки на Jetpack мають на 30% менше збоїв, пов'язаних із життєвим циклом.

AndroidX як основа

Всі бібліотеки Jetpack поширюються під ідентифікатором AndroidX (артефакти виду androidx.*). AndroidX замінив Support Library (артефакти com.android.support.*), розділивши монолітну бібліотеку на модульні артефакти з незалежним версіонуванням. Міграція на AndroidX виконується через опцію android.useAndroidX=true у gradle.properties — Android Studio автоматично конвертує імпорти.

Архітектурні компоненти: ViewModel, Lifecycle, LiveData

ViewModel — центральний компонент архітектури Jetpack, що зберігає дані UI. На відміну від Activity, яка знищується при повороті екрану, ViewModel залишається в пам'яті. Користувач заповнює форму, повертає телефон — дані не втрачаються. ViewModel автоматично очищається, коли LifecycleOwner (Activity або Fragment) завершує свій життєвий цикл назавжди (finish).

kotlin
class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("Екран запущено")
    }
}

LiveData — спостережуваний контейнер для даних, що враховує життєвий цикл. Якщо екран не видно (onStop), LiveData не надсилає оновлення — це запобігає витокам пам'яті та збоям при спробі оновити неіснуючу Activity. Lifecycle — клас, що зберігає поточний стан (CREATED, STARTED, RESUMED) та дозволяє іншим компонентам підписуватися на зміни стану. Разом ViewModel, LiveData та Lifecycle утворюють фундамент реактивної архітектури Android.

ViewModelScope та корутини

viewModelScope — вбудований CoroutineScope, прив'язаний до життєвого циклу ViewModel. Всі корутини, запущені в цьому scope, автоматично скасовуються при очищенні ViewModel. Це позбавляє від ручного керування Disposable та CompositeDisposable у кожній ViewModel. Для роботи з viewModelScope потрібна залежність androidx.lifecycle:lifecycle-viewmodel-ktx.

Room: робота з базою даних на Android

Room — це ORM-бібліотека Jetpack, що надає абстрактний шар над SQLite. Замість написання сирих SQL-запитів та ручного перетворення Cursor в об'єкти, розробник оголошує Entity (таблицю), DAO (Data Access Object) та Database (точку входу). Room перевіряє SQL-запити на етапі компіляції через анотацію @Query — якщо таблиці або колонки не існують, збірка падає зі зрозумілою помилкою.

kotlin
@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Entity User описує таблицю з трьома колонками. DAO оголошує suspend-функції для роботи з корутинами — запит виконується на фоновому потоці автоматично. Room підтримує міграції через анотацію @Migration: розробник описує SQL-скрипт переходу між версіями, і Room виконує його без втрати даних. При відсутності міграції Room падає з IllegalStateException — так проєкти захищені від випадкової втрати даних при оновленні схеми.

TypeConverters та відношення

Room зберігає лише примітивні типи та їх обгортки. Для зберігання списків, Date або кастомних об'єктів використовується @TypeConverter — статичний метод, що перетворює тип у String (JSON) або Long (timestamp). Відношення між таблицями моделюються через вкладені об'єкти з анотацією @Relation та допоміжні POJO-класи з @Transaction для ефективних join-запитів.

Navigation Component — бібліотека Jetpack для керування переходами між екранами. Замість ручного виклику FragmentTransaction розробник створює граф навігації (XML-файл з вузлами-дестинаціями), а система генерує клас Directions з типобезпечними методами переходів. Navigation Component гарантує коректну роботу back stack, deep links та передачі аргументів між екранами.

kotlin
// nav_graph.xml
// 
//     android:name=".ProfileFragment">
//     
//         android:defaultValue="-1"
//         app:argType="integer" />
// 

// У коді фрагмента:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

Аргументи userId передаються в графі навігації із зазначенням типу (integer) та значення за замовчуванням. Клас ProfileFragmentArgs генерується автоматично плагіном Navigation Safe Args — він містить всі аргументи з правильними типами Kotlin. Глибокі посилання налаштовуються в графі: app:deepLink="app://profile/{userId}". Navigation Component сама розбирає URL та створює бекстек, ніби користувач пройшов через інтерфейс.

Bottom Navigation та Conditional Navigation

Navigation Component інтегрується з BottomNavigationView через NavController: кожен пункт меню прив'язується до дестинації в графі. Перехід між табами не перестворює фрагмент — Navigation Component зберігає стан через NavBackStackEntry. Для умовної навігації (показати логін, якщо не авторизовано) використовується navController.navigate(condition) з перевіркою в onCreate.

AndroidX: Support Library нового покоління

AndroidX — це перероблена архітектура Support Library, у якій кожна бібліотека отримала власний артефакт з незалежною версією. Замість єдиного com.android.support:appcompat-v7:28.0.0 AndroidX пропонує androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 і так далі. Це усунуло проблему, коли різні залежності тягнули різні версії Support Library, викликаючи конфлікт.

Міграція на AndroidX виконується автоматично в Android Studio 3.2+ через меню Refactor → Migrate to AndroidX. Студія замінює всі імпорти в Java/Kotlin-файлах, маніфестах та ресурсах. Зворотна сумісність — головна перевага AndroidX: бібліотеки працюють на Android 5.0 (API 21) і вище, покриваючи 97% активних пристроїв за даними Google Play Console (2025).

Основні артефакти AndroidX

Найчастіше використовувані артефакти: appcompat (темна тема, Material Design на старих API), recyclerview (адаптивні списки з ViewHolder), constraintlayout (гнучкий контейнер з пласкою ієрархією), cardview (картки Material Design), preference (екран налаштувань з Material-стилем). Кожен артефакт версіонується незалежно, прискорюючи отримання виправлень без оновлення всього пакета.

Інші важливі бібліотеки Jetpack

Окрім Architecture та AndroidX, Jetpack включає безліч спеціалізованих бібліотек для типових завдань мобільної розробки. WorkManager — для фонових завдань з гарантованим виконанням (синхронізація, завантаження логів), підтримує періодичні та відкладені завдання, а також обмеження по мережі та батареї. DataStore — заміна SharedPreferences на основі корутин, що підтримує типізовані властивості (Preferences DataStore) та Protocol Buffers (Proto DataStore).

  • Hilt — DI-фреймворк на основі Dagger, що спрощує впровадження залежностей через анотації @HiltViewModel, @Inject, @Module. Вбудована інтеграція з ViewModel та Navigation.
  • Paging 3 — бібліотека для посторінкового завантаження даних з мережі/БД з підтримкою RemoteMediator (мережа + кеш), StateFlow та Compose.
  • CameraX — API для роботи з камерою, що абстрагує відмінності виробників (Samsung, Xiaomi, Honor) через єдиний інтерфейс CameraController.
  • Security Crypto — шифрування даних через EncryptedSharedPreferences та EncryptedFile на основі AES-256 з майстер-ключем в Android Keystore.

Кожна бібліотека має власний мінімальний SDK та артефакт. Google випускає мажорні версії раз на рік (збігаючись з релізом Android) та патчі безпеки — щоквартально. Рекомендація — підключати тільки необхідні бібліотеки, щоб не збільшувати розмір APK. Jetpack у зборі (всі артефакти) важить понад 20 МБ, але типовий застосунок використовує 5–7 бібліотек, додаючи до APK 3–5 МБ.

Часті запитання

Чи потрібно мігрувати з Support Library на AndroidX?

Так, Google припинила підтримку Support Library у 2019 році. Всі нові бібліотеки Jetpack та Google Play Services вимагають AndroidX. Міграція виконується за 30–60 хвилин через Android Studio.

Чи можна використовувати Jetpack з Java або тільки з Kotlin?

Jetpack повністю сумісний з Java. Однак багато фіч (viewModelScope, корутини, Compose) доступні тільки на Kotlin. Google рекомендує Kotlin для нових проєктів.

Чим ViewModel відрізняється від onSaveInstanceState?

ViewModel зберігає об'єкти в пам'яті та переживає поворот. onSaveInstanceState підходить тільки для серіалізованих примітивів (Bundle). ViewModel не зберігається при знищенні процесу — для цього потрібен SavedStateHandle.

Коли використовувати WorkManager замість корутин?

WorkManager — для завдань, які мають виконатися навіть після закриття застосунку: синхронізація, завантаження логів, надсилання аналітики. Корутини — для завдань, прив'язаних до екрана.

Як мігрувати з SharedPreferences на DataStore?

Замініть імпорти SharedPreferences на DataStore. Читання через dataStore.data.first() (suspend), запис через dataStore.edit { ... }. DataStore асинхронний та захищений від ANR.

Підсумки

  • Android Jetpack — набір із 50+ бібліотек для Android-розробки, об'єднаних під AndroidX зі зворотною сумісністю до API 21.
  • ViewModel переживає повороти екрану та зберігає дані UI, а Lifecycle повідомляє компоненти про зміну стану Activity/Fragment.
  • Room — type-safe ORM над SQLite з компіляційною перевіркою запитів, міграціями та підтримкою корутин.
  • Navigation Component керує переходами через графи з типобезпечними аргументами та автоматичним deep link.
  • WorkManager гарантує виконання фонових завдань навіть після закриття застосунку, DataStore замінює SharedPreferences.
  • Jetpack ділиться на чотири категорії: Architecture, UI, Behavior, Foundation — кожна покриває свій шар застосунку.
  • Застосунки на Jetpack мають на 30% менше збоїв, пов'язаних із життєвим циклом, і швидше розробляються завдяки готовим архітектурним рішенням.

Ми розробимо мобільний застосунок під ключ

IT Sectr створює застосунки для iOS та Android для стартапів і бізнесу з 2017 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.

Обговорити проект

Читайте також