Jetpack — какво е това, компоненти на архитектурата

Какво е 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 (по-малко boilerplate, повече бизнес логика), 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).

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 — ако таблиците или колоните не съществуват, изграждането се проваля с разбираема грешка.

@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: графи и аргументи

Navigation Component — Jetpack библиотека за управление на преходите между екрани. Вместо ръчно извикване на FragmentTransaction, разработчикът създава навигационен граф (XML файл с възли-дестинации), а системата генерира клас Directions с type-safe методи за преход. Navigation Component гарантира правилна работа на back stack, deep links и предаване на аргументи между екрани.

// nav_graph.xml
// <fragment android:id="@+id/profileFragment"
//     android:name=".ProfileFragment">
//     <argument android:name="userId"
//         android:defaultValue="-1"
//         app:argType="integer" />
// </fragment>

// В кода на фрагмента:
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 и създава back stack, сякаш потребителят е навигирал през интерфейса.

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. Studio заменя всички импорти в 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 MB, но типично приложение използва 5-7 библиотеки, добавяйки 3-5 MB към APK.