موبائل ایپس کے لیے Hot Reload: یہ کیا ہے، کام کرنے کا اصول اور میکانزم

Hot Reload کیا ہے؟

Hot Reload ایک ترقیاتی میکانزم ہے جس میں سورس کوڈ میں ترمیم کی جاتی ہے اور اسے روکے بغیر چلتی ہوئی ایپلیکیشن پر لاگو کیا جاتا ہے۔ ڈیویلپر فائل میں ترمیم کرتا ہے، اسے محفوظ کرتا ہے، اور 0.3–2 سیکنڈ میں اپ ڈیٹ شدہ انٹرفیس اسکرین پر ظاہر ہوتا ہے۔ ایپلیکیشن کی حالت (کاؤنٹر، اسکرول پوزیشن، درج کردہ ڈیٹا) محفوظ رہتی ہے — ڈیویلپر سیاق و سباق نہیں کھوتا۔

hot relay کا تصور ابتدائی ویب ٹولز (LiveReload، 2010) میں پیدا ہوا اور Flutter (2017) اور React Native (2015) نے موبائل ترقی کے لیے ڈھال لیا۔ آج، hot relay ڈیبگ کنفیگریشن اور پروفائلنگ کے ساتھ ساتھ جدید موبائل فریم ورکس کی لازمی خصوصیت ہے۔ hot relay کے بغیر، UI ترقی کو غیر موثر سمجھا جاتا ہے: ہر تبدیلی کے جائزے کے لیے 10–30 سیکنڈ کی دوبارہ تعمیر اور لانچ درکار ہوتا ہے۔

تکنیکی طور پر، hot relay تین مراحل پر مشتمل ہے: تبدیلی کا پتہ لگانا (فائل واچر)، تبدیل شدہ کوڈ کی تعمیر (تدریجی کمپائلر)، اور اطلاق (ہاٹ پیچنگ)۔ ہر فریم ورک ان مراحل کو اپنے طریقے سے نافذ کرتا ہے، لیکن نتیجہ ایک جیسا ہے: ترمیم اور ڈسپلے کے درمیان کم سے کم تاخیر۔

Flutter میں Hot Reload کیسے کام کرتا ہے

Flutter میں Hot Reload Dart VM فن تعمیر اور JIT تعمیر پر مبنی ہے۔ جب ڈیویلپر IDE میں “Hot Reload” دباتا ہے یا فائل محفوظ کرتا ہے، Flutter تبدیل شدہ Dart لائبریریوں کی کرنل فائلوں (.dill) میں تدریجی تعمیر کرتا ہے۔ Dart VM ان فائلوں کو لوڈ کرتا ہے اور چلتی ہوئی ایپلیکیشن میں تبدیل شدہ فنکشنز کے نفاذ کو بدل دیتا ہے۔

// Hot reload کے دوران محفوظ حالت والا Flutter stateful ویجیٹ
class CounterWidget extends StatefulWidget {
    @override
    State createState() => _CounterState();
}

class _CounterState extends State {
    int _counter = 0;

    @override
    Widget build(BuildContext context) {
        return Column(
            children: [
                Text('کاؤنٹر: $_counter'),
                ElevatedButton(
                    onPressed: () => setState(() => _counter++),
                    child: Text('بڑھائیں'),
                ),
            ],
        );
    }
}

مثال میں، StatefulWidget CounterWidget hot relay کے دوران _counter فیلڈ کو محفوظ رکھتا ہے۔ Dart VM reassemble() کال کرکے حالت (State) دوبارہ بناتا ہے، لیکن _counter کو دوبارہ ترتیب نہیں دیتا — جب تک ویجیٹ مکمل طور پر دوبارہ نہیں بنایا جاتا، قیمت محفوظ رہتی ہے۔ Flutter تمام State اشیاء کے لیے reassemble() کال کرتا ہے، اور build() اپ ڈیٹ شدہ کوڈ اور محفوظ حالت کے ساتھ دوبارہ چلتا ہے۔

hot relay کب کام نہیں کرتا: اگر کوئی جامد ابتدائی متغیر (static const)، عالمی متغیر، main()، enum/mixin کلاس اعلان، یا @override initState() میں کوڈ تبدیل ہو گیا ہو۔ ان صورتوں میں، Hot Restart کی ضرورت ہے۔ Flutter Team (2025) کے مطابق، hot relay 85–90% معاملات میں کامیاب ہوتا ہے؛ 10–15% تبدیلیوں کو مکمل دوبارہ شروع کرنے کی ضرورت ہوتی ہے۔

Dart VM JIT اور کرنل فائلیں

Dart VM ڈیبگ موڈ میں JIT کمپائلر کے طور پر کام کرتا ہے: یہ کرنل فارمیٹ (بائٹ کوڈ کے مشابہ) کے ذریعے Dart کوڈ کی تشریح کرتا ہے۔ Hot relay ایک نئی کرنل فائل لوڈ کرتا ہے اور پرانی فنکشن تعریفوں کو بدل دیتا ہے۔ VM isolates کو دوبارہ شروع نہیں کرتا — تمام غیر متزامن کارروائیاں (Future، Stream) چلتی رہتی ہیں۔ ریلیز موڈ میں، Dart AOT (dart2native) میں تعمیر ہوتا ہے، اور hot relay دستیاب نہیں ہوتا۔

React Native میں Fast Refresh کیسے کام کرتا ہے

Fast Refresh (پہلے Hot Reloading) React Native میں Metro بنڈلر استعمال کرتا ہے — ایک JavaScript ماڈیول بنڈلر جو فائل کی تبدیلیوں کی نگرانی کرتا ہے۔ جب ڈیویلپر فائل محفوظ کرتا ہے، Metro صرف تبدیل شدہ ماڈیول (HMR — Hot Module Replacement) کو کمپائل کرتا ہے اور WebSocket کے ذریعے چلتی ہوئی ایپلیکیشن کو اپ ڈیٹ بھیجتا ہے۔

// Hot reload کے دوران حالت محفوظ کرنے والا React Native کمپوننٹ
import React, { useState } from 'react';
import { View, Text, Button } from 'react-native';

const Counter = () => {
    const [count, setCount] = useState(0);

    return (
        <View>
            <Text>شمار کنندہ: {count}Text>
            <Button title="بڑھائیں"
                onPress={() => setCount(c => c + 1)} />
        View>
    );
};

Fast Refresh ماڈیول اپ ڈیٹ کرتے وقت React حالت (useState، useReducer) کو محفوظ رکھتا ہے۔ Metro HMR صرف تبدیل شدہ ماڈیول کا فرق (diff) منتقل کرتا ہے — پورا بنڈل نہیں۔ React Native React Fast Refresh استعمال کرتا ہے، جو React ٹیم (Dan Abramov، 2019) نے تیار کیا ہے: یہ کمپوننٹ کے لیے ایک نیا رینڈر تیار کرتا ہے لیکن hook کی حالتیں اور props محفوظ رکھتا ہے اگر کمپوننٹ کے دستخط تبدیل نہیں ہوئے ہوں۔

Fast Refresh ان تبدیلیوں پر کام نہیں کرتا: کمپوننٹ برآمد، hooks (useEffect، useMemo)، ماڈیول انحصار اور مقامی ماڈیول (Java/Objective-C)۔ ایسی تبدیلیوں کے لیے Reload (مکمل JS بنڈل دوبارہ لوڈ) یا Rebuild (مقامی کوڈ دوبارہ تعمیر) درکار ہے۔ Fast refresh کا وقت — 200–800 ملی سیکنڈ، مکمل reload — 2–5 سیکنڈ۔

Hot Reload بمقابلہ Hot Restart: موازنہ

Hot Reload اور Hot Restart مختلف استعمال کے منظرناموں کے ساتھ دو کوڈ اپ ڈیٹ موڈ ہیں۔ Hot Reload UI تبدیلیوں (اسٹائل، لے آؤٹ، رنگ، متن) کے لیے موزوں ہے، جب کلاس کی ساخت اور حالت کی قسم تبدیل نہیں ہوتی۔ Hot Restart طریقہ کار کے دستخط تبدیل کرنے، جڑ کے درخت میں نئے ویجیٹ/کمپوننٹ شامل کرنے، initState اور مقامی ماڈیول تبدیل کرنے پر ضروری ہے۔

تجویز کردہ حکمت عملی: hot relay سے شروع کریں۔ اگر تبدیلیاں لاگو نہیں ہوتیں (IDE “Reload needed” دکھاتا ہے) — hot restart کریں۔ Flutter میں، بٹن کا آئیکن بدل جاتا ہے: بجلی (⚡) hot relay کے لیے، کٹی ہوئی بجلی اگر restart ضروری ہو۔ مکمل دوبارہ تعمیر کے مقابلے میں hot relay کے ساتھ ترقی کی کارکردگی 40–60% زیادہ ہے (JetBrains Developer Survey 2024 کا ڈیٹا)۔

نفاذ کے میکانزم: کوڈ انجیکشن اور ہاٹ پیچنگ

کوڈ انجیکشن (code injection) — تمام فریم ورکس کے ذریعے استعمال ہونے والا hot relay کا عمومی میکانزم ہے۔ یہ تین مراحل پر مشتمل ہے۔ پہلا — تبدیلی کا پتہ لگانا: ایک فائل واچر (IDE میں شامل) یا فائل سسٹم (FSNotify) .dart، .js، .tsx فائل میں تبدیلی کا پتہ لگاتا ہے۔ دوسرا — تعمیر: تدریجی کمپائلر صرف تبدیل شدہ فائل کو ایک درمیانی نمائندگی (Dart کے لیے کرنل .dill، JS کے لیے HMR ماڈیول) میں تبدیل کرتا ہے۔ تیسرا — اطلاق: نیا کوڈ ڈیوائس پر بھیجا جاتا ہے اور چلتی ہوئی ایپلیکیشن کی میموری میں پرانی تعریفوں کو بدل دیتا ہے۔

ہاٹ پیچنگ (hot patching) — ایک تکنیک جس میں رن ٹائم ورچوئل میتھڈ ٹیبل میں فنکشن پوائنٹر کو بدل دیتا ہے۔ Dart VM ClassTable استعمال کرتا ہے — ایک داخلی ڈھانچہ جس میں تمام لوڈ کردہ کلاسز شامل ہیں۔ hot relay کے دوران، VM ClassTable میں کلاس ڈھونڈتا ہے اور کرنل فائل سے نئی فنکشن تعریفوں کے ساتھ اس کی فنکشن تعریفوں کو بدل دیتا ہے۔ موجودہ کلاس کی تمام مثالیں خود بخود نیا رویہ حاصل کر لیتی ہیں۔

// Flutter: hot reload کے بعد حالت کے انتظام کے لیے reassemble کال بیک
class MyWidget extends StatefulWidget {
    @override
    State createState() => _MyState();
}

mixin ReloadAware on State {
    @override
    void reassemble() {
        super.reassemble();
        // Hot reload کے بعد کیشے یا ڈیٹا کو دوبارہ ترتیب دیں
        clearCache();
    }
}

مثال میں، ReloadAware mixin reassemble() طریقہ کار کو اووررائڈ کرتا ہے، جسے Dart VM hot relay کے بعد ہر State آبجیکٹ پر کال کرتا ہے۔ ڈیویلپر کیشے کو دوبارہ ترتیب دے سکتا ہے، وسائل کو دوبارہ شروع کر سکتا ہے، یا حالت کی منتقلی انجام دے سکتا ہے۔ اس طریقہ کار کے بغیر، پرانا ڈیٹا کیشے میں رہ سکتا ہے اور ویجیٹ اپ ڈیٹ کے بعد عدم مطابقت پیدا کر سکتا ہے۔

ہاٹ پیچنگ کی حدود

ہاٹ پیچنگ ان تبدیلیوں کے لیے کام نہیں کرتی جن میں نئے فیلڈز کے لیے میموری دوبارہ مختص کرنا، کلاس میں متغیر کی قسم تبدیل کرنا، StatefulWidget میں نئے فیلڈز شامل کرنا، enum اقدار یا generic پیرامیٹرز تبدیل کرنا شامل ہے۔ یہ تبدیلیاں میموری میں موجود اشیاء کے ساتھ مطابقت نہیں رکھتیں — Dart VM پہلے سے مختص کردہ اشیاء میں فیلڈز کو “بدل” نہیں سکتا۔ ایسی صورتوں کے لیے، hot restart یا مکمل دوبارہ تعمیر درکار ہے۔

مقامی ترقی میں Hot Reload: Android اور iOS

مقامی Android اور iOS ترقی میں روایتی طور پر مکمل hot relay نہیں ہے۔ Android Studio Android 11+ اور AGP 4.2+ کے ساتھ Apply Changes کو سپورٹ کرتا ہے: ایپلیکیشن کو دوبارہ شروع کیے بغیر کوڈ اپ ڈیٹ۔ Apply Changes Android Runtime (ART) کے ذریعے کام کرتا ہے — یہ چلتے چلتے dex فائلوں میں طریقہ کار کے نفاذ کو بدل دیتا ہے۔ تاہم، Apply Changes محدود ہے: یہ وسائل کی تبدیلیوں (layout.xml، drawable)، مینی فیسٹ اور مقامی لائبریریوں کے لیے کام نہیں کرتا۔

Apple نے Xcode 15 (2023) میں Previews (SwiftUI Preview) متعارف کرایا — یہ کلاسیکی معنوں میں hot relay نہیں ہے۔ Previews پیش نظارہ سیکشن کو مرکزی ایپلیکیشن سے الگ کمپائل کرتا ہے اور Xcode کینوس میں نتیجہ دکھاتا ہے۔ فائل محفوظ کرنے پر، پیش نظارہ 1–3 سیکنڈ میں اپ ڈیٹ ہوتا ہے، لیکن ایپلیکیشن کی حالت محفوظ نہیں رہتی۔ UIKit پروجیکٹس کے لیے، hot relay تیسرے فریق کے ٹولز کے ذریعے دستیاب ہے: InjectionIII (John Holdsworth) اور SwiftHotReload۔

Kotlin Multiplatform (KMP) کو 2024 سے JetBrains کی طرف سے تجرباتی hot relay سپورٹ ملا۔ یہ میکانزم Kotlin/Native رن ٹائم پر مبنی ہے جس میں آبجیکٹ فائل (.klib) میں فنکشن کی تبدیلی شامل ہے۔ JetBrains Compose Multiplayer Flutter کی طرح اپنا hot relay نفاذ استعمال کرتا ہے: Kotlin/Native رن ٹائم میں تدریجی تعمیر اور کلاس کی تبدیلی۔ رفتار — 1–3 سیکنڈ، صرف UI تبدیلیوں کے لیے دستیاب۔

Android Studio میں Apply Changes: یہ کیسے کام کرتا ہے

Apply Changes — Android Studio کا ایک میکانزم جو ART رن ٹائم API استعمال کرتا ہے۔ کوڈ محفوظ کرتے وقت، Android Studio تعین کرتا ہے کہ کون سی کلاسیں تبدیل ہوئی ہیں اور adb کے ذریعے ان کی dex فائلیں ڈیوائس کو بھیجتا ہے۔ ART چلتی ہوئی ایپلیکیشن میں روکے بغیر طریقہ کار کے نفاذ کو بدل دیتا ہے۔ Apply Changes تین موڈز میں کام کرتا ہے: Instant Run (فوری طریقہ کار کی تبدیلی)، Swap (مثالیں دوبارہ بنا کر کلاس کی تبدیلی)، اور Restart Activity (اگر تبدیلیاں موجودہ حالت کے ساتھ مطابقت نہیں رکھتیں)۔