onCreate — qu’est-ce que c’est, initialisation d’Activity dans Android

Qu’est-ce que onCreate dans Android

onCreate est une méthode de rappel (callback) qu’Android appelle lors de la création d’une nouvelle instance d’une Activity ou d’un Fragment. C’est le premier point d’entrée dans le code de l’écran utilisateur : aucun code utilisateur n’est exécuté avant l’appel de onCreate. Le système transmet un paramètre Bundle à la méthode, qui contient soit des données précédemment sauvegardées (lors de la recréation), soit null (au premier lancement).

La méthode onCreate est définie dans la classe android.app.Activity et dans la classe androidx.fragment.app.Fragment. Les deux variantes effectuent des tâches similaires : initialisation du composant, configuration de l’UI et restauration de l’état. Cependant, l’implémentation spécifique diffère — Activity utilise setContentView pour charger la mise en page, tandis que Fragment retourne une View via onCreateView. Le développeur doit sélectionner au moins onCreate dans Activity — sans cela, Android ne peut pas afficher l’écran.

onCreate est appelé strictement une fois par cycle de vie complet d’une instance d’Activity. Même lors de la rotation de l’écran, une nouvelle instance d’Activity reçoit un nouvel appel de onCreate avec le Bundle de l’instance précédente. Cela fait de onCreate l’endroit idéal pour une initialisation unique : chargement de données, création d’adaptateurs, configuration de composants DI via Dagger ou Hilt.

onCreate dans Activity

Dans Activity, la méthode onCreate effectue quatre tâches principales : charger la mise en page, initialiser les éléments View, restaurer l’état depuis Bundle et configurer les gestionnaires d’événements primaires. Le code minimal obligatoire dans onCreate est d’appeler super.onCreate(savedInstanceState) et setContentView(R.layout.activity_main).

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

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

        // ViewBinding — un remplacement moderne de findViewById
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding?.root)

        // Initialisation à l’aide du binding
        binding?.apply {
            welcomeText.text = getString(R.string.welcome)
            startButton.setOnClickListener { startGame() }
        }

        // Restauration de l’état
        if (savedInstanceState != null) {
            score = savedInstanceState.getInt("score", 0)
            binding?.scoreText?.text = score.toString()
        }
    }
}

La pratique moderne utilise ViewBinding au lieu de findViewById. ViewBinding génère la classe ActivityMainBinding au moment de la compilation, ce qui élimine les erreurs avec des ID incorrects et réduit le code passe-partout. Google recommande ViewBinding comme méthode standard d’accès à View dans Activity et Fragment à partir d’Android Studio 3.6.

L’ordre des opérations dans onCreate doit être strict : d’abord super, ensuite setContentView, puis tout le reste. Appeler findViewById avant setContentView retourne null — la mise en page n’a pas encore été chargée et les éléments View n’existent pas dans la hiérarchie. C’est l’une des erreurs les plus fréquentes des développeurs Android débutants.

onCreate dans Fragment

onCreate dans Fragment diffère d’Activity : ici setContentView n’est pas appelé, seule l’initialisation des données non liées à l’UI est effectuée. Fragment sépare la création du composant et la création de la View en deux méthodes distinctes : onCreate (appelé une fois) et onCreateView (appelé chaque fois que la View est créée ou recréée).

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

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

        // Initialisation de ViewModel — survit à la recréation de la View
        viewModel = ViewModelProvider(this)[UserViewModel::class.java]

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

        // Sauvegarde lors de la rotation
        retainInstance = true
    }

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

La différence clé entre onCreate d’Activity et Fragment : onCreate dans Fragment ne doit pas contenir de code lié à la View, car la View peut être détruite et recréée (par exemple, lors du changement d’onglets ViewPager), tandis que onCreate n’est appelé qu’une seule fois. Le chargement des données, la configuration de ViewModel et l’initialisation des adaptateurs sont des tâches de onCreate, tandis que la liaison de la View est une tâche de onViewCreated.

savedInstanceState et restauration d’état

Le paramètre savedInstanceState dans onCreate est un mécanisme de sauvegarde et de restauration de l’état temporaire d’une Activity ou d’un Fragment. Lorsque le système détruit une Activity (rotation d’écran, manque de mémoire), il appelle onSaveInstanceState(), dans lequel le développeur place des entrées clé-valeur dans un Bundle. Lorsqu’une nouvelle instance est créée, ce Bundle est retourné dans onCreate.

Bundle prend en charge les types de données suivants : String, Integer, Boolean, Long, Float, Double, leurs tableaux, ainsi que les objets Parcelable et Serializable. Pour les objets complexes, Parcelable est utilisé — un mécanisme de sérialisation plus performant spécifique à Android. La taille du Bundle est limitée à environ 500 Ko — le dépassement de la limite provoque une 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)
}

Il est important de comprendre : onSaveInstanceState n’est pas appelé lorsque l’utilisateur ferme explicitement l’Activity via finish() ou le bouton Précédent. Le système considère que l’utilisateur termine consciemment le travail et n’a pas besoin de sauvegarder l’état. Par conséquent, vous ne pouvez pas compter uniquement sur savedInstanceState pour le stockage de données à long terme — utilisez Room, DataStore ou SharedPreferences.

Temporisation et limites de onCreate

onCreate s’exécute sur le thread principal (UI) et le système attend sa fin avant d’afficher l’Activity à l’écran. Si onCreate prend plus de 5 secondes, le système affiche une boîte de dialogue ANR (Application Not Responding) et propose à l’utilisateur de fermer l’application. Les opérations longues, telles que le chargement de données depuis le réseau ou la lecture depuis une base de données, doivent être déplacées vers un thread d’arrière-plan.

Selon les recommandations de Google Android Performance (2025), onCreate doit se terminer en moins d’1 seconde sur les appareils de milieu de gamme. Pour y parvenir : utilisez l’initialisation paresseuse (délégation lazy en Kotlin), reportez le chargement des données lourdes à onResume ou via des coroutines, appliquez ViewStub pour les composants UI rarement utilisés et profilez le temps de démarrage via Android Vitals.

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

    // Initialisation paresseuse — l’objet n’est créé qu’au premier accès
    val heavyData by lazy {
        HeavyDataLoader.load()
    }

    // Chargement des données en arrière-plan via lifecycleScope
    lifecycleScope.launch(Dispatchers.IO) {
        val users = userDao.getAllUsers()
        withContext(Dispatchers.Main) {
            adapter.submitList(users)
        }
    }
}

Outils de profilage : Android Studio Profiler (onglet CPU) montre le temps d’exécution exact de chaque méthode. Dans Android Vitals (console Google Play), vous pouvez suivre la métrique « Temps de démarrage à froid » — si le onCreate de votre Activity dépasse 500 ms, la console le marque comme un problème de performance. Chez IT Sectr, nous utilisons des tests Macrobenchmark pour le contrôle automatique du temps de démarrage de chaque Activity dans le pipeline CI.

ViewModel et onCreate

ViewModel est la meilleure façon d’initialiser dans onCreate les données qui doivent survivre à la rotation de l’écran. ViewModel est créé dans onCreate via ViewModelProvider et est automatiquement préservé lors des changements de configuration. Lorsqu’une Activity est recréée après une rotation, le ViewModel reste en mémoire et onCreate reçoit le même ViewModel sans perte de données.

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

    // ViewModel est créé une fois et survit aux changements de configuration
    val viewModel: ProfileViewModel =
        ViewModelProvider(this)[ProfileViewModel::class.java]

    // Observation LiveData — l’UI se met automatiquement à jour lorsque les données changent
    viewModel.user.observe(this) { user ->
        binding?.userName?.text = user.name
        binding?.userEmail?.text = user.email
    }

    // Chargement des données si ViewModel vient d’être créé
    if (savedInstanceState == null) {
        viewModel.loadProfile(userId)
    }
}

La combinaison ViewModel + LiveData/StateFlow résout le problème de rotation de l’écran sans sauvegarde manuelle dans Bundle. ViewModel stocke les données en mémoire, LiveData réabonne automatiquement l’Activity lors de la recréation, et StateFlow (de Kotlin Coroutines) ajoute de la réactivité avec le support des coroutines. C’est l’architecture standard recommandée par Google dans le Guide to App Architecture.

Erreurs courantes lors de l’utilisation de onCreate

Même les développeurs expérimentés commettent des erreurs typiques dans onCreate. Examinons les cinq problèmes les plus courants et comment les éviter.

Travailler avec View avant setContentView

L’erreur la plus courante est d’essayer de trouver une View via findViewById avant d’appeler setContentView. Tous les éléments View sont créés au moment de l’inflation de la mise en page, donc tout appel à findViewById avant setContentView retourne null et provoque une NullPointerException lors de la tentative d’utilisation de la View. Solution : ordre strict — d’abord super, puis setContentView, ensuite findViewById ou ViewBinding.

Blocage du thread UI par des opérations longues

Charger des données depuis le réseau, lire depuis une base de données ou traiter de grands tableaux directement dans onCreate bloque le rendu de la première image. L’utilisateur voit un écran noir jusqu’à la fin de onCreate, ce qui nuit à la perception de la vitesse de l’application. Solution : utilisez lifecycleScope.launch pour les opérations asynchrones, affichez un squelette (UI placeholder) jusqu’à la fin du chargement.

Ignorer savedInstanceState

Si vous ne restaurez pas l’état depuis Bundle lors de la rotation de l’écran, l’utilisateur perd toute saisie non sauvegardée : texte dans les champs de formulaire, position de défilement, éléments sélectionnés. Solution : vérifiez toujours savedInstanceState != null dans onCreate pour restaurer les données, même si la perte d’état semble peu probable.

Fuites mémoire via les classes anonymes

Les classes anonymes et les lambdas dans onCreate peuvent implicitement conserver une référence à une Activity après sa destruction. Par exemple, un Handler créé dans onCreate continue d’exécuter des tâches différées même après la destruction de l’Activity. Solution : utilisez LifecycleObserver, ViewModel et lifecycleScope, qui annulent automatiquement les tâches lors de la destruction.

Initialisation excessive dans Fragment.onCreate

Initialiser la View dans Fragment.onCreate est une erreur logique, car la View peut être recréée sans appeler onCreate. Si vous définissez un écouteur dans onCreate mais liez la View dans onCreateView, l’écouteur restera sur l’ancienne View lors de la recréation. Solution : effectuez tout le travail lié à la View dans onViewCreated, en laissant onCreate uniquement pour l’initialisation de la couche de données.