Hot Start در برنامه‌های موبایل: چیست، عوامل مؤثر و چگونه تسریع کنیم

Hot Start در برنامه‌های موبایل چیست

Hot Start — سناریوی راه‌اندازی برنامه‌ای است که فرآیند آن از قبل در حافظه RAM دستگاه وجود دارد. کاربر برنامه را کوچک می‌کند، سپس برمی‌گردد — و سیستم فرآیند جدیدی ایجاد نمی‌کند، بلکه فرآیند موجود را از سر می‌گیرد. در این سناریو بارگذاری سیستم عامل، مقداردهی اولیه کلاس Application و ایجاد فرآیند مورد نیاز نیست که زمان ظهور UI روی صفحه را به شدت کاهش می‌دهد. طبق مستندات 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 (راه‌اندازی سرد) زمانی رخ می‌دهد که برنامه برای اولین بار پس از نصب، راه‌اندازی مجدد دستگاه یا تخلیه از حافظه اجرا می‌شود. سیستم یک فرآیند جدید لینوکس ایجاد می‌کند، کلاس‌های Application را بارگذاری می‌کند، نمونه‌های ContentProvider را ایجاد می‌کند، مقداردهی اولیه کتابخانه‌ها را انجام می‌دهد و تنها پس از آن Activity را نمایش می‌دهد. کل فرآیند بسته به پیچیدگی برنامه و ویژگی‌های دستگاه 2–10 ثانیه طول می‌کشد.

Warm Start (راه‌اندازی گرم) — سناریوی میانی. فرآیند برنامه در حافظه زنده است، اما Activity از بین رفته و باید دوباره ایجاد شود. این اتفاق مثلاً هنگام چرخش صفحه یا بازگشت از برنامه دیگر می‌افتد، زمانی که Activity به دلیل کمبود حافظه تخلیه شده اما فرآیند باقی مانده است. Warm Start شامل فراخوانی Activity.onCreate و Activity.onStart است، اما شامل Application.onCreate و مقداردهی ContentProvider نمی‌شود. زمان Warm Start — از 500 میلی‌ثانیه تا 2 ثانیه. Hot Start — سریع‌ترین از سه: Activity از قبل در پشته بازگشت وجود دارد، فرآیند زنده است و سیستم به سادگی Activity.onRestart، onStart و onResume را فراخوانی می‌کند. زمان Hot Start — 200–500 میلی‌ثانیه. تفاوت با Warm Start در این است که Activity دوباره ایجاد نمی‌شود — از نمونه موجود بازیابی می‌شود.

چرخه حیات Android در Hot Start

در Android Hot Start زمانی آغاز می‌شود که کاربر از طریق صفحه Recents یا کلیک روی آیکون در حالت کوچک‌شده به برنامه برمی‌گردد. سیستم بررسی می‌کند که آیا فرآیند زنده است و اگر بله — به ترتیب Activity.onRestart، onStart و onResume را فراخوانی می‌کند. متد onCreate در Hot Start فراخوانی نمی‌شود، زیرا نمونه Activity از قبل در حافظه وجود دارد. این تفاوت مهمی با Warm Start است، جایی که onCreate به دلیل از بین رفتن Activity همچنان فراخوانی می‌شود. طبق Google I/O 2019، زمان معمول Hot Start در Android 200–400 میلی‌ثانیه است و هر کندی در این مرحله مستقیماً زمان درک شده راه‌اندازی را افزایش می‌دهد.

توسعه‌دهندگان اغلب متوجه نمی‌شوند که کد مقداردهی UI، اشتراک در LiveData یا تنظیم RecyclerView نه تنها در onCreate، بلکه در onStart یا onResume نیز اجرا می‌شود. در Hot Start این بلوک‌های کد دوباره اجرا می‌شوند، اگرچه UI از قبل تنظیم شده است. توصیه می‌شود مقداردهی یکبار مصرف (در 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 — 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) است. سیستم عامل فرآیند را دوباره ایجاد نمی‌کند اگر برنامه در حالت Suspended یا Background بوده است. در راه‌اندازی داغ applicationDidBecomeActive در AppDelegate فراخوانی می‌شود، اما applicationDidFinishLaunching فراخوانی نمی‌شود — این مشابه Android است، جایی که Application.onCreate نادیده گرفته می‌شود. iOS برنامه‌ها را به طور تهاجمی‌تری از حافظه تخلیه می‌کند: اگر دستگاه RAM کافی نداشته باشد، سیستم می‌تواند برنامه پس‌زمینه را تخلیه کند و راه‌اندازی بعدی Cold Start خواهد بود. طبق مستندات Apple Developer، میانگین زمان Hot Start در iOS 300–600 میلی‌ثانیه است.

تفاوت کلیدی iOS — عدم وجود معادل مستقیم Warm Start در مفهوم Android. در iOS هنگام کوچک کردن برنامه sceneDidEnterBackground فراخوانی می‌شود، و هنگام بازگشت — sceneWillEnterForeground و sceneDidBecomeActive. اگر سیستم صحنه را تخلیه کند اما فرآیند را زنده نگه دارد، راه‌اندازی بعدی از نظر صحنه Cold اما از نظر فرآیند Hot خواهد بود. توسعه‌دهنده باید این را هنگام قرار دادن کد مقداردهی در نظر بگیرد: اشتراک در NotificationCenter، به‌روزرسانی UI و بازنشانی حالت‌ها باید دقیقاً در 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 — فقط به‌روزرسانی UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // به‌روزرسانی داده روی صفحه
    }
}

عوامل مؤثر بر سرعت Hot Start

بر سرعت Hot Start چند دسته عامل تأثیر می‌گذارند. دسته اول — حجم کار در متدهای چرخه حیات onStart و onResume. اگر توسعه‌دهنده در این متدها بارگذاری داده از شبکه، تجزیه JSON، مقداردهی آداپتورها یا محاسبات سنگین قرار داده باشد، هر چنین بلوکی ده‌ها و صدها میلی‌ثانیه به زمان راه‌اندازی اضافه می‌کند. طبق داده‌های ابزار Android Vitals، برنامه‌هایی با مدت Hot Start بیش از 800 میلی‌ثانیه تا 20٪ از کاربران را در بازگشت مجدد از دست می‌دهند.

دسته دوم — فرگمنت‌ها و Viewهایی که از savedInstanceState بازیابی می‌شوند. اگر فرگمنت‌ها حاوی ViewPager2 سنگین، WebView یا سلسله‌مراتب پیچیده با تودرتویی عمیق باشند، بازیابی آنها منابع CPU را مصرف می‌کند. طبق Google I/O 2023، هر ViewGroup تو در تو به طور متوسط 2–5 میلی‌ثانیه به زمان رندر در Hot Start اضافه می‌کند. دسته سوم — SDKهای شخص ثالث: کتابخانه‌های تحلیل، crash-reporting، A/B-testing و بارگذارهای DEX ممکن است در هر بازگشت از پس‌زمینه مقداردهی را انجام دهند. توصیه می‌شود بررسی شود کدام SDKها دقیقاً در onStart/onResume کد اجرا می‌کنند و وظایف غیر بحرانی را به نخ پس‌زمینه موکول کنید.

روش‌های بهینه‌سازی راه‌اندازی داغ

بهینه‌سازی Hot Start به حداقل رساندن کار در متدهای چرخه حیات ازسرگیری خلاصه می‌شود. روش اول — مقداردهی تنبل: تمام کدی که برای فریم اول UI نیاز نیست باید پس از فراخوانی onResume با تأخیر از طریق Handler.postDelayed یا Coroutine.launch(Dispatchers.IO) اجرا شود. روش دوم — کش کردن حالت View: هنگام کوچک کردن برنامه داده‌ها را در کش حافظه ذخیره کنید تا در 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 امکان مدیریت ترتیب مقداردهی کامپوننت‌ها در زمان راه‌اندازی را فراهم می‌کند. همه 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 ابزار کلیدی Android Vitals در Google Play Console است — به طور خودکار معیارهای زمان راه‌اندازی را برای همه سناریوها (Cold, Warm, Hot) با تفکیک بر اساس مدل دستگاه و نسخه سیستم عامل جمع‌آوری می‌کند. علاوه بر این می‌توان از Macrobenchmark از AndroidX — کتابخانه‌ای برای تست خودکار عملکرد راه‌اندازی استفاده کرد. در iOS معادل آن MetricKit است که داده‌هایی درباره زمان راه‌اندازی، نرخ فریم و استفاده از حافظه جمع‌آوری می‌کند.

برای پروفایل دقیق راه‌اندازی داغ Firebase Performance Monitoring (ردیابی custom traces) و New Relic با داشبوردهای زمان راه‌اندازی مناسب هستند. در سمت توسعه‌دهنده برای اندازه‌گیری دستی از reportFullyDrawn در Android استفاده می‌شود — API که لحظه دقیق ترسیم UI و آمادگی برای تعامل را به سیستم اطلاع می‌دهد. در iOS معادل آن endActivity در MetricKit است. با ترکیب این ابزارها می‌توان تشخیص داد کدام SDK یا بلوک کد Hot Start را دقیقاً در دستگاه‌های خاص کند می‌کند.

نمونه Macrobenchmark برای Hot Start

کد در Kotlin با استفاده از کتابخانه Macrobenchmark برای اندازه‌گیری Cold و Hot Start. تست Activity را اجرا کرده و زمان تا رسیدن به حالت complete را اندازه‌گیری می‌کند.

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