onCreate — qué es, inicialización de Activity en Android

Qué es onCreate en Android

onCreate es un método de devolución de llamada (callback) que Android invoca al crear una nueva instancia de Activity o Fragment. Este es el primer punto de entrada en el código de la pantalla del usuario: ningún código de usuario se ejecuta antes de que se llame a onCreate. El sistema pasa un parámetro Bundle al método, que contiene datos guardados previamente (al recrear) o es null (en el primer inicio).

El método onCreate se define en la clase android.app.Activity y en la clase androidx.fragment.app.Fragment. Ambas variantes realizan tareas similares: inicialización del componente, configuración de la UI y restauración del estado. Sin embargo, la implementación específica difiere — Activity usa setContentView para cargar el diseño, mientras que Fragment devuelve una View a través de onCreateView. El desarrollador debe sobrescribir al menos onCreate en Activity — sin esto, Android no puede mostrar la pantalla.

onCreate se llama estrictamente una vez por ciclo de vida completo de una instancia de Activity. Incluso en la rotación de pantalla, una nueva instancia de Activity recibe una nueva llamada a onCreate con el Bundle de la instancia anterior. Esto convierte a onCreate en el lugar ideal para la inicialización única: carga de datos, creación de adaptadores, configuración de componentes DI a través de Dagger o Hilt.

onCreate en Activity

En Activity, el método onCreate realiza cuatro tareas clave: cargar el diseño layout, inicializar los elementos View, restaurar el estado desde Bundle y configurar los manejadores de eventos principales. El código mínimo obligatorio en onCreate es llamar a super.onCreate(savedInstanceState) y setContentView(R.layout.activity_main).

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

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

        // ViewBinding: un reemplazo moderno para findViewById
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding?.root)

        // Inicialización mediante binding
        binding?.apply {
            welcomeText.text = getString(R.string.welcome)
            startButton.setOnClickListener { startGame() }
        }

        // Restauración del estado
        if (savedInstanceState != null) {
            score = savedInstanceState.getInt("score", 0)
            binding?.scoreText?.text = score.toString()
        }
    }
}

La práctica moderna utiliza ViewBinding en lugar de findViewById. ViewBinding genera la clase ActivityMainBinding en tiempo de compilación, lo que elimina errores con ID incorrectos y reduce el código repetitivo. Google recomienda ViewBinding como la forma estándar de acceder a View en Activity y Fragment a partir de Android Studio 3.6.

El orden de las operaciones en onCreate debe ser estricto: primero super, luego setContentView, después todo lo demás. Llamar a findViewById antes de setContentView devuelve null — el diseño aún no se ha cargado y los elementos View no existen en la jerarquía. Este es uno de los errores más comunes de los desarrolladores principiantes de Android.

onCreate en Fragment

onCreate en Fragment difiere de Activity: aquí no se llama a setContentView, solo se realiza la inicialización de datos no relacionados con la UI. Fragment separa la creación del componente y la creación de la View en dos métodos distintos: onCreate (llamado una vez) y onCreateView (llamado cada vez que se crea o recrea la View).

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

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

        // Inicialización de ViewModel: sobrevive a la recreación de View
        viewModel = ViewModelProvider(this)[UserViewModel::class.java]

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

        // Guardado al rotar
        retainInstance = true
    }

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

La diferencia clave entre onCreate de Activity y Fragment: onCreate en Fragment no debe contener código relacionado con View, porque la View puede ser destruida y recreada (por ejemplo, al cambiar de pestaña en ViewPager), mientras que onCreate se llama solo una vez. La carga de datos, la configuración de ViewModel y la inicialización de adaptadores son tareas de onCreate, mientras que la vinculación de View es una tarea de onViewCreated.

savedInstanceState y restauración del estado

El parámetro savedInstanceState en onCreate es un mecanismo para guardar y restaurar el estado temporal de un Activity o Fragment. Cuando el sistema destruye un Activity (rotación de pantalla, falta de memoria), llama a onSaveInstanceState(), donde el desarrollador coloca pares clave-valor en un Bundle. Al crear una nueva instancia, este Bundle se devuelve en onCreate.

Bundle admite los siguientes tipos de datos: String, Integer, Boolean, Long, Float, Double, sus arrays, así como objetos Parcelable y Serializable. Para objetos complejos se utiliza Parcelable — un mecanismo de serialización más eficiente específico de Android. El tamaño de Bundle está limitado a aproximadamente 500 KB — superar el límite provoca 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)
}

Es importante entender: onSaveInstanceState no se llama cuando el usuario cierra explícitamente el Activity mediante finish() o el botón Atrás. El sistema considera que el usuario está finalizando conscientemente el trabajo y no necesita guardar el estado. Por lo tanto, no se puede confiar únicamente en savedInstanceState para el almacenamiento de datos a largo plazo — use Room, DataStore o SharedPreferences.

Tiempos y limitaciones de onCreate

onCreate se ejecuta en el hilo principal (UI) y el sistema espera a que finalice antes de mostrar el Activity en pantalla. Si onCreate tarda más de 5 segundos, el sistema muestra un diálogo ANR (Application Not Responding) y ofrece al usuario la opción de cerrar la aplicación. Las operaciones largas, como la carga de datos desde la red o la lectura de una base de datos, deben trasladarse a un hilo en segundo plano.

Según las recomendaciones de Google Android Performance (2025), onCreate debe completarse en menos de 1 segundo en dispositivos de gama media. Para lograrlo: use inicialización perezosa (delegado lazy en Kotlin), difiera la carga de datos pesados a onResume o mediante corrutinas, aplique ViewStub para componentes de UI poco usados y perfile el tiempo de inicio a través de Android Vitals.

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

    // Inicialización perezosa: el objeto se crea solo en el primer acceso
    val heavyData by lazy {
        HeavyDataLoader.load()
    }

    // Carga de datos en segundo plano mediante lifecycleScope
    lifecycleScope.launch(Dispatchers.IO) {
        val users = userDao.getAllUsers()
        withContext(Dispatchers.Main) {
            adapter.submitList(users)
        }
    }
}

Herramientas de perfilado: Android Studio Profiler (pestaña CPU) muestra el tiempo exacto de ejecución de cada método. En Android Vitals (consola de Google Play), puede rastrear la métrica “Tiempo de inicio en frío” — si el onCreate de su Activity supera los 500 ms, la consola lo marca como un problema de rendimiento. En IT Sectr, usamos pruebas Macrobenchmark para el control automático del tiempo de inicio de cada Activity en el pipeline de CI.

ViewModel y onCreate

ViewModel es la mejor manera de inicializar datos en onCreate que deben sobrevivir a la rotación de pantalla. ViewModel se crea en onCreate a través de ViewModelProvider y se conserva automáticamente ante cambios de configuración. Cuando un Activity se recrea después de una rotación, el ViewModel permanece en memoria y onCreate recibe el mismo ViewModel sin pérdida de datos.

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

    // ViewModel se crea una vez y sobrevive a los cambios de configuración
    val viewModel: ProfileViewModel =
        ViewModelProvider(this)[ProfileViewModel::class.java]

    // Observación de LiveData: la UI se actualiza automáticamente cuando los datos cambian
    viewModel.user.observe(this) { user ->
        binding?.userName?.text = user.name
        binding?.userEmail?.text = user.email
    }

    // Carga de datos si ViewModel acaba de crearse
    if (savedInstanceState == null) {
        viewModel.loadProfile(userId)
    }
}

La combinación de ViewModel + LiveData/StateFlow resuelve el problema de la rotación de pantalla sin guardado manual en Bundle. ViewModel almacena datos en memoria, LiveData vuelve a suscribir automáticamente el Activity al recrearse, y StateFlow (de Kotlin Coroutines) añade reactividad con soporte de corrutinas. Esta es la arquitectura estándar recomendada por Google en la Guide to App Architecture.

Errores comunes al trabajar con onCreate

Incluso los desarrolladores experimentados cometen errores típicos en onCreate. Veamos los cinco problemas más comunes y cómo evitarlos.

Trabajar con View antes de setContentView

El error más común es intentar encontrar una View mediante findViewById antes de llamar a setContentView. Todos los elementos View se crean en el momento de la inflación del diseño, por lo que cualquier llamada a findViewById antes de setContentView devuelve null y provoca una NullPointerException al intentar usar la View. Solución: orden estricto — primero super, luego setContentView, después findViewById o ViewBinding.

Bloqueo del hilo de UI con operaciones largas

Cargar datos desde la red, leer de una base de datos o procesar arrays grandes directamente en onCreate bloquea la representación del primer fotograma. El usuario ve una pantalla negra hasta que onCreate finaliza, lo que empeora la percepción de la velocidad de la aplicación. Solución: use lifecycleScope.launch para operaciones asíncronas, muestre un esqueleto (UI placeholder) hasta que la carga se complete.

Ignorar savedInstanceState

Si no restaura el estado desde Bundle al rotar la pantalla, el usuario pierde toda la entrada no guardada: texto en campos de formulario, posición de desplazamiento, elementos seleccionados. Solución: verifique siempre savedInstanceState != null en onCreate para restaurar datos, incluso si la pérdida de estado parece improbable.

Fugas de memoria a través de clases anónimas

Las clases anónimas y las lambdas en onCreate pueden retener implícitamente una referencia a un Activity después de que este sea destruido. Por ejemplo, un Handler creado en onCreate continúa ejecutando tareas retrasadas incluso después de que el Activity sea destruido. Solución: use LifecycleObserver, ViewModel y lifecycleScope, que cancelan automáticamente las tareas al destruirse.

Inicialización excesiva en onCreate de Fragment

Inicializar View en onCreate de Fragment es un error lógico, ya que la View puede ser recreada sin llamar a onCreate. Si configura un listener en onCreate pero vincula la View en onCreateView, el listener permanecerá en la View antigua al recrearse. Solución: realice todo el trabajo relacionado con View en onViewCreated, dejando onCreate solo para la inicialización de la capa de datos.