onCreate — che cos’è, inizializzazione di Activity in Android

Cos’è onCreate in Android

onCreate è un metodo di callback che Android chiama durante la creazione di una nuova istanza di un’Activity o un Fragment. Questo è il primo punto di ingresso nel codice dello schermo utente: nessun codice utente viene eseguito prima che onCreate venga chiamato. Il sistema passa un parametro Bundle al metodo, che contiene dati precedentemente salvati (durante la ricreazione) o null (al primo avvio).

Il metodo onCreate è definito nella classe android.app.Activity e nella classe androidx.fragment.app.Fragment. Entrambe le varianti eseguono compiti simili: inizializzazione del componente, configurazione dell’interfaccia utente e ripristino dello stato. Tuttavia, l’implementazione specifica differisce — Activity usa setContentView per caricare il layout, mentre Fragment restituisce una View tramite onCreateView. Lo sviluppatore deve sovrascrivere almeno onCreate in Activity — senza di ciò, Android non può visualizzare la schermata.

onCreate viene chiamato rigorosamente una volta per l’intero ciclo di vita di un’istanza di Activity. Anche durante la rotazione dello schermo, una nuova istanza di Activity riceve una nuova chiamata di onCreate con il Bundle dell’istanza precedente. Questo rende onCreate il luogo ideale per l’inizializzazione una tantum: caricamento dei dati, creazione degli adapter, configurazione dei componenti DI tramite Dagger o Hilt.

onCreate in Activity

In Activity, il metodo onCreate esegue quattro attività principali: caricamento del layout, inizializzazione degli elementi View, ripristino dello stato da Bundle e configurazione dei gestori di eventi primari. Il codice minimo obbligatorio in onCreate è chiamare super.onCreate(savedInstanceState) e setContentView(R.layout.activity_main).

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

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

        // ViewBinding — un moderno sostituto di findViewById
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding?.root)

        // Inizializzazione tramite binding
        binding?.apply {
            welcomeText.text = getString(R.string.welcome)
            startButton.setOnClickListener { startGame() }
        }

        // Ripristino dello stato
        if (savedInstanceState != null) {
            score = savedInstanceState.getInt("score", 0)
            binding?.scoreText?.text = score.toString()
        }
    }
}

La pratica moderna utilizza ViewBinding invece di findViewById. ViewBinding genera la classe ActivityMainBinding in fase di compilazione, eliminando gli errori con ID errati e riducendo il codice boilerplate. Google raccomanda ViewBinding come metodo standard per accedere a View in Activity e Fragment a partire da Android Studio 3.6.

L’ordine delle operazioni in onCreate deve essere rigoroso: prima super, poi setContentView, poi tutto il resto. Chiamare findViewById prima di setContentView restituisce null — il layout non è stato ancora caricato e gli elementi View non esistono nella gerarchia. Questo è uno degli errori più comuni degli sviluppatori Android principianti.

onCreate in Fragment

onCreate in Fragment differisce da Activity: qui setContentView non viene chiamato, viene eseguita solo l’inizializzazione dei dati non correlati all’interfaccia utente. Fragment separa la creazione del componente e la creazione della View in due metodi distinti: onCreate (chiamato una volta) e onCreateView (chiamato ogni volta che la View viene creata o ricreata).

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

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

        // Inizializzazione di ViewModel — sopravvive alla ricreazione della View
        viewModel = ViewModelProvider(this)[UserViewModel::class.java]

        // Argomenti da FragmentManager
        arguments?.let {
            viewModel.loadUser(it.getString("user_id") ?: "")
        }

        // Salvataggio durante la rotazione
        retainInstance = true
    }

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

La differenza chiave tra onCreate di Activity e Fragment: onCreate in Fragment non deve contenere codice relativo alla View, perché la View può essere distrutta e ricreata (ad esempio, durante il cambio di schede ViewPager), mentre onCreate viene chiamato solo una volta. Caricamento dei dati, configurazione di ViewModel e inizializzazione degli adapter sono compiti di onCreate, mentre il binding della View è un compito di onViewCreated.

savedInstanceState e ripristino dello stato

Il parametro savedInstanceState in onCreate è un meccanismo per salvare e ripristinare lo stato temporaneo di un’Activity o un Fragment. Quando il sistema distrugge un’Activity (rotazione dello schermo, memoria insufficiente), chiama onSaveInstanceState(), in cui lo sviluppatore inserisce coppie chiave-valore in un Bundle. Quando viene creata una nuova istanza, questo Bundle viene restituito in onCreate.

Bundle supporta i seguenti tipi di dati: String, Integer, Boolean, Long, Float, Double, i loro array, nonché oggetti Parcelable e Serializable. Per oggetti complessi, viene utilizzato Parcelable — un meccanismo di serializzazione più performante specifico di Android. La dimensione del Bundle è limitata a circa 500 KB — il superamento del limite causa una 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)
}

È importante capire: onSaveInstanceState non viene chiamato quando l’utente chiude esplicitamente l’Activity tramite finish() o il pulsante Indietro. Il sistema considera che l’utente stia terminando consapevolmente il lavoro e non abbia bisogno di salvare lo stato. Pertanto, non puoi fare affidamento esclusivamente su savedInstanceState per l’archiviazione dei dati a lungo termine — usa Room, DataStore o SharedPreferences.

Tempi e limitazioni di onCreate

onCreate viene eseguito sul thread principale (UI) e il sistema attende il suo completamento prima di visualizzare l’Activity sullo schermo. Se onCreate impiega più di 5 secondi, il sistema mostra una finestra di dialogo ANR (Application Not Responding) e offre all’utente l’opzione di chiudere l’applicazione. Le operazioni lunghe, come il caricamento dei dati dalla rete o la lettura da un database, devono essere spostate in un thread in background.

Secondo le raccomandazioni di Google Android Performance (2025), onCreate deve terminare in meno di 1 secondo sui dispositivi di fascia media. Per ottenere ciò: usa l’inizializzazione pigra (delegato lazy in Kotlin), rimanda il caricamento dei dati pesanti a onResume o tramite coroutine, applica ViewStub per i componenti UI usati raramente e analizza il tempo di avvio tramite Android Vitals.

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

    // Inizializzazione pigra — l’oggetto viene creato solo al primo accesso
    val heavyData by lazy {
        HeavyDataLoader.load()
    }

    // Caricamento dei dati in background tramite lifecycleScope
    lifecycleScope.launch(Dispatchers.IO) {
        val users = userDao.getAllUsers()
        withContext(Dispatchers.Main) {
            adapter.submitList(users)
        }
    }
}

Strumenti di profilazione: Android Studio Profiler (scheda CPU) mostra il tempo di esecuzione esatto di ogni metodo. In Android Vitals (Google Play Console), puoi monitorare la metrica “Tempo di avvio a freddo” — se l’onCreate della tua Activity supera i 500 ms, la console lo segnala come un problema di prestazioni. In IT Sectr, utilizziamo test Macrobenchmark per il controllo automatico del tempo di avvio di ogni Activity nella pipeline CI.

ViewModel e onCreate

ViewModel è il modo migliore per inizializzare in onCreate i dati che devono sopravvivere alla rotazione dello schermo. ViewModel viene creato in onCreate tramite ViewModelProvider e viene preservato automaticamente durante i cambiamenti di configurazione. Quando un’Activity viene ricreata dopo una rotazione, il ViewModel rimane in memoria e onCreate riceve lo stesso ViewModel senza perdita di dati.

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

    // ViewModel viene creato una volta e sopravvive ai cambiamenti di configurazione
    val viewModel: ProfileViewModel =
        ViewModelProvider(this)[ProfileViewModel::class.java]

    // Osservazione di LiveData — l’interfaccia utente si aggiorna automaticamente quando i dati cambiano
    viewModel.user.observe(this) { user ->
        binding?.userName?.text = user.name
        binding?.userEmail?.text = user.email
    }

    // Caricamento dei dati se ViewModel è stato appena creato
    if (savedInstanceState == null) {
        viewModel.loadProfile(userId)
    }
}

La combinazione di ViewModel + LiveData/StateFlow risolve il problema della rotazione dello schermo senza salvataggio manuale in Bundle. ViewModel memorizza i dati in memoria, LiveData riabbona automaticamente l’Activity durante la ricreazione e StateFlow (da Kotlin Coroutines) aggiunge reattività con il supporto delle coroutine. Questa è l’architettura standard raccomandata da Google nella Guide to App Architecture.

Errori comuni nell’uso di onCreate

Anche gli sviluppatori esperti commettono errori tipici in onCreate. Esaminiamo i cinque problemi più comuni e come evitarli.

Lavorare con View prima di setContentView

L’errore più comune è cercare di trovare una View tramite findViewById prima di chiamare setContentView. Tutti gli elementi View vengono creati al momento dell’inflazione del layout, quindi qualsiasi chiamata a findViewById prima di setContentView restituisce null e causa una NullPointerException quando si cerca di usare la View. Soluzione: ordine rigoroso — prima super, poi setContentView, poi findViewById o ViewBinding.

Blocco del thread UI con operazioni lunghe

Caricare dati dalla rete, leggere da un database o elaborare grandi array direttamente in onCreate blocca il rendering del primo fotogramma. L’utente vede uno schermo nero fino al termine di onCreate, il che peggiora la percezione della velocità dell’applicazione. Soluzione: usa lifecycleScope.launch per operazioni asincrone, mostra uno scheletro (UI placeholder) fino al completamento del caricamento.

Ignorare savedInstanceState

Se non ripristini lo stato da Bundle durante la rotazione dello schermo, l’utente perde tutti gli input non salvati: testo nei campi del modulo, posizione di scorrimento, elementi selezionati. Soluzione: controlla sempre savedInstanceState != null in onCreate per ripristinare i dati, anche se la perdita di stato sembra improbabile.

Perdite di memoria tramite classi anonime

Le classi anonime e le lambda in onCreate possono trattenere implicitamente un riferimento a un’Activity dopo la sua distruzione. Ad esempio, un Handler creato in onCreate continua a eseguire attività ritardate anche dopo che l’Activity è stata distrutta. Soluzione: usa LifecycleObserver, ViewModel e lifecycleScope, che cancellano automaticamente le attività in caso di distruzione.

Inizializzazione eccessiva in Fragment.onCreate

Inizializzare la View in Fragment.onCreate è un errore logico, poiché la View può essere ricreata senza chiamare onCreate. Se imposti un listener in onCreate ma leghi la View in onCreateView, il listener rimarrà sulla View vecchia durante la ricreazione. Soluzione: esegui tutto il lavoro relativo alla View in onViewCreated, lasciando onCreate solo per l’inizializzazione del layer dati.