React Native — ব্রিজ আর্কিটেকচার ও এর কার্যপ্রণালী
এই পাঠে যা শিখবেন
- 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-কে নেটিভ কোডের সাথে কোনোভাবে "যোগাযোগ" করতে হয়।
২ · ব্রিজ বনাম JSI
JS-সাইড একটি বার্তা তৈরি করে সিরিয়ালাইজ করে (JSON-জাতীয় ফরম্যাটে) একটি সারিতে রাখে; নেটিভ সাইড পরে সেই সারি থেকে বার্তা তুলে ডিসিরিয়ালাইজ করে প্রসেস করে — asynchronous, প্রায়ই ব্যাচে।
JS ইঞ্জিন সরাসরি নেটিভ ফাংশনের রেফারেন্স ধরে রাখতে পারে এবং সরাসরি, synchronous কল করতে পারে — সিরিয়ালাইজেশন বা সারিতে অপেক্ষা করার প্রয়োজন নেই, ফলাফল তাৎক্ষণিক ফেরত আসে।
৩ · একটি সত্যিকারের বার্তা-সারি সিমুলেশন
নিচের কোড সেলে ব্রিজকে একটি প্রকৃত Python লিস্টকে বার্তা-সারি হিসেবে ব্যবহার করে সিমুলেট করা হলো — JS-সাইড একটি বার্তা এনকিউ করে (হপ ১), তারপর একটি আলাদা "নেটিভ প্রসেসর" ফাংশন সেটি ডিকিউ করে উত্তর দেয় (হপ ২) — দুটি স্বতন্ত্র ধাপ, তাৎক্ষণিক নয়। এরপর JSI-কে একটি সরাসরি ফাংশন কল হিসেবে সিমুলেট করা হলো — কোনো সারি ছাড়াই, মাত্র ১ হপে।
# 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-তে এনকিউ করা ও প্রসেস করা একই, তাৎক্ষণিক ধাপ।
React Native-এর ক্লাসিক ব্রিজ একটি বাস্তব asynchronous, সিরিয়ালাইজেশন-ভিত্তিক কমিউনিকেশন চ্যানেল — এটি JS ও নেটিভকে আলাদা রানটাইম হিসেবে নিরাপদে চলতে দেয়, কিন্তু প্রতিটি ক্রস-থ্রেড কলে একটি ওভারহেড যোগ করে। JSI সেই ওভারহেড দূর করে সরাসরি রেফারেন্স ধরে সরাসরি কল করার সুযোগ দিয়ে — উভয় পদ্ধতিই এখনো প্রকৃত নেটিভ UI উইজেট ব্যবহার করে, শুধু JS-নেটিভ যোগাযোগের পথটি ভিন্ন।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ কেন ব্রিজ পদ্ধতিতে বার্তাগুলো "সিরিয়ালাইজড" হতে হয়?
JS ও নেটিভ ঐতিহাসিকভাবে আলাদা রানটাইম, আলাদা মেমরি স্পেসে চলে — তাই একপাশের একটি সরাসরি অবজেক্ট রেফারেন্স অন্যপাশে সরাসরি বোঝানো যায় না। তথ্যকে একটি সাধারণ, উভয়পাশে বোঝা যায় এমন ফরম্যাটে (JSON-জাতীয়) রূপান্তর করতে হয় — এটিই সিরিয়ালাইজেশন। JSI এই প্রয়োজনীয়তা কমায় সরাসরি C++ বাইন্ডিং দিয়ে, যা উভয়পাশ থেকেই অ্যাক্সেসযোগ্য।
প্র ০২ ব্রিজের এই async, ব্যাচড প্রকৃতি বাস্তব React Native অ্যাপে কোন ধরনের কাজে সমস্যা তৈরি করতে পারে?
উচ্চ-ফ্রিকোয়েন্সি, ল্যাটেন্সি-স্পর্শকাতর ইন্টারঅ্যাকশনে — যেমন জেসচার-চালিত অ্যানিমেশন যেখানে প্রতিটি ফ্রেমে JS ও নেটিভের মধ্যে দ্রুত আদান-প্রদান দরকার — প্রতিটি ব্রিজ রাউন্ড-ট্রিপ কিছুটা বিলম্ব যোগ করে যা জমতে জমতে দৃশ্যমান ল্যাগ তৈরি করতে পারে। এটিই JSI/নতুন আর্কিটেকচার চালু করার অন্যতম প্রধান কারণ।
প্র ০৩
কোড সেলে bridge_hops কেন দুটি আলাদা ফাংশনে (একবার করে) বাড়ানো হয়েছে?
কারণ ব্রিজ প্রকৃতপক্ষে দুটি স্বতন্ত্র ধাপ প্রতিনিধিত্ব করে — বার্তা তৈরি করে সারিতে রাখা (JS-সাইডের কাজ, যেকোনো মুহূর্তে ঘটতে পারে) এবং সেই বার্তা পরে তুলে প্রসেস করা (নেটিভ-সাইডের কাজ, সম্ভবত পরবর্তী কোনো "টিকে" ঘটে)। দুটোকে আলাদাভাবে গোনা এই asynchronous, দুই-ধাপ প্রকৃতিটিকে সঠিকভাবে মডেল করে।
অনুশীলন
-
চিন্তা করুন: আপনার ব্যবহৃত কোনো React Native অ্যাপে কোনো অ্যানিমেশন বা জেসচার সামান্য
"ঝাঁকুনি" (jank) দিয়েছে বলে মনে পড়ে কি? এখন ব্রিজের কথা জেনে সেটির একটি সম্ভাব্য কারণ কী হতে পারে বলে
মনে হয়?
দ্রুত, একাধিক ক্রস-থ্রেড বার্তা আদান-প্রদান দরকার এমন ইন্টারঅ্যাকশনে (যেমন একটি স্ক্রল-চালিত কাস্টম অ্যানিমেশন) ব্রিজের প্রতিটি রাউন্ড-ট্রিপের সিরিয়ালাইজেশন ও সারি-প্রসেসিং সময় জমে দৃশ্যমান ল্যাগ তৈরি করতে পারে — বিশেষ করে ক্লাসিক আর্কিটেকচারে।
-
পরীক্ষা করুন: কোড সেলে
native_process_bridge_queue()কল করার আগেjs_call_native_via_bridgeআরও একবার (মোট দুইবার) কল করুন, তারপরbridge_hops-এর চূড়ান্ত মান আগে থেকে অনুমান করে যাচাই করুন।দুইবার এনকিউ করলে
bridge_hopsপ্রথমে ২ হয় (প্রতিটি এনকিউ কলে +১)। তারপরnative_process_bridge_queue()সারিতে থাকা দুটি বার্তাই একে একে প্রসেস করে, প্রতিটির জন্যbridge_hopsআরও +১ করে বাড়ায় — চূড়ান্ত মান হয় ৪। এটি দেখায় ব্রিজের মোট হপ-সংখ্যা সরাসরি সারিতে থাকা বার্তার সংখ্যার সমানুপাতিক।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরের পাঠ: Flutter — উইজেট ট্রি ও রেন্ডারিং ইঞ্জিন পাঠ ১৮ React Native প্রকৃত নেটিভ উইজেট ব্যবহার করে ব্রিজ/JSI দিয়ে; Flutter সম্পূর্ণ ভিন্ন পথে হাঁটে — নিজস্ব রেন্ডারিং ইঞ্জিন দিয়ে সব নিজে আঁকে।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, UI কম্পোনেন্ট, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট — বাকি পাঠগুলো এই কোর্সেই আছে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks ও Mobile App Development — সব এক জায়গায়।