onCreate — vad är det, initiering av Activity i Android

Vad är onCreate i Android

onCreate — en callback-metod som Android anropar när en ny instans av Activity eller Fragment skapas. Detta är den första startpunkten i koden för användarskärmen: före anropet av onCreate körs ingen användarkod. Systemet skickar parametern Bundle till metoden, som antingen innehåller tidigare sparade data (vid återskapande) eller är null (vid första start).

Metoden onCreate definieras i klassen android.app.Activity och i klassen androidx.fragment.app.Fragment. Båda varianterna utför liknande uppgifter: initiering av komponenten, konfigurering av UI och återställning av tillstånd. Den specifika implementeringen skiljer sig dock — Activity använder setContentView för att ladda layouten, medan Fragment returnerar View via onCreateView. Utvecklaren är skyldig att åtminstone åsidosätta onCreate i Activity — utan detta kan Android inte visa skärmen.

onCreate anropas strikt en gång under hela livscykeln för Activity-instansen. Även vid skärmrotation får den nya Activity-instansen ett nytt onCreate-anrop med Bundle från den föregående instansen. Denna egenskap gör onCreate till den idealiska platsen för engångsinitiering: ladda data, skapa adaptrar, konfigurera DI-komponenter via Dagger eller Hilt.

onCreate i Activity

I Activity utför onCreate-metoden fyra nyckeluppgifter: ladda layout, initiera View-element, återställa tillstånd från Bundle och konfigurera primära händelsehanterare. Den obligatoriska minimikoden i onCreate — anrop av super.onCreate(savedInstanceState) och setContentView(R.layout.activity_main).

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

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

        // ViewBinding — modern ersättning för findViewById
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding?.root)

        // Initiering med hjälp av binding
        binding?.apply {
            welcomeText.text = getString(R.string.welcome)
            startButton.setOnClickListener { startGame() }
        }

        // Återställning av tillstånd
        if (savedInstanceState != null) {
            score = savedInstanceState.getInt("score", 0)
            binding?.scoreText?.text = score.toString()
        }
    }
}

Modern praxis — användning av ViewBinding istället för findViewById. ViewBinding genererar klassen ActivityMainBinding vid kompileringstillfället, vilket eliminerar fel med felaktiga ID och minskar mängden boilerplate-kod. Google rekommenderar ViewBinding som standardsättet att komma åt View i Activity och Fragment från och med Android Studio 3.6.

Ordningen av åtgärder i onCreate måste vara strikt: först super, sedan setContentView, därefter allt annat. Att anropa findViewById före setContentView returnerar null — layouten har inte laddats ännu och View-elementen finns inte i hierarkin. Detta är ett av de vanligaste misstagen bland nybörjare inom Android-utveckling.

onCreate i Fragment

onCreate i Fragment skiljer sig från Activity: här anropas inte setContentView, utan endast initiering av data som inte är relaterad till UI utförs. Fragment delar upp skapandet av komponenten och skapandet av View i två separata metoder: onCreate (anropas en gång) och onCreateView (anropas varje gång vid skapande eller återskapande av View).

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

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

        // ViewModel-initiering — överlever återskapande av View
        viewModel = ViewModelProvider(this)[UserViewModel::class.java]

        // Argument från FragmentManager
        arguments?.let {
            viewModel.loadUser(it.getString("user_id") ?: "")
        }

        // Spara vid rotation
        retainInstance = true
    }

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

Den viktigaste skillnaden mellan onCreate i Activity och Fragment: onCreate i Fragment får inte innehålla kod relaterad till View, eftersom View kan förstöras och återskapas (till exempel vid växling av ViewPager-flikar), medan onCreate bara anropas en gång. Att ladda data, konfigurera ViewModel och initiera adaptrar — uppgifter för onCreate, medan att binda View — uppgiften för onViewCreated.

savedInstanceState och återställning av tillstånd

Parametern savedInstanceState i onCreate — är mekanismen för att spara och återställa det tillfälliga tillståndet för Activity eller Fragment. När systemet förstör Activity (skärmrotation, minnesbrist), anropar det onSaveInstanceState(), där utvecklaren placerar ett nyckel-värdepar i Bundle. När en ny instans skapas returneras denna Bundle i onCreate.

Bundle stöder följande datatyper: String, Integer, Boolean, Long, Float, Double, deras arrayer, samt Parcelable- och Serializable-objekt. För komplexa objekt används Parcelable — en mer effektiv serialiseringsmekanism specifik för Android. Storleken på Bundle är begränsad till cirka 500 KB — överskridande av gränsen orsakar undantaget TransactionTooLargeException.

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

Det är viktigt att förstå: onSaveInstanceState anropas inte när användaren explicit stänger Activity via finish() eller genom att trycka på knappen "Tillbaka". Systemet antar att användaren i detta fall medvetet avslutar arbetet och att sparande av tillstånd inte krävs. Därför bör man inte enbart förlita sig på savedInstanceState för långtidslagring av data — använd Room, DataStore eller SharedPreferences.

Timing och begränsningar för onCreate

onCreate exekveras i huvudtråden (UI) och systemet väntar på att den ska slutföras innan det visar Activity på skärmen. Om onCreate tar längre tid än 5 sekunder visar systemet en ANR-dialogruta (Application Not Responding) och föreslår att användaren stänger appen. Långvariga operationer som att ladda data från nätverket eller läsa från databasen bör flyttas till bakgrundstråden.

Enligt rekommendationerna från Google Android Performance (2025) bör onCreate slutföras på mindre än 1 sekund på mellansegmentets enheter. För detta bör du: använda lat initiering (lazy-delegat i Kotlin), skjuta upp laddning av tunga data till onResume eller via korutiner, tillämpa ViewStub för sällan använda UI-komponenter, profilera starttiden via Android Vitals.

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

    // Lat initiering — objektet skapas endast vid första åtkomst
    val heavyData by lazy {
        HeavyDataLoader.load()
    }

    // Ladda data i bakgrundstråden via lifecycleScope
    lifecycleScope.launch(Dispatchers.IO) {
        val users = userDao.getAllUsers()
        withContext(Dispatchers.Main) {
            adapter.submitList(users)
        }
    }
}

Profileringsverktyg: Android Studio Profiler (CPU-fliken) visar den exakta exekveringstiden för varje metod. I Android Vitals (Google Play-konsolen) kan du följa metriken "Kallstarttid" — om din Activitys onCreate överstiger 500 ms markerar konsolen det som ett prestandaproblem. Vi på IT Sectr använder Macrobenchmark-tester för automatisk kontroll av starttiden för varje Activity i CI-pipelinen.

ViewModel och onCreate

ViewModel — det bästa sättet att initiera data i onCreate som måste överleva skärmrotation. ViewModel skapas i onCreate via ViewModelProvider och sparas automatiskt vid konfigurationsändring. När Activity återskapas efter rotation finns ViewModel kvar i minnet och onCreate får samma ViewModel utan dataförlust.

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

    // ViewModel skapas en gång och överlever konfigurationsändringar
    val viewModel: ProfileViewModel =
        ViewModelProvider(this)[ProfileViewModel::class.java]

    // LiveData-observation — UI uppdateras automatiskt när data ändras
    viewModel.user.observe(this) { user ->
        binding?.userName?.text = user.name
        binding?.userEmail?.text = user.email
    }

    // Ladda data om ViewModel nyss skapats
    if (savedInstanceState == null) {
        viewModel.loadProfile(userId)
    }
}

Kombinationen ViewModel + LiveData/StateFlow löser problemet med skärmrotation utan manuell lagring i Bundle. ViewModel lagrar data i minnet, LiveData prenumererar automatiskt om Activity vid återskapande, och StateFlow (från Kotlin Coroutines) lägger till reaktivitet med stöd för korutiner. Detta är den standardarkitektur som Google rekommenderar i guiden Guide to App Architecture.

Vanliga misstag vid arbete med onCreate

Även erfarna utvecklare gör typiska misstag i onCreate. Låt oss titta på de fem vanligaste problemen och hur man undviker dem.

Arbeta med View före setContentView

Det vanligaste misstaget — att försöka hitta View via findViewById före anropet av setContentView. Alla View-element skapas vid inflateringen av layouten, så varje hänvisning till findViewById före setContentView returnerar null och orsakar NullPointerException vid försök att använda View. Lösning: strikt ordning — först super, sedan setContentView, därefter findViewById eller ViewBinding.

Blockera UI-tråden med långvariga operationer

Att ladda data från nätverket, läsa från databasen eller bearbeta stora arrayer direkt i onCreate blockerar renderingen av den första bildrutan. Användaren ser en svart skärm tills onCreate är klar, vilket försämrar uppfattningen av appens hastighet. Lösning: använd lifecycleScope.launch för asynkrona operationer, visa ett skelett (placeholder UI) tills laddningen är klar.

Ignorera savedInstanceState

Om tillståndet inte återställs från Bundle vid skärmrotation förlorar användaren all osparad inmatning: text i formulärfält, rullningsposition, markerade element. Lösning: kontrollera alltid savedInstanceState != null i onCreate för att återställa data, även om tillståndsförlust verkar osannolik.

Minnesläckor via anonyma klasser

Anonyma klasser och lambdas i onCreate kan implicit hålla en referens till Activity efter dess förstörelse. Till exempel fortsätter en Handler skapad i onCreate att utföra fördröjda uppgifter även efter att Activity har förstörts. Lösning: använd LifecycleObserver, ViewModel och lifecycleScope, som automatiskt avbryter uppgifter vid förstörelse.

Överdriven initiering i Fragment onCreate

Initiering av View i Fragment onCreate — ett logiskt misstag, eftersom View kan återskapas utan anrop av onCreate. Om en lyssnare ställs in i onCreate och View binds i onCreateView, kommer lyssnaren vid återskapande att finnas kvar på den gamla View. Lösning: allt arbete med View utförs i onViewCreated, och onCreate lämnas endast för initiering av datalagret.