onCreate — ano ito, pagsisimula ng Activity sa Android

Ano ang onCreate sa Android

onCreate — isang paraan ng callback na tinatawag ng Android kapag gumagawa ng bagong instance ng Activity o Fragment. Ito ang unang entry point sa code ng screen ng user: bago ang tawag ng onCreate, walang code ng user na naisakatuparan. Ipinapasa ng system ang parameter na Bundle sa pamamaraan, na naglalaman ng dating na-save na data (sa paggawa muli) o null (sa unang paglunsad).

Ang paraan ng onCreate ay tinukoy sa klase na android.app.Activity at sa klase na androidx.fragment.app.Fragment. Ang parehong variant ay nagsasagawa ng mga katulad na gawain: pagsisimula ng component, pag-configure ng UI, at pagpapanumbalik ng estado. Gayunpaman, ang partikular na pagpapatupad ay naiiba — gumagamit ang Activity ng setContentView para sa pag-load ng layout, habang ang Fragment ay nagbabalik ng View sa pamamagitan ng onCreateView. Ang developer ay obligadong i-override ang hindi bababa sa onCreate sa Activity — kung wala ito, hindi maaaring ipakita ng Android ang screen.

Ang onCreate ay tinatawag nang mahigpit na isang beses sa buong lifecycle ng instance ng Activity. Kahit na sa pag-ikot ng screen, ang bagong instance ng Activity ay tumatanggap ng bagong tawag ng onCreate na may Bundle mula sa nakaraang instance. Ang pag-aari na ito ay ginagawang perpektong lugar ang onCreate para sa isang beses na pagsisimula: pag-load ng data, paggawa ng mga adapter, pag-configure ng mga component ng DI sa pamamagitan ng Dagger o Hilt.

onCreate sa Activity

Sa Activity, ang paraan ng onCreate ay nagsasagawa ng apat na pangunahing gawain: pag-load ng layout, pagsisimula ng mga elemento ng View, pagpapanumbalik ng estado mula sa Bundle, at pag-configure ng mga pangunahing tagapangasiwa ng kaganapan. Ang sapilitang minimum code sa onCreate — tawag ng super.onCreate(savedInstanceState) at setContentView(R.layout.activity_main).

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

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

        // ViewBinding — makabagong kapalit ng findViewById
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding?.root)

        // Pagsisimula gamit ang binding
        binding?.apply {
            welcomeText.text = getString(R.string.welcome)
            startButton.setOnClickListener { startGame() }
        }

        // Pagpapanumbalik ng estado
        if (savedInstanceState != null) {
            score = savedInstanceState.getInt("score", 0)
            binding?.scoreText?.text = score.toString()
        }
    }
}

Makabagong praktika — paggamit ng ViewBinding sa halip na findViewById. Ang ViewBinding ay gumagawa ng klase na ActivityMainBinding sa yugto ng compilation, na nag-aalis ng mga error sa maling ID at nagbabawas ng dami ng boilerplate code. Inirerekomenda ng Google ang ViewBinding bilang karaniwang paraan ng pag-access sa View sa Activity at Fragment simula sa Android Studio 3.6.

Ang pagkakasunud-sunod ng mga aksyon sa onCreate ay dapat na mahigpit: una super, pagkatapos setContentView, pagkatapos ang lahat ng iba pa. Ang pagtawag ng findViewById bago ang setContentView ay nagbabalik ng null — ang layout ay hindi pa na-load at ang mga elemento ng View ay wala sa hierarchy. Ito ay isa sa mga pinakakaraniwang pagkakamali ng mga nagsisimulang developer ng Android.

onCreate sa Fragment

Ang onCreate sa Fragment ay naiiba sa Activity: dito hindi tinatawag ang setContentView, tanging ang pagsisimula ng data na hindi nauugnay sa UI ang ginagawa. Hinahati ng Fragment ang paggawa ng component at paggawa ng View sa dalawang magkahiwalay na pamamaraan: onCreate (tinatawag nang isang beses) at onCreateView (tinatawag sa bawat oras sa paggawa o paggawa muli ng View).

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

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

        // Pagsisimula ng ViewModel — makakaligtas sa muling paggawa ng View
        viewModel = ViewModelProvider(this)[UserViewModel::class.java]

        // Mga argumento mula sa FragmentManager
        arguments?.let {
            viewModel.loadUser(it.getString("user_id") ?: "")
        }

        // Pag-save sa pag-ikot
        retainInstance = true
    }

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

Ang pangunahing pagkakaiba sa pagitan ng onCreate ng Activity at Fragment: ang onCreate sa Fragment ay hindi dapat maglaman ng code na nauugnay sa View, dahil ang View ay maaaring sirain at muling gawin (halimbawa, sa pagpapalit ng mga tab ng ViewPager), habang ang onCreate ay tinatawag lamang nang isang beses. Pag-load ng data, pag-configure ng ViewModel, at pagsisimula ng mga adapter — mga gawain ng onCreate, habang ang pagtali ng View — gawain ng onViewCreated.

savedInstanceState at pagpapanumbalik ng estado

Ang parameter na savedInstanceState sa onCreate — ay mekanismo para sa pag-save at pagpapanumbalik ng pansamantalang estado ng Activity o Fragment. Kapag sinira ng system ang Activity (pag-ikot ng screen, kakulangan ng memorya), tinatawag nito ang onSaveInstanceState(), kung saan inilalagay ng developer ang pares ng key-value sa Bundle. Sa paggawa ng bagong instance, ang Bundle na ito ay ibinalik sa onCreate.

Sinusuportahan ng Bundle ang mga sumusunod na uri ng data: String, Integer, Boolean, Long, Float, Double, kanilang mga array, pati na rin ang mga bagay na Parcelable at Serializable. Para sa mga kumplikadong bagay, ginagamit ang Parcelable — ito ay isang mas mahusay na mekanismo ng serialization, partikular sa Android. Ang laki ng Bundle ay limitado sa humigit-kumulang 500 KB — ang paglampas sa limitasyon ay nagdudulot ng pagbubukod na 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)
}

Mahalagang maunawaan: ang onSaveInstanceState ay hindi tinatawag kapag isinara ng user ang Activity sa pamamagitan ng finish() o pagpindot sa button na “Bumalik”. Itinuturing ng system na sa kasong ito ang user ay sinasadyang nagtatapos ng trabaho at ang pag-save ng estado ay hindi kinakailangan. Samakatuwid, hindi ka dapat umasa lamang sa savedInstanceState para sa pangmatagalang pag-iimbak ng data — gamitin ang Room, DataStore o SharedPreferences.

Oras at mga limitasyon ng onCreate

Ang onCreate ay isinasagawa sa pangunahing (UI) thread at naghihintay ang system na matapos ito bago ipakita ang Activity sa screen. Kung ang onCreate ay tumagal ng higit sa 5 segundo, magpapakita ang system ng dialog ng ANR (Application Not Responding) at iminumungkahi sa user na isara ang app. Ang mga mahabang operasyon tulad ng pag-load ng data mula sa network o pagbabasa mula sa database ay dapat ilipat sa background thread.

Ayon sa mga rekomendasyon ng Google Android Performance (2025), dapat matapos ang onCreate sa mas mababa sa 1 segundo sa mga mid-segment na device. Para dito, dapat mong: gumamit ng lazy initialization (lazy delegate sa Kotlin), ipagpaliban ang pag-load ng mabibigat na data sa onResume o sa pamamagitan ng coroutine, ilapat ang ViewStub para sa mga bihirang ginagamit na component ng UI, i-profile ang oras ng pagsisimula sa pamamagitan ng Android Vitals.

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

    // Lazy initialization — ang object ay ginagawa lamang sa unang pag-access
    val heavyData by lazy {
        HeavyDataLoader.load()
    }

    // Pag-load ng data sa background thread sa pamamagitan ng lifecycleScope
    lifecycleScope.launch(Dispatchers.IO) {
        val users = userDao.getAllUsers()
        withContext(Dispatchers.Main) {
            adapter.submitList(users)
        }
    }
}

Mga tool sa profiling: Ipinapakita ng Android Studio Profiler (tab ng CPU) ang eksaktong oras ng pagpapatupad ng bawat pamamaraan. Sa Android Vitals (console ng Google Play), maaari mong subaybayan ang metrik na “Oras ng malamig na pagsisimula” — kung ang onCreate ng iyong Activity ay lumampas sa 500 ms, minarkahan ito ng console bilang problema sa pagganap. Kami sa IT Sectr ay gumagamit ng mga pagsubok sa Macrobenchmark para sa awtomatikong kontrol ng oras ng pagsisimula ng bawat Activity sa pipeline ng CI.

ViewModel at onCreate

ViewModel — ang pinakamahusay na paraan upang simulan ang data sa onCreate na dapat makaligtas sa pag-ikot ng screen. Ang ViewModel ay ginawa sa onCreate sa pamamagitan ng ViewModelProvider at awtomatikong nai-save sa pagbabago ng configuration. Kapag ang Activity ay muling ginawa pagkatapos ng pag-ikot, ang ViewModel ay nananatili sa memorya at ang onCreate ay tumatanggap ng parehong ViewModel nang walang pagkawala ng data.

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

    // ViewModel ay ginagawa nang isang beses at nakakaligtas sa mga pagbabago ng configuration
    val viewModel: ProfileViewModel =
        ViewModelProvider(this)[ProfileViewModel::class.java]

    // Pagmamasid sa LiveData — awtomatikong nag-a-update ang UI kapag nagbago ang data
    viewModel.user.observe(this) { user ->
        binding?.userName?.text = user.name
        binding?.userEmail?.text = user.email
    }

    // Pag-load ng data kung ang ViewModel ay bagong gawa
    if (savedInstanceState == null) {
        viewModel.loadProfile(userId)
    }
}

Ang kumbinasyon ng ViewModel + LiveData/StateFlow ay lumulutas sa problema ng pag-ikot ng screen nang walang manu-manong pag-save sa Bundle. Iniimbak ng ViewModel ang data sa memorya, awtomatikong muling nag-subscribe ang LiveData sa Activity sa paggawa muli, at ang StateFlow (mula sa Kotlin Coroutines) ay nagdaragdag ng reactivity na may suporta sa coroutine. Ito ang karaniwang arkitektura na inirerekomenda ng Google sa gabay na Guide to App Architecture.

Mga karaniwang pagkakamali sa pagtatrabaho sa onCreate

Kahit na ang mga may karanasang developer ay gumagawa ng mga tipikal na pagkakamali sa onCreate. Tingnan natin ang limang pinakakaraniwang problema at paraan upang maiwasan ang mga ito.

Paggawa gamit ang View bago ang setContentView

Ang pinakakaraniwang pagkakamali — pagsubok na makahanap ng View sa pamamagitan ng findViewById bago ang tawag ng setContentView. Ang lahat ng elemento ng View ay ginagawa sa sandali ng pag-inflate ng layout, kaya ang anumang pagtukoy sa findViewById bago ang setContentView ay nagbabalik ng null at nagdudulot ng NullPointerException sa pagsubok na gamitin ang View. Solusyon: mahigpit na pagkakasunud-sunod — una super, pagkatapos setContentView, pagkatapos findViewById o ViewBinding.

Pag-block sa UI thread ng mahabang operasyon

Pag-load ng data mula sa network, pagbabasa mula sa database, o pagproseso ng malalaking array nang direkta sa onCreate ay humaharang sa pag-render ng unang frame. Nakikita ng user ang isang itim na screen hanggang matapos ang onCreate, na nagpapalala sa persepsyon ng bilis ng app. Solusyon: gumamit ng lifecycleScope.launch para sa mga asynchronous na operasyon, magpakita ng skeleton (placeholder UI) hanggang matapos ang pag-load.

Pagpapabaya sa savedInstanceState

Kung sa pag-ikot ng screen ay hindi naibalik ang estado mula sa Bundle, nawawala ng user ang lahat ng hindi nai-save na input: teksto sa mga field ng form, posisyon ng scroll, mga napiling elemento. Solusyon: palaging suriin ang savedInstanceState != null sa onCreate para maibalik ang data, kahit na ang pagkawala ng estado ay tila hindi malamang.

Pagtagas ng memorya sa pamamagitan ng mga anonymous class

Ang mga anonymous class at lambda sa onCreate ay maaaring magtago ng reference sa Activity pagkatapos nito masira. Halimbawa, ang Handler na ginawa sa onCreate ay patuloy na nagpapatupad ng mga naantalang gawain kahit na matapos sirain ang Activity. Solusyon: gumamit ng LifecycleObserver, ViewModel, at lifecycleScope, na awtomatikong kumukansela ng mga gawain sa pagkawasak.

Sobrang pagsisimula sa onCreate ng Fragment

Ang pagsisimula ng View sa onCreate ng Fragment — isang lohikal na pagkakamali, dahil ang View ay maaaring muling gawin nang walang tawag ng onCreate. Kung ang isang tagapakinig ay nakatakda sa onCreate at ang View ay itinali sa onCreateView, sa paggawa muli ang tagapakinig ay mananatili sa lumang View. Solusyon: lahat ng trabaho sa View ay isinasagawa sa onViewCreated, at ang onCreate ay iwan lamang para sa pagsisimula ng layer ng data.