Warm Start: esensya, mainit na pagsisimula at optimisasyon sa Android

Ano ang Warm Start

Warm Start (mainit na pagsisimula) ay isang estado sa pagitan ng Cold Start at Hot Start: ang proseso ng app ay nasa memorya (minsan sa Linux background cache), ngunit ang Activity ay hindi aktibo at muling lilikhain. Ang Android system kapag kulang sa RAM ay maaaring magbaba ng Activity mula sa stack, na iniiwan ang proseso na buhay. Kapag bumalik ang user sa app, magsisimula ang Warm Start: bagong instance ng Activity ay nilikha, ang lifecycle method na onCreate → onStart → onResume ay isinasagawa, ngunit ang Application.onCreate at pag-load ng klase ay nilalampasan.

Mga dahilan ng Warm Start

Ang Android system ay gumagawa ng desisyon tungkol sa pagbaba ng Activity batay sa priyoridad ng proseso (importance rank). Ang Activity sa background (antas PROCESS_STATE_IMPORTANT_FOREGROUND o PROCESS_STATE_TOP_SLEEPING) ay maaaring masira 5–30 minuto pagkatapos ng pag-minimize ng app, depende sa available na RAM. Sa mga device na may 3 GB RAM, ang Activity ay maaaring ibaba pagkatapos ng 10 minuto, sa mga device na may 8 GB — pagkatapos ng ilang oras. Mahalaga: sa Warm Start onSaveInstanceState ay tinatawag bago ang pagkasira ng Activity at ang developer ay maaaring mag-save ng estado ng UI.

Persepsyon ng user

Ang user ay hindi nakakakita ng pagkakaiba sa pagitan ng Warm at Cold Start — pinindot lang niya ang icon ng app at naghihintay. Ngunit sa Warm Start maaaring lumitaw ang puting screen (blank window) kung ang app ay hindi nag-set ng sarili nitong theme para sa start window. Inirerekomenda ng Google na mag-set ng custom na theme sa manifest (Theme.AppCompat.Light o Theme.Material3.DayNight) para sa start Activity upang maiwasan ang pagkutitap ng puting/itim na screen sa Warm Start. Sa Android 12+, ang SplashScreen API ay nagtatago rin ng epektong ito.

Warm Start vs Cold Start vs Hot Start

Ang pag-unawa sa pagkakaiba sa pagitan ng tatlong uri ng pagsisimula ay kinakailangan para sa pagpili ng tamang profiling at optimisasyon na estratehiya. Ang bawat uri ay may sariling tagal, sariling bottleneck, at sariling kasangkapan sa pagsukat.

Sa praktika, ang Warm Start ay bumubuo ng 30% hanggang 60% ng lahat ng pagsisimula ng app, depende sa gawi ng user at dami ng RAM ng device. Ang mga user na nagpapanatili ng maraming app na bukas (multitasker) ay mas madalas nakakaranas ng Warm Start. Para sa social network at messenger, ang Warm Start ang pinakakaraniwang senaryo dahil ang app ay palaging nasa background. Para sa mga banking app, sa kabaligtaran, ang Cold Start ang nangingibabaw (sapilitang paglilinis ng proseso para sa mga kadahilanang pangseguridad).

Mga yugto ng mainit na pagsisimula

Ang Warm Start ay binubuo ng tatlong yugto, bawat isa ay maaaring sukatin at i-optimize. Hindi tulad ng Cold Start, walang yugto ng fork at pag-load ng klase, ngunit may yugto ng pagpapanumbalik ng estado (restore) na maaaring magastos.

Yugto 1: Start window (window background)

Sinusuri ng system kung ang app ay may theme para sa start window. Kung walang nakatakdang theme, ipinapakita ang puting (o itim, depende sa system) na screen. Kung may nakatakdang theme, ipinapakita ang background mula sa theme. Ang yugtong ito ay tumatagal ng 10–30 ms, ngunit biswal na nararamdaman kung ang theme ay hindi tumutugma sa aktwal na UI ng app. Gamitin ang Theme.Material3.DayNight na may custom na windowBackground na ang kulay ay tumutugma sa background ng unang screen — ito ay lumilikha ng epekto ng instant na pag-load.

Yugto 2: Paglikha ng Activity (pagpapanumbalik)

Tinatawag ng system ang onCreate na may pagpapadala ng Bundle savedInstanceState na na-save sa onSaveInstanceState bago ang pagkasira ng Activity. Kung ang app ay nag-save ng estado nang tama (teksto ng field, posisyon ng scroll, data ng ViewModel), ang pagpapanumbalik ay mabilis na nangyayari. Kung hindi — ang Activity ay magsisimula mula sa blangkong pahina at makikita ng user ang loader habang naglo-load ang data. Pangunahing punto: ang mga ViewModel object ay nakakaligtas sa Warm Start lamang kung ang proseso ay hindi nawasak — sa Warm Start ang ViewModel ay nananatili sa memorya.

Yugto 3: Unang frame (TTFD)

Pagkatapos ng onCreate, isinasagawa ang onStart → onResume at tinatawag ng system ang unang pag-render. Ang TTFD (Time To First Draw) para sa Warm Start ay dapat na mas mababa sa 300 ms sa katamtamang device. Kung ang unang screen ay naglalaman ng kumplikadong RecyclerView na may mabibigat na View o naglo-load ng mga imahe sa pamamagitan ng network, ang TTFD ay maaaring lumampas sa hangganan. Gamitin ang Placeholder at Shimmer para sa maayos na pag-load ng nilalaman pagkatapos ng unang frame.

Paano sukatin ang Warm Start

Ang pagsukat ng Warm Start ay mas kumplikado kaysa sa Cold Start dahil kailangan mong i-simulate ang estado na «buhay ang proseso, nawasak ang Activity». Ang karaniwang ADB command na may bandila na -S ay hindi angkop — pinapatay nito ang proseso. Para sa Warm Start gumamit ng ibang approach.

ADB shell am start nang walang -S

Una, patakbuhin ang app sa pamamagitan ng adb shell monkey o tapikin ang icon, pagkatapos ay i-minimize ito (adb shell input keyevent 3 keyevent HOME). Maghintay ng 5–10 segundo upang maibaba ng system ang Activity at patakbuhin ang adb shell am start -W (walang -S). Ang command ay magbabalik ng oras ng pagsisimula na mas maikli kaysa sa Cold Start. Para sa reproducibility gumamit ng script: patakbuhin → maghintay → home → maghintay → patakbuhin.

# Simulasyon ng Warm Start sa pamamagitan ng ADB
$ adb shell am start -W \
    com.example.app/.MainActivity

# Output (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Macrobenchmark para sa Warm Start

Ang library na androidx.benchmark.macro ay sumusuporta sa pagsukat ng Warm Start. Para dito sa test itakda ang startupMode = StartupMode.WARM — ang library ay magpapatakbo ng app, i-minimize ito, maghihintay (configurable delay), at pagkatapos ay susukatin ang muling pagsisimula. Ang Macrobenchmark ay gumagawa ng 10–20 runs at kinakalkula ang mga percentile. Sa CI/CD maaari kang magtakda ng hangganan: kung ang P50 Warm Start ay lumampas sa 600 ms — ang test ay bumagsak. Ito ay nagpapahintulot sa pagsubaybay ng mga regression sa bawat commit.

Firebase Performance Monitoring

Ang Firebase ay awtomatikong nag-iiba ng Cold at Warm Start batay sa oras mula noong huling pagsasara ng app. Kung ang app ay binuksan sa nakaraang 30 minuto, inuuri ng Firebase ang pagsisimula bilang Warm. Sa Firebase console makikita mo ang mga hiwalay na graph para sa bawat uri ng pagsisimula, na nagpapahintulot sa pagsusuri ng epektibidad ng mga optimisasyon. Halimbawa, pagkatapos i-implement ang pag-save ng estado sa ViewModel, makikita ang pagbaba ng Warm Start ng hanggang 30%.

I-optimize ang Warm Start

Ang optimisasyon ng Warm Start ay nakatuon sa dalawang direksyon: pagpapabilis ng Activity.onCreate at tamang pagpapanumbalik ng estado. Dahil ang Application.onCreate at pag-load ng klase ay naisagawa na, ang pangunahing bottleneck ay ang UI code ng unang screen.

Asynchronous na pagpapanumbalik ng estado

Kung ang na-save na estado (savedInstanceState) ay naglalaman ng data na kailangang i-deserialize (Bitmap, String, JSON), gawin ito sa background thread. Sa halip na direktang pagbabasa mula sa Bundle sa onCreate, magpatakbo ng coroutine at magpakita ng shimmer screen. Sa praktika, ang deserialization ng Bundle sa katamtamang device ay tumatagal ng 20–100 ms — mukhang kaunti, ngunit para sa Warm Start ito ay 10–50% ng kabuuang oras. Gamitin ang Saved State Module ng Jetpack library na awtomatikong nagse-save at nagpapanumbalik ng estado ng ViewModel sa Bundle o database.

Pag-optimize ng setContentView

Ang pagpapalawak ng XML layout (layout inflation) — isa sa pinakamahal na yugto ng Warm Start. Kung ang unang screen ay gumagamit ng kumplikadong CoordinatorLayout na may AppBar, CollapsingToolbar, NestedScrollView at tatlong RecyclerView, ang oras ng inflation ay maaaring umabot ng 300 ms. Mga solusyon: gamitin ang ConstraintLayout para sa patag na hierarchy, ilapat ang ViewStub para sa mga seksyong hindi nakikita sa simula (bottom sheet, dialog), paganahin ang asynchronous inflation para sa mabibigat na fragment sa pamamagitan ng AsyncLayoutInflater. Sa Jetpack Compose hindi kailangan ang inflation, ngunit ang pag-compile ng Compose tree sa Warm Start ay maaaring tumagal ng katulad na oras.

Pag-cache ng data

Sa Warm Start, ang data na na-load ng app sa nakaraang session ay maaaring nasa cache na: Room database, SharedPreferences, in-memory cache sa ViewModel. Kung ang unang screen mo ay nagpapakita ng listahan mula sa server, suriin ang cache sa pagsisimula at i-update ang data sa background. Gamitin ang estratehiya na cache-then-network: unang ipakita ang naka-cache na data (instant), pagkatapos ay i-update mula sa server (asynchronous). Ito ay nagbabawas ng perceived na oras ng Warm Start sa 100–200 ms.

// ViewModel na may caching para sa Warm Start
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // Cache muna, pagkatapos network
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: data nasa database na
            cache.emit(api.fetchItems()) // Update sa background
        }
    }
}

Pagpapanatili ng estado sa Warm Start

Ang tamang pag-save ng estado ay ang pangunahing salik na nag-iiba ng mabuting Warm Start mula sa masama. Inaasahan ng user na bumalik sa app at makita ang parehong bagay na kanyang iniwan — kasama ang posisyon ng scroll, teksto sa mga field, mga napiling tab.

onSaveInstanceState

Tinatawag ng system ang onSaveInstanceState sa pagkasira ng Activity, ngunit BAGO ang proseso ay maaaring patayin. Sa Bundle lamang ang mga simpleng data ang nai-save (String, Int, Parcelable, Serializable). Para sa kumplikadong data gamitin ang SavedStateHandle sa ViewModel — awtomatiko itong nagse-save at nagpapanumbalik ng mga field sa Warm Start. Hindi tulad ng onSaveInstanceState, ang SavedStateHandle ay gumagana kahit na ang proseso ay nakaligtas sa Warm Start (ViewModel ay hindi nawasak). Halimbawa: para sa teksto sa EditText gamitin ang SavedStateHandle.getLiveData(“text”) — ang teksto ay awtomatikong mai-save at mapapanumbalik.

ViewModel at Warm Start

Kung sa Warm Start ang proseso ay hindi pinatay, ang ViewModel ay nananatili sa memorya at ang onCleared ay hindi tinatawag. Nangangahulugan ito na ang lahat ng data na na-load sa nakaraang session ay agad na magagamit. Ngunit kung ang proseso ay pinatay (device sa deep sleep ng higit sa 30 minuto), ang ViewModel ay nawasak at muling nilikha gamit ang SavedStateHandle. Para sa tamang paggana ng ViewModel sa Warm Start gamitin ang SavedStateHandle na may mga field na kailangang maibalik sa anumang senaryo. Pagkakaiba: ang ViewModel na may @HiltViewModel ay awtomatikong sumusuporta sa SavedStateHandle.

Pagpapanatili ng scroll ng RecyclerView

Isa sa mga pinakakaraniwang problema ng Warm Start — pagkawala ng posisyon ng scroll. Ang user ay nag-scroll ng feed hanggang sa ika-50 elemento, ni-minimize ang app, bumalik — at nakikita ang simula ng listahan. Solusyon: i-save ang layoutManager.onSaveInstanceState (nagse-save ng posisyon at offset ng unang nakikitang elemento) at ibalik ito sa onRestoreInstanceState. Maaari ring i-save ang huling nakikitang posisyon sa SharedPreferences na may key na petsa/oras upang mabilis na maibalik ang posisyon sa Warm Start.

// Pagpapanatili ng scroll position ng RecyclerView
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putParcelable(
        "rv_state", binding.recyclerView
            .layoutManager?.onSaveInstanceState()
    )
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    savedInstanceState?.getParcelable<Parcelable>("rv_state")
        ?.let { binding.recyclerView.layoutManager?.onRestoreInstanceState(it) }
}

Mga halimbawa ng code para sa Warm Start

Dalawang praktikal na halimbawa ng optimisasyon ng Warm Start: paggamit ng SavedStateHandle sa ViewModel at asynchronous na pagpapanumbalik ng kumplikadong data pagkatapos ng pagsisimula.

ViewModel na may SavedStateHandle

Awtomatikong nagse-save ang SavedStateHandle ng mga field sa Bundle at pinapanumbalik ang mga ito sa Warm Start. Ang field ng profile ng user (String, JSON) ay maibabalik nang walang karagdagang mga kahilingan sa server. Kung ang proseso ay pinatay, ang SavedStateHandle ay maglo-load ng huling na-save na estado mula sa Bundle.

class ProfileViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val profile: StateFlow<Profile?>
        get() = savedStateHandle
            .getStateFlow("profile", null)

    fun loadProfile(id: String) {
        viewModelScope.launch {
            savedStateHandle["profile"] =
                api.getProfile(id)
        }
    }
}

// Warm Start: profile ay hindi null, UI walang loader
// Pagkatapos mag-load: nag-a-update ang profile sa SavedStateHandle

AsyncLayoutInflater para sa mabigat na screen

Kung ang unang screen ay naglalaman ng kumplikadong layout (mapa, gradient, maraming listahan), gamitin ang AsyncLayoutInflater para palawakin ang mabibigat na elemento sa background. Habang ang layout ay pinalalawak, magpakita ng placeholder na may shimmer effect. Ito ay lalong mahalaga para sa Warm Start, kung saan ang bawat millisecond ay mahalaga. Ang AsyncLayoutInflater ay gumagana sa background thread at naghahatid ng handa na View sa pamamagitan ng callback sa pangunahing thread.

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

        // Placeholder layout para sa instant rendering
        setContentView(R.layout.placeholder_shimmer)

        // Asynchronous na pag-load ng mabigat na layout
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}