Hot Start في التطبيقات المحمولة: ما هو، العوامل وكيفية التسريع

ما هو Hot Start في التطبيقات المحمولة

Hot Start هو سيناريو تشغيل حيث تكون عملية التطبيق موجودة بالفعل في ذاكرة الوصول العشوائي للجهاز. يقوم المستخدم بتصغير التطبيق، ثم يعود — ولا يقوم النظام بإنشاء عملية جديدة بل يستأنف العملية الموجودة. في هذا السيناريو، لا يلزم تحميل نظام التشغيل أو تهيئة فئة Application أو إنشاء عملية، مما يقلل بشكل كبير الوقت حتى ظهور واجهة المستخدم على الشاشة. وفقًا لوثائق Android (2025)، يستغرق Hot Start 200–500 مللي ثانية فقط، بينما يمكن أن يصل 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، وإجراء تهيئة المكتبات، وعندها فقط يعرض النشاط. تستغرق العملية بأكملها من 2 إلى 10 ثوانٍ اعتمادًا على تعقيد التطبيق وخصائص الجهاز.

Warm Start هو سيناريو وسيط. عملية التطبيق حية في الذاكرة، ولكن تم تدمير النشاط ويجب إعادة إنشائه. يحدث هذا، على سبيل المثال، عند تدوير الشاشة أو عند العودة من تطبيق آخر حيث تم إزالة النشاط بسبب ضغط الذاكرة ولكن العملية بقيت. يتضمن Warm Start استدعاء Activity.onCreate و Activity.onStart، لكنه لا يشمل Application.onCreate أو تهيئة ContentProvider. وقت Warm Start من 500 مللي ثانية إلى 2 ثانية. Hot Start هو الأسرع بين الثلاثة: النشاط موجود بالفعل في مكدس العودة، والعملية حية، والنظام ببساطة يستدعي Activity.onRestart و onStart و onResume. وقت Hot Start هو 200–500 مللي ثانية. الفرق عن Warm Start هو أن النشاط لا يتم إنشاؤه من جديد — بل يتم استعادته من المثيل الموجود.

دورة حياة Android أثناء Hot Start

في Android، يتم تشغيل Hot Start عندما يعود المستخدم إلى التطبيق عبر شاشة الأخيرة أو بالنقر على أيقونة التطبيق أثناء تصغيره. يتحقق النظام مما إذا كانت العملية حية، وإذا كان الأمر كذلك، يستدعي بالتسلسل Activity.onRestart و onStart و onResume. لا يتم استدعاء طريقة onCreate أثناء Hot Start لأن مثيل النشاط موجود بالفعل في الذاكرة. هذا فرق مهم عن Warm Start، حيث لا يزال onCreate يُستدعى بسبب تدمير النشاط. وفقًا لـ Google I/O 2019، فإن وقت Hot Start النموذجي في Android هو 200–400 مللي ثانية، وأي تباطؤ في هذه المرحلة يزيد بشكل مباشر من وقت الإطلاق الملموس.

غالبًا ما يغفل المطورون أن كود تهيئة واجهة المستخدم، والاشتراكات في LiveData، أو إعداد RecyclerView تتم ليس فقط في onCreate ولكن أيضًا في onStart أو onResume. أثناء Hot Start، يتم تنفيذ هذه الكتل البرمجية مرة أخرى، على الرغم من أن واجهة المستخدم قد تم إعدادها بالفعل. يوصى بفصل التهيئة لمرة واحدة (في onCreate مع التحقق من savedInstanceState) والمنطق القابل للاستئناف (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 — يتم استعادة النشاط
        }
    }

    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). لا يعيد نظام التشغيل إنشاء العملية إذا كان التطبيق في حالة معلقة أو خلفية. أثناء التشغيل الساخن، يتم استدعاء applicationDidBecomeActive في AppDelegate، ولكن لا يتم استدعاء applicationDidFinishLaunching — وهذا مشابه لـ Android حيث يتم تخطي Application.onCreate. يقوم iOS بتفريغ التطبيقات من الذاكرة بشكل أكثر عدوانية: إذا كان الجهاز يفتقر إلى ذاكرة الوصول العشوائي، فقد يقوم النظام بتفريغ تطبيق خلفي، وسيكون الإطلاق التالي هو Cold Start. وفقًا لوثائق Apple Developer، متوسط وقت Hot Start في iOS هو 300–600 مللي ثانية.

الفرق الرئيسي في iOS هو عدم وجود نظير مباشر لـ Warm Start بمعنى Android. في iOS، عند تصغير التطبيق، يتم استدعاء sceneDidEnterBackground، وعند العودة، يتم استدعاء sceneWillEnterForeground و sceneDidBecomeActive. إذا قام النظام بتفريغ المشهد لكنه أبقى العملية حية، سيكون الإطلاق التالي باردًا من منظور المشهد ولكنه ساخن من منظور العملية. يجب على المطور مراعاة ذلك عند وضع كود التهيئة: يجب أن تكون الاشتراكات في NotificationCenter وتحديثات واجهة المستخدم وإعادة تعيين الحالة في sceneDidBecomeActive، وليس فقط في viewDidLoad.

مثال لمعالجة Hot Start في iOS

يوضح كود Swift هذا كيفية تتبع عدد عمليات الإطلاق الساخنة وفصل المنطق. العداد foregroundCount يزداد في كل عودة من الخلفية.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — تهيئة كاملة
            setupSDKs()
        } else {
            // Hot Start — تحديث واجهة المستخدم فقط
            refreshUI()
        }
    }

    private func refreshUI() {
        // تحديث البيانات على الشاشة
    }
}

العوامل المؤثرة على سرعة Hot Start

تؤثر عدة فئات من العوامل على سرعة Hot Start. الأولى هي مقدار العمل في طرق دورة الحياة onStart و onResume. إذا وضع المطور تحميل بيانات الشبكة، أو تحليل JSON، أو تهيئة المحولات، أو حسابات ثقيلة في هذه الطرق، كل كتلة من هذا القبيل تضيف عشرات أو مئات المللي ثانية إلى وقت الإطلاق. وفقًا لـ Android Vitals، التطبيقات التي تزيد مدة Hot Start فيها عن 800 مللي ثانية تفقد ما يصل إلى 20% من المستخدمين عند العودة.

الفئة الثانية هي الأجزاء والعروض المستعادة من savedInstanceState. إذا كانت الأجزاء تحتوي على ViewPager2 ثقيل أو WebView أو تسلسلات هرمية معقدة ومتداخلة بعمق، فإن استعادتها تستهلك موارد وحدة المعالجة المركزية. وفقًا لـ Google I/O 2023، كل ViewGroup متداخلة تضيف في المتوسط 2–5 مللي ثانية إلى وقت العرض أثناء Hot Start. الفئة الثالثة هي SDKs الطرف الثالث: مكتبات التحليلات، والإبلاغ عن الأعطال، واختبار A/B، ومحملات DEX قد تقوم بالتهيئة في كل عودة من الخلفية. يوصى بالتحقق من أي SDKs تشغل كودًا تحديدًا في onStart/onResume وتأجيل المهام غير الحرجة إلى خيط خلفية.

طرق تحسين التشغيل الساخن

يتلخص تحسين Hot Start في تقليل العمل في طرق دورة حياة الاستئناف. الطريقة الأولى هي التهيئة البطيئة: أي كود غير ضروري للإطار الأول لواجهة المستخدم يجب تنفيذه بعد onResume مع تأخير عبر Handler.postDelayed أو Coroutine.launch(Dispatchers.IO). الطريقة الثانية هي تخزين حالة العرض مؤقتًا: عند تصغير التطبيق، احفظ البيانات في ذاكرة تخزين مؤقت بحيث لا تضطر أثناء Hot Start إلى إعادة تحميلها من قاعدة البيانات أو الشبكة. الطريقة الثالثة هي استخدام SavedStateHandle في Android و StateRestorationPolicy في iOS لتقليل كمية البيانات المستعادة.

التحميل البطيء بعد Hot Start

في هذا المثال، يؤجل Handler.postDelayed تهيئة التحليلات لمدة 500 مللي ثانية بعد عرض الإطار الأول. هذا لا يؤثر على وقت الإطلاق الملموس لأن المستخدم يرى الواجهة بالفعل.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // تهيئة بعد الإطار الأول
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

استخدام مكتبة App Startup

AndroidX App Startup يسمح لك بالتحكم في ترتيب تهيئة المكونات عند الإطلاق. تتم تهيئة جميع ContentProviders تلقائيًا أثناء 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، الأداة الرئيسية هي Android Vitals في Google Play Console — تجمع تلقائيًا مقاييس وقت الإطلاق لجميع السيناريوهات (Cold، Warm، Hot) مقسمة حسب طراز الجهاز وإصدار نظام التشغيل. بالإضافة إلى ذلك، يمكنك استخدام Macrobenchmark من AndroidX — مكتبة لاختبار أداء الإطلاق الآلي. في iOS، المعادل هو MetricKit، الذي يجمع بيانات عن وقت الإطلاق ومعدل الإطارات واستخدام الذاكرة.

للتحليل التفصيلي للتشغيل الساخن، فإن Firebase Performance Monitoring (يتتبع التتبعات المخصصة) و New Relic مع لوحات معلومات وقت الإطلاق مناسبة. على جانب المطور للقياس اليدوي، يُستخدم reportFullyDrawn في Android — API يبلغ النظام باللحظة الدقيقة التي يتم فيها عرض واجهة المستخدم وجاهزيتها للتفاعل. في iOS، المعادل هو endActivity في MetricKit. من خلال الجمع بين هذه الأدوات، يمكنك تحديد أي SDK أو كتلة كود تبطئ Hot Start على أجهزة محددة.

مثال Macrobenchmark لـ Hot Start

كود Kotlin باستخدام مكتبة Macrobenchmark لقياس Cold و Hot Start. يختبر الإطلاق النشاط ويقيس الوقت حتى الحالة الكاملة.

@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()
        }
    }
}