موبائل ایپس میں Hot Start: یہ کیا ہے، عوامل اور کیسے تیز کریں

موبائل ایپس میں Hot Start کیا ہے

Hot Start ایک لانچ منظر نامہ ہے جہاں ایپ کا عمل پہلے سے ڈیوائس کی RAM میں موجود ہوتا ہے۔ صارف ایپ کو چھوٹا کرتا ہے، پھر واپس آتا ہے — اور نظام نیا عمل نہیں بناتا بلکہ موجودہ عمل کو دوبارہ شروع کرتا ہے۔ اس منظر نامے میں، OS لوڈنگ، Application کلاس کی ابتدا، یا عمل کی تخلیق کی ضرورت نہیں ہوتی، جو UI کے اسکرین پر ظاہر ہونے تک کے وقت کو ڈرامائی طور پر کم کر دیتا ہے۔ Android دستاویزات (2025) کے مطابق، Hot Start صرف 200-500 ms لیتا ہے، جبکہ Cold Start 5 سیکنڈ یا اس سے زیادہ ہو سکتا ہے۔ رفتار کا فرق خاص طور پر محدود میموری والے آلات پر نمایاں ہوتا ہے، جہاں نظام زیادہ کثرت سے پس منظر والی ایپس کو اتارتا ہے۔

Hot Start کی اہم خصوصیت کال کیے جانے والے لائف سائیکل طریقوں کا کم سے کم سیٹ ہے۔ Android میں، یہ Activity.onCreate اور Activity.onStart ہیں؛ iOS میں، یہ applicationDidBecomeActive ہے۔ Cold Start کے برعکس، جہاں Application.onCreate، ContentProvider.onCreate، Activity.onCreate اور بہت سی لائبریری ابتدائیات ترتیب وار کال کی جاتی ہیں، Hot Start ان تمام مراحل کو چھوڑ دیتا ہے۔ ڈویلپر کو سمجھنا چاہیے کہ گرم اسٹارٹ کے دوران خاص طور پر کون سا کوڈ عمل میں آتا ہے — اکثر بھاری SDK ابتدائیات، تجزیات اور DI کنٹینرز Cold اور Hot Start دونوں پر دہرائے جاتے ہیں، حالانکہ گرم اسٹارٹ کے دوران ان کی مزید ضرورت نہیں ہوتی۔

Cold Start، Warm Start اور Hot Start: موازنہ

تین ایپ لانچ منظرنامے ابتدائیہ کی گہرائی میں مختلف ہیں۔ Cold Start اس وقت ہوتا ہے جب ایپ تنصیب، ڈیوائس ریبوٹ، یا میموری سے ہٹائے جانے کے بعد پہلی بار لانچ کی جاتی ہے۔ نظام ایک نیا Linux عمل تخلیق کرتا ہے، Application کلاسز لوڈ کرتا ہے، ContentProvider مثالیں بناتا ہے، لائبریری ابتدائیہ انجام دیتا ہے اور اس کے بعد ہی Activity کو رینڈر کرتا ہے۔ پورا عمل ایپ کی پیچیدگی اور ڈیوائس کی خصوصیات کے لحاظ سے 2-10 سیکنڈ لیتا ہے۔

Warm Start ایک درمیانی منظر نامہ ہے۔ ایپ کا عمل میموری میں زندہ ہے، لیکن Activity تباہ ہو چکی ہے اور اسے دوبارہ بنانا ضروری ہے۔ یہ، مثال کے طور پر، اسکرین گھومنے پر یا کسی دوسری ایپ سے واپسی پر ہوتا ہے جہاں میموری کے دباؤ کی وجہ سے Activity ہٹا دی گئی تھی لیکن عمل باقی رہا۔ Warm Start میں Activity.onCreate اور Activity.onStart کال کرنا شامل ہے، لیکن اس میں Application.onCreate یا ContentProvider ابتدائیہ شامل نہیں ہے۔ Warm Start کا وقت 500 ms سے 2 سیکنڈ ہے۔ Hot Start تینوں میں سب سے تیز ہے: Activity پہلے سے واپسی کے ڈھیر میں موجود ہے، عمل زندہ ہے، اور نظام صرف Activity.onRestart، onStart اور onResume کال کرتا ہے۔ Hot Start کا وقت 200-500 ms ہے۔ Warm Start سے فرق یہ ہے کہ Activity نئے سرے سے نہیں بنائی جاتی — اسے موجودہ مثال سے بحال کیا جاتا ہے۔

Hot Start کے دوران Android لائف سائیکل

Android میں، Hot Start اس وقت متحرک ہوتا ہے جب صارف حالیہ اسکرین کے ذریعے یا چھوٹی ہوئی حالت میں ایپ آئیکن کو ٹیپ کرکے ایپ پر واپس آتا ہے۔ نظام چیک کرتا ہے کہ عمل زندہ ہے یا نہیں، اور اگر ہے تو ترتیب وار Activity.onRestart، onStart اور onResume کال کرتا ہے۔ Hot Start کے دوران onCreate طریقہ کال نہیں کیا جاتا کیونکہ Activity کی مثال پہلے سے میموری میں موجود ہے۔ یہ Warm Start سے ایک اہم فرق ہے، جہاں Activity کی تباہی کی وجہ سے onCreate اب بھی کال کیا جاتا ہے۔ Google I/O 2019 کے مطابق، Android میں عام Hot Start وقت 200-400 ms ہے، اور اس مرحلے پر کوئی بھی سستی براہ راست سمجھے جانے والے لانچ وقت کو بڑھاتی ہے۔

ڈویلپر اکثر نظر انداز کرتے ہیں کہ UI ابتدائیہ کوڈ، LiveData سبسکرپشنز، یا RecyclerView سیٹ اپ نہ صرف onCreate میں بلکہ onStart یا onResume میں بھی انجام پاتے ہیں۔ Hot Start کے دوران، یہ کوڈ بلاکس دوبارہ عمل میں آتے ہیں، حالانکہ UI پہلے سے ترتیب دیا جا چکا تھا۔ ایک بار کی ابتدائیہ (savedInstanceState چیک کے ساتھ onCreate میں) اور دوبارہ شروع ہونے والی منطق (onStart/onResume) کو الگ کرنے کی سفارش کی جاتی ہے۔ مثال کے طور پر، بھاری کارروائیاں — اڈیپٹر سیٹ اپ، فہرست لوڈنگ — کو ایک بلاک میں منتقل کیا جانا چاہیے جو onRestart کے دوران عمل میں نہ آئے، یا savedInstanceState چیک کریں۔

لانچ کی قسم کو ٹریک کرنے کی مثال

مندرجہ ذیل Kotlin کوڈ لانچ منظر نامے کا پتہ لگانے اور وقت ناپنے کا ایک آسان طریقہ دکھاتا ہے۔ launchTimeStamp متغیر لانچ شروع ہونے کے لمحے کو قید کرتا ہے، اور isColdStart سرد اور گرم اسٹارٹ کے لیے منطق کو الگ کرنے کی اجازت دیتا ہے۔

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

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

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // ایک بار کی ابتدائیہ
        } else {
            isColdStart = false
            // Hot Start — Activity بحال ہو رہی ہے
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

گرم لانچ کے دوران iOS لائف سائیکل

iOS میں، Hot Start sceneDidBecomeActive (UIKit) یا onAppear (SwiftUI) کے ذریعے پس منظر سے ایپ پر واپس آنے سے مطابقت رکھتا ہے۔ اگر ایپ معطل یا پس منظر کی حالت میں تھی تو آپریٹنگ سسٹم عمل کو دوبارہ تخلیق نہیں کرتا۔ گرم لانچ کے دوران، AppDelegate میں applicationDidBecomeActive کال کیا جاتا ہے، لیکن applicationDidFinishLaunching کال نہیں کیا جاتا — یہ Android کی طرح ہے جہاں Application.onCreate کو چھوڑ دیا جاتا ہے۔ iOS میموری سے ایپس کو زیادہ جارحانہ طریقے سے اتارتا ہے: اگر ڈیوائس میں RAM کی کمی ہو تو نظام کسی پس منظر والی ایپ کو اتار سکتا ہے، اور اگلا لانچ Cold Start ہوگا۔ Apple Developer دستاویزات کے مطابق، iOS میں اوسط Hot Start وقت 300-600 ms ہے۔

iOS میں ایک اہم فرق Android کے معنوں میں Warm Start کے براہ راست مشابہ کی کمی ہے۔ iOS میں، جب ایپ کو چھوٹا کیا جاتا ہے، sceneDidEnterBackground کال کیا جاتا ہے، اور واپسی پر، sceneWillEnterForeground اور sceneDidBecomeActive کال کیے جاتے ہیں۔ اگر نظام منظر کو اتارتا ہے لیکن عمل کو زندہ رکھتا ہے، تو اگلا لانچ منظر کے نقطہ نظر سے سرد ہوگا لیکن عمل کے نقطہ نظر سے گرم ہوگا۔ ڈویلپر کو ابتدائیہ کوڈ رکھتے وقت اس پر غور کرنا چاہیے: NotificationCenter سبسکرپشنز، UI اپ ڈیٹس اور حالت کی ری سیٹ sceneDidBecomeActive میں ہونی چاہیے، نہ کہ صرف viewDidLoad میں۔

iOS میں Hot Start کو سنبھالنے کی مثال

یہ Swift کوڈ دکھاتا ہے کہ گرم لانچ کی تعداد کو کیسے ٹریک کیا جائے اور منطق کو کیسے الگ کیا جائے۔ کاؤنٹر foregroundCount پس منظر سے ہر واپسی پر بڑھتا ہے۔

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — مکمل ابتدائیہ
            setupSDKs()
        } else {
            // Hot Start — صرف UI اپ ڈیٹ
            refreshUI()
        }
    }

    private func refreshUI() {
        // اسکرین پر ڈیٹا اپ ڈیٹ کرنا
    }
}

Hot Start کی رفتار کو متاثر کرنے والے عوامل

عوامل کے کئی زمرے Hot Start کی رفتار کو متاثر کرتے ہیں۔ پہلا ہے onStart اور onResume لائف سائیکل طریقوں میں کام کی مقدار۔ اگر ڈویلپر نے ان طریقوں میں نیٹ ورک ڈیٹا لوڈنگ، JSON تجزیہ، اڈیپٹر ابتدائیہ یا بھاری حسابات رکھے ہیں، تو ایسا ہر بلاک شروع ہونے کے وقت میں دسیوں یا سینکڑوں ملی سیکنڈ کا اضافہ کرتا ہے۔ Android Vitals کے مطابق، Hot Start مدت 800 ms سے زیادہ والی ایپس واپسی پر 20% تک صارفین کھو دیتی ہیں۔

دوسرا زمرہ savedInstanceState سے بحال کیے گئے فریگمنٹس اور ویوز ہیں۔ اگر فریگمنٹس میں بھاری ViewPager2، WebView یا پیچیدہ گہرے Nestڈ شدہ درجہ بندیاں ہوں تو ان کی بحالی CPU وسائل استعمال کرتی ہے۔ Google I/O 2023 کے مطابق، ہر Nestڈ ViewGroup Hot Start کے دوران رینڈرنگ وقت میں اوسطاً 2-5 ms کا اضافہ کرتا ہے۔ تیسرا زمرہ تیسرے فریق کے SDK ہیں: تجزیاتی لائبریریاں، کریش رپورٹنگ ٹولز، A/B ٹیسٹنگ فریم ورک اور DEX لوڈر پس منظر سے ہر واپسی پر ابتدائیہ انجام دے سکتے ہیں۔ سفارش کی جاتی ہے کہ چیک کریں کہ کون سے SDK خاص طور پر onStart/onResume میں کوڈ چلاتے ہیں اور غیر اہم کاموں کو پس منظر کے دھاگے پر ملتوی کریں۔

گرم لانچ کو بہتر بنانے کے طریقے

Hot Start کی بہتری کا خلاصہ دوبارہ شروع کرنے والے لائف سائیکل طریقوں میں کام کو کم سے کم کرنے پر ہے۔ پہلا طریقہ سست ابتدائیہ ہے: پہلے UI فریم کے لیے ضروری نہ ہونے والا کوئی بھی کوڈ onResume کے بعد Handler.postDelayed یا Coroutine.launch(Dispatchers.IO) کے ذریعے تاخیر سے چلنا چاہیے۔ دوسرا طریقہ ویو سٹیٹ کیشنگ ہے: جب ایپ چھوٹی کی جائے تو ڈیٹا کو ان میموری کیش میں محفوظ کریں تاکہ Hot Start کے دوران آپ کو ڈیٹا بیس یا نیٹ ورک سے دوبارہ لوڈ نہ کرنا پڑے۔ تیسرا طریقہ Android میں SavedStateHandle اور iOS میں StateRestorationPolicy استعمال کرنا ہے تاکہ بحال کیے جانے والے ڈیٹا کی مقدار کو کم سے کم کیا جا سکے۔

Hot Start کے بعد سست لوڈنگ

اس مثال میں، Handler.postDelayed پہلے فریم کے رینڈر ہونے کے 500 ms بعد تجزیاتی ابتدائیہ کو ملتوی کرتا ہے۔ یہ سمجھے جانے والے لانچ وقت کو متاثر نہیں کرتا کیونکہ صارف پہلے ہی انٹرفیس دیکھ رہا ہے۔

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // پہلے فریم کے بعد ابتدائیہ
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

App Startup لائبریری کا استعمال

AndroidX App Startup آپ کو لانچ پر اجزاء کی ابتدائیہ ترتیب کو کنٹرول کرنے کی اجازت دیتا ہے۔ تمام ContentProvider Cold Start کے دوران خود بخود شروع ہوتے ہیں، لیکن آپ Hot Start کے دوران ضروری نہ ہونے والے اجزاء کے لیے خودکار ابتدائیہ غیر فعال کر سکتے ہیں۔

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

لانچ ٹائم مانیٹرنگ کے اوزار

Hot Start وقت ناپنے کے لیے، پلیٹ فارم کے بلٹ ان ٹولز اور تیسرے فریق کے حل دونوں موجود ہیں۔ Android میں، اہم ٹول Google Play Console میں Android Vitals ہے — یہ ڈیوائس ماڈل اور OS ورژن کے مطابق تقسیم کردہ تمام منظرناموں (Cold، Warm، Hot) کے لیے خود بخود لانچ وقت کے میٹرکس جمع کرتا ہے۔ مزید برآں، آپ AndroidX سے Macrobenchmark استعمال کر سکتے ہیں — خودکار اسٹارٹ اپ کارکردگی جانچ کے لیے ایک لائبریری۔ iOS میں، مساوی MetricKit ہے، جو لانچ وقت، فریم ریٹ اور میموری استعمال کے بارے میں ڈیٹا جمع کرتا ہے۔

تفصیلی گرم اسٹارٹ پروفائلنگ کے لیے، Firebase Performance Monitoring (کسٹم ٹریس کو ٹریک کرتا ہے) اور لانچ ٹائم ڈیش بورڈز کے ساتھ New Relic موزوں ہیں۔ ڈویلپر کی طرف دستی پیمائش کے لیے، Android میں reportFullyDrawn استعمال کیا جاتا ہے — ایک API جو نظام کو عین لمحہ بتاتا ہے جب UI رینڈر ہو جاتا ہے اور تعامل کے لیے تیار ہوتا ہے۔ iOS میں، مساوی MetricKit میں endActivity ہے۔ ان اوزاروں کو ملا کر، آپ شناخت کر سکتے ہیں کہ مخصوص آلات پر کون سا SDK یا کوڈ بلاک Hot Start کو سست کرتا ہے۔

Hot Start کے لیے Macrobenchmark مثال

Macrobenchmark لائبریری استعمال کرتے ہوئے Kotlin کوڈ Cold اور Hot Start ناپنے کے لیے۔ ٹیسٹ Activity لانچ کرتا ہے اور مکمل حالت تک کا وقت ناپتا ہے۔

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}