Jetpack — це набір бібліотек Android від Google, які спрощують розробку та прискорюють створення стабільних застосунків. Компоненти на кшталт ViewModel, Room та Navigation вирішують типові завдання: керування життєвим циклом, зберігання даних та навігація. За даними Android Developers (2026), Jetpack охоплює понад 50 бібліотек, кожна з яких зворотно сумісна з Android 5.0 (API 21) через AndroidX — бібліотеку сумісності, що замінила Support Library.
Головне
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). Кожна категорія вирішує завдання певного шару застосунку — від керування даними до інтерфейсу користувача.
Google просуває три принципи Jetpack: accelerate development (менше шаблонного коду, більше бізнес-логіки), eliminate boilerplate (ViewModel позбавляє від ручного збереження стану, Room — від написання SQLiteOpenHelper) та build with confidence (кожна бібліотека проходить 15+ тисяч тестів перед релізом). За даними Android Developers (2026), застосунки на Jetpack мають на 30% менше збоїв, пов'язаних із життєвим циклом.
Всі бібліотеки Jetpack поширюються під ідентифікатором AndroidX (артефакти виду androidx.*). AndroidX замінив Support Library (артефакти com.android.support.*), розділивши монолітну бібліотеку на модульні артефакти з незалежним версіонуванням. Міграція на AndroidX виконується через опцію android.useAndroidX=true у gradle.properties — Android Studio автоматично конвертує імпорти.
ViewModel — центральний компонент архітектури Jetpack, що зберігає дані UI. На відміну від Activity, яка знищується при повороті екрану, ViewModel залишається в пам'яті. Користувач заповнює форму, повертає телефон — дані не втрачаються. ViewModel автоматично очищається, коли LifecycleOwner (Activity або Fragment) завершує свій життєвий цикл назавжди (finish).
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 — вбудований CoroutineScope, прив'язаний до життєвого циклу ViewModel. Всі корутини, запущені в цьому scope, автоматично скасовуються при очищенні ViewModel. Це позбавляє від ручного керування Disposable та CompositeDisposable у кожній ViewModel. Для роботи з viewModelScope потрібна залежність androidx.lifecycle:lifecycle-viewmodel-ktx.
Room — це ORM-бібліотека Jetpack, що надає абстрактний шар над SQLite. Замість написання сирих SQL-запитів та ручного перетворення Cursor в об'єкти, розробник оголошує Entity (таблицю), DAO (Data Access Object) та Database (точку входу). Room перевіряє SQL-запити на етапі компіляції через анотацію @Query — якщо таблиці або колонки не існують, збірка падає зі зрозумілою помилкою.
@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 — так проєкти захищені від випадкової втрати даних при оновленні схеми.
Room зберігає лише примітивні типи та їх обгортки. Для зберігання списків, Date або кастомних об'єктів використовується @TypeConverter — статичний метод, що перетворює тип у String (JSON) або Long (timestamp). Відношення між таблицями моделюються через вкладені об'єкти з анотацією @Relation та допоміжні POJO-класи з @Transaction для ефективних join-запитів.
Navigation Component — бібліотека Jetpack для керування переходами між екранами. Замість ручного виклику FragmentTransaction розробник створює граф навігації (XML-файл з вузлами-дестинаціями), а система генерує клас Directions з типобезпечними методами переходів. Navigation Component гарантує коректну роботу back stack, deep links та передачі аргументів між екранами.
// 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 та створює бекстек, ніби користувач пройшов через інтерфейс.
Navigation Component інтегрується з BottomNavigationView через NavController: кожен пункт меню прив'язується до дестинації в графі. Перехід між табами не перестворює фрагмент — Navigation Component зберігає стан через NavBackStackEntry. Для умовної навігації (показати логін, якщо не авторизовано) використовується navController.navigate(condition) з перевіркою в onCreate.
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).
Найчастіше використовувані артефакти: appcompat (темна тема, Material Design на старих API), recyclerview (адаптивні списки з ViewHolder), constraintlayout (гнучкий контейнер з пласкою ієрархією), cardview (картки Material Design), preference (екран налаштувань з Material-стилем). Кожен артефакт версіонується незалежно, прискорюючи отримання виправлень без оновлення всього пакета.
Окрім Architecture та AndroidX, Jetpack включає безліч спеціалізованих бібліотек для типових завдань мобільної розробки. WorkManager — для фонових завдань з гарантованим виконанням (синхронізація, завантаження логів), підтримує періодичні та відкладені завдання, а також обмеження по мережі та батареї. DataStore — заміна SharedPreferences на основі корутин, що підтримує типізовані властивості (Preferences DataStore) та Protocol Buffers (Proto DataStore).
Кожна бібліотека має власний мінімальний SDK та артефакт. Google випускає мажорні версії раз на рік (збігаючись з релізом Android) та патчі безпеки — щоквартально. Рекомендація — підключати тільки необхідні бібліотеки, щоб не збільшувати розмір APK. Jetpack у зборі (всі артефакти) важить понад 20 МБ, але типовий застосунок використовує 5–7 бібліотек, додаючи до APK 3–5 МБ.
Часті запитання
Так, Google припинила підтримку Support Library у 2019 році. Всі нові бібліотеки Jetpack та Google Play Services вимагають AndroidX. Міграція виконується за 30–60 хвилин через Android Studio.
Jetpack повністю сумісний з Java. Однак багато фіч (viewModelScope, корутини, Compose) доступні тільки на Kotlin. Google рекомендує Kotlin для нових проєктів.
ViewModel зберігає об'єкти в пам'яті та переживає поворот. onSaveInstanceState підходить тільки для серіалізованих примітивів (Bundle). ViewModel не зберігається при знищенні процесу — для цього потрібен SavedStateHandle.
WorkManager — для завдань, які мають виконатися навіть після закриття застосунку: синхронізація, завантаження логів, надсилання аналітики. Корутини — для завдань, прив'язаних до екрана.
Замініть імпорти SharedPreferences на DataStoredataStore.data.first() (suspend), запис через dataStore.edit { ... }. DataStore асинхронний та захищений від ANR.
Підсумки
Ми розробимо мобільний застосунок під ключ
IT Sectr створює застосунки для iOS та Android для стартапів і бізнесу з 2017 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.