Warm Start: جوہر، گرم آغاز اور Android میں اصلاح

Warm Start کیا ہے

Warm Start Cold Start اور Hot Start کے درمیان ایک حالت ہے: ایپ کا عمل میموری میں موجود ہوتا ہے (کبھی کبھی Linux بیک گراؤنڈ کیش میں)، لیکن Activity فعال نہیں ہوتی اور نئے سرے سے بنائی جائے گی۔ جب Android کی RAM کم ہو جاتی ہے، تو یہ عمل کو زندہ چھوڑ کر Activity کو اسٹیک سے ہٹا سکتا ہے۔ جب صارف ایپ پر واپس آتا ہے، تو Warm Start ہوتا ہے: ایک نیا Activity مثال بنایا جاتا ہے، لائف سائیکل کے طریقے onCreate → onStart → onResume عمل میں آتے ہیں، لیکن Application.onCreate اور کلاس لوڈنگ کو چھوڑ دیا جاتا ہے۔

Warm Start کی وجوہات

Android عمل کی ترجیح (اہمیت کی درجہ بندی) کی بنیاد پر Activity کو ہٹانے کا فیصلہ کرتا ہے۔ پس منظر میں ایک Activity (سطح PROCESS_STATE_IMPORTANT_FOREGROUND یا PROCESS_STATE_TOP_SLEEPING) ایپ کو کم سے کم کرنے کے 5–30 منٹ بعد تباہ ہو سکتی ہے، دستیاب RAM پر منحصر ہے۔ 3 GB RAM والے آلات پر، Activity 10 منٹ میں ہٹائی جا سکتی ہے؛ 8 GB RAM والے آلات پر، کئی گھنٹوں بعد۔ اہم: Warm Start کے دوران onSaveInstanceState کو Activity تباہ ہونے سے پہلے بلایا جاتا ہے، اور ڈیولپر UI حالت محفوظ کر سکتا ہے۔

صارف کا ادراک

صارف Warm اور Cold Start کے درمیان فرق نہیں دیکھتا — وہ صرف ایپ آئیکن پر ٹیپ کرتا ہے اور انتظار کرتا ہے۔ تاہم، Warm Start کے دوران، ایک سفید اسکرین ظاہر ہو سکتی ہے اگر ایپ نے حسب ضرورت اسٹارٹ اپ ونڈو تھیم سیٹ نہیں کی ہے۔ Google Warm Start کے دوران سفید/سیاہ اسکرین جھلملاہٹ سے بچنے کے لیے مینی فیسٹ میں اسٹارٹ اپ Activity کے لیے حسب ضرورت تھیم (Theme.AppCompat.Light یا Theme.Material3.DayNight) سیٹ کرنے کی سفارش کرتا ہے۔ Android 12+ پر، SplashScreen API بھی اس اثر کو چھپاتا ہے۔

Warm Start بمقابلہ Cold Start بمقابلہ Hot Start

تینوں لانچ اقسام کے درمیان فرق کو سمجھنا صحیح پروفائلنگ اور اصلاح کی حکمت عملی منتخب کرنے کے لیے ضروری ہے۔ ہر قسم کا اپنا دورانیہ، اپنی رکاوٹیں اور اپنے پیمائش کے اوزار ہوتے ہیں۔

عملی طور پر، Warm Start صارف کی عادات اور آلہ RAM کے لحاظ سے تمام ایپ لانچز کا 30% سے 60% تک ہوتا ہے۔ جو صارفین کئی ایپس کھلی رکھتے ہیں (ملٹی ٹاسکر)، وہ Warm Start کا زیادہ سامنا کرتے ہیں۔ سوشل نیٹ ورکس اور میسنجر کے لیے، Warm Start سب سے عام منظر ہے کیونکہ ایپ ہمیشہ پس منظر میں ہوتی ہے۔ بینکنگ ایپس کے لیے، اس کے برعکس، Cold Start غالب ہے (حفاظتی وجوہات کی بنا پر عمل کی جبری صفائی)۔

گرم آغاز کے مراحل

Warm Start تین مراحل پر مشتمل ہے، ہر ایک کو ماپا اور بہتر بنایا جا سکتا ہے۔ Cold Start کے برعکس، یہاں کوئی fork مرحلہ یا کلاس لوڈنگ نہیں ہے، لیکن ایک حالت کی بحالی کا مرحلہ ہے جو مہنگا ہو سکتا ہے۔

مرحلہ 1: اسٹارٹ اپ ونڈو (ونڈو پس منظر)

سسٹم چیک کرتا ہے کہ آیا ایپ کے پاس اسٹارٹ اپ ونڈو کے لیے تھیم ہے۔ اگر تھیم سیٹ نہیں ہے، تو ایک سفید (یا سیاہ، سسٹم پر منحصر) اسکرین دکھائی دیتی ہے۔ اگر تھیم سیٹ ہے، تو تھیم کا پس منظر دکھایا جاتا ہے۔ یہ مرحلہ 10–30 ms لیتا ہے، لیکن یہ بصری طور پر قابل توجہ ہے اگر تھیم ایپ کے حقیقی UI سے مماثل نہ ہو۔ Theme.Material3.DayNight کو حسب ضرورت windowBackground کے ساتھ استعمال کریں جس کا رنگ پہلی اسکرین کے پس منظر سے مماثل ہو — یہ فوری لوڈنگ اثر پیدا کرتا ہے۔

مرحلہ 2: Activity کی تخلیق (بحالی)

سسٹم onCreate کو Bundle savedInstanceState پاس کر کے بلاتا ہے جو Activity تباہ ہونے سے پہلے onSaveInstanceState میں محفوظ کیا گیا تھا۔ اگر ایپ نے حالت (فیلڈ ٹیکسٹ، سکرول پوزیشن، ViewModel ڈیٹا) صحیح طریقے سے محفوظ کی ہے، تو بحالی جلدی ہوتی ہے۔ اگر نہیں، تو Activity شروع سے شروع ہوتی ہے اور صارف ڈیٹا لوڈ ہونے تک لوڈر دیکھتا ہے۔ کلیدی نکتہ: ViewModel اشیاء Warm Start سے صرف اس صورت میں بچتی ہیں جب عمل تباہ نہ ہوا ہو — Warm Start کے دوران، ViewModel میموری میں رہتا ہے۔

مرحلہ 3: پہلا فریم (TTFD)

onCreate کے بعد، onStart → onResume عمل میں آتے ہیں، اور سسٹم پہلی ڈرا کو متحرک کرتا ہے۔ Warm Start کے لیے TTFD (Time To First Draw) درمیانی درجے کے آلے پر 300 ms سے کم ہونا چاہیے۔ اگر پہلی اسکرین میں بھاری Views کے ساتھ پیچیدہ RecyclerView ہے یا نیٹ ورک سے تصاویر لوڈ کرتی ہے، تو TTFD حد سے تجاوز کر سکتا ہے۔ پہلے فریم کے بعد ہموار مواد لوڈنگ کے لیے Placeholder اور Shimmer استعمال کریں۔

Warm Start کی پیمائش کیسے کریں

Warm Start کی پیمائش Cold Start سے زیادہ پیچیدہ ہے کیونکہ آپ کو اس حالت کی نقل کرنی ہوتی ہے جہاں عمل زندہ ہے لیکن Activity تباہ ہے۔ -S پرچم کے ساتھ معیاری ADB کمانڈ کام نہیں کرتی — یہ عمل کو مار دیتی ہے۔ Warm Start کے لیے مختلف طریقے استعمال کریں۔

-S کے بغیر ADB shell am start

پہلے، adb shell monkey کے ذریعے ایپ لانچ کریں یا آئیکن پر ٹیپ کریں، پھر اسے کم سے کم کریں (adb shell input keyevent 3 keyevent HOME)۔ 5–10 سیکنڈ انتظار کریں تاکہ سسٹم Activity کو ہٹا سکے، پھر adb shell am start -W (-S کے بغیر) چلائیں۔ کمانڈ Cold Start سے کم اسٹارٹ اپ وقت لوٹائے گی۔ تولیدی صلاحیت کے لیے، ایک اسکرپٹ استعمال کریں: لانچ → انتظار → ہوم → انتظار → لانچ۔

# ADB کے ذریعے Warm Start سمولیشن
$ adb shell am start -W \
    com.example.app/.MainActivity

# آؤٹ پٹ (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Warm Start کے لیے Macrobenchmark

androidx.benchmark.macro لائبریری Warm Start پیمائش کی حمایت کرتی ہے۔ ٹیسٹ میں، startupMode = StartupMode.WARM سیٹ کریں — لائبریری ایپ لانچ کرے گی، اسے کم سے کم کرے گی، انتظار کرے گی (قابل ترتیب تاخیر)، اور پھر دوبارہ لانچ کی پیمائش کرے گی۔ Macrobenchmark 10–20 تکرار کرتی ہے اور فیصد کا حساب لگاتی ہے۔ CI/CD میں، آپ ایک حد مقرر کر سکتے ہیں: اگر P50 Warm Start 600 ms سے تجاوز کر جائے تو ٹیسٹ ناکام ہو جاتا ہے۔ یہ ہر کمٹ کے ساتھ رجعت کو ٹریک کرنے کی اجازت دیتا ہے۔

Firebase Performance Monitoring

Firebase خود بخود آخری ایپ بند ہونے کے وقت کی بنیاد پر Cold اور Warm Start میں فرق کرتا ہے۔ اگر ایپ پچھلے 30 منٹ کے اندر کھولی گئی تھی، تو Firebase لانچ کو Warm کے طور پر درجہ بندی کرتا ہے۔ Firebase کنسول میں، آپ ہر اسٹارٹ اپ قسم کے لیے الگ چارٹ دیکھیں گے، جو آپ کو اصلاح کی تاثیر کا جائزہ لینے کی اجازت دیتا ہے۔ مثال کے طور پر، ViewModel میں حالت کا تحفظ لاگو کرنے کے بعد، آپ Warm Start وقت میں 30% کمی دیکھ سکتے ہیں۔

Warm Start کو کیسے بہتر بنائیں

Warm Start کی اصلاح دو شعبوں پر مرکوز ہے: Activity.onCreate کو تیز کرنا اور حالت کی صحیح بحالی۔ چونکہ Application.onCreate اور کلاس لوڈنگ پہلے ہی مکمل ہو چکی ہے، اہم رکاوٹ پہلی اسکرین کا UI کوڈ ہے۔

غیر ہم وقت حالت کی بحالی

اگر محفوظ کردہ حالت (savedInstanceState) میں ڈیٹا ہے جسے ڈی سیریلائزیشن کی ضرورت ہے (Bitmap, String, JSON)، تو اسے پس منظر کے تھریڈ پر کریں۔ onCreate میں Bundle سے براہ راست پڑھنے کے بجائے، ایک coroutine شروع کریں اور shimmer اسکرین دکھائیں۔ عملی طور پر، درمیانی درجے کے آلے پر Bundle ڈی سیریلائزیشن 20–100 ms لیتی ہے — یہ تھوڑا لگتا ہے، لیکن Warm Start کے لیے، یہ کل وقت کا 10–50% ہے۔ Jetpack کا Saved State Module استعمال کریں، جو خود بخود ViewModel حالت کو Bundle یا ڈیٹا بیس میں محفوظ اور بحال کرتا ہے۔

setContentView کی اصلاح

XML لے آؤٹ انفلیشن Warm Start کے مہنگے ترین مراحل میں سے ایک ہے۔ اگر پہلی اسکرین AppBar، CollapsingToolbar، NestedScrollView کے علاوہ تین RecyclerViews کے ساتھ پیچیدہ CoordinatorLayout استعمال کرتی ہے، تو انفلیشن کا وقت 300 ms تک پہنچ سکتا ہے۔ حل: فلیٹ درجہ بندی کے لیے ConstraintLayout استعمال کریں، اسٹارٹ اپ پر نظر نہ آنے والے حصوں (bottom sheet, dialog) کے لیے ViewStub لگائیں، AsyncLayoutInflater کے ذریعے بھاری fragments کے لیے غیر ہم وقت انفلیشن فعال کریں۔ Jetpack Compose میں، انفلیشن کی ضرورت نہیں، لیکن Warm Start کے دوران Compose درخت کی تالیف اسی طرح کا وقت لے سکتی ہے۔

ڈیٹا کیشنگ

Warm Start کے دوران، ایپ نے پچھلے سیشن میں جو ڈیٹا لوڈ کیا تھا وہ پہلے سے کیش میں ہو سکتا ہے: Room ڈیٹا بیس، SharedPreferences، ViewModel میں ان میموری کیش۔ اگر آپ کی پہلی اسکرین سرور سے فہرست دکھاتی ہے، تو اسٹارٹ اپ پر کیش چیک کریں اور پس منظر میں ڈیٹا اپ ڈیٹ کریں۔ cache-then-network حکمت عملی استعمال کریں: پہلے کیش کردہ ڈیٹا دکھائیں (فوری)، پھر سرور سے اپ ڈیٹ کریں (غیر ہم وقت)۔ یہ محسوس شدہ Warm Start وقت کو 100–200 ms تک کم کر دیتا ہے۔

// Warm Start کے لیے کیشنگ کے ساتھ ViewModel
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // پہلے کیش، پھر نیٹ ورک
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: ڈیٹا پہلے سے DB میں
            cache.emit(api.fetchItems()) // پس منظر میں اپ ڈیٹ
        }
    }
}

Warm Start کے دوران حالت کا تحفظ

مناسب حالت کا تحفظ اہم عنصر ہے جو اچھے Warm Start کو برے سے ممتاز کرتا ہے۔ صارف ایپ پر واپس آنے اور بالکل وہی دیکھنے کی توقع رکھتا ہے جو انہوں نے چھوڑا تھا — بشمول سکرول پوزیشن، فیلڈز میں ٹیکسٹ اور منتخب ٹیبز۔

onSaveInstanceState

سسٹم onSaveInstanceState کو اس وقت بلاتا ہے جب Activity تباہ ہو رہی ہوتی ہے، لیکن عمل کے مارے جانے سے پہلے۔ Bundle میں صرف سادہ ڈیٹا کی اقسام (String, Int, Parcelable, Serializable) محفوظ کی جاتی ہیں۔ پیچیدہ ڈیٹا کے لیے، ViewModel میں SavedStateHandle استعمال کریں — یہ Warm Start کے دوران خود بخود فیلڈز کو محفوظ اور بحال کرتا ہے۔ onSaveInstanceState کے برعکس، SavedStateHandle اس وقت بھی کام کرتا ہے جب عمل Warm Start سے بچ جاتا ہے (ViewModel تباہ نہیں ہوتا)۔ مثال: EditText میں ٹیکسٹ کے لیے، SavedStateHandle.getLiveData(“text”) استعمال کریں — ٹیکسٹ خود بخود محفوظ اور بحال ہو جائے گا۔

ViewModel اور Warm Start

اگر Warm Start کے دوران عمل نہیں مارا گیا، تو ViewModel میموری میں رہتا ہے اور onCleared نہیں بلایا جاتا۔ اس کا مطلب ہے کہ پچھلے سیشن میں لوڈ کیا گیا تمام ڈیٹا فوری طور پر دستیاب ہے۔ تاہم، اگر عمل مارا گیا (آلہ 30 منٹ سے زیادہ گہری نیند میں)، تو ViewModel تباہ ہو جاتا ہے اور SavedStateHandle کے ساتھ نیا بنایا جاتا ہے۔ Warm Start کے دوران درست ViewModel رویے کے لیے، ان فیلڈز کے ساتھ SavedStateHandle استعمال کریں جنہیں کسی بھی منظر نامے میں بحال کرنے کی ضرورت ہے۔ فرق: @HiltViewModel والا ViewModel خود بخود SavedStateHandle کو سپورٹ کرتا ہے۔

RecyclerView سکرول پوزیشن محفوظ کرنا

Warm Start کے سب سے عام مسائل میں سے ایک — سکرول پوزیشن کھونا۔ صارف 50ویں آئٹم تک سکرول کرتا ہے، ایپ کم سے کم کرتا ہے، واپس آتا ہے — اور فہرست کا شروع دیکھتا ہے۔ حل: layoutManager.onSaveInstanceState محفوظ کریں (پہلے نظر آنے والے آئٹم کی پوزیشن اور آفسیٹ محفوظ کرتا ہے) اور اسے onRestoreInstanceState میں بحال کریں۔ آپ آخری نظر آنے والی پوزیشن کو تاریخ/وقت کلید کے ساتھ SharedPreferences میں بھی محفوظ کر سکتے ہیں تاکہ Warm Start کے دوران جلدی پوزیشن بحال کی جا سکے۔

// 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) }
}

Warm Start کے لیے کوڈ کی مثالیں

Warm Start اصلاح کی دو عملی مثالیں: ViewModel میں SavedStateHandle کا استعمال اور اسٹارٹ اپ کے بعد پیچیدہ ڈیٹا کی غیر ہم وقت بحالی۔

SavedStateHandle کے ساتھ ViewModel

SavedStateHandle خود بخود فیلڈز کو Bundle میں محفوظ کرتا ہے اور Warm Start کے دوران انہیں بحال کرتا ہے۔ صارف پروفائل فیلڈ (String, JSON) غیر ضروری سرور کی درخواستوں کے بغیر بحال ہو جائے گی۔ اگر عمل مارا گیا، تو SavedStateHandle 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 null نہیں، UI بغیر لوڈر کے
// لوڈ کرنے کے بعد: profile SavedStateHandle میں اپ ڈیٹ ہوتا ہے

بھاری اسکرینوں کے لیے AsyncLayoutInflater

اگر پہلی اسکرین میں پیچیدہ لے آؤٹ ہے (نقشہ، گریڈیئنٹ، متعدد فہرستیں)، تو پس منظر میں بھاری عناصر کو انفلیٹ کرنے کے لیے AsyncLayoutInflater استعمال کریں۔ جب لے آؤٹ انفلیٹ ہو رہا ہو، تو shimmer اثر کے ساتھ placeholder دکھائیں۔ یہ Warm Start کے لیے خاص طور پر اہم ہے، جہاں ہر ملی سیکنڈ اہمیت رکھتا ہے۔ AsyncLayoutInflater پس منظر کے تھریڈ پر چلتا ہے اور تیار View کو مرکزی تھریڈ پر کال بیک میں بھیجتا ہے۔

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

        // فوری رینڈرنگ کے لیے Placeholder لے آؤٹ
        setContentView(R.layout.placeholder_shimmer)

        // بھاری لے آؤٹ کی غیر ہم وقت لوڈنگ
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}