Cold Start — কোল্ড লঞ্চ এবং Android-এ অপ্টিমাইজেশন

Cold Start কী

Cold Start (কোল্ড লঞ্চ) একটি পরিস্থিতি যেখানে একটি Android অ্যাপ্লিকেশন সবচেয়ে প্রাথমিক অবস্থা থেকে লঞ্চ হয়: অপারেটিং সিস্টেম একটি নতুন প্রক্রিয়া তৈরি করে (Zygote থেকে fork), মেমোরি বরাদ্দ করে, DEX কোড ART-তে লোড করে, ক্লাস ইনিশিয়ালাইজ করে এবং একটি Application ইনস্ট্যান্স তৈরি করে, তারপর প্রথম Activity। অ্যাপ লঞ্চের আগে, ডিভাইস মেমোরিতে এটি সম্পর্কে কোনো ডেটা থাকে না, ক্যাশ করা ক্লাস ইমেজ ছাড়া যদি Background Dexopt ব্যবহার করা হয়।

কখন Cold Start হয়

কোল্ড লঞ্চ তিনটি ক্ষেত্রে ঘটে: অ্যাপ ইনস্টলেশনের পরে প্রথম লঞ্চে, ডিভাইস রিবুটের পরে লঞ্চে, এবং মেমোরির অভাবে সিস্টেম প্রক্রিয়াটি সরিয়ে দেওয়ার পরে লঞ্চে। ২–৪ GB RAM বিশিষ্ট ডিভাইসে, সিস্টেম ব্যাকগ্রাউন্ড প্রক্রিয়াগুলিকে বেশ আক্রমণাত্মকভাবে সরিয়ে দেয়, তাই Cold Start প্রতিবার হতে পারে যখন ব্যবহারকারী কয়েক ঘন্টা নিষ্ক্রিয়তার পরে অ্যাপে ফিরে আসে। Android ১২+-এ, সিস্টেম একটি হিমায়িত প্রক্রিয়া (freeze / cached) রাখতে পারে, কিন্তু সক্রিয় মেমোরি সাশ্রয়ের (OOM-killer) সাথে, প্রক্রিয়াটি শেষ হয়ে যাবে।

কেন Cold Start একটি গুরুত্বপূর্ণ মেট্রিক

Google (Find My Device রিপোর্ট, ২০২৩) অনুযায়ী, ৬৫% ব্যবহারকারী অ্যাপ বন্ধ করে দেয় যদি এটি ৩ সেকেন্ডের মধ্যে না খোলে। সামাজিক নেটওয়ার্ক এবং মেসেজিং অ্যাপের জন্য, যেখানে ব্যবহারকারীরা দিনে ডজন খানেক বার ফিরে আসে, Cold Start সরাসরি ধরে রাখাকে প্রভাবিত করে। Google Play Console-এ, Cold Start মেট্রিক Android Vitals বিভাগের অংশ এবং ANR এবং কর্মক্ষমতা সূচকগুলির মধ্যে একটি হিসাবে প্রদর্শিত হয়। একটি অ্যাপ যা “খারাপ” Cold Start থ্রেশহোল্ড (২৫% ডিভাইসে ৫ সেকেন্ডের বেশি) অতিক্রম করে, কনসোলে একটি সতর্কতা পায় এবং অনুসন্ধান ফলাফলে ডাউনগ্রেড হতে পারে।

Cold Start vs Warm Start vs Hot Start

Android তিন ধরনের অ্যাপ লঞ্চের মধ্যে পার্থক্য করে, প্রতিটির আলাদা সময়কাল, UX প্রভাব এবং অপ্টিমাইজেশন পদ্ধতি রয়েছে। পার্থক্য বোঝা সঠিক প্রোফাইলিং কৌশল বেছে নেওয়ার জন্য অপরিহার্য।

Warm Start ঘটে যখন অ্যাপ প্রক্রিয়া ইতিমধ্যে ব্যাকগ্রাউন্ডে বিদ্যমান, কিন্তু Activity ধ্বংস হয়ে গেছে (যেমন, ব্যবহারকারী দীর্ঘ বিরতির পরে ফিরে এসেছে এবং সিস্টেম Activity মেমোরি মুক্ত করেছে)। Hot Start — যখন ব্যবহারকারী অ্যাপটি ছোট করে এবং অবিলম্বে আবার খোলে: Activity থমকে আছে এবং পুনরুদ্ধার ন্যূনতম সময় নেয়। ব্যবহারকারীর জন্য, Cold Start সবচেয়ে লক্ষণীয় লঞ্চ ধরন, এবং এর অপ্টিমাইজেশন UX-এ সবচেয়ে বড় উন্নতি দেয়।

প্রকারের মধ্যে রূপান্তর

Cold Start Warm Start হতে পারে যখন অ্যাপটি অন্তত একবার লঞ্চ হয়েছে — ART সংকলিত ক্লাস ইমেজ (Boot Profile-এ Image) ক্যাশ করে এবং পরবর্তী DEX লোডিং দ্রুত হয়। তাই, প্রথম Cold Start-এর পরে দ্বিতীয় লঞ্চ সাধারণত ২০–৪০% দ্রুত হয়। যদি অ্যাপ Baseline Profiles ব্যবহার করে, প্রোফাইলগুলি প্রথম লঞ্চে লোড হয় এবং দ্বিতীয় স্টার্ট আরও দ্রুত হতে পারে: Google Play, যা Baseline Profiles প্রকাশ করেছে, Android ১২+ ডিভাইসে Cold Start ৩০% দ্রুত করেছে।

কোল্ড লঞ্চের ধাপ

Cold Start কঠোরভাবে সংজ্ঞায়িত ধাপ নিয়ে গঠিত, যার প্রতিটি স্বাধীনভাবে মাপা এবং অপ্টিমাইজ করা যায়। ধাপগুলি জানা অ্যাপটি কোন পর্যায়ে সময় হারাচ্ছে তা নির্ধারণ করতে সাহায্য করে। Google চারটি প্রধান ধাপ চিহ্নিত করে: প্রক্রিয়া তৈরি, Application ইনিশিয়ালাইজেশন, Activity তৈরি, এবং প্রথম ফ্রেম।

ধাপ ১: প্রক্রিয়া তৈরি (fork)

Android সিস্টেম (ActivityManagerService) Zygote প্রক্রিয়া থেকে fork করে একটি নতুন প্রক্রিয়া তৈরি করে। Zygote সাধারণ Android ক্লাস সহ পূর্বে লোড করা একটি প্রক্রিয়া। Fork ৩০–৮০ ms সময় নেয় — এই সময় অ্যাপের নিয়ন্ত্রণের বাইরে। Fork-এর পরে, ActivityThread শুরু হয় — অ্যাপ্লিকেশনের প্রধান লুপ ইনস্ট্যান্স। এই ধাপে, ClassLoader-এর মাধ্যমে ক্লাস লোডিংও ঘটে এবং ART প্রথম বাইটকোড ব্যাখ্যা করা শুরু করে। যদি অ্যাপ অনেক স্ট্যাটিক ইনিশিয়ালাইজার ব্যবহার করে, এই ধাপ দীর্ঘায়িত হতে পারে।

ধাপ ২: Application.onCreate

ActivityThread শুরু হওয়ার সাথে সাথেই Application.onCreate কল করা হয়। এখানে ডেভেলপাররা প্রায়শই ভুল করে, সবকিছু একসাথে ইনিশিয়ালাইজ করে: Crashlytics, Firebase, নেটওয়ার্ক ক্লায়েন্ট, ডাটাবেস, Dagger উপাদান, DI কন্টেইনার। এই প্রতিটি ইনিশিয়ালাইজেশন মূল থ্রেডে ব্লক করা সময়। যদি Application.onCreate ৫০০ ms সময় নেয়, ব্যবহারকারী অর্ধ সেকেন্ডের জন্য সাদা (বা কালো) স্ক্রিন দেখে। মিড-রেঞ্জ ডিভাইসে এই ধাপের সর্বোত্তম সময়কাল ২০০ ms-এর কম।

ধাপ ৩: Activity.onCreate

Application ইনিশিয়ালাইজেশনের পরে, একটি Activity ইনস্ট্যান্স তৈরি হয় (MainActivity বা Launcher Activity)। Activity.onCreate কল করা হয়, যেখানে setContentView, ফ্র্যাগমেন্ট ইনিশিয়ালাইজেশন, ViewModel সেটআপ এবং LiveData/Flow সাবস্ক্রিপশন ঘটে। যদি onCreate মূল থ্রেডে ডেটা (SharedPreferences, SQLite, API) সিঙ্ক্রোনাসভাবে লোড করে, ধাপটি বেড়ে যায়। লক্ষ্য মিড-রেঞ্জ ডিভাইসে onCreate ২০০–৪০০ ms-এর মধ্যে রাখা।

ধাপ ৪: প্রথম ফ্রেম (TTFD)

OnCreate শেষ হওয়ার পরে, প্রথম রেন্ডারিং শুরু হয়: মাপ, লেআউট, ড্র। এই মুহূর্তটিকে TTFD (Time To First Draw) বলা হয়। যদি অ্যাপ স্প্ল্যাশ স্ক্রিন (Android ১২+-এ SplashScreen API-র মাধ্যমে বা থিমের মাধ্যমে) ব্যবহার করে, রেন্ডারিং দ্রুত হতে পারে, কিন্তু ব্যবহারকারী তবুও স্প্ল্যাশ অদৃশ্য হওয়া পর্যন্ত অপেক্ষা করবে। Cold Start-এর জন্য আদর্শ TTFD ১.৫ সেকেন্ডের কম।

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

Cold Start মাপার জন্য বিশেষ সরঞ্জাম প্রয়োজন, কারণ সাধারণ লগিং (Log.d) শুধুমাত্র Application তৈরি হওয়ার পরে কাজ শুরু করে, এবং fork টাইমিং এবং ক্লাস লোডিং অপ্রাপ্য থাকে। Google তিনটি পদ্ধতি সুপারিশ করে: ADB কমান্ড, Android Vitals এবং কাস্টম পারফ ম্যাক্রো।

ADB-র মাধ্যমে মাপা

সবচেয়ে সহজ এবং পুনরুৎপাদনযোগ্য পদ্ধতি হল adb shell am start -S -W কমান্ড। -S ফ্ল্যাগ লঞ্চের আগে অ্যাপকে জোর করে বন্ধ করে (Cold Start নিশ্চিত করে)। কমান্ড তিনটি মেট্রিক আউটপুট করে: ThisTime (Activity শুরু সময়), TotalTime (প্রক্রিয়া লঞ্চ সহ মোট সময়), এবং WaitTime (Activity Manager-এর সমস্ত বিলম্ব সহ সময়)। পরিষ্কার মাপের জন্য, ৫–৭ বার রিডিং নিন এবং মিডিয়ান ব্যবহার করুন — একক রিডিং শব্দের অধীন (CPU থ্রটলিং, ব্যাকগ্রাউন্ড লোড)।

# মাপার সাথে বাধ্যতামূলক Cold Start
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# কমান্ড আউটপুট:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

Google Play Console অ্যাপটি ইনস্টল করা সমস্ত ডিভাইস থেকে বেনামী মেট্রিক সংগ্রহ করে। Android Vitals → Launch time বিভাগে, ডিভাইস মডেল এবং Android সংস্করণ অনুযায়ী Cold Start-এর মিডিয়ান বিতরণ প্রদর্শিত হয়। এটি পরীক্ষার ডিভাইসে নয়, বরং ব্যবহারকারীদের ডিভাইসে বাস্তব মেট্রিক দেখার একমাত্র উপায়। যদি Cold Start Redmi 9A (২ GB RAM) এ ৫ সেকেন্ড এবং Pixel 8 এ ১.২ সেকেন্ড অতিক্রম করে, সমস্যাটি মেমোরি আকার এবং ক্লাস গণনা। Google ২৫তম পার্সেন্টাইলের উপর ভিত্তি করে ব্যবহারকারী-অনুভূত বিলম্বও দেখায়।

Macrobenchmark

Google Jetpack Macrobenchmark (androidx.benchmark লাইব্রেরি) ইন্সট্রুমেন্টেড অ্যাপ লঞ্চ টেস্ট লেখার অনুমতি দেয়। টেস্ট অ্যাপ ইনস্টল করে, এটি কোল্ড স্টেট থেকে লঞ্চ করে এবং প্রথম ফ্রেম পর্যন্ত সময় মাপে। Macrobenchmark স্বয়ংক্রিয়ভাবে ২০ বার রান করে, আউটলায়ার বাদ দেয় এবং স্থিতিশীল পার্সেন্টাইল দেখায়। CI/CD-র জন্য, আপনি বেসলাইন এবং বর্তমান লঞ্চ তুলনা করতে পারেন — যদি সময় বাড়ে, CI পাইপলাইন ব্যর্থ হতে পারে।

Cold Start কীভাবে অপ্টিমাইজ করবেন

Cold Start অপ্টিমাইজ করা একটি পদ্ধতিগত কাজ যা অ্যাপের একাধিক স্তরকে প্রভাবিত করে: কোড, রিসোর্স, বিল্ড কনফিগারেশন এবং ইনিশিয়ালাইজেশন আর্কিটেকচার। Google সবচেয়ে ব্যয়বহুল অংশ — Application.onCreate — থেকে শুরু করে ছোট বিবরণের দিকে যাওয়ার সুপারিশ করে।

লেজি ইনিশিয়ালাইজেশন (Lazy Init)

সমস্ত ইনিশিয়ালাইজেশন যা স্টার্টআপে প্রয়োজনীয় নয়, Application.onCreate থেকে প্রথম ব্যবহারের পয়েন্টে সরান। Firebase, Crashlytics, analytics SDK, push-notifications, DI উপাদান — প্রথম স্ক্রিন রেন্ডার হওয়ার পরে সবকিছু ইনিশিয়ালাইজ করা যায়। Kotlin-এ Lazy (by lazy) বা স্পষ্ট initialize(context) কল সহ ContentProvider ইনিশিয়ালাইজেশন ব্যবহার করুন। Google (Android Performance, ২০২৩) অনুযায়ী, লেজি ইনিশিয়ালাইজেশন ৫+ SDK ব্যবহার করা অ্যাপের জন্য Cold Start ৪০–৬০% কমায়।

Baseline Profiles

Baseline Profiles হল অ্যাপ স্টার্টআপে ব্যবহৃত গুরুত্বপূর্ণ ক্লাস এবং পদ্ধতির AOT সংকলন। Baseline Profiles ছাড়া, ART DEX কোড ব্যাখ্যা করে বা JIT-র মাধ্যমে সংকলন করে, যা সময় নেয়। প্রোফাইলের সাথে, ART অ্যাপ ইনস্টলেশনের সময় নির্দিষ্ট পদ্ধতিগুলিকে নেটিভ কোডে (AOT) সংকলন করে। Google দাবি করে যে Baseline Profiles Android ৯+-এ Cold Start ১৫–৪০% এবং Android ১২+ ART অপ্টিমাইজেশনের সাথে ৬০% পর্যন্ত দ্রুত করে। প্রোফাইল তৈরি করতে, androidx.benchmark:benchmark-baseline-profile-gradle-plugin প্লাগইন ব্যবহার করুন।

App Startup Library

androidx.startup লাইব্রেরি উপাদান ইনিশিয়ালাইজেশন অর্ডার করতে এবং এটি একটি ContentProvider-এ সম্পাদন করতে দেয়। বিভিন্ন লাইব্রেরির একাধিক ContentProvider-এর পরিবর্তে (প্রতিটি কোল্ড স্টার্টে ১–২ ms যোগ করে), App Startup তাদের একটি নির্ভরতা গ্রাফে একত্রিত করে এবং প্রয়োজন অনুযায়ী কঠোরভাবে ইনিশিয়ালাইজ করে। স্টার্টআপে, শুধুমাত্র @Initializer দিয়ে চিহ্নিত উপাদানগুলি যা প্রথম স্ক্রিনের জন্য প্রয়োজনীয়, সম্পাদিত হয়। বাকিগুলির জন্য, needEarlyInit = false ফ্ল্যাগ সেট করা হয় — তারা প্রথম রেন্ডারের পরে লঞ্চ হয়।

// App Startup Initializer — স্টার্টআপের পরে ইনিশিয়ালাইজেশন
class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    override fun dependencies() = listOf<Class<out Initializer<*>>>()
}

// AndroidManifest.xml-এ ঐচ্ছিক হিসাবে চিহ্নিত করুন
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

DEX আকার কমানো

DEX ফাইলের আকার সরাসরি ART লোডিং সময়কে প্রভাবিত করে। অস্বীকৃতি এবং মৃত কোড অপসারণের জন্য R8/ProGuard ব্যবহার করুন (MinifyEnabled = true)। ম্যানিফেস্টে android:extractNativeLibs="false" সক্ষম করুন যাতে APK ইনস্টলেশনের সময় .so ফাইলগুলি আনপ্যাক না করে। ১০+ রেফারেন্স ট্র্যাকিং সহ প্রকল্পগুলির জন্য, শুধুমাত্র প্রথম স্ক্রিনের জন্য startup-priority যোগ করুন। DEX-এ প্রতিটি অতিরিক্ত পদ্ধতি লোডিংয়ে ০.৫–২ ms যোগ করে, এবং ৫০k+ পদ্ধতি সহ অ্যাপের জন্য (multidex সহ primary dex) — ৩০০ ms পর্যন্ত।

Android Vitals-এ Cold Start

Google Play Console-এ Android Vitals (Launch time বিভাগ) অ্যাপটি ইনস্টল করা সমস্ত ডিভাইস থেকে ডেটা সংগ্রহ করে, শর্ত থাকে যে ব্যবহারকারী বেনামী ডায়াগনস্টিকসের জন্য সম্মতি দিয়েছেন। মেট্রিকগুলি Cold Start সময়ের উপর ভিত্তি করে তিনটি বিভাগে বিভক্ত: “ভাল”, “মাঝারি”, “খারাপ”।

Google-এর সীমা

Google “খারাপ” Cold Start কে যেকোনো ডিভাইসে ৫ সেকেন্ডের বেশি সময় হিসাবে সংজ্ঞায়িত করে। তবে, বাস্তবে, ফ্ল্যাগশিপ ডিভাইসের (Snapdragon ৮ Gen) জন্য, ভাল সময় ১.৫ সেকেন্ডের কম, মিড-রেঞ্জের জন্য — ২.৫ সেকেন্ডের কম, বাজেটের জন্য — ৪ সেকেন্ডের কম। Android Vitals প্রতিটি ডিভাইস মডেল-এর জন্য মিডিয়ান দেখায়, যা বুঝতে সাহায্য করে কোন ডিভাইসে অ্যাপ ধীর। যদি Cold Start Samsung A-series বা Xiaomi Redmi ডিভাইসে খারাপ হয়, কারণ প্রায়শই ধীর ফ্ল্যাশ মেমোরি এবং কম RAM (Baseline Profiles-এর মাধ্যমে ত্বরণ এই ধরনের ডিভাইসে সবচেয়ে বেশি প্রভাব দেয়)।

Google Play মেট্রিক কীভাবে ব্যবহার করে

কনসোলে প্রদর্শিত হওয়ার পাশাপাশি, Cold Start মেট্রিক Google Play Search-এ অ্যাপের গুণমান রেটিংকে প্রভাবিত করে। “খারাপ” স্টার্টআপের উচ্চ শতাংশ সহ অ্যাপগুলি ইনস্টলেশন পৃষ্ঠায় “কর্মক্ষমতা সতর্কতা” লেবেল পায়, যা রূপান্তর হ্রাস করে। Google (Android Performance Playbook, ২০২৪) অনুযায়ী, Cold Start সমস্যা সমাধান করা অ্যাপগুলি ইনস্টলেশন রূপান্তর গড়ে ৫% বাড়িয়েছে এবং ধরে রাখা (D1) ৩–৭% উন্নত করেছে।

Firebase Performance-এর সাথে একীকরণ

আরও বিস্তারিত পর্যবেক্ষণের জন্য, Firebase Performance Monitoring ব্যবহার করুন। এটি সেশন স্তরে Cold Start ট্র্যাক করে, অ্যাপ সংস্করণ এবং Android সংস্করণ অনুযায়ী ভাগ করে। Android Vitals-এর বিপরীতে, Firebase ধাপ অনুযায়ী ব্যয় করা সময়ের ট্রেস ডায়াগ্রাম দেখায়। উদাহরণস্বরূপ, আপনি দেখতে পারেন যে সংস্করণ ৩.২.০-এ, Application.onCreate ৮০০ ms সময় নিয়েছে (একটি নতুন পুশ নোটিফিকেশন লাইব্রেরির কারণে), যখন সংস্করণ ৩.২.১-এ — ২০০ ms (ফিক্সের পরে)।

অপ্টিমাইজেশনের জন্য কোড উদাহরণ

নীচে দুটি ব্যবহারিক উদাহরণ দেওয়া হল যা সরাসরি Cold Start দ্রুত করে: স্টার্টআপের পরে SDK ইনিশিয়ালাইজেশন সরানো এবং SplashScreen API ব্যবহার করা।

Application.onCreate থেকে ইনিশিয়ালাইজেশন সরানো

একটি সাধারণ ভুল是所有 SDK Application.onCreate-এ ইনিশিয়ালাইজ করা। নীচে দেখানো হয়েছে কীভাবে অ-গুরুত্বপূর্ণ ইনিশিয়ালাইজেশন একটি করুটিনে সরানো যায় যা প্রথম ফ্রেম আঁকার পরে চালু হয়। গুরুত্বপূর্ণ: Firebase, Crashlytics এবং Crash Reporting SDK স্টার্টআপে ইনিশিয়ালাইজ করা আবশ্যক — এগুলি স্থগিত করা যায় না কারণ এগুলি অন্যান্য উপাদানের ইনিশিয়ালাইজেশনের সময় ক্র্যাশ ধরে। বাকিগুলির জন্য, প্রথম Activity-তে lifecycleScope ব্যবহার করুন।

// ❌ খারাপ — সমস্ত ইনিশিয়ালাইজেশন Application.onCreate-এ
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // গুরুত্বপূর্ণ
        Analytics.init(this) // পরে করা যাবে
        Database.init(this) // পরে করা যাবে
        ImageLoader.init(this) // পরে করা যাবে
    }
}

// ✅ ভাল — Firebase স্টার্টআপে, বাকি after inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// প্রথম ফ্রেমের পরে MainActivity-তে:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Android ১২+-এ, অফিসিয়াল SplashScreen API ব্যবহার করুন যা প্রক্রিয়া শুরু হওয়ার সাথে সাথেই একটি সিস্টেম স্প্ল্যাশ (গাঢ়/হালকা ব্যাকগ্রাউন্ডে অ্যাপ আইকন) দেখায়। এটি ব্যবহারকারীর কাছ থেকে ইনিশিয়ালাইজেশন সময় লুকিয়ে রাখে — তারা সাদা স্ক্রিনের পরিবর্তে স্প্ল্যাশ দেখে। পুরানো ডিভাইসের জন্য, theme-based splash (স্টাইলে Theme.SplashScreen) ব্যবহার করুন। গুরুত্বপূর্ণ: স্প্ল্যাশ ৩০০ ms-এর বেশি স্থায়ী হওয়া উচিত নয় — যদি ততক্ষণে অ্যাপ প্রস্তুত না হয়, একটি “স্থায়ী” কঙ্কাল (shimmer) আঁকুন এবং লোডিং অগ্রগতি দেখান।

// SplashScreen API — Android 12+
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val splashScreen = installSplashScreen()
        splashScreen.setKeepOnScreenCondition {
            isReady.value == false
        }
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

// থিম-ভিত্তিক স্প্ল্যাশ (Android 5-11)
// themes.xml-এ:
// <style name="Theme.App.Starting" parent="Theme.SplashScreen">
//   <item name="windowSplashScreenBackground">@color/white</item>
//   <item name="windowSplashScreenAnimatedIcon">@mipmap/ic_launcher</item>
// </style>