Jetpack — mi ez, architektúra összetevők

Mi az Android Jetpack?

Android Jetpack — a Google könyvtár-, eszköz- és architektúra-ajánlásgyűjteménye, amelyet 2018-ban mutattak be a Google I/O-n. A Jetpack felváltotta a Support Library-t és az Android Architecture Components-ot, egyetlen ökoszisztémába egyesítve azokat. A Jetpack előtt minden Android könyvtár függetlenül frissült, ami verzióütközéseket okozott. A Jetpack szinkronizálta a verziókat egy egységes AndroidX azonosító alatt, és bevezette a stabil főverziók modelljét kisebb javításokkal.

A Jetpack könyvtárai négy kategóriába oszlanak: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Minden kategória az alkalmazás egy adott rétegének feladatait oldja meg — az adatkezeléstől a felhasználói felületig.

A Jetpack filozófiája

A Google három Jetpack elvet hirdet: accelerate development (kevesebb boilerplate, több üzleti logika), eliminate boilerplate (a ViewModel kiküszöböli a kézi állapotmentést, a Room pedig a SQLiteOpenHelper írását) és build with confidence (minden könyvtár 15+ ezer teszten megy keresztül a kiadás előtt). Az Android Developers (2026) szerint a Jetpack alkalmazások 30%-kal kevesebb életciklushoz kapcsolódó összeomlást tapasztalnak.

AndroidX mint alap

Minden Jetpack könyvtár AndroidX azonosító alatt kerül terjesztésre (androidx.* formájú artefaktumok). Az AndroidX felváltotta a Support Library-t (com.android.support.* artefaktumok), a monolitikus könyvtárat moduláris, független verziószámozású artefaktumokra bontva. Az AndroidX-re való migráció a android.useAndroidX=true opcióval történik a gradle.properties-ben — az Android Studio automatikusan konvertálja az importokat.

Architektúra összetevők: ViewModel, Lifecycle, LiveData

ViewModel — a Jetpack architektúra központi összetevője, amely tárolja az UI adatokat. Ellentétben az Activity-vel, amely a képernyő forgatásakor megsemmisül, a ViewModel a memóriában marad. A felhasználó kitölt egy űrlapot, elforgatja a telefont — az adatok nem vesznek el. A ViewModel automatikusan törlődik, amikor a LifecycleOwner (Activity vagy Fragment) véglegesen befejezi életciklusát (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("Képernyő elindult")
    }
}

LiveData — egy megfigyelhető adattároló, amely figyelembe veszi az életciklust. Ha a képernyő nem látható (onStop), a LiveData nem küld frissítéseket — ez megakadályozza a memóriaszivárgást és az összeomlásokat, amikor egy nem létező Activity-t próbálunk frissíteni. Lifecycle — egy osztály, amely tárolja az aktuális állapotot (CREATED, STARTED, RESUMED), és lehetővé teszi más összetevők számára, hogy feliratkozzanak az állapotváltozásokra. A ViewModel, LiveData és Lifecycle együtt képezik a reaktív Android architektúra alapját.

ViewModelScope és korutinok

viewModelScope — egy beépített CoroutineScope, amely a ViewModel életciklusához van kötve. Az ebben a scope-ban elindított összes korutin automatikusan törlődik a ViewModel tisztításakor. Ez kiküszöböli a Disposable és CompositeDisposable kézi kezelését minden ViewModel-ben. A viewModelScope használatához az androidx.lifecycle:lifecycle-viewmodel-ktx függőség szükséges.

Room: adatbázis-kezelés Androidon

Room — a Jetpack ORM könyvtára, amely absztrakt réteget biztosít az SQLite felett. A nyers SQL lekérdezések írása és a Cursor kézi objektummá alakítása helyett a fejlesztő Entity (tábla), DAO (Data Access Object) és Database (belépési pont) deklarál. A Room a @Query annotáción keresztül ellenőrzi az SQL lekérdezéseket fordítási időben — ha a táblák vagy oszlopok nem léteznek, a build érthető hibával meghiúsul.

@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
}

Az Entity User egy háromoszlopos táblát ír le. A DAO suspend-függvényeket deklarál a korutinokkal való munkához — a lekérdezés automatikusan a háttérszálon fut. Room támogatja a migrációt a @Migration annotáción keresztül: a fejlesztő leírja a verziók közötti átmenet SQL szkriptjét, és a Room adatvesztés nélkül hajtja végre. Migráció hiányában a Room IllegalStateException-t dob — így a projektek védve vannak a véletlen adatvesztéstől a séma frissítésekor.

TypeConverters és kapcsolatok

A Room csak primitív típusokat és azok burkolóit tárolja. Listák, Date vagy egyedi objektumok tárolásához a @TypeConverter használatos — egy statikus metódus, amely a típust String (JSON) vagy Long (timestamp) értékké alakítja. A táblák közötti kapcsolatok egymásba ágyazott objektumokkal, @Relation annotációval és @Transaction segéd POJO osztályokkal modellezhetők a hatékony join lekérdezésekhez.

Navigation Component: gráfok és argumentumok

Navigation Component — a Jetpack könyvtára a képernyők közötti átmenetek kezelésére. A FragmentTransaction kézi meghívása helyett a fejlesztő navigációs gráfot hoz létre (XML fájl csomópont-célokkal), a rendszer pedig legenerálja a Directions osztályt type-safe átmeneti metódusokkal. A Navigation Component garantálja a back stack, a deep linkek és a képernyők közötti argumentumátadás helyes működését.

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

// A fragment kódjában:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

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

Az userId argumentumok a navigációs gráfban kerülnek átadásra a típus (integer) és az alapértelmezett érték megadásával. A ProfileFragmentArgs osztályt a Navigation Safe Args plugin automatikusan generálja — tartalmazza az összes argumentumot a helyes Kotlin típusokkal. A mély linkek a gráfban konfigurálhatók: app:deepLink="app://profile/{userId}". A Navigation Component maga elemzi ki az URL-t, és úgy hozza létre a back stack-et, mintha a felhasználó a felületen navigált volna.

Bottom Navigation és Conditional Navigation

A Navigation Component a NavController-ön keresztül integrálódik a BottomNavigationView-val: minden menüpont egy célhoz van kötve a gráfban. A lapok közötti váltás nem hozza létre újra a fragmentet — a Navigation Component a NavBackStackEntry-n keresztül megőrzi az állapotot. Feltételes navigációhoz (bejelentkezés megjelenítése, ha nincs hitelesítve) a navController.navigate(condition) használható onCreate-ben történő ellenőrzéssel.

AndroidX: az új generációs Support Library

AndroidX — a Support Library újratervezett architektúrája, amelyben minden könyvtár saját, független verziójú artefaktumot kapott. Az egyetlen com.android.support:appcompat-v7:28.0.0 helyett az AndroidX androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 és így tovább kínál. Ez megoldotta azt a problémát, amikor a különböző függőségek a Support Library különböző verzióit húzták be, ütközést okozva.

Az AndroidX-re való migráció automatikusan történik az Android Studio 3.2+-ban a Refactor → Migrate to AndroidX menüponton keresztül. A Studio lecseréli az összes importot a Java/Kotlin fájlokban, manifestekben és erőforrásokban. Visszafelé kompatibilitás — az AndroidX fő előnye: a könyvtárak Android 5.0 (API 21) és magasabb verziókon működnek, lefedve az aktív eszközök 97%-át a Google Play Console (2025) szerint.

Fő AndroidX artefaktumok

A leggyakrabban használt artefaktumok: appcompat (sötét téma, Material Design régi API-ken), recyclerview (adaptív listák ViewHolder-rel), constraintlayout (rugalmas konténer lapos hierarchiával), cardview (Material Design kártyák), preference (beállítások képernyő Material stílusban). Minden artefaktum független verziószámozással rendelkezik, felgyorsítva a javítások beérkezését a teljes csomag frissítése nélkül.

Egyéb fontos Jetpack könyvtárak

Az Architecture és AndroidX mellett a Jetpack számos speciális könyvtárat tartalmaz a mobilfejlesztés tipikus feladataihoz. WorkManager — háttérfeladatokhoz garantált végrehajtással (szinkronizálás, naplók feltöltése), támogatja az időszakos és késleltetett feladatokat, valamint a hálózati és akkumulátor-korlátozásokat. DataStore — a SharedPreferences korutin-alapú helyettesítője, amely támogatja a tipizált tulajdonságokat (Preferences DataStore) és a Protocol Buffers-t (Proto DataStore).

• Hilt — Dagger-alapú DI keretrendszer, amely leegyszerűsíti a függőséginjektálást a @HiltViewModel, @Inject, @Module annotációkon keresztül. Beépített integráció a ViewModel-lel és Navigation-nel.
• Paging 3 — könyvtár adatok lapozott betöltéséhez hálózatból/adatbázisból RemoteMediator (hálózat + gyorsítótár), StateFlow és Compose támogatással.
• CameraX — API a kamerával való munkához, amely elvonatkoztatja a gyártók (Samsung, Xiaomi, Honor) közötti különbségeket egy egységes CameraController felületen keresztül.
• Security Crypto — adattitkosítás EncryptedSharedPreferences és EncryptedFile segítségével, AES-256 alapú, mesterkulccsal az Android Keystore-ban.

Minden könyvtárnak saját minimális SDK-ja és artefaktuma van. A Google évente egyszer (egybeesve az Android kiadásával) ad ki fő verziókat, és negyedévente biztonsági javításokat. Javaslat — csak a szükséges könyvtárakat csatlakoztassa, hogy ne növelje az APK méretét. A Jetpack teljes egészében (összes artefaktum) több mint 20 MB-ot nyom, de egy tipikus alkalmazás 5-7 könyvtárat használ, 3-5 MB-ot adva az APK-hoz.