onStart: esensya, visibility ng Activity sa Android screen

Esensya ng onStart method sa Android

onStart — ang pangalawang method ng lifecycle ng Activity, na tinatawag ng system pagkatapos ng onCreate (o pagkatapos ng onRestart kapag bumalik mula sa stopped state). Sa sandali ng pagtawag ng onStart, ang Activity o Fragment ay nagiging nakikita sa screen. Nakikita ng user ang interface, ngunit ang screen ay hindi pa handa para sa interaksyon — ang input focus ay lilitaw lamang pagkatapos ng onResume.

Ang onStart method ay bahagi ng “nakikitang buhay” (visible lifetime) ng Activity — ang pagitan sa pagitan ng onStart at onStop. Sa panahong ito, ang Activity ay maaaring bahagyang matakpan ng ibang mga window (halimbawa, ng transparent na Activity o dialog window), ngunit ang UI nito ay nananatiling nakikita. Ito ang nagpapakilala sa nakikitang buhay mula sa “buhay sa foreground” (onResume — onPause), kapag ang Activity ay may buong input focus.

Ang pag-unawa sa tatlong-antigong hierarchy na ito ay kritikal na mahalaga para sa tamang pamamahagi ng code. onCreate — isang beses na initialization, onStart — pagkonekta ng mga nakikitang resource, onResume — monopoly access sa eksklusibong mga resource. Ang developer na nagkakamali sa mga antas na ito ay nanganganib na lumikha ng mga pagtagas ng memory o hindi tamang pag-uugali ng app kapag lumilipat sa pagitan ng mga screen.

onStart sa Activity

Sa Activity, ang onStart method ay tinatawag sa bawat oras na ang screen ay lilitaw sa display — kapwa sa unang paglunsad (pagkatapos ng onCreate) at sa pagbabalik mula sa background mode (pagkatapos ng onRestart). Hindi tulad ng onCreate, ang onStart ay maaaring tawagin nang maraming beses sa buhay ng isang instance ng Activity, kaya dito inilalagay ang code na dapat isagawa sa bawat oras na lumilitaw ang screen.

class DashboardActivity : AppCompatActivity() {
    private val connectivityReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context?, intent: Intent?) {
            val isConnected = ... // pagsusuri ng ConnectivityManager
            binding?.statusIndicator?.setColor(
                if (isConnected) Color.GREEN else Color.RED
            )
        }
    }

    override fun onStart() {
        super.onStart()
        registerReceiver(
            connectivityReceiver,
            IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION)
        )
        SensorManager.getInstance().registerStepCounter()
    }

    override fun onStop() {
        unregisterReceiver(connectivityReceiver)
        SensorManager.getInstance().unregisterStepCounter()
        super.onStop()
    }
}

Pangunahing patakaran: lahat ng resource na nakonekta sa onStart ay dapat ilabas sa onStop. Ito ay ginagarantiyahan na kapag ang Activity ay nakatago mula sa screen, hindi ito kumokonsumo ng baterya, hindi nakikinig sa mga system event, at hindi sumasakop ng memory. Ang Android Studio ay naglalaman ng mga lint rule na nagbababala tungkol sa pagrehistro ng BroadcastReceiver nang walang kaukulang pag-unsubscribe.

onStart sa Fragment

Ang onStart sa Fragment ay malapit na nakatali sa lifecycle ng Activity-container. Ang Fragment ay tumatanggap ng onStart call pagkatapos na ang Activity kung saan ito matatagpuan ay nakatanggap ng onStart. Gayunpaman, kung ang Fragment ay idinagdag sa deferred mode (FragmentTransaction.commit() walang addToBackStack), ang onStart ay maaaring tawagin nang may pagkaantala.

class MapFragment : Fragment() {
    private var mapView: MapView? = null

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        mapView = MapView(requireContext())
        return mapView!!
    }

    override fun onStart() {
        super.onStart()
        mapView?.onStart()
        LocationService.connect(requireContext())
    }

    override fun onStop() {
        mapView?.onStop()
        LocationService.disconnect()
        super.onStop()
    }
}

Katangian ng Fragment.onStart: kung ang Fragment ay nasa ViewPager na may offscreenPageLimit = 1, ang mga katabing fragment ay makakatanggap din ng onStart bago sila maging nakikita. Ito ay maaaring humantong sa napaagang pagrehistro ng mga tagapakinig. Para sa mga ganitong kaso, gamitin ang method na setUserVisibleHint() o pagsusuri ng isVisible sa loob ng onStart upang magrehistro ng mga tagapakinig para lamang sa mga talagang nakikitang fragment.

Pagkakaiba sa pagitan ng onStart at onResume

Ang pangunahing pagkakaiba sa pagitan ng onStart at onResume — ang antas ng aktibidad ng screen. Ang onStart ay nagpapahiwatig na ang Activity ay nakikita sa screen, ngunit hindi kinakailangang nasa foreground. Ang onResume ay nagpapahiwatig na ang Activity ay nasa foreground at may input focus. Ang pagkakaiba ay ipinapakita sa pamamagitan ng halimbawa ng dialog window: kapag ang Dialog ay lumitaw sa itaas ng Activity, ang Activity ay nawawalan ng onResume (onPause ay tinatawag), ngunit nananatiling nakikita — onStart/onStop ay hindi tinatawag.

Talaan ng mga pagkakaiba ay malinaw na nagpapakita kung sa anong mga senaryo tinatawag ang bawat method:

Tumutulong ang talahanayang ito sa developer na magpasya kung saang method ilalagay ang partikular na code. Halimbawa, kung ang app ay dapat mag-pause ng video playback sa anumang pagtakip ng screen (kahit sa dialog), ang code ay inilalagay sa onPause. Kung ang video ay dapat huminto lamang sa kumpletong pagtatago ng screen — ang code ay inilalagay sa onStop.

Pagrehistro ng mga tagapakinig at serbisyo

onStart — ang optimal na lugar para magrehistro ng mga tagapakinig na dapat gumana lamang habang ang Activity ay nakikita sa screen. Ito ay tungkol sa tatlong pangunahing uri ng system component: BroadcastReceiver para sa mga system event, LocationListener para sa geolocation, at SensorListener para sa mga sensor ng device.

BroadcastReceiver sa onStart

Ang BroadcastReceiver ay dinamikong nirerehistro sa pamamagitan ng Context.registerReceiver() sa onStart at nag-a-unsubscribe sa onStop sa pamamagitan ng unregisterReceiver(). Ang dinamikong pagrehistro ay mas gusto kaysa sa static (sa manifest), dahil nililimitahan nito ang buhay ng receiver sa panahon ng visibility ng Activity — ang app ay hindi nagigising mula sa system broadcast message kapag ang Activity ay nakatago.

private val batteryReceiver = object : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent) {
        val level = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1)
        binding?.batteryText?.text = "$level%"
    }
}

override fun onStart() {
    super.onStart()
    registerReceiver(batteryReceiver, IntentFilter(Intent.ACTION_BATTERY_CHANGED))
}

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

LocationListener at SensorListener

Geolocation at mga sensor — mga operasyong malakas sa resource. Ang paghingi ng GPS updates sa onStart at pagkansela sa onStop ay ginagarantiyahan na ang app ay hindi kumokonsumo ng baterya kapag ang screen ay nakatago. Para sa tumpak na pagsasaayos, gamitin ang requestLocationUpdates na may minimum na interval at distansya — halimbawa, 10 segundo at 10 metro, na nagbibigay ng optimal na balanse sa pagitan ng katumpakan at konsumo ng enerhiya.

Mga Animasyon at onStart

Ang pagsisimula ng mga animasyon sa onStart, hindi sa onCreate, ay ginagarantiyahan na ang animasyon ay magsisimula sa bawat oras na lumilitaw ang screen. Kung sisimulan mo ang animasyon sa onCreate, ito ay gagana lamang sa unang paggawa ng Activity, ngunit hindi sa pagbabalik mula sa background mode. Ang onStart ay tinatawag sa bawat oras na ang Activity ay nagiging nakikita, na ginagawa itong perpektong lugar para sa pagsisimula ng mga cyclic na animasyon at transition.

private lateinit var pulseAnimator: ValueAnimator

override fun onStart() {
    super.onStart()
    pulseAnimator.start()
    binding?.loadingIndicator?.animate()?.alpha(1f)?.start()
}

override fun onStop() {
    pulseAnimator.cancel()
    binding?.loadingIndicator?.animate()?.cancel()
    super.onStop()
}

Para sa mga animasyon na gumagamit ng ObjectAnimator o ValueAnimator, mahalagang tawagin ang cancel() sa onStop. Kung ang animasyon ay patuloy na gumagana pagkatapos itago ang Activity, walang kabuluhang kumokonsumo ito ng GPU at CPU resources, na nagpapababa ng performance ng device at nagpapabilis ng pag-discharge ng baterya. Ang Android Studio Profiler (GPU graph) ay nagbibigay-daan sa pagsubaybay ng mga aktibong animasyon at pag-detect ng mga pagtagas.

Ang patakaran ng pares na onStart/onStop ay nalalapat din sa pagtatrabaho sa camera para sa preview (CameraX). Ang pagbubukas ng camera sa onStart at pagsasara sa onStop ay ginagarantiyahan na ang camera ay hindi naka-block para sa ibang mga app kapag ang iyong app ay hindi nakikita sa screen. Ang paglabag sa patakarang ito ay isa sa mga karaniwang dahilan ng negatibong review sa Google Play.