onStop — ano ito, pagtatago ng Activity sa lifecycle ng Android

Ano ang onStop sa Android?

onStop — ay isang callback na paraan ng klase na AppCompatActivity (at ang nauna nitong Activity), na tinatawag ng operating system ng Android kapag ang Activity ay tumigil na maging ganap na nakikita ng user. Sa sandaling ito, ang Activity ay nakatago ng ibang Activity, dialog window, system launcher, o lock screen. Mula sa pananaw ng lifecycle, ang onStop ay sumusunod pagkatapos ng onPause at nagpapahiwatig na ang Activity ay hindi na nakikita sa screen, kahit na ang object ng Activity at ang estado nito ay nananatili sa memorya.

Kapag ang Activity ay lumipat sa estado ng Stopped (itinitigil), pinapanatili nito ang estado nito sa RAM — lahat ng field, View hierarchy, at ViewModel ay nananatiling accessible. Ito ang nagtatangi ng Stopped mula sa nawasak (Destroyed) na estado, kung saan ang Activity ay ganap na tinanggal. Maaaring patayin ng System UI ang proseso ng application na nasa estado ng Stopped kapag kulang ang memorya — ito ang tinatawag na process death. Ang developer ay obligadong i-save ang kritikal na data (mga draft, scroll position) sa onSaveInstanceState(), na tinatawag bago ang onStop, upang garantiyahan ang pagbawi kapag pinatay ang proseso.

Ayon sa specifikasyon ng Android Compatibility Definition Document (CDD) para sa bersyon 14+, ang proseso sa estado ng Stopped ay may mas mababang priyoridad kapag pinapatay ng OOM Killer — mas mababa kaysa sa mga proseso sa Background phase, ngunit mas mataas kaysa sa mga naka-cache na proseso. Ayon sa estadistika ng Google, 68% ng mga kaso ng pagpatay ng proseso ay nangyayari kapag ang Activity ay nasa estado ng Stopped, hindi Paused.

Kailan tinatawag ang onStop: mga sitwasyon at pagkakasunod-sunod

onStop ay tinatawag kapag ganap na nawala ang visibility ng Activity, anuman ang dahilan: paglulunsad ng bagong Activity sa ibabaw ng kasalukuyan, pagpapaliit ng application (pagpindot ng Home), pag-lock ng screen, papasok na tawag, o pagbubukas ng system dialog. Sa lahat ng mga kasong ito, ang Activity ay unang tumatanggap ng onPause (bahagyang pagkawala ng focus), pagkatapos ay onStop (ganap na pagkawala ng visibility).

Mga pangunahing sitwasyon ng pagtawag ng onStop:

• Paglulunsad ng bagong Activity sa ibabaw ng kasalukuyan — ang kasalukuyang Activity ay tumatanggap ng onPause, pagkatapos ay onStop; ang bagong Activity ay dumadaan sa onCreate → onStart → onResume.
• Pagpapaliit ng application (Home) — ang Activity ay lumilipat sa onPause → onStop sa loob ng 200–300 ms, nananatili sa memorya sa estado ng Stopped.
• Pag-lock ng screen — tinatawag ng system ang onPause → onStop, dahil ang lock screen ay ganap na sumasakop sa Activity.
• Papasok na tawag — ang Activity ng telepono (Dialer) ay inilulunsad sa ibabaw, ang kasalukuyang Activity ay lumilipat sa onStop.
• Paglipat sa ibang application (Recent Apps) — ang Activity ay nakatago, tumatanggap ng onStop, ngunit nananatili sa cache ng proseso.

Mahalagang maunawaan na ang onStop ay hindi tinatawag sa pag-ikot ng screen — sa kasong ito, ang Activity ay nawasak (onPause → onStop → onDestroy) at nilikha muli (onCreate → onStart → onResume). Exception — ang flag na android:configChanges="orientation" sa manifest, kung saan ang Activity ay hindi muling nililikha, bagkus ay tumatanggap ng tawag na onConfigurationChanged().

onStop sa lifecycle ng Activity

onStop ay sumasakop sa sentral na lugar sa pagkakasunod-sunod ng lifecycle ng Activity sa pagitan ng nakikita at hindi nakikitang estado. Buong pagkakasunod-sunod: onCreate → onStart → onResume → (aktibong estado) → onPause → onStop → onDestroy (o onRestart → onStart → onResume sa pagbabalik).

*Sa estado ng Stopped, ang Activity ay itinatago sa memorya, ngunit maaaring patayin ng system kapag kulang ang mga mapagkukunan. Priyoridad ng pagpatay ng mga prosesong Stopped — pangalawa sa huli, mas mataas lamang sa mga walang laman na naka-cache na proseso.

onStop at onSaveInstanceState: Tinatawag ng system ang onSaveInstanceState(Bundle) bago ang onStop upang i-save ang dinamikong estado ng UI. Ang developer ay nag-o-override ng paraang ito upang i-save sa Bundle ang mga halaga ng input field, posisyon ng RecyclerView, mga napiling item. Kahit na ang Activity ay hindi nawasak (ang user ay pinaliit lamang at bumalik), ang Bundle ay ipinapasa sa onCreate sa mga pagbabago ng configuration. Inirerekomenda ng Google na i-save lamang ang pansamantalang UI state — hindi data ng repository o ViewModel na nabubuhay sa labas ng Activity.

Anong mga mapagkukunan ang dapat palayain sa onStop

Sa onStop, ang developer ay obligadong palayain ang lahat ng mga mapagkukunan na hindi kailangan kapag ang Activity ay hindi nakikita. Ito ay nagbabawas ng karga sa baterya, processor, at memorya, at pumipigil sa ANR kapag bumalik sa aktibidad.

Ano ang dapat palayain sa onStop:

• Mga animation at transitions — ihinto ang ObjectAnimator, ValueAnimator, ViewPropertyAnimator. Ang isang tumatakbong animation ng hindi nakikitang Activity ay pag-aaksaya ng mga GPU cycle.
• Mga sensor (Sensors) — mag-unsubscribe mula sa SensorManager (accelerometer, gyroscope, magnetometer). Ang mga sensor ay kumokonsumo ng enerhiya kahit na nakatago ang Activity.
• Camera at mikropono — palayain ang Camera2 o CameraX, ihinto ang MediaRecorder. Ang pag-iiwan ng camera na aktibo sa nakatagong Activity ay ipinagbabawal ng patakaran ng Google Play.
• LocationListener — mag-unsubscribe mula sa FusedLocationProviderClient o LocationManager. Ang geolocation ay ang pinaka-enerhiya na mapagkukunan.
• Network listeners — isara ang WebSocket, kanselahin ang mga HTTP request na hindi kailangan sa background.
• MediaPlayer at ExoPlayer — i-pause o ihinto kung ang pag-playback ay hindi dapat magpatuloy sa background.

Ano ang hindi dapat gawin sa onStop: Huwag magsagawa ng mahabang operasyon — pag-save ng malaking data sa database, network request, komplikadong kalkulasyon. Ang onStop ay isinasagawa sa main thread at humaharang sa pagbabalik sa Activity. Para sa mahabang operasyon, gamitin ang WorkManager na may pagkaantala o coroutine sa viewModelScope. Huwag palayain ang mga mapagkukunan ng ViewModel — ang ViewModel ay nabubuhay sa onStop at gagamitin sa pagbabalik.

Pagkakaiba sa pagitan ng onStop at onPause

Ang onPause at onStop ay naiiba sa antas ng pagkawala ng visibility at dami ng mga obligadong aksyon. Ang onPause ay tinatawag sa bahagyang pagkawala ng focus (halimbawa, pagbubukas ng dialog window o system menu), onStop — sa ganap na pagkawala ng visibility. Ang pagkakaibang ito ay mahalaga para sa pagpili kung aling mga mapagkukunan ang palalayain sa bawat yugto.

Pangkalahatang tuntunin: sa onPause, palayain ang mga system resource na agad na nakakaapekto sa karanasan ng user ng ibang application (camera, media player), sa onStop — lahat ng iba pang mapagkukunan na hindi kailangan kapag nakatago ang Activity. Inirerekomenda ng Google na i-save ang kritikal na data ng user sa onPause (draft ng email, mga setting), dahil ang onStop ay maaaring hindi mangyari sa mabilis na paglipat.

onStop → onRestart: pagbabalik sa screen

Kapag ang user ay bumalik sa nakatagong Activity, tinatawag ng system ang onRestart → onStart → onResume. Ang paraang onRestart ay nagpapahiwatig na ang Activity ay bumabalik mula sa estado ng Stopped. Ito ay isang mahalagang yugto para sa pagbawi ng UI at mga mapagkukunan na pinalaya sa onStop.

Pagkakasunod-sunod ng mga tawag sa pagbabalik:

• onRestart() — ang Activity ay naabisuhan na ito ay muling ipapakita. Mga tipikal na aksyon: muling pagkarga ng data, pag-update ng mga listahan.
• onStart() — ang Activity ay nagiging nakikita, ngunit hindi pa aktibo. Dito ang mga mapagkukunang pinalaya sa onStop ay muling sinisimulan.
• onResume() — ang Activity ay tumatanggap ng focus at handa na para sa interaksyon. Ang mga animation ay sinisimulan, ang mga sensor ay nirerehistro.

Kung ang proseso ng application ay pinatay ng system sa estado ng Stopped, ang onCreate ay tinatawag sa halip na onRestart, at ang Bundle mula sa onSaveInstanceState ay ipinapasa para sa pagbawi ng estado. Ang sitwasyong ito (process death) — isa sa mga pinakakaraniwang sanhi ng bug sa Android applications: ang mga developer ay nag-iimplementa ng onRestart ngunit nakakalimutang isaalang-alang ang pagbawi sa pamamagitan ng onCreate pagkatapos patayin ang proseso.

Mga halimbawa ng code na may onStop sa Kotlin

Halimbawa 1: Pangunahing implementasyon ng onStop na may pagpapalaya ng sensor

Nagpapakita ng tamang pag-unsubscribe mula sa mga sensor at paghinto ng animation kapag nakatago ang Activity. Pagkatapos bumalik sa screen, ang mga mapagkukunan ay naibabalik sa onStart.

class MainActivity : AppCompatActivity() {
    private lateinit var sensorManager: SensorManager
    private var accelerometer: Sensor? = null
    private var rotationAnimator: ObjectAnimator? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
        accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    }

    override fun onStart() {
        super.onStart()
        accelerometer?.let {
            sensorManager.registerListener(sensorListener, it, SensorManager.SENSOR_DELAY_NORMAL)
        }
        rotationAnimator = ObjectAnimator.ofFloat(findViewById(R.id.icon), "rotation", 0f, 360f)
        rotationAnimator?.apply {
            duration = 3000
            repeatMode = ValueAnimator.RESTART
            repeatCount = ValueAnimator.INFINITE
            start()
        }
    }

    override fun onStop() {
        super.onStop()
        sensorManager.unregisterListener(sensorListener)
        rotationAnimator?.cancel()
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("MainActivity", "Ang Activity ay bumabalik mula sa Stopped na estado")
    }

    private val sensorListener = SensorEventListener { event, _ ->
        Log.d("MainActivity", "Accel: x=${event.values[0]}, y=${event.values[1]}, z=${event.values[2]}")
    }
}

Ang code ay nagrerehistro ng accelerometer sensor at nag-start ng walang katapusang rotation animation sa onStart. Sa onStop, ang sensor ay pinapatay at ang animation ay kinakansela — ito ay pumipigil sa pagkonsumo ng baterya kapag nakatago ang Activity. Pagkatapos bumalik sa pamamagitan ng onRestart → onStart, ang mga mapagkukunan ay muling nililikha.

Halimbawa 2: onStop na may pag-save ng estado sa pamamagitan ng SavedStateHandle

Modernong approach gamit ang ViewModel + SavedStateHandle. Ang data ng form ay awtomatikong nai-save sa onStop nang walang manual na Bundle.

class FormViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {
    var email: String
        get() = savedStateHandle["email"] ?: ""
        set(value) { savedStateHandle["email"] = value }

    var message: String
        get() = savedStateHandle["message"] ?: ""
        set(value) { savedStateHandle["message"] = value }
}

class FormActivity : AppCompatActivity() {
    private val viewModel: FormViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_form)
        Log.d("FormActivity", "onCreate: email=${viewModel.email}")
    }

    override fun onStop() {
        super.onStop()
        Log.d("FormActivity", "onStop: data na-save sa SavedStateHandle")
    }
}

Awtomatikong nai-save ng SavedStateHandle ang mga halaga sa Bundle sa onSaveInstanceState, na tinatawag bago ang onStop. Sa pag-ikot ng screen o pagpatay ng proseso, ang data ay naibabalik nang walang pagkawala. Inirerekomenda ng Google ang SavedStateHandle para sa mga form at draft sa halip na direktang onSaveInstanceState.

Halimbawa 3: lifecycleScope para sa mga operasyon sa onStop

Paggamit ng lifecycleScope na may coroutine para sa asynchronous na pag-save ng data sa paglipat sa onStop. Ang coroutine ay sinisimulan sa IO dispatcher, hindi binablock ang main thread.

class NoteActivity : AppCompatActivity() {
    private val noteRepository = NoteRepository()

    override fun onStop() {
        lifecycleScope.launch(Dispatchers.IO) {
            val text = findViewById<EditText>(R.id.note_content).text.toString()
            noteRepository.saveDraft(text)
            withContext(Dispatchers.Main) {
                Log.d("NoteActivity", "Draft na-save sa onStop")
            }
        }
        super.onStop()
    }
}

Ang coroutine na lifecycleScope.launch ay awtomatikong kinakansela kung ang lifecycle ng Activity ay matapos. Ang paggamit ng Dispatchers.IO ay ginagarantiyahan na ang pagsulat sa database o file ay hindi haharang sa pagbabalik sa Activity. Ayon sa Google, ang mga coroutine sa lifecycleScope ay ang ginustong paraan para sa asynchronous na operasyon sa onStop.