موبائل ڈویلپمنٹ میں Runtime, Hot Reload اور بلڈ: یہ کیا ہیں، کلیدی تصورات اور کیسے کام کرتے ہیں

Runtime اور Reflection: iOS Runtime, Method Swizzling اور متحرک ڈسپیچ

Runtime (عملدرآمد ماحول) وہ سافٹ ویئر ہے جو ایپلیکیشن کے عملدرآمد کا انتظام کرتا ہے۔ iOS Runtime کے تناظر میں، یہ Objective-C کا متحرک نظام ہے جو آبجیکٹس کو پیغام بھیجنے، فوری طور پر کلاسز بنانے اور رن ٹائم پر طریقوں کو تبدیل کرنے کی اجازت دیتا ہے۔ یہ ممکن ہے کیونکہ Objective-C C کے اوپر بنائی گئی ایک متحرک طور پر ٹائپ کی گئی زبان ہے۔

Reflection ایک پروگرام کی اپنی ساخت کو رن ٹائم پر جانچنے اور تبدیل کرنے کی صلاحیت ہے۔ iOS Runtime میں، یہ class_getInstanceMethod، method_exchangeImplementations اور objc_getAssociatedObject جیسے فنکشنز کے ذریعے لاگو کیا جاتا ہے۔ Kotlin/Java میں، ریفلیکشن KClass / java.lang.reflect استعمال کرتا ہے۔

IT Sectr میں، ہم Runtime بہت کم استعمال کرتے ہیں — صرف مخصوص کاموں کے لیے جہاں کوئی متبادل نہیں ہے۔ مثال کے طور پر، مرکزی تجزیہ لاگنگ یا لائبریریوں میں کیڑے ٹھیک کرنے کے لیے Method Swizzling۔ تاہم، Runtime ایک طاقتور ٹول ہے جس کے لیے گہری سمجھ اور احتیاط کی ضرورت ہے۔

Method Swizzling

Method Swizzling ایک تکنیک ہے جو رن ٹائم پر Objective-C طریقہ کے نفاذ کو دوسرے سے تبدیل کرتی ہے۔ یہ iOS کے لیے Aspect-Oriented Programming (AOP) کی ایک خاص صورت ہے۔ Swizzling موجودہ طریقوں کے سورس کوڈ کو تبدیل کیے بغیر ان میں لاگنگ، تجزیہ یا کیشنگ شامل کرنے کی اجازت دیتا ہے۔

ایک عام مثال: خودکار سکرین لاگنگ شامل کرنے کے لیے UIViewController میں viewWillAppear: کو تبدیل کرنا۔ اہم: swizzling کو +load یا +initialize طریقہ میں کیا جانا چاہیے تاکہ کلاس کے استعمال سے پہلے عملدرآمد یقینی ہو۔ غلط swizzling غیر متعین رویے اور ڈیبگ کرنے میں مشکل کیڑے پیدا کر سکتا ہے۔

// Method Swizzling for logging viewWillAppear:
@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(xxx_viewWillAppear:);
        
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
        method_exchangeImplementations(originalMethod, swizzledMethod);
    });
}

- (void)xxx_viewWillAppear:(BOOL)animated {
    [self xxx_viewWillAppear:animated]; // اصل طریقہ کو کال کرنا
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

یہ کوڈ swizzling کے ذریعے تمام UIViewController پر viewWillAppear: کو تبدیل کرتا ہے۔ method_exchangeImplementations کے بعد، اصل viewWillAppear: کو کال کرنے سے xxx_viewWillAppear: کال ہوتا ہے، جو اصل طریقہ کو کال کرتا ہے (تکراری کال کے ذریعے) اور تجزیہ شامل کرتا ہے۔ DispatchOnce swizzling کے ایک بار کے عملدرآمد کی ضمانت دیتا ہے۔

ویب ٹولز (Transpilation, Polyfill, Bundler, Webpack, Metro)

جدید ویب ڈویلپمنٹ اور React Native یا Flutter کے ساتھ موبائل ڈویلپمنٹ بلڈ ٹولز کے بغیر ناممکن ہے۔ Transpilation کوڈ کو ایک زبان سے دوسری میں تبدیل کرنا ہے۔ سب سے مشہور مثال: TypeScript → JavaScript۔ ایک ٹرانسپائلر (Babel, tsc) جدید کوڈ کو پسماندہ مطابقت والے ورژن میں تبدیل کرتا ہے۔

Polyfill وہ کوڈ ہے جو پرانے براؤزرز میں گمشدہ فعالیت شامل کرتا ہے۔ مثال کے طور پر، Promise.allSettled() Internet Explorer میں کام نہیں کرتا، لیکن polyfill یہ صلاحیت شامل کرتا ہے۔ مقامی Runtime کے برعکس، جو براہ راست ڈیوائس پر کوڈ عملدرآمد کا انتظام کرتا ہے، polyfills اور ٹرانسپائلر زبان کی تجریدی سطح پر کام کرتے ہیں — وہ نحو اور APIs کو ڈھالتے ہیں، لیکن عملدرآمد کے ماحول میں مداخلت نہیں کرتے۔

Webpack سب سے مشہور بنڈلر ہے (State of JS 2024 کے مطابق 72% پروجیکٹس میں استعمال ہوتا ہے)۔ Metro Facebook کا بنڈلر ہے، React Native میں بطور ڈیفالٹ استعمال ہوتا ہے۔ JavaScript میں Reflection Object.getPrototypeOf، Proxy اور Reflect API کے ذریعے موجود ہے — یہ میکانزم رن ٹائم پر آبجیکٹس کو جانچنے اور تبدیل کرنے کی اجازت دیتے ہیں، جو بنڈلرز میں سٹیٹک ماڈیول تجزیہ سے بنیادی طور پر مختلف ہے۔ Webpack ایک کنفیگریشن فائل استعمال کرتا ہے جو انٹری پوائنٹ، آؤٹ پٹ، لوڈرز (مختلف فائل کی اقسام کو پروسیس کرنے کے لیے) اور پلگ انز (اضافی فعالیت کے لیے) بیان کرتی ہے۔

// webpack.config.js — کم سے کم کنفیگریشن
const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist'),
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: 'babel-loader',
            },
        ],
    },
    mode: 'production',
};

یہ کنفیگریشن انٹری پوائنٹ (index.js)، آؤٹ پٹ فائل (bundle.js) اور Babel کے ذریعے JavaScript پروسیسنگ کا اصول بیان کرتی ہے۔ production موڈ آپٹیمائزیشن کو فعال کرتا ہے: مینفیکیشن، ٹری شیکنگ اور خودکار ماحول کا پتہ لگانا۔ Runtime مرحلے پر، یہ تمام آپٹیمائزیشن منطق کو متاثر نہیں کرتیں — براؤزر چھوٹے بنڈل کو عام JavaScript کے طور پر چلاتا ہے۔

کوڈ آپٹیمائزیشن (Minification, Tree Shaking, Obfuscation)

Minification خالی جگہوں اور تبصروں کو ہٹا کر اور لمبے متغیرات کو چھوٹے نام دے کر کوڈ کو سکیڑنے کا عمل ہے۔ مشہور مینیفائر: Terser (JS/TS)، CSSNano (CSS)، html-minifier-terser۔ مینفیکیشن فائل کا سائز 50–70% کم کرتی ہے۔ پروڈکشن میں، Runtime چھوٹے کوڈ کو اصلی کوڈ کی طرح چلاتا ہے — فرق صرف پڑھنے کی اہلیت اور فائل کے سائز میں ہے، معنوں میں نہیں۔

Tree Shaking ایپلیکیشن میں استعمال نہ ہونے والے مردہ کوڈ کو ہٹانا ہے۔ یہ ES ماڈیولز (import/export) کے سٹیٹک تجزیہ پر مبنی ہے۔ اگر کوئی فنکشن ایکسپورٹ کیا جاتا ہے لیکن کبھی امپورٹ نہیں کیا جاتا، Tree Shaking اسے حتمی بلڈ سے ہٹا دیتا ہے۔ Tree Shaking کوڈ کا سٹیٹک تجزیہ کرتا ہے — Reflection کے برعکس، جو متحرک طور پر کام کرتا ہے اور کمپائل ٹائم پر پوشیدہ طریقوں اور خصوصیات تک رسائی حاصل کر سکتا ہے۔

Tree Shaking

Tree Shaking Webpack میں پروڈکشن موڈ میں خودکار طور پر فعال ہوتا ہے۔ ایک اہم شرط: کوڈ کو ES ماڈیولز (import/export) استعمال کرنا چاہیے، CommonJS (require) نہیں۔ اگر کوئی لائبریری CommonJS میں لکھی گئی ہے، تو ٹری شیکنگ کام نہیں کرے گی۔ بہترین ٹری شیکنگ کے لیے، import _ from 'lodash' کے بجائے import { merge } from 'lodash-es' جیسے درست امپورٹ استعمال کریں۔ یہ ایک فنکشن کے لیے بنڈل سائز 500 KB سے 10 KB تک کم کر دیتا ہے۔

Hot Reload

Hot Reload ایک ٹیکنالوجی ہے جو مکمل ری لوڈ کے بغیر ایپلیکیشن کوڈ کو اپ ڈیٹ کرنے کی اجازت دیتی ہے۔ React Native اور Flutter میں، Hot Reload موجودہ ایپلیکیشن اسٹیٹ کو برقرار رکھتے ہوئے تبدیل شدہ فائل کو فوری طور پر اپ ڈیٹ کرتا ہے۔ یہ ڈویلپمنٹ کو یکسر تیز کرتا ہے: تبدیلیاں مکمل ری بلڈ کے لیے 10–30 سیکنڈ کے بجائے 1–2 سیکنڈ میں نظر آتی ہیں۔ Hot Reload Runtime کے اندر کام کرتا ہے: تبدیل شدہ ماڈیول عملدرآمد کے ماحول کو دوبارہ شروع کیے بغیر چلتی ہوئی ایپلیکیشن میں داخل کیا جاتا ہے۔

Hot Restart اپ ڈیٹ شدہ کوڈ کے ساتھ ایپلیکیشن کا تیز دوبارہ شروع ہے، لیکن اسٹیٹ محفوظ نہیں ہوتی۔ یہ اس وقت استعمال ہوتا ہے جب Hot Reload ممکن نہ ہو (مثلاً، جب مقامی کوڈ یا گلوبل متغیرات تبدیل ہو گئے ہوں)۔ IT Sectr میں، ہم UI ڈویلپمنٹ کے تمام مراحل میں Hot Reload استعمال کرتے ہیں — یہ بصری ایڈجسٹمنٹ پر 50% تک وقت بچاتا ہے۔

جدول 3. بلڈ ٹولز کا موازنہ۔ Webpack عالمگیر معیار ہے۔ Metro React Native کے لیے مخصوص ہے۔ Vite اور esbuild رفتار پر مرکوز نئی نسل ہیں۔ Rollup لائبریریاں شائع کرنے کے لیے بہترین انتخاب ہے۔

ہاٹ ریلوڈ (Hot Reload, Hot Restart)

Hot Reload ایک ٹیکنالوجی ہے جو ویب ڈویلپمنٹ (React Hot Loader, HMR — Hot Module Replacement) میں شروع ہوئی اور Flutter اور React Native کے ساتھ موبائل ڈویلپمنٹ میں منتقل ہوئی۔ خلاصہ: جب فائل تبدیل ہوتی ہے، بنڈلر اپ ڈیٹ شدہ ماڈیول چلتی ہوئی ایپلیکیشن کو بھیجتا ہے، جو اسٹیٹ کھونے کے بغیر پرانے کوڈ کو بدل دیتا ہے۔ مکمل ری بلڈ کے برعکس، Hot Reload Runtime کو دوبارہ شروع نہیں کرتا — عملدرآمد کا ماحول چلتا رہتا ہے اور تبدیل شدہ ماڈیول HMR یا ریفلیکشن جیسی ریفرنس اپ ڈیٹ جیسے میکانزم کے ذریعے متحرک طور پر جڑ جاتا ہے۔

Hot Reload اس لیے کام کرتا ہے کیونکہ فریم ورک وجیٹس (Flutter) یا اجزاء (React) کو میموری میں رکھتا ہے اور صرف تبدیل شدہ حصوں کو اپ ڈیٹ کرتا ہے۔ Hot Restart ایک کھردرا میکانزم ہے: یہ ایپلیکیشن کو مکمل طور پر دوبارہ شروع کرتا ہے، لیکن مکمل ری بلڈ سے تیز ہے کیونکہ یہ مقامی کوڈ کو دوبارہ کمپائل نہیں کرتا۔ IT Sectr میں، ہم UI ڈویلپ کرتے وقت Hot Reload اور نیویگیشن یا اسٹیٹ مینجمنٹ تبدیل کرتے وقت Hot Restart استعمال کرتے ہیں۔