JSI: یہ کیا ہے، کام کرنے کا اصول اور فن تعمیر

JSI کیا ہے؟

JSI (JavaScript Interface) ایک C++ پرت ہے جو JavaScript انجن (Hermes، JavaScriptCore، V8) کو C++ آبجیکٹس، فنکشنز اور میموری تک براہ راست رسائی کی صلاحیت فراہم کرتی ہے۔ Bridge کے برعکس، جو کالز کو JSON میں سیریلائز کرتا تھا اور انہیں ایک غیر ہم وقت ساز قطار کے ذریعے بھیجتا تھا، JSI JS کوڈ کو ہم وقت ساز طریقے سے C++ طریقوں کو کال کرنے اور فوری نتیجہ حاصل کرنے کی اجازت دیتا ہے۔

JSI React Native 0.64 میں نئے فن تعمیر (New Architecture) کے حصے کے طور پر متعارف کرایا گیا تھا۔ بنیادی مقصد اس رکاوٹ کو ختم کرنا تھا جو Bridge پیش کرتا تھا: JS اور نیٹیو کوڈ کے درمیان ہر تعامل سیریلائزیشن، ڈی سیریلائزیشن اور پیغام کی قطار سے گزرنے میں وقت صرف کرتا تھا۔ JSI jsi::Value، jsi::Object اور jsi::Function انٹرفیس کو لاگو کرنے والے ریپرز کے ذریعے JS انجن کو C++ آبجیکٹس تک براہ راست رسائی دے کر اس مسئلے کو حل کرتا ہے۔

JSI Bridge کا ایک سے ایک متبادل نہیں ہے — یہ انضمام کے لئے بنیادی طور پر مختلف نقطہ نظر ہے۔ Bridge ایک میل باکس کی طرح کام کرتا تھا: JS ایک پیغام بھیجتا تھا، یہ ایک قطار سے گزرتا تھا، نیٹیو سائیڈ اسے پروسیس کرتی تھی اور جواب بھیجتی تھی۔ JSI ایک پوائنٹر کی طرح کام کرتا ہے: JS ایک C++ آبجیکٹ کا حوالہ حاصل کرتا ہے اور عام JS فنکشنز کی طرح ہم وقت ساز طریقے سے اس کے طریقوں کو کال کر سکتا ہے۔ یہ دو ماحول کے درمیان تعامل کے فن تعمیر میں ایک بنیادی فرق ہے۔

تخلیق کی تاریخ

JSI کی ضرورت اصل Bridge کی حدود سے پیدا ہوئی، جو React Native 2015 میں قائم کیا گیا تھا۔ فریم ورک کی مقبولیت میں اضافہ اور ایپلیکیشنز کے پیچیدہ ہونے کے ساتھ، کارکردگی کا مسئلہ واضح ہو گیا: ہر نیٹیو ماڈیول کال کو سیریلائزیشن کے لئے کم از کم 3–5 ms درکار تھا۔ سادہ عملیات جیسے سینسر کی قدر پڑھنا یا اسکرین کا سائز حاصل کرنا، یہ قابل قبول تھا، لیکن اینیمیشنز، گرافکس کے کام اور سلسلہ وار ڈیٹا پروسیسنگ کے لئے — یہ اہم تھا۔ React Native ٹیم نے 2019 میں نئے فن تعمیر پر کام شروع کیا، اور JSI اس کی بنیاد بن گیا۔

JavaScript انجن کی معاونت

JSI JavaScript انجنوں پر ایک تجریدی پرت کے طور پر ڈیزائن کیا گیا ہے۔ یہ ایک متحد C++ API فراہم کرتا ہے جو ہر مخصوص انجن کے لئے لاگو کیا جاتا ہے: Hermes، JavaScriptCore (iOS)، V8 (Android)۔ اس کا مطلب ہے کہ ڈیویلپرز کو انجنوں کے درمیان فرق کے بارے میں فکر کرنے کی ضرورت نہیں ہے — Fabric اور TurboModules تمام معاون انجنوں پر یکساں کام کرتے ہیں۔

JSI کیسے کام کرتا ہے؟

JSI کے مرکز میں میزبان آبجیکٹس (Host Objects) کا تصور ہے — C++ آبجیکٹس جو JS ماحول میں نیٹیو JS آبجیکٹس کے طور پر برآمد کیے جاتے ہیں۔ جب JS کوڈ ایسے آبجیکٹ کی کسی خاصیت یا طریقے تک رسائی حاصل کرتا ہے، JSI کال کو روکتا ہے اور اسے متعلقہ C++ طریقے کو سونپتا ہے۔ یہ ہم وقت ساز طور پر، اسی تھریڈ میں، سیاق و سباق کی تبدیلی کے بغیر اور JSON سٹرنگ کے لئے میموری مختص کئے بغیر ہوتا ہے۔

ہر میزبان آبجیکٹ jsi::HostObject انٹرفیس کو get، set اور getPropertyNames طریقوں کے ساتھ لاگو کرتا ہے۔ JS انجن ان طریقوں کو ہر بار کال کرتا ہے جب آبجیکٹ کی کسی خاصیت تک رسائی حاصل کی جاتی ہے۔ مثال کے طور پر، JS میں NativeModule.someMethod() کال کرتے وقت، JSI اس کال کو متعلقہ میزبان آبجیکٹ طریقے کی C++ کال میں تبدیل کرتا ہے۔ واپسی کی قدر jsi::Value کے طور پر JS کو واپس بھیجی جاتی ہے — ایک عام قسم جو نمبر، سٹرنگ، بولین، آبجیکٹ یا undefined کی نمائندگی کر سکتی ہے۔

JSI کی ایک اہم خصوصیت پیغام کی قطار کی عدم موجودگی ہے۔ Bridge ایک غیر ہم وقت ساز قطار استعمال کرتا تھا: JS ایک درخواست بھیجتا تھا، دوسرے کاموں پر سوئچ کرتا تھا، نیٹیو سائیڈ درخواست پروسیس کرتی تھی، اور نتیجہ کال بیک کے ذریعے واپس آتا تھا۔ JSI ہم وقت ساز طور پر کام کرتا ہے: اگر JS JSI کے ذریعے نیٹیو ماڈیول طریقہ کال کرتا ہے، تو JS کوڈ کا نفاذ نتیجہ موصول ہونے تک روک دیا جاتا ہے۔ یہ منطق کو آسان بناتا ہے (کال بیکس کا انتظار کرنے کی ضرورت نہیں) اور ریس کنڈیشنز کو ختم کرتا ہے، لیکن احتیاط کی ضرورت ہے — لمبی ہم وقت ساز کالز JS تھریڈ کو بلاک کرتی ہیں۔

JSI اقدار کا لائف سائیکل

JSI کے ذریعے بنائی گئی قدریں JS انجن رن ٹائم میں رہتی ہیں اور کوڑا کرکٹ جمع کرنے والے کے زیر انتظام ہوتی ہیں۔ جب C++ کوڈ jsi::String یا jsi::Object بناتا ہے اور اسے JS کو واپس کرتا ہے، ماحول خود بخود میموری کا انتظام کرتا ہے۔ اگر C++ کوڈ کالز کے درمیان JS قدر کا حوالہ رکھنا چاہتا ہے، تو jsi::Value::getWeak() یا رن ٹائم روٹ آبجیکٹ پر محفوظ حوالہ کے ساتھ عالمی jsi::Object::setProperty استعمال کیا جاتا ہے۔ یہ کوڑا کرکٹ جمع کرنے والے کی طرف سے قبل از وقت ہٹانے کو روکتا ہے۔

تھریڈ سیفٹی

JSI ڈیفالٹ طور پر تھریڈ سیف نہیں ہے۔ تمام JSI طریقہ کالز اس تھریڈ سے ہونی چاہئیں جہاں JS عمل پیرا ہوتا ہے (عام طور پر React Native کا JS تھریڈ)۔ اگر کوئی نیٹیو ماڈیول علیحدہ تھریڈ پر پس منظر کا کام شروع کرتا ہے، تو نتیجہ TurboModules سے runOnJS استعمال کرکے JS تھریڈ کے ذریعے واپس بھیجنا ضروری ہے۔ یہ حد ہم وقتی اور سیریلائزیشن کی عدم موجودگی کی قیمت ہے۔

JSI بمقابلہ Bridge: موازنہ

JSI اور Bridge کے درمیان فرق بنیادی ہے اور JS-نیٹیو کوڈ تعامل کے تمام پہلوؤں کو متاثر کرتا ہے۔ Bridge غیر ہم وقت ساز تھا، ڈیٹا کو JSON میں سیریلائز کرتا تھا اور پیغام کی قطار استعمال کرتا تھا؛ JSI ہم وقت ساز ہے، نیٹیو حوالوں کے ساتھ کام کرتا ہے اور سیریلائزیشن کی ضرورت نہیں ہے۔

React Native ٹیم کے مطابق، Facebook Marketplace ایپ میں Bridge سے JSI میں منتقلی نے JS اور نیٹیو اطراف کے درمیان ڈیٹا ڈپلیکیشن کو ختم کرکے شروع ہونے کا وقت 35% کم کیا اور میموری کی کھپت 20% کم کی۔

Bridge کب ضروری تھا

Bridge کوئی “غلطی” نہیں تھا — یہ 2015 میں React Native کی تخلیق کے وقت ایک جائز تعمیری فیصلہ تھا۔ مختلف زبانوں والے دو پلیٹ فارمز کے لئے نیٹیو ڈیولپمنٹ کو ایک عالمی تبادلے کی شکل کی ضرورت تھی۔ سیریلائزیشن کی شکل کے طور پر JSON تمام پلیٹ فارمز پر دستیاب تھا اور تعامل کو متحد کرنے کی اجازت دیتا تھا۔ مسئلہ بعد میں واضح ہوا، جب React Native پیچیدہ ایپلیکیشنز کے لئے استعمال ہونے لگا جن میں فی سیکنڈ ہزاروں نیٹیو ماڈیول کالز ہوتی تھیں۔

پسماندہ مطابقت

React Native پسماندہ مطابقت برقرار رکھتا ہے: Bridge کے لئے لکھے گئے نیٹیو ماڈیولز مطابقت کی پرت کے ذریعے نئے فن تعمیر میں کام جاری رکھتے ہیں۔ تاہم، نئے ماڈیولز کے لئے براہ راست TurboModules کے ذریعے JSI استعمال کرنے کی سفارش کی جاتی ہے۔ موجودہ ماڈیولز کی منتقلی میں ماڈیول کی کاروباری منطق کو تبدیل کئے بغیر تعامل کے پروٹوکول کو تبدیل کرنا شامل ہے۔

React Native فن تعمیر میں JSI

JSI ایک بنیادی پرت ہے جس پر نئے React Native فن تعمیر کے تمام اجزاء تعمیر کئے گئے ہیں۔ JSI کے بغیر، نہ Fabric (نیا رینڈرر) اور نہ TurboModules (بهتر بنائے گئے نیٹیو ماڈیولز) ممکن ہوتے۔ JSI تمام سطحوں پر JS کو C++ کے ساتھ تعامل کرنے کا ایک متحد طریقہ فراہم کرتا ہے۔

Fabric اور JSI

Fabric React Native کا نیا رینڈرر ہے جو C++ UI نمائندگیوں تک ہم وقت ساز رسائی کے لئے JSI استعمال کرتا ہے۔ پرانے فن تعمیر میں، رینڈرنگ Bridge کے ذریعے ہوتی تھی: JS React عناصر بناتا تھا، انہیں JSON میں سیریلائز کرتا تھا، Bridge کے ذریعے بھیجتا تھا، نیٹیو سائیڈ ڈی سیریلائز کرتی تھی اور UI بناتی تھی۔ Fabric JSI کے ذریعے براہ راست JS سے C++ شیڈو ٹری آبجیکٹس بناتا ہے، Yoga کے ذریعے ہم وقت ساز طور پر لی آؤٹ کا حساب لگاتا ہے اور تیار فریموں کو نیٹیو رینڈرر کو بھیجتا ہے — ایک بھی سیریلائزیشن کے بغیر۔

TurboModules اور JSI

TurboModules React Native نیٹیو ماڈیولز کا ارتقاء ہے۔ Bridge میں ماڈیول رجسٹر کرنے اور JSON کے ذریعے اس کے طریقوں کو کال کرنے کے بجائے، TurboModules سست لوڈنگ اور براہ راست طلب کے لئے JSI استعمال کرتا ہے۔ جب JS کوڈ پہلی بار کسی ماڈیول تک رسائی حاصل کرتا ہے، JSI ایک میزبان آبجیکٹ بناتا ہے — یہ نیٹیو ماڈیول لوڈ کرتا ہے اور اس کے طریقوں کو C++ فنکشنز کے طور پر پیش کرتا ہے۔ سست لوڈنگ کا مطلب ہے کہ ماڈیول پہلی رسائی تک میموری استعمال نہیں کرتا — یہ خاص طور پر درجنوں نیٹیو ماڈیولز والی ایپلیکیشنز کے لئے اہم ہے، جن میں سے بہت سے صرف مخصوص اسکرینوں میں استعمال ہوتے ہیں۔

JSI کے ذریعے کوڈ جنریشن

نئے فن تعمیر میں JSI کے ساتھ کام کرنے کے لئے Codegen استعمال کیا جاتا ہے — ایک آلہ جو JavaScript تصریحات سے C++ بائنڈنگز تیار کرتا ہے۔ ڈیویلپر TypeScript یا Flow میں نیٹیو ماڈیول انٹرفیس بیان کرتا ہے، اور Codegen JSI-مطابق میزبان آبجیکٹ لاگو کرنے والا C++ کوڈ تیار کرتا ہے۔ یہ معمول کے کام کو خودکار کرتا ہے اور ضمانت دیتا ہے کہ JS اور C++ اطراف کی اقسام مطابقت پذیر ہیں۔

JSI کے ساتھ کوڈ کی مثالیں

آئیے دیکھتے ہیں کہ عملی طور پر JSI کے ساتھ کام کیسا لگتا ہے۔ اس مثال میں، ہم ایک سادہ C++ کلاس بناتے ہیں جو JSI کے ذریعے JS میں برآمد کی جاتی ہے، اور React Native میں JavaScript کوڈ سے اس کے طریقے کو کال کرتے ہیں۔

// Calculator.h — C++ کلاس ہیڈر JS سے قابل رسائی
class Calculator {
public:
    double add(double a, double b) { return a + b; }
    double multiply(double a, double b) { return a * b; }
};

Calculator کلاس میں دو ریاضیاتی طریقے ہیں۔ ہمیں اسے JS سے قابل رسائی بنانے کی ضرورت ہے۔ اس کے لئے، ایک میزبان آبجیکٹ بنایا جاتا ہے جو Calculator کو لپیٹتا ہے اور JSI کے ذریعے اس کے طریقوں کو پیش کرتا ہے۔

// CalculatorHostObject.cpp — JSI ریپر کا نفاذ
class CalculatorHostObject : public jsi::HostObject {
private:
    Calculator calc;

public:
    jsi::Value get(jsi::Runtime& runtime,
        const jsi::PropNameID& name) override {
        auto propName = name.utf8(runtime);

        if (propName == "add") {
            return jsi::Function::createFromHostFunction(
                runtime, name, 2,
                [this](jsi::Runtime& runtime,
                    const jsi::Value& thisVal,
                    const jsi::Value* args,
                    size_t count) -> jsi::Value {
                    return jsi::Value(calc.add(
                        args[0].asNumber(),
                        args[1].asNumber()));
                });
        }
        return jsi::Value::undefined();
    }
};

اس کوڈ میں، get طریقہ ہر بار کال کیا جاتا ہے جب JS آبجیکٹ کی کسی خاصیت تک رسائی حاصل کرتا ہے۔ اگر خاصیت کا نام “add” ہے، تو ایک C++ فنکشن لوٹایا جاتا ہے جو JS سے دو آرگیومینٹ لیتا ہے اور calc.add() کو کال کرتا ہے۔ قدر jsi::Value کے طور پر لوٹائی جاتی ہے — JSI خود بخود double کو JS نمبر میں تبدیل کر دیتا ہے۔

JavaScript سے کال کرنا

JS ماحول میں میزبان آبجیکٹ کو رجسٹر کرنے کے بعد، کال ایک عام JS فنکشن کی طرح لگتی ہے۔ کوڈ جنریشن کے مرحلے میں تمام اقسام کی جانچ کی جاتی ہے، جو رن ٹائم کے دوران قسم کی عدم مطابقت کی غلطیوں کو ختم کرتی ہے۔

// JavaScript — JSI کے ذریعے C++ کیلکولیٹر کو کال کرنا
import { Calculator } from 'react-native-calculator'

const result = Calculator.add(5, 3)
console.log(result) // 8 — ہم وقت ساز، بغیر تاخیر کے

const product = Calculator.multiply(4, 2.5)
console.log(product) // 10 — فوری نتیجہ

نوٹ: نتیجہ فوری طور پر لوٹایا جاتا ہے، Promise کے بغیر، await کے بغیر، کال بیکس کے بغیر۔ یہ ایک ہم وقت ساز کال ہے جو Bridge فن تعمیر میں ناممکن تھی۔ طویل مدتی عملیات (فائل پڑھنا، نیٹ ورک کی درخواست) کے لئے، غیر ہم وقت ساز پیٹرن استعمال کرنے چاہئیں — JSI بھاری کاموں کے لئے پس منظر تھریڈز کی ضرورت کو ختم نہیں کرتا۔

عملی طور پر، زیادہ تر ڈیویلپرز JSI میزبان آبجیکٹس کو دستی طور پر نہیں لکھتے — یہ کام Codegen کرتا ہے، جو TypeScript تصریحات کی بنیاد پر C++ ریپرز تیار کرتا ہے۔ تاہم، JSI اندرونی طور پر کیسے کام کرتا ہے یہ سمجھنا مؤثر کارکردگی ڈیبگنگ اور پیچیدہ نیٹیو ماڈیولز بناتے وقت ضروری ہے جنہیں C++ لائبریریوں (Skia، FFmpeg، OpenCV) تک براہ راست رسائی درکار ہوتی ہے۔