Expo و Expo Go چیست

What is Expo and Expo Go?

فهرست مطالب

مقدمه (نمای کلی و فنی Expo در اکوسیستم React Native)

Expo چیست و چه مشکلی را حل می‌کند

Expo Go چیست و معماری Runtime آن

نحوه اجرای پروژه با Expo Go (جریان JS Bundle)

Expo CLI و ساختار پروژه

Managed Workflow vs Bare Workflow (تحلیل فنی، مزایا و محدودیت‌ها)

محدودیت‌های Expo Go و مواردی که اجرا نمی‌شوند

EAS Build (Android / iOS) بدون مک + روند build

سناریوهای واقعی استفاده در پروژه‌های Production و MVP

Performance، Debugging و تفاوت با build نهایی

جمع‌بندی فنی و معیار انتخاب Expo

 

1. مقدمه (نمای کلی و فنی Expo در اکوسیستم React Native)

اکوسیستم React Native (RN) همواره بر اساس اصول "Learn Once, Write Anywhere" بنا شده است، اما در عمل، راه‌اندازی محیط توسعه، مدیریت وابستگی‌های نیتیو (Native Dependencies)، و فرآیند Build برای پلتفرم‌های iOS و Android چالش‌های قابل توجهی را برای توسعه‌دهندگان ایجاد کرده است. این چالش‌ها شامل مدیریت Xcode و Android Studio، ناسازگاری بین پکیج‌های RN، و پیچیدگی‌های مربوط به امضای اپلیکیشن‌ها (Signing) می‌شود.

Expo به عنوان یک فریم‌ورک و مجموعه‌ای از ابزارها برای ساده‌سازی و استانداردسازی این فرآیند توسعه ظاهر شده است. Expo در هسته خود، یک لایه انتزاعی (Abstraction Layer) را بر روی React Native ایجاد می‌کند که هدف اصلی آن، کاهش پیچیدگی‌های نیتیو و تمرکز توسعه‌دهنده بر روی کد جاوااسکریپت و React است.

در یک سطح فنی، Expo دو جزء اصلی دارد: Expo SDK که مجموعه‌ای از APIهای نیتیو را به صورت استاندارد و سازگار با نسخه‌های مختلف RN ارائه می‌دهد، و Expo Go که به عنوان یک Runtime Environment عمل می‌کند. این ساختار امکان توسعه سریع (Rapid Prototyping) را فراهم می‌آورد، چرا که نیازی به کامپایل مجدد کد نیتیو برای مشاهده تغییرات کوچک نیست.

Expo به طور فزاینده‌ای در اکوسیستم RN به یک استاندارد "دی فکتو" برای پروژه‌هایی تبدیل شده است که نیاز به بهره‌وری بالا و سازگاری سریع با پلتفرم‌های موبایل دارند، به خصوص در فازهای اولیه توسعه و ساخت MVPها. این راهنما به تشریح جزئیات فنی این اکوسیستم می‌پردازد.

2. Expo چیست و چه مشکلی را حل می‌کند 

Expo در ابتدا به عنوان یک ابزار برای "آزمایش سریع" React Native طراحی شد. اما با تکامل، به یک پلتفرم کامل توسعه تبدیل گردید که دو مشکل اساسی توسعه RN را هدف قرار داده است:

مشکل اول: Fragmentation و پیچیدگی محیط Native
توسعه React Native نیازمند مدیریت دقیق ورژن‌های Swift/Objective-C (iOS) و Java/Kotlin (Android) است. اضافه کردن یک کتابخانه نیتیو جدید اغلب مستلزم دستکاری فایل‌های Podfile (iOS) یا build.gradle (Android) است.

راه حل Expo: Expo با ارائه Managed Workflow، این مسئولیت را از دوش توسعه‌دهنده برمی‌دارد. Expo SDK شامل مجموعه‌ای از ماژول‌های از پیش کامپایل شده و بهینه‌شده است که نیاز به دخالت مستقیم در کد نیتیو را به شدت کاهش می‌دهد. Expo SDK تضمین می‌کند که APIهای مختلف (مانند دوربین، موقعیت‌یابی، نوتیفیکیشن‌ها) در نسخه‌های مختلف RN و سیستم‌عامل‌ها به صورت سازگار عمل کنند.

مشکل دوم: فرآیند تست و استقرار (Deployment)
بدون Expo، هر تغییر در کد جاوااسکریپت یا نیتیو نیازمند یک فرآیند کامپایل کامل (معمولاً زمان‌بر) است تا بتوان نتیجه را بر روی یک دستگاه فیزیکی یا شبیه‌ساز مشاهده کرد.

راه حل Expo: Expo Go به عنوان یک محیط ران‌تایم (Runtime) عمل می‌کند. این اپلیکیشن موبایل، کد جاوااسکریپت شما را از راه دور (از طریق شبکه) دریافت کرده و آن را مستقیماً در ماشین مجازی جاوااسکریپت (JavaScript VM) درون خود اجرا می‌کند. این امر چرخه بازخورد (Feedback Loop) را از چند دقیقه به چند ثانیه کاهش می‌دهد.

از منظر فنی، Expo یک لایه نرم‌افزاری است که بر روی هسته React Native قرار می‌گیرد و از طریق یک سیستم ماژولار (SDK) قابلیت‌های نیتیو را در دسترس قرار می‌دهد. این رویکرد باعث می‌شود که کد RN شما از طریق پکیج‌های سازگار شده با Expo اجرا شود، بدون نیاز به تنظیمات پیچیده Gradle یا CocoaPods در مراحل اولیه توسعه.

3. Expo Go چیست و معماری Runtime آن

Expo Go یک اپلیکیشن موبایل (قابل نصب از App Store و Google Play) است که به عنوان یک میزبان (Host) برای پروژه‌های Expo عمل می‌کند. این اپلیکیشن شامل هسته React Native، یک موتور جاوااسکریپت (مانند Hermes یا JavaScriptCore)، و تمام کتابخانه‌های SDK ارائه شده توسط Expo است.

معماری Runtime Expo Go

معماری Expo Go بر اساس اصل Remote JavaScript Bundling استوار است. جریان کار به شرح زیر است:

  1. Bootstrap: کاربر اپلیکیشن Expo Go را باز می‌کند. این اپلیکیشن با یک Bundle جاوااسکریپت مینیمال اولیه راه‌اندازی می‌شود که شامل منطق بارگذاری پروژه است.
  2. Connection: کاربر با اسکن کردن یک QR کد (یا ورود دستی یک آدرس IP)، دستگاه موبایل خود را به سرور توسعه (که معمولاً توسط expo start اجرا می‌شود) متصل می‌کند.
  3. Metro Bundler: سرور توسعه، از Metro Bundler (پیکربندی شده برای React Native) برای کامپایل کد جاوااسکریپت و تمام وابستگی‌های جاوااسکریپت شما استفاده می‌کند.
  4. Bundle Transmission: این Bundle کامپایل شده به صورت ترنسکشنال (Transactional) از طریق شبکه (HTTP/WebSocket) به اپلیکیشن Expo Go ارسال می‌شود.
  5. Execution: Expo Go کد جاوااسکریپت دریافتی را در JavaScript VM خود اجرا می‌کند. این کد شروع به رندر کردن UI با استفاده از کامپوننت‌های React Native می‌کند.
  6. Native Bridge Interaction: زمانی که کد جاوااسکریپت شما نیاز به دسترسی به قابلیت‌های نیتیو (مانند دوربین یا شتاب‌سنج) دارد، از طریق مکانیزم استاندارد React Native Bridge به ماژول‌های نیتیو درون خود Expo Go متصل می‌شود. از آنجا که Expo Go شامل تمام ماژول‌های استاندارد SDK است، این فراخوانی‌ها با موفقیت انجام می‌شوند.

مزیت فنی: عدم نیاز به کامپایل مجدد Native Code در هر تغییر. تغییرات جاوااسکریپت فوراً با بازتولید Hot Reloading یا Fast Refresh اعمال می‌شوند.

نقطه ضعف: Expo Go یک نسخه "سراسری" از SDK است. اگر پروژه شما از یک ماژول نیتیو سفارشی استفاده کند که بخشی از SDK رسمی Expo نباشد، Expo Go نمی‌تواند آن را لود کند.

4. نحوه اجرای پروژه با Expo Go (جریان JS Bundle)

فرض می‌کنیم پروژه React Native با Expo CLI مقداردهی اولیه شده است (با استفاده از npx create-expo-app).

مراحل فنی:

  1. راه‌اندازی سرور توسعه:

    npx expo start
# یا به صورت ساده: npm start

    این دستور Metro Bundler را راه‌اندازی می‌کند و یک سرور WebSocket برای ارتباط با دستگاه‌ها ایجاد می‌کند. خروجی کنسول شامل یک QR کد است که در برگیرنده URL سرور توسعه شماست (مثلاً exp://192.168.1.10:19000).

  2. اتصال از دستگاه:
    • اطمینان حاصل کنید که دستگاه موبایل و کامپیوتر توسعه‌دهنده در یک شبکه محلی (LAN) قرار دارند.
    • اپلیکیشن Expo Go را روی دستگاه باز کنید.
    • با استفاده از دوربین دستگاه، QR کد نمایش داده شده در ترمینال یا مرورگر (با رفتن به http://localhost:8081) را اسکن کنید.
  3. فرایند بارگذاری (Bundle Loading):
    • Expo Go از طریق WebSocket با سرور توسعه ارتباط برقرار می‌کند.
    • Expo Go درخواست Bundle جاوااسکریپت را ارسال می‌کند.
    • Metro Bundler فایل‌های JS و JSX/TSX پروژه را ترانسپایل کرده و یک Bundle یکپارچه تولید می‌کند.
    • این Bundle از طریق HTTP به Expo Go استریم می‌شود.
  4. اجرای کد:
    • Expo Go Bundle را در JavaScript VM خود اجرا می‌کند.
    • هنگامی که کامپوننتی مانند <Camera /> از expo-camera رندر می‌شود، کد جاوااسکریپت فراخوانی مربوطه را به پل نیتیو ارسال می‌کند.
    • از آنجا که Expo Go شامل کتابخانه‌های نیتیو SDK است، این فراخوانی به ماژول دوربین موجود در اپلیکیشن Go هدایت می‌شود و نتیجه به جاوااسکریپت بازگردانده می‌شود.

نکته در مورد app.json یا app.config.js: پیکربندی‌های مخصوص دستگاه‌های نیتیو (مانند نام اپلیکیشن، آیکون‌ها، یا مجوزها) که در این فایل‌ها تعریف شده‌اند، توسط Expo Go در زمان اجرا خوانده و اعمال می‌شوند، بدون نیاز به بازسازی (Rebuild) اپلیکیشن نیتیو.

5. Expo CLI و ساختار پروژه

Expo CLI ابزار اصلی برای تعامل با اکوسیستم Expo است. این ابزار وظیفه مدیریت پروژه‌ها، راه‌اندازی سرور توسعه، مدیریت پیکربندی‌ها و اجرای فرآیندهای بیلد را بر عهده دارد.

ساختار پایه پروژه (با ):

my-expo-app/
├── .git/
├── node_modules/
├── assets/             # برای تصاویر، فونت‌ها و سایر منابع استاتیک
├── src/                # معمولاً محتوای اصلی برنامه
├── .gitignore
├── App.js (یا App.tsx)  # نقطه ورود برنامه
├── app.json (یا app.config.js) # فایل پیکربندی اصلی Expo
└── package.json        # وابستگی‌ها و اسکریپت‌های npm

فایل پیکربندی اصلی: /

این فایل قلب تنظیمات Expo برای مدیریت اپلیکیشن در پلتفرم‌های مختلف است. ساختار آن معمولاً شامل دو بخش اصلی است: تنظیمات عمومی (expo) و تنظیمات پلتفرم‌های خاص (ios, android).

مثال ساختاری (JSON):

{
  "expo": {
    "name": "My Awesome App",
    "slug": "my-awesome-app",
    "version": "1.0.0",
    "orientation": "portrait",
    "icon": "./assets/icon.png",
    "userInterfaceStyle": "light",
    "assetBundlePatterns": [
      "./assets/**"
    ],
    "ios": {
      "supportsTablet": true,
      "bundleIdentifier": "com.mycompany.myapp"
    },
    "android": {
      "adaptiveIcon": {
        "foregroundImage": "./assets/adaptive-icon.png",
        "backgroundColor": "#FFFFFF"
      },
      "package": "com.mycompany.myapp"
    }
  }
}

نقش فنی: هنگامی که از EAS Build استفاده می‌شود، این فایل به عنوان ورودی اصلی برای تولید مانیفست‌های نیتیو (مانند Info.plist در iOS و AndroidManifest.xml در Android) استفاده می‌شود. همچنین، برای پروژه‌هایی که از Development Builds استفاده می‌کنند، این فایل تعیین می‌کند که کدام ماژول‌های سفارشی باید در Bundle ران‌تایم گنجانده شوند.

6. Managed Workflow vs Bare Workflow (تحلیل فنی، مزایا و محدودیت‌ها)

Expo دو شیوه اصلی توسعه را ارائه می‌دهد که بر میزان کنترل توسعه‌دهنده بر محیط Native تأثیر می‌گذارد.

6.1. Managed Workflow

در این شیوه، Expo تمام پیچیدگی‌های مدیریت پروژه‌های نیتیو را بر عهده می‌گیرد.

ویژگی‌های فنی:

  1. وابستگی محدود: شما فقط می‌توانید از کتابخانه‌هایی استفاده کنید که بخشی از Expo SDK هستند یا توسط Expo سازگار شده‌اند (Managed Packages).
  2. بدون Eject: شما هرگز مستقیماً فایل‌های android/ یا ios/ را ویرایش نمی‌کنید.
  3. Build از طریق EAS: کامپایل نهایی پروژه (شامل کد نیتیو) تنها از طریق سرویس‌های ابری EAS امکان‌پذیر است.

مزایا:

  • سرعت توسعه: راه‌اندازی سریع، بدون نیاز به نصب Android Studio یا Xcode برای شروع.
  • پایداری (Stability): Expo تضمین می‌کند که وابستگی‌های SDK با یکدیگر ناسازگار نباشند.
  • بروزرسانی آسان: به‌روزرسانی SDK (مثلاً از SDK 49 به 50) اغلب با اجرای یک دستور ساده (expo upgrade) انجام می‌شود.

محدودیت‌ها:

  • عدم انعطاف‌پذیری: اگر به یک کتابخانه نیتیو بسیار خاص (مثلاً یک SDK پرداخت بسیار جدید) نیاز دارید که در SDK Expo موجود نیست، نمی‌توانید آن را اضافه کنید.

6.2. Bare Workflow (یا Ejected Workflow)

این شیوه به توسعه‌دهنده کنترل کامل بر روی ساختار Native پروژه را می‌دهد.

ویژگی‌های فنی:

  1. ایجاد دایرکتوری‌های نیتیو: با دستوراتی مانند npx expo prebuild (یا expo eject در نسخه‌های قدیمی‌تر)، دایرکتوری‌های ios/ و android/ تولید می‌شوند.
  2. استفاده از Native Modules دلخواه: توسعه‌دهنده می‌تواند مستقیماً پکیج‌های NPM که نیازمند لینک‌دهی Native هستند (مانند react-native-webview یا Firebase SDK) را نصب کند و آن‌ها را در Xcode/Android Studio مدیریت نماید.
  3. Build محلی ممکن است: از آنجا که ساختار نیتیو وجود دارد، توسعه‌دهنده می‌تواند با استفاده از ابزارهای محلی (Android Studio/Xcode) بیلد را انجام دهد، هرچند استفاده از EAS Build همچنان برای سادگی توصیه می‌شود.

مزایا:

  • انعطاف‌پذیری کامل: دسترسی کامل به هر کتابخانه React Native و هر ماژول Native.
  • مالکیت کد: کد نیتیو پروژه تحت کنترل مستقیم توسعه‌دهنده است.

محدودیت‌ها:

  • پیچیدگی: چالش‌های سنتی React Native (مدیریت Pods، Gradle، تداخل ورژن‌ها) باز می‌گردند.
  • بروزرسانی سخت‌تر: ارتقاء به SDK جدید نیازمند همگام‌سازی دستی تغییرات Expo SDK با فایل‌های Native پروژه است.

انتخاب استراتژیک:

اکثر پروژه‌های جدید با Managed Workflow شروع می‌شوند. اگر نیاز به ماژول‌های غیر-Expo پیدا شود، پروژه به Bare Workflow مهاجرت می‌کند (یا از Development Builds در Managed Workflow استفاده می‌کند که یک راه حل میانی است).

7. محدودیت‌های Expo Go و مواردی که اجرا نمی‌شوند

Expo Go یک محیط ران‌تایم بسیار قدرتمند است، اما محدودیت‌هایی دارد که ناشی از ماهیت توزیع آن از طریق فروشگاه‌های اپلیکیشن است.

7.1. محدودیت‌های Runtime

Expo Go صرفاً می‌تواند کدهای جاوااسکریپت را اجرا کند و به ماژول‌هایی دسترسی دارد که در Bundle اپلیکیشن Go از پیش کامپایل شده‌اند (ماژول‌های Expo SDK).

مواردی که اجرا نمی‌شوند (در Expo Go استاندارد):

  1. Native Modules سفارشی (Custom Native Modules): اگر پکیجی نصب کنید که در فایل package.json نیاز به لینک‌دهی Native داشته باشد (مثلاً react-native-maps در گذشته یا هر پکیج اختصاصی)، Expo Go نمی‌تواند آن را بارگذاری کند، زیرا کد نیتیو مربوطه در اپلیکیشن Go شما وجود ندارد.
  2. فایل‌های پیکربندی نیتیو سفارشی: تنظیماتی که نیاز به تغییر در Info.plist یا AndroidManifest.xml برای زمان بیلد دارند (مانند Intent Filters خاص، سرویس‌های پس‌زمینه پیچیده) قابل اعمال نیستند، مگر اینکه از طریق ابزارهای Expo (مانند EAS Config Plugin) تعریف شوند.
  3. کد نیتیو سفارشی: شما نمی‌توانید فایل‌های Swift، Kotlin، Java یا Objective-C جدیدی به پروژه اضافه کنید و آن‌ها را از جاوااسکریپت فراخوانی کنید (مگر اینکه پروژه در Bare Workflow باشد).

7.2. راه حل‌ها: Development Builds و EAS

برای غلبه بر محدودیت‌های Expo Go، اکوسیستم Expo راهکار Development Builds را از طریق EAS Build معرفی کرده است.

  • Development Build: با استفاده از EAS Build، شما یک نسخه اپلیکیشن سفارشی (Custom Client) می‌سازید که شامل تمام ماژول‌های SDK استاندارد به علاوه هر کتابخانه نیتیو سفارشی که شما در پروژه خود اضافه کرده‌اید، است.
  • این اپلیکیشن سفارشی (که می‌توانید آن را به صورت TestFlight یا در Google Play Internal Testing توزیع کنید) می‌تواند کد جاوااسکریپت شما را از طریق Metro Bundler دریافت کرده و به تمام Native Modules تعریف شده دسترسی داشته باشد. این عملاً مرز بین Managed و Bare Workflow را در زمان توسعه و تست مبهم می‌کند.

8. EAS Build (Android / iOS) بدون مک + روند build

EAS (Expo Application Services) Build سرویس کامپایل ابری Expo است که فرآیند بیلد را از محیط محلی شما به سرورهای ابری منتقل می‌کند. این امر به ویژه برای توسعه‌دهندگان ویندوز یا لینوکس که دسترسی مستقیم به Xcode (مورد نیاز برای بیلد iOS) ندارند، حیاتی است.

8.1. معماری EAS Build

EAS Build از یک ماشین مجازی مبتنی بر کانتینر استفاده می‌کند که بر اساس نیاز، محیط‌های کاملاً آماده‌ای از Xcode (برای iOS) و Android SDK (برای Android) را فراهم می‌آورد.

  1. پیکربندی: فایل app.json یا eas.json (برای تنظیمات خاص بیلد) به عنوان ورودی استفاده می‌شود.
  2. ارسال کد: توسعه‌دهنده دستور eas build را اجرا می‌کند. کد منبع، فایل‌های پیکربندی و وابستگی‌ها به سرورهای EAS آپلود می‌شوند.
  3. ایجاد محیط: سرور EAS یک محیط ایزوله (معمولاً بر اساس Docker) آماده می‌کند. برای iOS، این محیط شامل macOS است.
  4. اجرای Prebuild (در صورت نیاز): اگر پروژه در Bare Workflow باشد یا از Development Build استفاده شود، EAS مراحل prebuild را شبیه‌سازی می‌کند تا ساختار Native آماده شود.
  5. کامپایل:
    • iOS: Xcode برای تولید .ipa با استفاده از فرآیندهای Provisioning Profile و Certificate مدیریت شده توسط EAS (یا شما) اجرا می‌شود.
    • Android: Gradle برای تولید .aab (یا .apk) اجرا می‌شود.
  6. توزیع/دانلود: پس از موفقیت آمیز بودن بیلد، فایل خروجی (IPA/AAB) برای دانلود در دسترس قرار می‌گیرد و می‌تواند مستقیماً به App Store Connect یا Google Play Console آپلود شود.

8.2. روند بیلد برای iOS بدون مک (The "No-Mac" Flow)

  1. تنظیم حساب اپل: شما باید یک حساب توسعه‌دهنده اپل فعال داشته باشید.
  2. مدیریت Credentials: از طریق EAS CLI و سرویس EAS، گواهی‌ها (Certificates) و پروفایل‌های Provisioning را آپلود و مدیریت می‌کنید (eas credentials). EAS این اطلاعات را به صورت امن در فضای ابری خود ذخیره می‌کند.

  3. اجرای بیلد:

    eas build --platform ios --profile production

    EAS Build این فرآیند را به صورت کاملاً خودکار روی ماشین‌های مکِ خود انجام می‌دهد و در نهایت فایل .ipa را ارائه می‌کند.

مزیت فنی کلیدی: این فرآیند وابستگی توسعه‌دهنده به حفظ و نگهداری محیط‌های پیچیده Xcode و مدیریت کلیدهای محلی را از بین می‌برد.

9. سناریوهای واقعی استفاده در پروژه‌های Production و MVP

انتخاب Expo به شدت به فاز توسعه و نیازهای فنی محصول وابسته است.

9.1. فاز MVP و نمونه‌سازی سریع (Prototyping)

Expo در این فاز، بهترین عملکرد را دارد و تقریباً یک استاندارد است.

  • استفاده از Expo Go: با استفاده از Managed Workflow و Expo Go، یک تیم کوچک می‌تواند در عرض چند ساعت یک اپلیکیشن کاملاً کارآمد با دسترسی به دوربین، سنسورها و موقعیت‌یابی را بر روی دستگاه‌های تسته‌کنندگان (Testers) اجرا کند.
  • سرعت تکرار: زمان کوتاه بازخورد توسعه (Hot Reloading) به تیم این امکان را می‌دهد که طرح‌های UI و منطق کسب و کار را به سرعت اعتبارسنجی کنند.
  • تست‌های داخلی: استفاده از Development Builds با EAS به تیم اجازه می‌دهد تا اپلیکیشن را با تمام قابلیت‌های نیتیو (که با استفاده از EAS Config Pluginها تنظیم شده‌اند) بدون نیاز به بیلد محلی، تست کنند.

9.2. پروژه‌های Production (Managed Workflow با EAS)

بسیاری از اپلیکیشن‌های تجاری بزرگ امروزی از Expo در Managed Workflow استفاده می‌کنند و تنها زمانی که نیازهای نیتیو فراتر از SDK باشد، به Bare Workflow روی می‌آورند.

  • مثال: یک اپلیکیشن تجارت الکترونیک با استفاده از Expo SDK برای مدیریت UI، پیمایش، و APIهای استاندارد (مانند مدیریت وضعیت اپلیکیشن، ذخیره‌سازی محلی) توسعه می‌یابد.
  • استفاده از EAS Build Production: برای استقرار نهایی، بیلدها از طریق EAS انجام می‌شوند. اگر پروژه در Managed Workflow بماند، وابستگی‌های Native کاملاً توسط Expo مدیریت شده و تست شده‌اند.
  • Config Plugins: اگر نیاز به افزودن Firebase SDK باشد، توسعه‌دهنده یک Config Plugin می‌نویسد که در زمان بیلد EAS، تغییرات لازم را در AndroidManifest.xml و Info.plist اعمال می‌کند. این به ما اجازه می‌دهد تا انعطاف‌پذیری Bare Workflow را با پایداری Managed Workflow ترکیب کنیم.

9.3. پروژه‌های Production (Bare Workflow)

زمانی که نیاز به ادغام عمیق با سیستم‌عامل یا استفاده از Native Modules بسیار قدیمی/خاص باشد، Bare Workflow ضروری است.

  • مثال: یک اپلیکیشن مالی که نیاز به یک کتابخانه امنیتی سطح پایین (Low-Level Security Library) دارد که نیاز به دسترسی مستقیم به چارچوب‌های امنیتی iOS/Android دارد که در SDK Expo پوشش داده نشده‌اند.
  • نقش Expo: حتی در Bare Workflow، توسعه‌دهنده همچنان از ابزارهایی مانند Expo CLI برای مدیریت وابستگی‌ها، مدیریت پیکربندی‌ها (از طریق app.config.js) و استفاده از EAS Build برای فرآیند بیلد استفاده می‌کند. Expo در این سناریو به عنوان یک "لایه مدیریت پروژه نیتیو پیشرفته" عمل می‌کند.

10. Performance، Debugging و تفاوت با build نهایی

تفاوت عملکرد و دیباگینگ بین محیط Expo Go و یک اپلیکیشن نیتیو بیلد شده نهایی (Production Build) یک ملاحظه فنی مهم است.

10.1. Performance در Expo Go

اجرای کد در Expo Go تحت تأثیر دو عامل اصلی قرار می‌گیرد:

  1. شبکه (Network Latency): از آنجا که JS Bundle از طریق شبکه به دستگاه استریم می‌شود، زمان بارگذاری اولیه (Initial Load Time) در Expo Go کمی طولانی‌تر از بیلد نهایی است، به خصوص اگر دستگاه در شبکه کندی باشد.
  2. JavaScript VM Overhead: Expo Go شامل کدهای اضافی برای مدیریت ارتباط با سرور توسعه، مدیریت QR کد و اجرای پل‌های مختلف است که در بیلد نهایی حذف می‌شوند.
  3. JavaScriptCore در مقابل Hermes: در برخی دستگاه‌ها، Expo Go ممکن است از JavaScriptCore به عنوان موتور جاوااسکریپت استفاده کند (مگر اینکه صریحاً Hermes فعال شده باشد). Hermes (که موتور پیش‌فرض در بیلد نهایی است) به طور کلی برای زمان بوت شدن سریع‌تر و مصرف حافظه کمتر در دستگاه‌های اندرویدی بهینه‌سازی شده است.

10.2. Debugging

دیباگینگ در Expo Go بسیار منعطف است:

  • Remote Debugging: با استفاده از گزینه‌های منوی توسعه‌دهنده در Expo Go، می‌توانید اپلیکیشن را مستقیماً با Chrome Developer Tools متصل کنید. این به شما اجازه می‌دهد Breakpoints بگذارید، متغیرها را بازرسی کنید و دستورات کنسول را اجرا کنید.
  • React DevTools: دسترسی آسان به پروفایلینگ و بازرسی درخت کامپوننت‌ها.

10.3. تفاوت با Build نهایی

بیلد نهایی (که از طریق EAS یا به صورت محلی ساخته شده) از نظر فنی بسیار بهینه‌ تر است:

  1. Bundling Statically: کد جاوااسکریپت برای بیلد نهایی به صورت ایستا (Statically) در Bundle نهایی (مانند index.android.bundle یا main.jsbundle) کامپایل و ذخیره می‌شود. هیچ ارتباط شبکه‌ای برای دریافت کد وجود ندارد.
  2. حذف کد توسعه: تمام کدهای مربوط به Hot Reloading، Debugging، و ابزارهای توسعه‌دهنده (مانند if (__DEV__) بلوک‌ها) در بیلد پروداکشن حذف می‌شوند (Tree Shaking و Minification).
  3. استفاده از Hermes (Production): برای بیلد نهایی معمولاً از Hermes استفاده میکنند که کامپایل AOT (Ahead-Of-Time) کد جاوااسکریپت را برای بهبود عملکرد اجرا می‌کند.
  4. ماژول‌های نیتیو: بیلد نهایی شامل تمام Native Modules لینک شده است، در حالی که Expo Go فقط شامل ماژول‌های SDK از پیش کامپایل شده است.

بنابراین، Performance در بیلد نهایی همیشه بهتر از محیط Expo Go است، زیرا محیط Expo Go شامل سربار (Overhead) زیادی برای تسهیل توسعه سریع است.

11. جمع‌بندی فنی و معیار انتخاب Expo

Expo یک پلتفرم است که با هدف بهینه‌سازی چرخه توسعه React Native، به خصوص در زمینه مدیریت وابستگی‌های نیتیو و استقرار، طراحی شده است.

معیار فنی انتخاب Managed Workflow (Expo Go + EAS) و Bare Workflow (یا React Native خالص):

از نظر سرعت توسعه اولیه،

Managed Workflow انتخاب بسیار سریعی است چون هیچ نیازی به تنظیمات نیتیو، Android Studio یا Xcode ندارد و توسعه‌دهنده می‌تواند بلافاصله کدنویسی را شروع کند.

در مقابل، Bare Workflow سرعت اولیه پایین‌تری دارد چون نیازمند نصب ابزارهای نیتیو، تنظیم Environment و پیکربندی اولیه پروژه است.

از نظر نیاز به Native Modules غیر استاندارد،

در Managed Workflow این نیاز پایین است و فقط از طریق Config Plugins یا Development Build قابل مدیریت است.

اما در Bare Workflow کنترل کامل روی Native Code وجود دارد و امکان استفاده از هر SDK یا ماژول بومی بدون محدودیت فراهم است.

از نظر پیچیدگی نگهداری پروژه،

Managed Workflow پیچیدگی کمتری دارد چون Expo مسئول مدیریت SDK، وابستگی‌ها و هماهنگی نسخه‌هاست.

در Bare Workflow نگهداری پیچیده‌تر است و توسعه‌دهنده باید Pods، Gradle و تداخل نسخه‌ها را به‌صورت دستی مدیریت کند.

از نظر زمان بازخورد (Feedback Loop)،

Managed Workflow بسیار سریع است؛ تغییرات بدون بیلد مجدد و مستقیماً با Expo Go دیده می‌شوند.

در Bare Workflow بازخورد کندتر است، چون هر تغییر نیتیو نیازمند بیلد مجدد اپلیکیشن است.

از نظر پشتیبانی از چند پلتفرم،

Managed Workflow عملکرد عالی دارد و قابلیت‌های SDK به‌صورت خودکار بین iOS و Android همگام می‌شوند.

در Bare Workflow تضمین سازگاری بین پلتفرم‌ها نیازمند پیاده‌سازی و بررسی دستی است.

 

نتیجه‌گیری:

Expo با استفاده از Managed Workflow و ابزارهای EAS Build، یک ابزار مهندسی قوی برای اکثر پروژه‌های React Native (به ویژه MVP ها و اپلیکیشن‌ های کسب و کار، استاندارد) فراهم می‌کند. این ابزار پیچیدگی‌ های نیتیو را انتزاعی می‌کند و توسعه‌ دهنده را به سمت کد جاوااسکریپت سوق می‌دهد.

اگر تیم توسعه شما نیازی به کتابخانه‌ های سطح پایین یا دستکاری‌ های عمیق در Native Code ندارد، استفاده از Expo Go برای توسعه و EAS Build برای استقرار، بهینه‌ترین مسیر فنی موجود در اکوسیستم React Native است. اگر محدودیت‌های Managed Workflow مانع این کار شد، انتقال به Bare Workflow (با حفظ EAS برای بیلد) انعطاف‌پذیری کامل را تضمین می‌کند.