onCreate — mi ez, az Activity inicializálása Androidban

Mi az onCreate Androidban

onCreate — egy visszahívás (callback) metódus, amelyet az Android hív meg egy új Activity vagy Fragment példány létrehozásakor. Ez az első belépési pont a felhasználói képernyő kódjába: az onCreate meghívása előtt semmilyen felhasználói kód nem hajtódik végre. A rendszer átadja a metódusnak a Bundle paramétert, amely vagy korábban mentett adatokat tartalmaz (újralétrehozáskor), vagy null (első indításkor).

Az onCreate metódus az android.app.Activity osztályban és az androidx.fragment.app.Fragment osztályban van definiálva. Mindkét változat hasonló feladatokat lát el: a komponens inicializálása, a UI konfigurálása és az állapot visszaállítása. A konkrét implementáció azonban eltér — az Activity a setContentView-t használja az elrendezés betöltéséhez, míg a Fragment a View-t az onCreateView-n keresztül adja vissza. A fejlesztő köteles legalább az onCreate-t felülírni az Activity-ben — enélkül az Android nem tudja megjeleníteni a képernyőt.

Az onCreate szigorúan egyszer hívódik meg az Activity példány teljes életciklusa során. Még a képernyő elforgatásakor is az új Activity példány egy új onCreate hívást kap a korábbi példány Bundle-jével. Ez a tulajdonság teszi az onCreate-t ideális helyszínné az egyszeri inicializáláshoz: adatok betöltése, adapterek létrehozása, DI komponensek konfigurálása Dagger vagy Hilt segítségével.

onCreate az Activity-ben

Az Activity-ben az onCreate metódus négy kulcsfeladatot lát el: a layout elrendezés betöltése, a View elemek inicializálása, az állapot visszaállítása a Bundle-ből és az elsődleges eseménykezelők konfigurálása. A kötelező minimális kód az onCreate-ben — a super.onCreate(savedInstanceState) és a setContentView(R.layout.activity_main) hívása.

class MainActivity : AppCompatActivity() {
    private var binding: ActivityMainBinding? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // ViewBinding — a findViewById modern helyettesítője
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding?.root)

        // Inicializálás binding segítségével
        binding?.apply {
            welcomeText.text = getString(R.string.welcome)
            startButton.setOnClickListener { startGame() }
        }

        // Állapot visszaállítása
        if (savedInstanceState != null) {
            score = savedInstanceState.getInt("score", 0)
            binding?.scoreText?.text = score.toString()
        }
    }
}

Modern gyakorlat — a ViewBinding használata a findViewById helyett. A ViewBinding a fordítási fázisban létrehozza az ActivityMainBinding osztályt, ami kiküszöböli a hibás ID-k okozta tévedéseket és csökkenti a sablonkód mennyiségét. A Google az Android Studio 3.6-tól kezdve a ViewBinding-et ajánlja a View elérésének standard módjaként Activity-ben és Fragment-ben.

A műveletek sorrendjének az onCreate-ben szigorúnak kell lennie: először super, aztán setContentView, majd minden más. A findViewById hívása a setContentView előtt null-t ad vissza — az elrendezés még nem töltődött be, és a View elemek nem léteznek a hierarchiában. Ez az egyik leggyakoribb hiba a kezdő Android-fejlesztők körében.

onCreate a Fragment-ben

Az onCreate a Fragment-ben eltér az Activity-től: itt nem hívják a setContentView-t, csak a UI-hoz nem kapcsolódó adatok inicializálása történik. A Fragment a komponens létrehozását és a View létrehozását két külön metódusra bontja: onCreate (egyszer hívódik) és onCreateView (minden alkalommal meghívódik a View létrehozásakor vagy újralétrehozásakor).

class UserListFragment : Fragment() {
    private lateinit var viewModel: UserViewModel
    private var binding: FragmentUserListBinding? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // ViewModel inicializálása — túléli a View újralétrehozását
        viewModel = ViewModelProvider(this)[UserViewModel::class.java]

        // Argumentumok a FragmentManager-ből
        arguments?.let {
            viewModel.loadUser(it.getString("user_id") ?: "")
        }

        // Megőrzés elforgatáskor
        retainInstance = true
    }

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        binding = FragmentUserListBinding.inflate(inflater, container, false)
        return binding!!.root
    }
}

A legfontosabb különbség az Activity és Fragment onCreate között: az onCreate a Fragment-ben nem tartalmazhat View-hoz kapcsolódó kódot, mert a View megsemmisülhet és újra létrejöhet (például a ViewPager lapok váltásakor), míg az onCreate csak egyszer hívódik meg. Adatok betöltése, ViewModel beállítása és adapterek inicializálása — az onCreate feladatai, míg a View hozzákötése — az onViewCreated feladata.

savedInstanceState és állapot visszaállítása

A savedInstanceState paraméter az onCreate-ben — az Activity vagy Fragment átmeneti állapotának mentési és visszaállítási mechanizmusa. Amikor a rendszer megsemmisíti az Activity-t (képernyő elforgatása, memóriahiány), meghívja az onSaveInstanceState()-t, amelybe a fejlesztő kulcs-érték párt helyez a Bundle-be. Az új példány létrehozásakor ez a Bundle visszakerül az onCreate-be.

A Bundle a következő adattípusokat támogatja: String, Integer, Boolean, Long, Float, Double, ezek tömbjei, valamint Parcelable és Serializable objektumok. Összetett objektumokhoz a Parcelable-t használják — ez egy hatékonyabb szerializációs mechanizmus, amely Android-specifikus. A Bundle mérete körülbelül 500 KB-ra korlátozott — a határ túllépése TransactionTooLargeException kivételt okoz.

companion object {
    private const val KEY_USER_NAME = "user_name"
    private const val KEY_SCORE = "score"
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_game)

    if (savedInstanceState != null) {
        userName = savedInstanceState.getString(KEY_USER_NAME) ?: ""
        currentScore = savedInstanceState.getInt(KEY_SCORE)
    }
}

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString(KEY_USER_NAME, userName)
    outState.putInt(KEY_SCORE, currentScore)
}

Fontos megérteni: az onSaveInstanceState nem hívódik meg, amikor a felhasználó explicit módon bezárja az Activity-t a finish() vagy a „Vissza" gomb megnyomásával. A rendszer úgy véli, hogy ebben az esetben a felhasználó tudatosan fejezi be a munkát, és az állapot mentése nem szükséges. Ezért nem szabad kizárólag a savedInstanceState-re hagyatkozni a hosszú távú adattároláshoz — használja a Room, DataStore vagy SharedPreferences megoldásokat.

Az onCreate időzítése és korlátai

Az onCreate a fő (UI) szálon hajtódik végre, és a rendszer megvárja a befejezését, mielőtt megjelenítené az Activity-t a képernyőn. Ha az onCreate 5 másodpercnél tovább tart, a rendszer egy ANR (Application Not Responding) párbeszédablakot jelenít meg, és javasolja a felhasználónak az alkalmazás bezárását. A hosszú műveleteket, mint a hálózati adatok betöltése vagy az adatbázisból való olvasás, háttérszálba kell helyezni.

A Google Android Performance (2025) ajánlásai szerint az onCreate-nek kevesebb mint 1 másodperc alatt kell befejeződnie a középkategóriás eszközökön. Ehhez a következőket kell tenni: használjon lusta inicializálást (lazy delegate Kotlinban), halassza el a nehéz adatok betöltését az onResume-ba vagy korutinokon keresztül, alkalmazzon ViewStub-ot a ritkán használt UI komponensekhez, profilozza a rendszerindítási időt az Android Vitals segítségével.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    // Lusta inicializálás — az objektum csak az első hozzáféréskor jön létre
    val heavyData by lazy {
        HeavyDataLoader.load()
    }

    // Adatok betöltése háttérszálon a lifecycleScope segítségével
    lifecycleScope.launch(Dispatchers.IO) {
        val users = userDao.getAllUsers()
        withContext(Dispatchers.Main) {
            adapter.submitList(users)
        }
    }
}

Profilozó eszközök: az Android Studio Profiler (CPU fül) megmutatja az egyes metódusok pontos végrehajtási idejét. Az Android Vitals-ben (Google Play konzol) nyomon követhető a „Hidegindítási idő" metrika — ha az Activity onCreate-je meghaladja az 500 ms-ot, a konzol teljesítményproblémaként jelöli meg. Mi az IT Sectr-nél Macrobenchmark teszteket használunk az egyes Activity-k indítási idejének automatikus ellenőrzésére a CI-csővezetékben.

ViewModel és onCreate

ViewModel — a legjobb módja az onCreate-ben azon adatok inicializálásának, amelyeknek túl kell élniük a képernyő elforgatását. A ViewModel az onCreate-ben jön létre a ViewModelProvider segítségével, és automatikusan megőrződik a konfiguráció megváltozásakor. Amikor az Activity az elforgatás után újra létrejön, a ViewModel a memóriában marad, és az onCreate ugyanazt a ViewModel-t kapja adatveszteség nélkül.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_profile)

    // A ViewModel egyszer jön létre és túléli a konfigurációs változásokat
    val viewModel: ProfileViewModel =
        ViewModelProvider(this)[ProfileViewModel::class.java]

    // LiveData megfigyelés — a UI automatikusan frissül az adatok változásakor
    viewModel.user.observe(this) { user ->
        binding?.userName?.text = user.name
        binding?.userEmail?.text = user.email
    }

    // Adatok betöltése, ha a ViewModel most jött létre
    if (savedInstanceState == null) {
        viewModel.loadProfile(userId)
    }
}

A ViewModel + LiveData/StateFlow kombináció megoldja a képernyő elforgatásának problémáját anélkül, hogy manuálisan kellene menteni a Bundle-be. A ViewModel a memóriában tárolja az adatokat, a LiveData automatikusan újra feliratkoztatja az Activity-t az újralétrehozáskor, a StateFlow (a Kotlin Coroutines-ból) pedig reaktivitást ad korutin támogatással. Ez a Google által a Guide to App Architecture útmutatóban ajánlott standard architektúra.

Gyakori hibák az onCreate használatakor

Még tapasztalt fejlesztők is elkövetnek tipikus hibákat az onCreate-ben. Vizsgáljuk meg az öt leggyakoribb problémát és az elkerülésük módját.

View-val való munka a setContentView előtt

A leggyakoribb hiba — megpróbálni megtalálni a View-t a findViewById segítségével a setContentView hívása előtt. Az összes View elem az elrendezés inflálásának pillanatában jön létre, így bármely findViewById hivatkozás a setContentView előtt null-t ad vissza, és NullPointerException-t okoz a View használatának megkísérlésekor. Megoldás: szigorú sorrend — először super, aztán setContentView, majd findViewById vagy ViewBinding.

A UI szál blokkolása hosszú műveletekkel

A hálózati adatok betöltése, adatbázisból való olvasás vagy nagy tömbök feldolgozása közvetlenül az onCreate-ben blokkolja az első képkocka megjelenítését. A felhasználó fekete képernyőt lát, amíg az onCreate be nem fejeződik, ami rontja az alkalmazás sebességének érzékelését. Megoldás: használjon lifecycleScope.launch-t aszinkron műveletekhez, jelenítsen meg egy vázat (placeholder UI) a betöltés befejezéséig.

A savedInstanceState figyelmen kívül hagyása

Ha a képernyő elforgatásakor nem állítják vissza az állapotot a Bundle-ből, a felhasználó elveszíti az összes nem mentett bevitelt: szöveget az űrlapmezőkben, görgetési pozíciót, kiválasztott elemeket. Megoldás: mindig ellenőrizze a savedInstanceState != null-t az onCreate-ben az adatok visszaállításához, még akkor is, ha az állapotvesztés valószínűtlennek tűnik.

Memóriaszivárgás anonim osztályokon keresztül

Az anonim osztályok és lambda-k az onCreate-ben implicit módon megtarthatják a hivatkozást az Activity-re annak megsemmisülése után. Például egy onCreate-ben létrehozott Handler továbbra is végrehajtja az elhalasztott feladatokat még az Activity megsemmisülése után is. Megoldás: használjon LifecycleObserver-t, ViewModel-t és lifecycleScope-ot, amelyek automatikusan törlik a feladatokat a megsemmisüléskor.

Túlzott inicializálás a Fragment onCreate-jében

A View inicializálása a Fragment onCreate-jében — logikai hiba, mert a View az onCreate hívása nélkül is újra létrejöhet. Ha egy figyelőt az onCreate-ben állítanak be, és a View-t az onCreateView-ben kötik hozzá, az újralétrehozáskor a figyelő a régi View-n marad. Megoldás: minden View-val kapcsolatos munkát az onViewCreated-ben végezzen, az onCreate-t csak az adatréteg inicializálására hagyja.