নেটিভ বনাম ক্রস-প্ল্যাটফর্ম বনাম হাইব্রিড — একটি আর্কিটেকচার ম্যাপ
এই পাঠে যা শিখবেন
- নেটিভ, ক্রস-প্ল্যাটফর্ম ও হাইব্রিড অ্যাপ্রোচের সংজ্ঞা এবং প্রতিটির আর্কিটেকচার কেমন দেখতে
- প্রতিটি অ্যাপ্রোচে ভাষা/SDK, পারফরম্যান্স, ডিভাইস API অ্যাক্সেস ও কোডবেস সংখ্যার তুলনা
- একটি ফিচারের জন্য প্রতিটি অ্যাপ্রোচে বাস্তবে কত কোড শেয়ার হয় তা গাণিতিকভাবে যাচাই করা
- কেন "সবচেয়ে বেশি কোড শেয়ারিং" মানেই "সেরা পছন্দ" নয়
১ · তিনটি আর্কিটেকচারাল অ্যাপ্রোচ
একটি মোবাইল ফিচার — ধরা যাক, ক্যামেরা দিয়ে প্রোফাইল ছবি তুলে আপলোড করার ফিচার — তৈরি করার সময় প্রথম সিদ্ধান্তই হলো: কোন আর্কিটেকচারাল অ্যাপ্রোচে এটি বানানো হবে। তিনটি প্রধান রাস্তা আছে:
প্রতিটি প্ল্যাটফর্মের নিজস্ব ভাষা ও SDK ব্যবহার করে সম্পূর্ণ আলাদা কোডবেস — সর্বোচ্চ পারফরম্যান্স ও সম্পূর্ণ ডিভাইস API অ্যাক্সেস, কিন্তু দুইবার (বা ততোধিক) কাজ।
একটি শেয়ার্ড কোডবেস যা কম্পাইল/ব্রিজের মাধ্যমে নেটিভ ভিউয়ে রূপান্তরিত হয় — বেশিরভাগ কোড শেয়ার্ড, কিছু ফিচারের জন্য ছোট নেটিভ ব্রিজ মডিউল লাগে।
একটি ওয়েব কোডবেস একটি নেটিভ শেলের ভেতরে WebView-তে wrap করা — সবচেয়ে বেশি কোড শেয়ারিং, কিন্তু সবচেয়ে দুর্বল ও সবচেয়ে কম পারফরম্যান্সের ডিভাইস API অ্যাক্সেস।
২ · তুলনা টেবিল
নিচের টেবিলে তিনটি অ্যাপ্রোচের সুপরিচিত, ব্যাপকভাবে-স্বীকৃত বৈশিষ্ট্য তুলে ধরা হয়েছে — এখানে কোনো নির্দিষ্ট ফ্রেমওয়ার্ক API সিনট্যাক্স দাবি করা হয়নি, শুধু আর্কিটেকচারাল বৈশিষ্ট্য।
| অ্যাপ্রোচ | ভাষা/SDK | পারফরম্যান্স | ডিভাইস API অ্যাক্সেস | কোডবেস সংখ্যা |
|---|---|---|---|---|
| নেটিভ | Swift/UIKit/SwiftUI (iOS), Kotlin/Jetpack Compose (Android) | সর্বোচ্চ — প্ল্যাটফর্ম-অপটিমাইজড | সরাসরি, সম্পূর্ণ | প্রতি প্ল্যাটফর্মে আলাদা (২টি বা বেশি) |
| ক্রস-প্ল্যাটফর্ম | JavaScript/TypeScript (React Native), Dart (Flutter) | নেটিভের কাছাকাছি — bridge/compile করা | bridge/plugin দিয়ে প্রায়-সম্পূর্ণ | একটি শেয়ার্ড + ছোট নেটিভ মডিউল |
| হাইব্রিড | HTML/CSS/JS (WebView-তে wrap করা) | সবচেয়ে কম — WebView লেয়ারের ওভারহেড | WebView plugin API দিয়ে সীমিত | একটি শেয়ার্ড ওয়েব কোডবেস |
৩ · একটি ফিচারের প্ল্যাটফর্ম-নির্দিষ্ট কোড খরচ হিসাব
উপরের টেবিলটি স্থির বিবরণ — নিচের কোড সেলে একই তুলনা গণনা করে দেখা যাক। ধরা যাক ফিচারটি হলো "ক্যামেরা দিয়ে প্রোফাইল ছবি আপলোড করা", এবং আমরা iOS ও Android — এই দুটি প্ল্যাটফর্মের জন্য এটি তৈরি করছি। প্রতিটি অ্যাপ্রোচে বাস্তবে কত লাইন প্ল্যাটফর্ম-নির্দিষ্ট কোড লাগে এবং কত শতাংশ কোড শেয়ার্ড থাকে তা হিসাব করা হয়েছে।
# ফিচার: "ক্যামেরা দিয়ে প্রোফাইল ছবি আপলোড" -- তিনটি অ্যাপ্রোচে কোড খরচ হিসাব
# এটি সত্যিকারের Python হিসাব -- হার্ডকোড করা আউটপুট নয়
PLATFORMS = ["iOS", "Android"]
def native_cost(platforms, per_platform_lines):
# প্রতিটি প্ল্যাটফর্মের জন্য সম্পূর্ণ আলাদা ইমপ্লিমেন্টেশন -- ০% শেয়ার্ড
breakdown = {p: per_platform_lines for p in platforms}
total = sum(breakdown.values())
shared_pct = 0.0
codebases = len(platforms) # প্রতিটি প্ল্যাটফর্মে আলাদা কোডবেস বজায় রাখতে হয়
return breakdown, total, shared_pct, codebases
def cross_platform_cost(platforms, shared_lines, bridge_lines_per_platform):
# শেয়ার্ড কোড + প্রতি প্ল্যাটফর্মে ছোট নেটিভ ব্রিজ মডিউল (যেমন ক্যামেরা অ্যাক্সেস)
breakdown = {p: bridge_lines_per_platform for p in platforms}
total = shared_lines + sum(breakdown.values())
shared_pct = round(shared_lines / total * 100, 1)
codebases = 1
return breakdown, total, shared_pct, codebases
def hybrid_cost(platforms, shared_web_lines):
# কোনো নেটিভ কোড লাগে না -- একটিই ওয়েব কোডবেস দুই প্ল্যাটফর্মেই WebView-তে চলে
breakdown = {p: 0 for p in platforms}
total = shared_web_lines
shared_pct = 100.0
codebases = 1
return breakdown, total, shared_pct, codebases
native_b, native_t, native_s, native_c = native_cost(PLATFORMS, 220)
cross_b, cross_t, cross_s, cross_c = cross_platform_cost(PLATFORMS, 300, 40)
hybrid_b, hybrid_t, hybrid_s, hybrid_c = hybrid_cost(PLATFORMS, 260)
rows = [
("নেটিভ", native_b, native_t, native_s, native_c),
("ক্রস-প্ল্যাটফর্ম", cross_b, cross_t, cross_s, cross_c),
("হাইব্রিড", hybrid_b, hybrid_t, hybrid_s, hybrid_c),
]
print(f"{'অ্যাপ্রোচ':16s} | {'iOS লাইন':9s} | {'Android লাইন':13s} | {'মোট লাইন':9s} | শেয়ার্ড % | কোডবেস")
for name, breakdown, total, shared_pct, codebases in rows:
print(f"{name:16s} | {breakdown['iOS']:9d} | {breakdown['Android']:13d} | {total:9d} | {shared_pct:8.1f}% | {codebases}")
ranked = sorted(rows, key=lambda r: r[3], reverse=True)
print("\nশেয়ার্ড % অনুযায়ী ক্রম (সর্বোচ্চ প্রথমে):")
for name, breakdown, total, shared_pct, codebases in ranked:
print(f" {name}: {shared_pct:.1f}% শেয়ার্ড, {codebases}টি কোডবেস বজায় রাখতে হয়")
440 লাইন মোট (২২০+২২০), 0% শেয়ার্ড, 2টি কোডবেস।
ক্রস-প্ল্যাটফর্মে 380 লাইন মোট (৩০০ শেয়ার্ড + ৪০+৪০ ব্রিজ), ৭৮.৯% শেয়ার্ড,
1টি কোডবেস। হাইব্রিডে 260 লাইন মোট, 100% শেয়ার্ড, 1টি
কোডবেস — কিন্তু মনে রাখবেন, এই হিসাবে "ডিভাইস অ্যাক্সেসের গভীরতা" ধরা হয়নি, শুধু কোড-শেয়ারিং।
হাইব্রিড অ্যাপ্রোচে কোড শেয়ারিং সবচেয়ে বেশি হলেও এটি স্বয়ংক্রিয়ভাবে "সেরা" পছন্দ নয় — কারণ কোড শেয়ারিং শুধু একটি মাত্রা; ডিভাইস API অ্যাক্সেসের গভীরতা ও পারফরম্যান্স আরেকটি মাত্রা, যেখানে হাইব্রিড সবচেয়ে দুর্বল। সঠিক অ্যাপ্রোচ বেছে নেওয়া মানে এই ট্রেড-অফগুলো প্রকল্পের নির্দিষ্ট চাহিদার সাথে মিলিয়ে দেখা — পরবর্তী পাঠে (L03) আমরা PWA-কে চতুর্থ অপশন হিসেবে যোগ করে এই তুলনাকে আরও বিস্তৃত করব।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ ক্রস-প্ল্যাটফর্ম অ্যাপ্রোচে ছোট নেটিভ ব্রিজ মডিউল কেন লাগে — সম্পূর্ণ ০ নেটিভ কোড কেন সম্ভব নয়?
ক্যামেরা, GPS, বায়োমেট্রিক সেন্সরের মতো কিছু ফিচারের জন্য মাঝে মাঝে এমন প্ল্যাটফর্ম API দরকার হয় যা
ক্রস-প্ল্যাটফর্ম ফ্রেমওয়ার্ক নিজে থেকে কভার করে না, বা করলেও প্ল্যাটফর্ম-নির্দিষ্ট আচরণ ঠিক করতে ছোট
নেটিভ মডিউল লেখা লাগে। এ কারণেই কোড সেলে cross_platform_cost-এ
bridge_lines_per_platform সম্পূর্ণ ০ না রেখে একটি ছোট ধনাত্মক সংখ্যা রাখা হয়েছে।
প্র ০২ হাইব্রিড অ্যাপ্রোচে কোড শেয়ারিং আমাদের হিসাবে ১০০% — তাহলে এটি কেন সবসময় সেরা পছন্দ নয়?
কারণ কোড শেয়ারিং শুধু একটি মাত্রা। হাইব্রিড অ্যাপ WebView-এর ভেতর দিয়ে চলে বলে ডিভাইস API অ্যাক্সেস সবচেয়ে সীমিত এবং পারফরম্যান্স সবচেয়ে কম — একটি অ্যাপের কোন মাত্রাটি বেশি গুরুত্বপূর্ণ তার ওপর নির্ভর করে সিদ্ধান্ত নিতে হয়, শুধু কোড-শেয়ারিং সংখ্যা দেখে নয়।
প্র ০৩
কোড সেলে native_cost-এ shared_pct সরাসরি 0.0 লেখা, কিন্তু বাকি
দুটোতে ভাগ করে হিসাব করা হয়েছে — কেন?
নেটিভ অ্যাপ্রোচের সংজ্ঞা অনুযায়ীই প্রতিটি প্ল্যাটফর্মের কোড সম্পূর্ণ আলাদা — তাই গাণিতিকভাবে শেয়ারিং
সবসময় ঠিক ০, এটি ইনপুটের ওপর নির্ভর করে না। কিন্তু ক্রস-প্ল্যাটফর্ম ও হাইব্রিডে শেয়ার্ড লাইনের সংখ্যা
পরিবর্তিত হতে পারে, তাই shared_lines / total দিয়ে সত্যিকারের হিসাব করা হয়েছে।
অনুশীলন
-
চিন্তা করুন: মনে করুন আপনার টিমের সবার JavaScript/React অভিজ্ঞতা আছে, কিন্তু কারো
Swift বা Kotlin অভিজ্ঞতা নেই। কোন অ্যাপ্রোচ প্রাথমিকভাবে বেশি ব্যবহারিক মনে হয়, এবং কেন?
ক্রস-প্ল্যাটফর্ম (বিশেষত React Native) বেশি ব্যবহারিক মনে হয়, কারণ এটি টিমের বিদ্যমান JavaScript দক্ষতা পুনরায় ব্যবহার করতে দেয়। নেটিভ অ্যাপ্রোচে টিমকে দুটি সম্পূর্ণ নতুন ভাষা (Swift ও Kotlin) শিখতে হতো এবং দুটি আলাদা কোডবেস বজায় রাখতে হতো — সময় ও খরচ দুটোই বাড়ে।
-
পরীক্ষা করুন: উপরের কোড সেলে
cross_platform_cost(PLATFORMS, 300, 40)কলেbridge_lines_per_platformমান40থেকে100-এ পরিবর্তন করে দেখুনtotalওshared_pctকীভাবে বদলায়।নতুন
breakdownহবে{'iOS': 100, 'Android': 100}, তাইtotal = 300 + 100 + 100 = 500।shared_pct = round(300 / 500 * 100, 1) = 60.0— অর্থাৎ প্রতি প্ল্যাটফর্মে বেশি নেটিভ ব্রিজ কোড লাগলে শেয়ার্ড শতাংশ কমে যায়, ঠিক যেমন বাস্তবে জটিল ডিভাইস-ইন্টিগ্রেশন ফিচার বেশি হলে ক্রস-প্ল্যাটফর্ম অ্যাপেও নেটিভ কোডের ভাগ বেড়ে যায়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ অ্যাপ লাইফসাইকেল, মোবাইল UI/UX, MVVM/MVI আর্কিটেকচার, নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- Full-Stack Web Frameworks কোর্স সহোদর কোর্স MVC/MVVM, স্টেট ম্যানেজমেন্ট, টেস্টিং ও CI/CD-র সাধারণ আর্কিটেকচারাল ভিত্তি সেই কোর্সেই তৈরি হয়েছে — এই কোর্স মোবাইল-নির্দিষ্ট পার্থক্য শেখায়।
- সব 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 — সব এক জায়গায়।