মোবাইল অ্যাপে 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 শুরু হয় যখন ব্যবহারকারী Recent স্ক্রিনের মাধ্যমে বা ছোট করার সময় অ্যাপ আইকনে ট্যাপ করে অ্যাপে ফিরে আসে। সিস্টেম পরীক্ষা করে প্রক্রিয়াটি জীবিত কিনা, এবং যদি হ্যাঁ, তবে ক্রমান্বয়ে 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)-এর মাধ্যমে ব্যাকগ্রাউন্ড থেকে অ্যাপে ফেরার সাথে মিলে যায়। অ্যাপটি যদি Suspended বা Background অবস্থায় থাকে তবে অপারেটিং সিস্টেম প্রক্রিয়াটি পুনরায় তৈরি করে না। হট লঞ্চের সময়, 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 কল করা হয়। যদি সিস্টেম দৃশ্যটি সরিয়ে দেয় কিন্তু প্রক্রিয়াটি জীবিত রাখে, পরবর্তী লঞ্চটি দৃশ্যের দৃষ্টিকোণ থেকে Cold হবে কিন্তু প্রক্রিয়ার দৃষ্টিকোণ থেকে Hot হবে। ইনিশিয়ালাইজেশন কোড রাখার সময় ডেভেলপারকে এটি বিবেচনা করতে হবে: 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 অনুসারে, 800 ms-এর বেশি Hot Start সময়কালের অ্যাপগুলি ফেরায় 20% পর্যন্ত ব্যবহারকারী হারায়।

দ্বিতীয় শ্রেণীটি হল savedInstanceState থেকে পুনরুদ্ধার করা ফ্র্যাগমেন্ট এবং ভিউ। যদি ফ্র্যাগমেন্টগুলিতে ভারী ViewPager2, WebView বা জটিল গভীরভাবে নেস্টেড হায়ারার্কি থাকে, তবে তাদের পুনরুদ্ধার CPU সম্পদ গ্রহণ করে। Google I/O 2023 অনুসারে, প্রতিটি নেস্টেড 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()
        }
    }
}