Cold Start — سرد آغاز اور Android میں اصلاح

Cold Start کیا ہے

Cold Start (سرد آغاز) ایک منظرنامہ ہے جس میں Android ایپلیکیشن سب سے ابتدائی حالت سے شروع کی جاتی ہے: آپریٹنگ سسٹم ایک نیا عمل بناتا ہے (Zygote سے fork)، میموری مختص کرتا ہے، DEX کوڈ کو ART میں لوڈ کرتا ہے، کلاسز کو ابتدائیہ بناتا ہے اور Application کی مثال بناتا ہے، پھر پہلی Activity۔ ایپ شروع ہونے سے پہلے، ڈیوائس میموری میں اس کے بارے میں کوئی ڈیٹا نہیں ہوتا، سوائے کیشڈ کلاس امیجز کے اگر Background Dexopt استعمال کیا جاتا ہے۔

Cold Start کب ہوتا ہے

سرد آغاز تین صورتوں میں ہوتا ہے: ایپ انسٹالیشن کے بعد پہلی بار شروع کرنے پر، ڈیوائس ریبوٹ کے بعد شروع کرنے پر، اور میموری کی کمی کی وجہ سے سسٹم کے عمل کو ہٹانے کے بعد شروع کرنے پر۔ 2–4 GB RAM والے آلات پر، سسٹم پس منظر کے عمل کو کافی جارحانہ طور پر ہٹاتا ہے، لہذا Cold Start ہر بار ہو سکتا ہے جب صارف کئی گھنٹوں کی غیرفعالیت کے بعد ایپ پر واپس آتا ہے۔ Android 12+ پر، سسٹم ایک منجمد عمل (freeze / cached) رکھ سکتا ہے، لیکن فعال میموری بچت (OOM-killer) کے ساتھ، عمل ختم کر دیا جائے گا۔

Cold Start ایک اہم پیمائش کیوں ہے

Google (Find My Device رپورٹ، 2023) کے مطابق، 65% صارفین ایپ بند کر دیتے ہیں اگر یہ 3 سیکنڈ میں نہ کھلے۔ سوشل نیٹ ورکس اور میسنجر کے لیے، جہاں صارف دن میں درجنوں بار واپس آتے ہیں، Cold Start براہ راست برقرار رکھنے کو متاثر کرتا ہے۔ Google Play Console میں، Cold Start پیمائش Android Vitals سیکشن کا حصہ ہے اور ANR اور کارکردگی کے اشارے میں سے ایک کے طور پر ظاہر ہوتی ہے۔ ایک ایپ جو “خراب” Cold Start حد (25% آلات پر 5 سیکنڈ سے زیادہ) سے تجاوز کرتی ہے، کنسول میں انتباہ حاصل کرتی ہے اور تلاش کے نتائج میں تنزلی کی جا سکتی ہے۔

Cold Start بمقابلہ Warm Start بمقابلہ 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 کے بعد دوسرا آغاز عام طور پر 20–40% تیز ہوتا ہے۔ اگر ایپ Baseline Profiles استعمال کرتی ہے، تو پروفائلز پہلے آغاز پر لوڈ ہوتے ہیں اور دوسرا آغاز اور بھی تیز ہو سکتا ہے: Google Play، جس نے Baseline Profiles شائع کیں، نے Android 12+ والے آلات پر Cold Start کو 30% تیز کیا۔

سرد آغاز کے مراحل

Cold Start سختی سے متعین مراحل پر مشتمل ہے، جن میں سے ہر ایک کو آزادانہ طور پر ناپا اور بہتر بنایا جا سکتا ہے۔ مراحل کو جاننے سے یہ تعین کرنے میں مدد ملتی ہے کہ ایپ کس مرحلے میں وقت کھو رہی ہے۔ Google چار اہم مراحل کی نشاندہی کرتا ہے: عمل کی تشکیل، Application ابتدائیہ، Activity تشکیل، اور پہلا فریم۔

مرحلہ 1: عمل کی تشکیل (fork)

Android نظام (ActivityManagerService) Zygote عمل سے fork کرکے ایک نیا عمل بناتا ہے۔ Zygote مشترکہ Android کلاسز کے ساتھ پہلے سے لوڈ کردہ عمل ہے۔ Fork میں 30–80 ms لگتے ہیں — یہ وقت ایپ کے کنٹرول سے باہر ہے۔ Fork کے بعد، ActivityThread شروع ہوتا ہے — ایپلیکیشن کے مرکزی لوپ کی مثال۔ اس مرحلے پر، ClassLoader کے ذریعے کلاس لوڈنگ بھی ہوتی ہے، اور ART پہلے بائٹ کوڈ کی تشریح شروع کرتا ہے۔ اگر ایپ بہت سے جامد ابتدائیہ استعمال کرتی ہے، تو یہ مرحلہ لمبا ہو سکتا ہے۔

مرحلہ 2: Application.onCreate

ActivityThread شروع ہونے کے فوراً بعد Application.onCreate کہا جاتا ہے۔ یہاں ڈیولپرز اکثر غلطی کرتے ہیں، سب کچھ ایک ساتھ شروع کر کے: Crashlytics، Firebase، نیٹ ورک کلائنٹس، ڈیٹا بیس، Dagger اجزاء، DI کنٹینرز۔ ان میں سے ہر ابتدائیہ مرکزی تھریڈ پر مسدود وقت ہے۔ اگر Application.onCreate میں 500 ms لگتے ہیں، تو صارف آدھے سیکنڈ کے لیے سفید (یا سیاہ) اسکرین دیکھتا ہے۔ درمیانی درجے کے آلے پر اس مرحلے کی بہترین مدت 200 ms سے کم ہے۔

مرحلہ 3: Activity.onCreate

Application ابتدائیہ کے بعد، Activity کی ایک مثال بنائی جاتی ہے (MainActivity یا Launcher Activity)۔ Activity.onCreate کہا جاتا ہے، جہاں setContentView، فریگمنٹ ابتدائیہ، ViewModel سیٹ اپ اور LiveData/Flow سبسکرپشن ہوتی ہے۔ اگر onCreate مرکزی تھریڈ پر ڈیٹا (SharedPreferences، SQLite، API) ہم وقت لوڈ کرتا ہے، تو مرحلہ بڑھ جاتا ہے۔ مقصد درمیانی درجے کے آلے پر onCreate کو 200–400 ms میں رکھنا ہے۔

مرحلہ 4: پہلا فریم (TTFD)

OnCreate مکمل ہونے کے بعد پہلی رینڈرنگ شروع ہوتی ہے: پیمائش، لے آؤٹ، ڈرا۔ اس لمحے کو TTFD (Time To First Draw) کہا جاتا ہے۔ اگر ایپ اسپلیش اسکرین (Android 12+ پر SplashScreen API یا تھیم کے ذریعے) استعمال کرتی ہے، تو رینڈرنگ تیز ہو سکتی ہے، لیکن صارف پھر بھی اسپلیش کے غائب ہونے تک انتظار کرے گا۔ Cold Start کے لیے مثالی TTFD 1.5 سیکنڈ سے کم ہے۔

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 کی تمام تاخیر سمیت وقت)۔ صاف پیمائش کے لیے، 5–7 ریڈنگز لیں اور میڈین استعمال کریں — انفرادی ریڈنگز شور (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 کی میڈین تقسیم ظاہر ہوتی ہے۔ یہ صارفین کے آلات پر حقیقی پیمائشیں دیکھنے کا واحد طریقہ ہے، نہ صرف ٹیسٹ آلات پر۔ اگر Redmi 9A (2 GB RAM) پر Cold Start 5 سیکنڈ اور Pixel 8 پر 1.2 سیکنڈ سے تجاوز کرتا ہے، تو مسئلہ میموری کے سائز اور کلاسز کی تعداد ہے۔ Google 25ویں فیصد کی بنیاد پر صارف کے ذریعے محسوس ہونے والی تاخیر بھی دکھاتا ہے۔

Macrobenchmark

Google Jetpack Macrobenchmark (androidx.benchmark لائبریری) آلہ دار ایپ شروع کرنے کے ٹیسٹ لکھنے کی اجازت دیتی ہے۔ ٹیسٹ ایپ انسٹال کرتا ہے، اسے سرد حالت سے شروع کرتا ہے اور پہلے فریم تک کا وقت ناپتا ہے۔ Macrobenchmark خود بخود 20 بار چلتا ہے، باہر کی قدروں کو ہٹاتا ہے اور مستحکم فیصد دکھاتا ہے۔ CI/CD کے لیے، آپ بیس لائن اور موجودہ شروع کا موازنہ کر سکتے ہیں — اگر وقت بڑھتا ہے، تو CI پائپ لائن ناکام ہو سکتی ہے۔

Cold Start کو کیسے بہتر بنائیں

Cold Start کو بہتر بنانا ایک منظم کام ہے جو ایپ کی متعدد سطحوں کو متاثر کرتا ہے: کوڈ، وسائل، تعمیراتی ترتیب اور ابتدائیہ فن تعمیر۔ Google سب سے مہنگے حصے — Application.onCreate — سے شروع کرنے اور چھوٹی تفصیلات کی طرف بڑھنے کی تجویز کرتا ہے۔

سست ابتدائیہ (Lazy Init)

تمام ابتدائیہ جو شروع میں ضروری نہیں، Application.onCreate سے پہلے استعمال کے مقام پر منتقل کریں۔ Firebase، Crashlytics، analytics SDK، push اطلاعات، DI اجزاء — سب کچھ پہلی اسکرین رینڈر ہونے کے بعد شروع کیا جا سکتا ہے۔ Kotlin میں Lazy (by lazy) استعمال کریں یا واضح initialize(context) کال کے ساتھ ContentProvider ابتدائیہ استعمال کریں۔ Google (Android Performance، 2023) کے مطابق، سست ابتدائیہ 5+ SDK استعمال کرنے والی ایپس کے لیے Cold Start کو 40–60% کم کرتا ہے۔

Baseline Profiles

Baseline Profiles ایپ شروع ہونے پر استعمال ہونے والی اہم کلاسز اور طریقوں کی AOT تیاری ہے۔ Baseline Profiles کے بغیر، ART DEX کوڈ کی تشریح کرتا ہے یا JIT کے ذریعے تیار کرتا ہے، جس میں وقت لگتا ہے۔ پروفائلز کے ساتھ، ART ایپ انسٹالیشن کے دوران متعین طریقوں کو مقامی کوڈ (AOT) میں تیار کرتا ہے۔ Google کا دعویٰ ہے کہ Baseline Profiles Android 9+ پر Cold Start کو 15–40% اور Android 12+ ART اصلاحات کے ساتھ 60% تک تیز کرتی ہیں۔ پروفائلز بنانے کے لیے، androidx.benchmark:benchmark-baseline-profile-gradle-plugin پلگ ان استعمال کریں۔

App Startup Library

androidx.startup لائبریری اجزاء کے ابتدائیہ کو ترتیب دینے اور اسے ایک ContentProvider میں انجام دینے کی اجازت دیتی ہے۔ مختلف لائبریریوں کے متعدد ContentProviders (ہر ایک سرد آغاز میں 1–2 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 فائلیں نکالے نہ۔ 10 سے زیادہ حوالہ جات والے منصوبوں کے لیے، صرف پہلی اسکرین کے لیے startup-priority شامل کریں۔ DEX میں ہر اضافی طریقہ لوڈنگ میں 0.5–2 ms کا اضافہ کرتا ہے، اور 50k+ طریقوں والی ایپس کے لیے (primary dex کے ساتھ multidex) — 300 ms تک۔

Android Vitals میں Cold Start

Google Play Console میں Android Vitals (Launch time سیکشن) ان تمام آلات سے ڈیٹا جمع کرتا ہے جہاں ایپ انسٹال ہے، بشرطیکہ صارف نے گمنام تشخیص کے لیے رضامندی دی ہو۔ پیمائشیں Cold Start وقت کی بنیاد پر تین زمروں میں تقسیم ہوتی ہیں: “اچھا”، “اعتدال پسند”، “خراب”۔

Google کی حدیں

Google “خراب” Cold Start کو کسی بھی آلے پر 5 سیکنڈ سے زیادہ وقت کے طور پر بیان کرتا ہے۔ تاہم، عملی طور پر، فلیگ شپ آلات (Snapdragon 8 Gen) کے لیے اچھا وقت 1.5 سیکنڈ سے کم، درمیانی درجے کے لیے — 2.5 سیکنڈ سے کم، بجٹ کے لیے — 4 سیکنڈ سے کم ہے۔ Android Vitals ہر ڈیوائس ماڈل کے لیے میڈین دکھاتا ہے، جس سے یہ سمجھنے میں مدد ملتی ہے کہ کن آلات پر ایپ سست ہے۔ اگر Samsung A-series یا Xiaomi Redmi آلات پر Cold Start خراب ہے، تو وجہ اکثر سست فلیش میموری اور کم RAM ہے (Baseline Profiles کے ذریعے تیزی ایسے آلات پر سب سے زیادہ اثر دیتی ہے)۔

Google Play پیمائش کو کیسے استعمال کرتا ہے

کنسول میں ظاہر ہونے کے علاوہ، Cold Start پیمائش Google Play Search میں ایپ کے معیار کی درجہ بندی کو متاثر کرتی ہے۔ “خراب” آغاز کے زیادہ فیصد والی ایپس انسٹالیشن پیج پر “کارکردگی کا انتباہ” لیبل حاصل کرتی ہیں، جو تبدیلی کو کم کرتا ہے۔ Google (Android Performance Playbook، 2024) کے مطابق، Cold Start مسائل حل کرنے والی ایپس نے انسٹالیشن کی تبدیلی میں اوسطاً 5% اضافہ کیا اور برقرار رکھنے (D1) میں 3–7% بہتری لائی۔

Firebase Performance کے ساتھ انضمام

مزید تفصیلی نگرانی کے لیے، Firebase Performance Monitoring استعمال کریں۔ یہ سیشن کی سطح پر Cold Start کو ٹریک کرتا ہے، ایپ ورژن اور Android ورژن کے مطابق تقسیم کرتا ہے۔ Android Vitals کے برعکس، Firebase مرحلے کے مطابق خرچ کیے گئے وقت کا ٹریس ڈایاگرام دکھاتا ہے۔ مثال کے طور پر، آپ دیکھ سکتے ہیں کہ ورژن 3.2.0 میں، Application.onCreate نے 800 ms لیے (ایک نئی پش نوٹیفکیشن لائبریری کی وجہ سے)، جبکہ ورژن 3.2.1 میں — 200 ms (درستگی کے بعد)۔

اصلاح کے لیے کوڈ کی مثالیں

ذیل میں دو عملی مثالیں ہیں جو براہ راست Cold Start کو تیز کرتی ہیں: شروع ہونے کے بعد SDK ابتدائیہ کو منتقل کرنا اور SplashScreen API استعمال کرنا۔

Application.onCreate سے ابتدائیہ منتقل کرنا

ایک عام غلطی تمام SDKs کو Application.onCreate میں شروع کرنا ہے۔ ذیل میں دکھایا گیا ہے کہ غیر اہم ابتدائیہ کو ایک کوروٹین میں کیسے منتقل کیا جائے جو پہلے فریم کھینچنے کے بعد شروع ہوتا ہے۔ اہم: Firebase، Crashlytics اور Crash Reporting SDKs کو شروع میں شروع کیا جانا چاہیے — انہیں موخر نہیں کیا جا سکتا کیونکہ وہ دوسرے اجزاء کے ابتدائیہ کے دوران کریش پکڑتے ہیں۔ باقی کے لیے، پہلی 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 12+ پر، سرکاری SplashScreen API استعمال کریں جو عمل شروع ہوتے ہی ایک سسٹم اسپلیش (سیاہ/ہلکے پس منظر پر ایپ آئیکن) دکھاتا ہے۔ یہ صارف سے ابتدائیہ کا وقت چھپاتا ہے — وہ سفید اسکرین کے بجائے اسپلیش دیکھتا ہے۔ پرانے آلات کے لیے، theme-based splash (اسٹائل میں Theme.SplashScreen) استعمال کریں۔ اہم: اسپلیش 300 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>