পাঠ ১৭ · ৫৭-এর মধ্যে · মডিউল ৪
Home / Courses / Mobile App Development / React Native ব্রিজ

React Native — ব্রিজ আর্কিটেকচার ও এর কার্যপ্রণালী

React Native bridge architecture and how it works
১০ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • React Native-এর দুই-থ্রেড মডেল — JS থ্রেড ও নেটিভ সাইড আলাদা রানটাইমে চলে কেন
  • ক্লাসিক "ব্রিজ" আর্কিটেকচার — asynchronous, সিরিয়ালাইজড বার্তা কীভাবে কাজ করে
  • নতুন JSI আর্কিটেকচার — সরাসরি, synchronous কল কীভাবে ওভারহেড কমায়
  • একটি সত্যিকারের Python সিমুলেশনে ব্রিজ (২ হপ) বনাম JSI (১ হপ) — প্রকৃত গণনাসহ

১ · React Native-এর দুই-থ্রেড মডেল

একটি React Native অ্যাপে JavaScript কোড (React কম্পোনেন্ট ট্রি, বিজনেস লজিক) একটি JS থ্রেডJS ThreadReact Native অ্যাপের JavaScript ইঞ্জিন (যেমন Hermes) যেখানে React কম্পোনেন্ট, স্টেট ও বিজনেস লজিক চলে — এটি ডিভাইসের নেটিভ UI থ্রেড থেকে আলাদা একটি রানটাইম।-এ চলে, যেখানে UI নিজেই প্রকৃত নেটিভ প্ল্যাটফর্ম উইজেট (iOS-এ UIKit উপাদান, Android-এ নেটিভ ভিউ) দিয়ে তৈরি হয়ে নেটিভ সাইডে থাকে। যেহেতু এই দুটো ঐতিহাসিকভাবে সম্পূর্ণ আলাদা রানটাইম — তারা সরাসরি মেমরি শেয়ার করতে পারে না; একটি ক্যামেরা খোলা বা একটি অ্যানিমেশন ট্রিগার করার মতো কাজে JS-কে নেটিভ কোডের সাথে কোনোভাবে "যোগাযোগ" করতে হয়।

ক্লাসিক ব্রিজ (২ হপ, async) JS থ্রেড ব্রিজ (async queue) নেটিভ থ্রেড JSI (১ হপ, sync) JS থ্রেড নেটিভ থ্রেড
ক্লাসিক ব্রিজ বার্তাটি সারিতে রাখে তারপর নেটিভ সাইড আলাদাভাবে তুলে প্রসেস করে (দুটি ধাপ); JSI সরাসরি কল করে সাথে সাথে ফলাফল পায় (এক ধাপ)।

২ · ব্রিজ বনাম JSI

ব্রিজ (ক্লাসিক আর্কিটেকচার)
JS-সাইড একটি বার্তা তৈরি করে সিরিয়ালাইজ করে (JSON-জাতীয় ফরম্যাটে) একটি সারিতে রাখে; নেটিভ সাইড পরে সেই সারি থেকে বার্তা তুলে ডিসিরিয়ালাইজ করে প্রসেস করে — asynchronous, প্রায়ই ব্যাচে।
JSI (নতুন আর্কিটেকচার)
JS ইঞ্জিন সরাসরি নেটিভ ফাংশনের রেফারেন্স ধরে রাখতে পারে এবং সরাসরি, synchronous কল করতে পারে — সিরিয়ালাইজেশন বা সারিতে অপেক্ষা করার প্রয়োজন নেই, ফলাফল তাৎক্ষণিক ফেরত আসে।

৩ · একটি সত্যিকারের বার্তা-সারি সিমুলেশন

নিচের কোড সেলে ব্রিজকে একটি প্রকৃত Python লিস্টকে বার্তা-সারি হিসেবে ব্যবহার করে সিমুলেট করা হলো — JS-সাইড একটি বার্তা এনকিউ করে (হপ ১), তারপর একটি আলাদা "নেটিভ প্রসেসর" ফাংশন সেটি ডিকিউ করে উত্তর দেয় (হপ ২) — দুটি স্বতন্ত্র ধাপ, তাৎক্ষণিক নয়। এরপর JSI-কে একটি সরাসরি ফাংশন কল হিসেবে সিমুলেট করা হলো — কোনো সারি ছাড়াই, মাত্র ১ হপে।

Python
# React Native-এর ক্লাসিক "ব্রিজ" -- একটি বার্তা-সারি (message queue) হিসেবে সিমুলেট করা হলো
# JS-সাইড কল করে বার্তা সারিতে রাখে (হপ ১); নেটিভ সাইড আলাদা ধাপে সেটি তুলে প্রসেস করে (হপ ২)

bridge_queue = []
bridge_hops = 0

def js_call_native_via_bridge(module, method, args):
    global bridge_hops
    message = {"module": module, "method": method, "args": args}
    bridge_queue.append(message)
    bridge_hops += 1   # হপ ১: JS বার্তাটি সিরিয়ালাইজ করে সারিতে রাখলো
    print(f"[JS থ্রেড]     bridge_queue-তে যোগ হলো -> {message}")

def native_process_bridge_queue():
    global bridge_hops
    responses = []
    while bridge_queue:
        message = bridge_queue.pop(0)
        bridge_hops += 1   # হপ ২: নেটিভ সাইড আলাদাভাবে বার্তাটি তুলে প্রসেস করলো
        result = f"{message['module']}.{message['method']} সম্পন্ন হলো"
        responses.append(result)
        print(f"[Native থ্রেড] প্রসেস করলো -> {result}")
    return responses

js_call_native_via_bridge("Camera", "takePhoto", {})
native_process_bridge_queue()

print(f"\nব্রিজ পদ্ধতিতে মোট হপ: {bridge_hops}")

# ---- JSI (নতুন আর্কিটেকচার) -- সরাসরি, synchronous কল, কোনো সারি ছাড়াই ----
jsi_hops = 0

def js_call_native_via_jsi(module, method, args):
    global jsi_hops
    jsi_hops += 1   # হপ ১ (এবং একমাত্র হপ): সরাসরি নেটিভ ফাংশন কল, তাৎক্ষণিক ফলাফল
    result = f"{module}.{method} সম্পন্ন হলো (সরাসরি)"
    print(f"[JS -> Native সরাসরি কল] {result}")
    return result

js_call_native_via_jsi("Camera", "takePhoto", {})

print(f"\nJSI পদ্ধতিতে মোট হপ: {jsi_hops}")
print(f"\nপার্থক্য: ব্রিজ = {bridge_hops} হপ (queue + async প্রসেসিং), JSI = {jsi_hops} হপ (সরাসরি sync কল)")

    
লক্ষ্য করুন bridge_hops দুইবার বাড়ে — একবার js_call_native_via_bridge-এ (এনকিউ করার সময়) এবং একবার native_process_bridge_queue-এ (ডিকিউ করে প্রসেস করার সময়), কারণ বাস্তবে এগুলো দুটি সত্যিকারের আলাদা মুহূর্ত — সম্ভবত ভিন্ন সময়ে ঘটে। jsi_hops মাত্র একবার বাড়ে, কারণ JSI-তে এনকিউ করা ও প্রসেস করা একই, তাৎক্ষণিক ধাপ।
মূল কথা · Key takeaway

React Native-এর ক্লাসিক ব্রিজ একটি বাস্তব asynchronous, সিরিয়ালাইজেশন-ভিত্তিক কমিউনিকেশন চ্যানেল — এটি JS ও নেটিভকে আলাদা রানটাইম হিসেবে নিরাপদে চলতে দেয়, কিন্তু প্রতিটি ক্রস-থ্রেড কলে একটি ওভারহেড যোগ করে। JSI সেই ওভারহেড দূর করে সরাসরি রেফারেন্স ধরে সরাসরি কল করার সুযোগ দিয়ে — উভয় পদ্ধতিই এখনো প্রকৃত নেটিভ UI উইজেট ব্যবহার করে, শুধু JS-নেটিভ যোগাযোগের পথটি ভিন্ন।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন ব্রিজ পদ্ধতিতে বার্তাগুলো "সিরিয়ালাইজড" হতে হয়?

JS ও নেটিভ ঐতিহাসিকভাবে আলাদা রানটাইম, আলাদা মেমরি স্পেসে চলে — তাই একপাশের একটি সরাসরি অবজেক্ট রেফারেন্স অন্যপাশে সরাসরি বোঝানো যায় না। তথ্যকে একটি সাধারণ, উভয়পাশে বোঝা যায় এমন ফরম্যাটে (JSON-জাতীয়) রূপান্তর করতে হয় — এটিই সিরিয়ালাইজেশন। JSI এই প্রয়োজনীয়তা কমায় সরাসরি C++ বাইন্ডিং দিয়ে, যা উভয়পাশ থেকেই অ্যাক্সেসযোগ্য।

প্র ০২ ব্রিজের এই async, ব্যাচড প্রকৃতি বাস্তব React Native অ্যাপে কোন ধরনের কাজে সমস্যা তৈরি করতে পারে?

উচ্চ-ফ্রিকোয়েন্সি, ল্যাটেন্সি-স্পর্শকাতর ইন্টারঅ্যাকশনে — যেমন জেসচার-চালিত অ্যানিমেশন যেখানে প্রতিটি ফ্রেমে JS ও নেটিভের মধ্যে দ্রুত আদান-প্রদান দরকার — প্রতিটি ব্রিজ রাউন্ড-ট্রিপ কিছুটা বিলম্ব যোগ করে যা জমতে জমতে দৃশ্যমান ল্যাগ তৈরি করতে পারে। এটিই JSI/নতুন আর্কিটেকচার চালু করার অন্যতম প্রধান কারণ।

প্র ০৩ কোড সেলে bridge_hops কেন দুটি আলাদা ফাংশনে (একবার করে) বাড়ানো হয়েছে?

কারণ ব্রিজ প্রকৃতপক্ষে দুটি স্বতন্ত্র ধাপ প্রতিনিধিত্ব করে — বার্তা তৈরি করে সারিতে রাখা (JS-সাইডের কাজ, যেকোনো মুহূর্তে ঘটতে পারে) এবং সেই বার্তা পরে তুলে প্রসেস করা (নেটিভ-সাইডের কাজ, সম্ভবত পরবর্তী কোনো "টিকে" ঘটে)। দুটোকে আলাদাভাবে গোনা এই asynchronous, দুই-ধাপ প্রকৃতিটিকে সঠিকভাবে মডেল করে।

অনুশীলন

  1. চিন্তা করুন: আপনার ব্যবহৃত কোনো React Native অ্যাপে কোনো অ্যানিমেশন বা জেসচার সামান্য "ঝাঁকুনি" (jank) দিয়েছে বলে মনে পড়ে কি? এখন ব্রিজের কথা জেনে সেটির একটি সম্ভাব্য কারণ কী হতে পারে বলে মনে হয়?

    দ্রুত, একাধিক ক্রস-থ্রেড বার্তা আদান-প্রদান দরকার এমন ইন্টারঅ্যাকশনে (যেমন একটি স্ক্রল-চালিত কাস্টম অ্যানিমেশন) ব্রিজের প্রতিটি রাউন্ড-ট্রিপের সিরিয়ালাইজেশন ও সারি-প্রসেসিং সময় জমে দৃশ্যমান ল্যাগ তৈরি করতে পারে — বিশেষ করে ক্লাসিক আর্কিটেকচারে।

  2. পরীক্ষা করুন: কোড সেলে native_process_bridge_queue() কল করার আগে js_call_native_via_bridge আরও একবার (মোট দুইবার) কল করুন, তারপর bridge_hops-এর চূড়ান্ত মান আগে থেকে অনুমান করে যাচাই করুন।

    দুইবার এনকিউ করলে bridge_hops প্রথমে ২ হয় (প্রতিটি এনকিউ কলে +১)। তারপর native_process_bridge_queue() সারিতে থাকা দুটি বার্তাই একে একে প্রসেস করে, প্রতিটির জন্য bridge_hops আরও +১ করে বাড়ায় — চূড়ান্ত মান হয় ৪। এটি দেখায় ব্রিজের মোট হপ-সংখ্যা সরাসরি সারিতে থাকা বার্তার সংখ্যার সমানুপাতিক।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
Android নেটিভ ডেভেলপমেন্ট ওভারভিউ