Activity Lifecycle: ano ito, onCreate onStart onResume sa Android

Ano ang Activity Lifecycle

Activity Lifecycle (lifecycle ng Activity) — isang finite state machine na pinagdadaanan ng bawat screen ng Android application mula sa sandali ng paggawa hanggang sa ganap na pagkasira. Pinamamahalaan ng Android system ang prosesong ito batay sa mga aksyon ng user: pagbubukas ng application, pag-minimize, pag-ikot ng screen, pagsagot sa papasok na tawag, paglipat sa pagitan ng mga application, at pagtatapos.

Ang pag-unawa sa lifecycle ay kinakailangan para sa bawat Android developer, dahil maaaring sirain ng system ang Activity anumang oras kapag kulang ang memory — at ang application ay dapat na maibalik nang tama ang estado nito. Ayon sa Google Android Vitals (2025), ang mga application na hindi humahawak ng pag-save ng estado sa onSaveInstanceState() ay nagpapakita ng 42% mas maraming pag-crash sa muling paggawa ng Activity.

Ang lifecycle ay may kasamang anim na pangunahing callback method: onCreate(), onStart(), onResume(), onPause(), onStop(), onDestroy(). Bukod pa rito, may pamamaraang onRestart() na tinatawagan bago ang onStart() kapag bumalik ang Activity mula sa tumigil na estado. Ang bawat pamamaraan ay may mahigpit na tinukoy na layunin at oras ng pagpapatupad — tinatawagan sila ng system nang sunud-sunod, at maaaring i-override ng developer ang alinman sa mga ito upang isagawa ang kanilang sariling logic.

Ang cycle ay maaaring hatiin sa tatlong pangunahing yugto: buong habang-buhay (onCreate → onDestroy), nakikitang habang-buhay (onStart → onStop), at habang-buhay sa foreground (onResume → onPause). Ang pag-unawa sa tatlong antas na ito ay tumutulong sa wastong pamamahagi ng initialization code at pagpapalaya ng mga mapagkukunan.

Mga pamamaraan ng lifecycle ng Activity

Ang bawat pamamaraan ng lifecycle ay nagsasagawa ng mahigpit na tinukoy na gawain. Tinatawagan sila ng system sa isang nakapirming pagkakasunud-sunod, at ang developer ay dapat lamang mag-override ng mga pamamaraan na kinakailangan para sa partikular na logic. Hindi inirerekomenda na direktang tawagan ang mga lifecycle method — ito ay ginagawa ng Android Runtime.

Pangkalahatang scheme ng mga tawag

Karaniwang pagkakasunud-sunod sa pagsisimula ng application: onCreate → onStart → onResume. Sa pagpindot ng “Bumalik” na buton: onPause → onStop → onDestroy. Sa pag-minimize: onPause → onStop, pagkatapos sa pagbalik: onRestart → onStart → onResume.

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

    override fun onStart() {
        super.onStart()
    }

    override fun onResume() {
        super.onResume()
    }

    override fun onPause() {
        super.onPause()
    }

    override fun onStop() {
        super.onStop()
    }

    override fun onDestroy() {
        super.onDestroy()
    }

    override fun onRestart() {
        super.onRestart()
    }
}

Ang bawat na-override na pamamaraan ay dapat tumawag sa super na bersyon — kung wala ito, hindi makukumpleto ng system nang tama ang transition sa pagitan ng mga estado. Ang panuntunang ito ay nakasaad sa dokumentasyon ng Android Developers at sinusuri ng mga lint rule ng Android Studio.

Tatlong antas ng lifecycle

Unang antas — buong habang-buhay (entire lifetime): agwat sa pagitan ng onCreate at onDestroy. Dito isinasagawa ang isang beses na pagsisimula at huling pagpapalaya ng mga pandaigdigang mapagkukunan. Ikalawang antas — nakikitang habang-buhay (visible lifetime): sa pagitan ng onStart at onStop. Ang Activity ay nakikita sa screen, ngunit maaaring bahagyang natatakpan ng ibang window. Ikatlong antas — habang-buhay sa foreground (foreground lifetime): sa pagitan ng onResume at onPause. Ang Activity ay nasa tuktok ng task stack at nakikipag-ugnayan sa user.

onCreate — paggawa ng Activity

onCreate() — ang una at tanging mandatoryong pamamaraan ng lifecycle ng Activity. Ito ay tinatawagan nang isang beses ng system sa paggawa ng instance ng Activity. Ang pamamaraang ito ay tumatanggap ng parameter na savedInstanceState: Bundle? na naglalaman ng dating na-save na estado, kung ang Activity ay muling ginawa pagkatapos ng pagkasira — halimbawa, sa pag-ikot ng screen.

Sa loob ng onCreate, ang mga sumusunod na gawain ay isinasagawa: pagsisimula ng user interface sa pamamagitan ng setContentView() na may pagpapadala ng layout resource, pagbubuklod ng mga View element sa pamamagitan ng findViewById(), pag-configure ng mga adapter para sa RecyclerView at ViewPager, pagpapanumbalik ng estado mula sa savedInstanceState, pagsisimula ng ViewModel at LiveData, pag-configure ng mga click at gesture listener. Ang pamamaraan ay dapat matapos nang mabilis hangga't maaari — ang mga matagal na operasyon dito ay humaharang sa pag-render ng unang frame, na nagpapataas ng oras ng pagsisimula ng application.

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

    val userNameText: TextView = findViewById(R.id.user_name)
    val loadButton: Button = findViewById(R.id.load_button)

    if (savedInstanceState != null) {
        userNameText.text = savedInstanceState.getString("user_name")
    }

    loadButton.setOnClickListener {
        loadUserProfile()
    }
}

Kung ang Activity ay ginagawa sa unang pagkakataon, ang savedInstanceState ay katumbas ng null. Sa muling paggawa pagkatapos ng pag-ikot ng screen, ang Bundle ay naglalaman ng data na na-save sa onSaveInstanceState(). Ang pagsusuri para sa null ay isang karaniwang kasanayan para sa tamang pagpapanumbalik ng UI nang walang pagkawala ng data na inilagay ng user.

onStart — paglitaw sa screen

Ang onStart() ay tinatawagan kaagad pagkatapos ng onCreate() o pagkatapos ng onRestart(), kapag ang Activity ay naging nakikita ng user. Sa estadong ito, ang Activity ay wala pa sa foreground at hindi makakapag-interact sa user, ngunit ang user interface nito ay nakikita na sa screen. Halimbawa, sa pagsisimula ng application, sa pagitan ng pagtawag ng onStart at onResume, ine-render ng system ang unang frame ng interface.

Sa pamamaraang onStart, karaniwang isinasagawa ang mga sumusunod na aksyon: pagsisimula ng mga animation na dapat gumana habang nakikita ang Activity; pagbubuklod ng mga BroadcastReceiver; pagkonekta sa mga serbisyo ng geolocation at sensor; pag-update ng data mula sa ViewModel o Room. Dito rin isinasagawa ang pagbubuklod sa mga Bound-service sa pamamagitan ng bindService(), kung ang application ay gumagamit ng client-server architecture sa loob ng proseso.

override fun onStart() {
    super.onStart()
    val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
    locationManager.requestLocationUpdates(
        LocationManager.GPS_PROVIDER,
        5000L,
        10f,
        locationListener
    )
}

override fun onStop() {
    super.onStop()
    val locationManager = getSystemService(Context.LOCATION_SERVICE) as LocationManager
    locationManager.removeUpdates(locationListener)
}

Mahalagang panuntunan: ang mga mapagkukunang nakonekta sa onStart ay dapat pakawalan sa onStop. Tinitiyak nito na kapag ang Activity ay hindi nakikita sa screen, hindi ito kumokonsumo ng baterya at mga mapagkukunan ng system. Sinusuri ng Google Play Store ang mga application para sa pagtagas ng LocationListener at iba pang serbisyo ng system sa pag-moderate ng mga update.

onResume — pagkuha ng focus

onResume() — ang estado kung saan ang Activity ay nasa foreground at handa na para sa pakikipag-ugnayan sa user. Ito ang working state ng screen: ibinibigay ng system ang input focus sa Activity, at lahat ng touch event, keyboard input, at gestures ay nakadirekta sa screen na ito. Ang onResume method ay tinatawagan sa bawat oras na bumalik ang Activity sa foreground — pagkatapos ng pagkumpleto ng ibang Activity, pagkatapos isara ang dialog window, pagkatapos i-unlock ang device.

Sa onResume isinasagawa: pagpapatuloy ng mga animation na na-pause sa onPause; pagbubukas ng camera at iba pang eksklusibong mapagkukunan; pagpaparehistro ng mga sensor listener (accelerometer, gyroscope); pagsisimula ng mga timer at stopwatch para sa UI; pag-update ng nilalaman ng screen gamit ang mga kasalukuyang data. Sa pares na onResume / onPause, ginagawa ang mga mapagkukunang dapat aktibo lamang sa focus — halimbawa, patuloy na pagkilala sa pagsasalita o pagkuha ng video.

override fun onResume() {
    super.onResume()
    cameraHolder.openCamera()
    animator.resume()
    sensorManager.registerListener(
        stepCounter,
        sensorManager.getDefaultSensor(Sensor.TYPE_STEP_COUNTER),
        SensorManager.SENSOR_DELAY_NORMAL
    )
}

override fun onPause() {
    super.onPause()
    cameraHolder.closeCamera()
    animator.pause()
    sensorManager.unregisterListener(stepCounter)
}

Ang pagkakaiba sa pagitan ng onStart at onResume ay makabuluhan: ang Activity ay maaaring nakikita (onStart) ngunit hindi aktibo (onResume) — halimbawa, kapag may pop-up dialog window o transparent lock screen na ipinapakita sa itaas nito. Tama sa onResume, hindi sa onStart, dapat buksan ang mga eksklusibong mapagkukunan na nangangailangan ng monopolistikong access.

onPause — pagkawala ng focus

Ang onPause() ay tinatawagan kapag nawala ng Activity ang input focus, ngunit nananatiling bahagyang nakikita. Mga karaniwang scenario: pagbubukas ng dialog window, pagpindot ng “Mga Kamakailang Application” na buton, papasok na tawag, pagpindot ng “Home” na buton (sa kasong ito, susunod ang onStop pagkatapos ng onPause). Ang onPause method ay ang huling maaasahang lugar para i-save ang data na hindi dapat mawala ng user.

Sa onPause isinasagawa: pag-save ng mga draft ng email at mga form ng input sa Room o SharedPreferences; pagtigil ng mga animation at video playback; pagsara ng camera at pagpapakawala ng mga monopolistikong mapagkukunan; pagkansela ng mga mamahaling operasyon na hindi kritikal para sa background. Ang onPause method ay dapat matapos sa mas mababa sa 100 millisecond — hinaharangan ng system ang transition sa susunod na Activity hanggang sa ibalik ng onPause ang kontrol, at ang paglampas sa limitasyon ay humahantong sa ANR (Application Not Responding).

override fun onPause() {
    super.onPause()
    val editor = SharedPreferences.Manager ...
    editor.putString("draft_text", draftEditText.text.toString())
    editor.apply()
    videoView.pause()
    cameraHolder.release()
}

Mahalaga: ang onPause ay isinasagawa sa UI thread, kaya ang anumang blocking operations, tulad ng pagsulat sa database sa pamamagitan ng Room na may synchronous query, ay dapat palitan ng asynchronous (coroutines) o isagawa sa background thread. Gamitin ang apply() sa halip na commit() para sa SharedPreferences — ang apply ay nagsusulat ng data nang asynchronous at hindi hinaharangan ang UI thread.

onStop — pagtatago mula sa screen

Ang onStop() ay tinatawagan kapag ang Activity ay hindi na nakikita ng user. Ito ay nangyayari sa mga sumusunod na kaso: ang Activity ay ganap na natatakpan ng ibang Activity; pinindot ng user ang “Home” na buton o lumipat sa ibang application; ang Activity ay tinatapos (tatawagin pagkatapos ang onDestroy). Sa estado ng onStop, ang Activity ay nananatili sa memory at pinapanatili ang lahat ng field nito — hindi ito nawasak, ngunit hindi rin aktibo.

Sa onStop isinasagawa: pag-unsubscribe mula sa BroadcastReceiver na nirehistro sa onStart; pagdiskonekta mula sa Bound-services; pagpapakawala ng LocationListener, SensorListener, at iba pang system listener; pagtigil ng matagal na background operations na hindi kailangan kapag nakatago ang application; pagsulat ng kasalukuyang UI state sa Bundle sa pamamagitan ng onSaveInstanceState(), kung hindi ito nagawa sa onPause.

override fun onStop() {
    super.onStop()
    unregisterReceiver(connectivityReceiver)
    unbindService(serviceConnection)
    if (isChangingConfigurations()) {
        Log.d("Lifecycle", "Ang Activity ay muling ginagawa dahil sa configuration")
    }
}

Maaaring sirain ng system ang Activity sa estado ng onStop nang hindi tinatawagan ang onDestroy kapag kulang ang memory. Kaya ang lahat ng kritikal na data ay dapat i-save bago ang transition sa onStop. Ang flag na isChangingConfigurations() ay nagbibigay-daan upang matukoy kung ang pagtawag ng onStop ay nauugnay sa pag-ikot ng screen — sa kasong ito, ang Activity ay muling gagawin, hindi tatapusin.

onDestroy — pagkasira ng Activity

onDestroy() — ang huling pamamaraan ng lifecycle, tinatawagan bago ang ganap na pagkasira ng Activity. Tinatawagan ng system ang onDestroy sa dalawang kaso: ang Activity ay tinatapos sa pamamagitan ng pagtawag ng finish() o pinindot ng user ang “Bumalik” na buton; ang Activity ay sinisira ng system dahil sa pagbabago ng configuration (halimbawa, pag-ikot ng screen) at muling gagawin. Ang onDestroy method ay nagbibigay-daan sa huling paglilinis ng mga mapagkukunan: pagtanggal ng mga thread at coroutine, pagsasara ng permanenteng bukas na mga cursor at socket, pagpapakawala ng native memory sa pamamagitan ng NDK.

override fun onDestroy() {
    super.onDestroy()
    backgroundJob.cancel()
    dbHelper.close()
    if (isFinishing) {
        Log.d("Lifecycle", "Ang Activity ay tuluyang tinatapos")
    } else {
        Log.d("Lifecycle", "Ang Activity ay muling gagawin")
    }
}

Mahalagang tala: ang onDestroy ay hindi garantisado kung ang proseso ng application ay pinatay ng system (out-of-memory kill). Kaya hindi maaaring umasa sa onDestroy para sa pag-save ng data — ang gawaing ito ay nalutas sa onPause o onStop. Ang property na isFinishing ay nagbibigay-daan upang makilala ang pagtatapos ng Activity sa pamamagitan ng finish() mula sa muling paggawa sa pagbabago ng configuration.

onRestart — pagbalik mula sa tumigil na estado

Ang onRestart() ay tinatawagan bago ang onStart(), kapag ang Activity ay bumalik mula sa tumigil na estado (onStop) pabalik sa foreground. Ito ay nangyayari kapag muling binuksan ng user ang application mula sa “Mga Kamakailan” na menu o bumalik sa Activity sa pamamagitan ng pagpindot ng “Bumalik” sa child screen. Ang onRestart method ay nagbibigay-daan upang isagawa ang logic na naiiba sa onCreate — halimbawa, pag-update ng data na maaaring nagbago habang nakatago ang Activity.

override fun onRestart() {
    super.onRestart()
    refreshDataFromNetwork()
    Log.d("Lifecycle", "Ang Activity ay muling sisimulan mula sa stack")
}

Karaniwang scenario: binuksan ng user ang application, lumipat sa ibang gawain, at bumalik makalipas ang isang oras. Sa onRestart, maaaring suriin ng application ang pagiging napapanahon ng data at, kung maraming oras na ang lumipas, mag-alok na i-reload ang content. Pinapabuti nito ang karanasan ng user at binabawasan ang posibilidad ng pagpapakita ng lumang impormasyon.

Pag-ikot ng screen at pag-save ng estado

Pag-ikot ng screen — ang pinakakaraniwang scenario para sa muling paggawa ng Activity. Bilang default, sinisira ng Android ang kasalukuyang Activity at gumagawa ng bago sa bawat pagbabago ng oryentasyon. Kung hindi nai-save ang estado, mawawala sa user ang lahat ng inilagay na data. Para dito, nagbibigay ang Android ng dalawang mekanismo: onSaveInstanceState() para sa serializable na data at ViewModel para sa data na nakaligtas sa mga pagbabago ng configuration.

onSaveInstanceState at onRestoreInstanceState

Ang onSaveInstanceState() ay tinatawagan bago ang pagkasira ng Activity upang i-save ang pansamantalang estado. Ang na-save na data ay ipinapadala sa onCreate sa pamamagitan ng parameter na savedInstanceState at sa onRestoreInstanceState method na tinatawagan pagkatapos ng onStart. Ang Bundle ay may limitasyon sa laki — mga 500 KB, kaya ang malalaking volume ng data (halimbawa, bitmap) ay ini-save sa pamamagitan ng ViewModel.

<!-- AndroidManifest.xml — pag-aayos ng oryentasyon -->
<activity android:name=".MainActivity"
    android:configChanges="orientation|screenSize" />

Ang pag-aayos ng oryentasyon sa pamamagitan ng android:configChanges ay pumipigil sa muling paggawa ng Activity, ngunit itinuturing na antipattern kung ang application ay dapat sumuporta sa parehong oryentasyon. Ang modernong rekomendasyon ng Google — gamitin ang ViewModel kasama ng onSaveInstanceState para sa data na inilalagay ng user sa UI.

Lifecycle ng Fragment

Ang Fragment ay may sariling lifecycle, katulad ng Activity, ngunit may mga karagdagang pamamaraan: onAttach, onCreate, onCreateView, onViewCreated, onStart, onResume, onPause, onStop, onDestroyView, onDestroy, onDetach. Ang Fragment ay palaging umiiral sa loob ng Activity, at ang lifecycle nito ay nakatali sa lifecycle ng container-Activity. Kung ang Activity ay nawasak, sinusundan ito ng Fragment.

Pangunahing pagkakaiba: ang Fragment ay hindi lamang namamahala ng estado ng component, kundi pati na rin ng hierarchy ng View. Ang onCreateView method ay nagbabalik ng root View ng fragment, at ang onDestroyView ay sumisira sa hierarchy na ito. Pinapayagan nito ang Fragment na makaligtas sa muling paggawa ng Activity sa pag-ikot ng screen: ang Fragment ay pinapanatili, at ang View nito ay muling ginagawa sa onCreateView.

class ProfileFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        return inflater.inflate(R.layout.fragment_profile, container, false)
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        val avatarImage: ImageView = view.findViewById(R.id.avatar_image)
        loadAvatar(avatarImage)
    }
}

Ang pag-unawa sa pagkakaiba sa pagitan ng onCreate at onCreateView ay kritikal na mahalaga: ang onCreate ay tinatawagan nang isang beses sa buhay ng Fragment (kahit sa muling paggawa ng View), habang ang onCreateView ay tinatawagan sa bawat oras na ginagawa o muling ginagawa ng Fragment ang View hierarchy nito. Ang pagsisimula ng data ay isinasagawa sa onCreate, at ang pagbubuklod ng UI sa onViewCreated.

LifecycleObserver at Jetpack

LifecycleObserver — isang bahagi ng Android Jetpack library na nagbibigay-daan upang tumugon sa mga pagbabago ng lifecycle nang hindi nag-o-override ng mga pamamaraan sa Activity o Fragment. Sa halip na duplicate ang code sa bawat lifecycle method, gumagawa ang developer ng hiwalay na klase na may mga anotasyong @OnLifecycleEvent at ipinapadala ito sa lifecycle.addObserver().

Ang Jetpack ay nagbibigay din ng klase na LifecycleOwner — isang interface na ipinapatupad ng AppCompatActivity at Fragment. Anumang object na nagpapatupad ng LifecycleOwner ay maaaring mamahala ng mga subscription ng LiveData, coroutine sa pamamagitan ng lifecycleScope, at trabaho ng WorkManager kaugnay ng lifecycle. Ito ang pundasyon ng modernong Android architecture batay sa MVVM at Jetpack.

class MyLocationObserver(private val context: Context) : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        startLocationUpdates()
    }

    override fun onStop(owner: LifecycleOwner) {
        stopLocationUpdates()
    }
}

// Sa Activity:
lifecycle.addObserver(MyLocationObserver(this))

Ang paggamit ng DefaultLifecycleObserver ay nagpapasimple ng pagsubok, nagbabawas ng duplikasyon ng code, at ginagawang reusable ang lifecycle logic sa pagitan ng iba't ibang screen. Ito ay modernong kapalit para sa manu-manong pag-override ng onStart/onStop sa bawat Activity. Sa mga Android application na binuo ng IT Sectr, inilalapat namin ang LifecycleObserver para sa geolocation, Bluetooth scanning, at analytics — binabawasan nito ang dami ng boilerplate code ng 30–40%.