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 স্টার্টআপ Activity-র জন্য ম্যানিফেস্টে কাস্টম থিম (Theme.AppCompat.Light বা Theme.Material3.DayNight) সেট করার পরামর্শ দেয় যাতে Warm Start চলাকালীন সাদা/কালো স্ক্রিনের ঝিকিমিকি এড়ানো যায়। 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 এক্সিকিউট হয়, এবং সিস্টেম প্রথম ড্র শুরু করে। TTFD (Time To First Draw) Warm Start-এর জন্য মিড-রেঞ্জ ডিভাইসে 300 ms-এর কম হওয়া উচিত। যদি প্রথম স্ক্রিনে ভারী Views সহ জটিল RecyclerView থাকে বা নেটওয়ার্ক থেকে ছবি লোড করে, তাহলে TTFD সীমা অতিক্রম করতে পারে। প্রথম ফ্রেমের পরে মসৃণ কন্টেন্ট লোডিংয়ের জন্য Placeholder এবং Shimmer ব্যবহার করুন।

কীভাবে Warm Start মাপবেন

Warm Start মাপা Cold Start-এর চেয়ে বেশি জটিল কারণ আপনাকে এমন অবস্থা অনুকরণ করতে হবে যেখানে প্রক্রিয়াটি জীবিত কিন্তু Activity ধ্বংস। -S ফ্ল্যাগ সহ স্ট্যান্ডার্ড ADB কমান্ড কাজ করে না — এটি প্রক্রিয়াটিকে মেরে ফেলে। Warm Start-এর জন্য ভিন্ন পদ্ধতি ব্যবহার করুন।

ADB shell am start -S ছাড়া

প্রথমে, 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 ব্যবহার করুন, যা স্বয়ংক্রিয়ভাবে Bundle বা ডেটাবেসে ViewModel অবস্থা সংরক্ষণ এবং পুনরুদ্ধার করে।

setContentView অপ্টিমাইজেশন

XML লেআউট ইনফ্লেশন Warm Start-এর সবচেয়ে ব্যয়বহুল ধাপগুলির মধ্যে একটি। যদি প্রথম স্ক্রিনে AppBar, CollapsingToolbar, NestedScrollView প্লাস তিনটি RecyclerView সহ জটিল CoordinatorLayout ব্যবহার করে, তাহলে ইনফ্লেশন সময় 300 ms পর্যন্ত পৌঁছাতে পারে। সমাধান: সমতল শ্রেণিবিন্যাসের জন্য ConstraintLayout ব্যবহার করুন, স্টার্টআপে অদৃশ্য বিভাগগুলির জন্য ViewStub প্রয়োগ করুন (বটম শীট, ডায়ালগ), AsyncLayoutInflater-এর মাধ্যমে ভারী ফ্র্যাগমেন্টের জন্য অ্যাসিঙ্ক্রোনাস ইনফ্লেশন সক্ষম করুন। 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 ব্যবহার এবং স্টার্টআপের পরে জটিল ডেটার অ্যাসিঙ্ক্রোনাস পুনরুদ্ধার।

ViewModel SavedStateHandle সহ

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 ব্যবহার করুন। লেআউট ইনফ্লেট হওয়ার সময়, শিমার প্রভাব সহ একটি 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)
        }
    }
}