Uber Eats پشتهٔ فید اصلی را از معماری نیتیو سنتی به یک WebView تک‌صفحه‌ای هدایت‌شده توسط لایهٔ نیتیو منتقل کرد تا سرعت انتشار تغییرات، کنترل پیکربندی و توانایی آزمایش را افزایش دهد، بدون اینکه روانی و کیفیت تجربهٔ کاربری قربانی شود.

نیازمندی‌ها و انگیزه‌ها

تیم مهندسی با چالش‌هایی روبه‌رو بود که برای بسیاری از اپلیکیشن‌های بزرگ آشناست: چرخهٔ طولانی انتشار باینری در اپ استور و گوگل‌پلی، دشواری آزمایش سریع و نیاز به مدیریت حجم بالایی از متریک‌ها برای قیف خرید. هدف تعیین‌کننده، کسب کنترل بیشتر روی انتشار و پیکربندی تجربهٔ کاربر بود، در حالی که انتقال‌ها و انیمیشن‌های نیتیو حفظ می‌شد.

معماری انتخابی: شِل نیتیو + SPA در WebView

رویکرد تیم مبتنی بر قرار دادن یک شِل نیتیو بود که یک اپلیکیشن تک‌صفحه‌ای (SPA) را داخل WebView بارگذاری می‌کند. اجزای اصلی:

  • لایهٔ نیتیو: مدیریت چرخهٔ حیات، مجوزها، نوتیفیکیشن و SDKهای حساس؛ ارائهٔ توکن‌های امن و مدیریت حافظه.
  • SPA داخل WebView: پیاده‌سازی مسیرها، حالت و بخش عمدهٔ رابط کاربری که با جاوااسکریپت کنترل می‌شود.
  • پل JS–نیتیو (bridge): فراخوانی توابع سیستم، ارسال رویدادهای آنالیتیکس و مسیریابی عمیق به صورت امن.

برای مراجعه و تعاریف فنی می‌توان به منابع مرجع دربارهٔ WebView و Single-page application مراجعه کرد.

پشتهٔ فنی و اجزای کلیدی

  • شِل نیتیو: بارگذاری WebView، مدیریت کش سیستمی و توزیع امن توکن‌ها.
  • باندل جاوااسکریپت: نسخه‌بندی‌شده و از طریق CDN سرویس‌دهی می‌شود تا نیاز به انتشار باینری کاهش یابد.
  • سیستم مسیریابی و حفظ وضعیت: برای حصول روانی تجربهٔ کاربر بین صفحات فید و صفحهٔ فروشگاه پیاده‌سازی شد.
  • آنالیتیکس و انتساب رویدادها: هم‌ترازی دقیق رویدادهای نیتیو و وب برای تحلیل قیف و A/B تست.
  • فیچر فلگ و rollout تدریجی: امکان انتشار مرحله‌ای، بازگشت سریع و آزمایش در مقیاس بالا.

نمونهٔ تصویری از پیاده‌سازی

ساختار رابط و جریان داده‌ها بین لایه‌ها در یکی از تصاویر تیم نمایش داده شده است:

معماری WebView تک‌صفحه‌ای هدایت‌شده توسط نیتیو در Uber Eats

چالش‌ها و مشکلات مقیاس

در اجرای واقعی و در مقیاس بالا، با موارد زیر مواجه شدند:

  • رعایت قوانین فروشگاه‌های اپ: شفاف‌سازی نقش شِل نیتیو و اطمینان از اینکه قابلیت‌های هسته‌ای در باینری مدیریت می‌شوند.
  • حفظ روانی رابط: WebView به‌تنهایی قادر به بازتولید تمام انتقال‌های پیچیدهٔ نیتیو نیست؛ ترکیب انیمیشن‌های نیتیو و رندر وب به حفظ تجربه کمک کرد.
  • عملکرد و مصرف حافظه: مدیریت بارگذاری، پیش‌بارگذاری، lazy loading و کش هوشمند برای فیدهای سنگین ضروری بود.
  • دیباگینگ و ابزارپذیری: نیاز به ابزارهای بهتر برای مشاهده خطاها و پروفایلینگ JS در دستگاه‌های واقعی وجود داشت.
  • دسترسی و قابلیت‌های بومی: ویژگی‌هایی مثل پرداخت درون‌برنامه‌ای یا ردیابی موقعیت نیاز به پل‌های امن نیتیو داشتند.

استراتژی مهاجرت

مهاجرت مرحله‌ای و مبتنی بر اندازه‌گیری دنبال شد:

  1. ساخت پروتوتایپ برای اثبات مفهوم و ارزیابی اولیهٔ چالش‌ها.
  2. تعریف متریک‌های حیاتی و هم‌ترازی رویدادها بین نیتیو و وب.
  3. استفاده از فیچر فلگ برای rollout مرحله‌ای و اجرای A/B تست.
  4. گسترش تدریجی به فیدها و صفحات دیگر بر اساس نتایج و بازخوردها.

نتایج و درس‌های عملی

پس از پیاده‌سازی، سرعت انتشار تغییرات افزایش یافت و تیم‌های محصول توانستند تجربیات آزمایشی را سریع‌تر ارائه دهند. ترکیب هوشمند انیمیشن‌های نیتیو با رندر وب به حفظ کیفیت رابط کمک کرد، اما موفقیت وابسته به زیرساخت‌های مناسب و فرهنگ مهندسی بود.

چه زمانی این رویکرد مناسب است و چه زیرساخت‌هایی لازم دارید

این معماری زمانی بیشترین مزیت را دارد که شرایط زیر برقرار باشد:

  • تیم فرانت‌اند قوی با تجربه در SPA و بهینه‌سازی عملکرد.
  • زیرساخت آنالیتیکس و مانیتورینگ برای هم‌ترازی رخدادها بین وب و نیتیو.
  • توانایی مدیریت باندل‌ها و انتشار امن از طریق CDN و فیچر فلگ.
  • تعهد به حفظ تجربهٔ کاربر با ترکیب بهینهٔ نیتیو و وب.

برای کسب اطلاعات بیشتر در مورد مدل‌های ترکیبی موبایل می‌توان به بحث‌های مربوط به Hybrid mobile application یا منابع رسانه‌ای مانند TechCrunch مراجعه کرد.

محدودیت‌ها و هشدارها

این راهکار همه‌منظوره نیست. برای اپ‌هایی با وابستگی سنگین به SDKهای نیتیو، رندر گرافیکی پیچیده یا نیازهای امنیتی خاص، مهاجرت کامل به WebView توصیه نمی‌شود. تیم باید برای هزینه‌های اولیهٔ مهندسی، طراحی پل‌های امن و آموزش توسعه‌دهندگان آماده باشد.

پیشنهادهای اجرایی

  • با یک فید چالشی و قابل اندازه‌گیری شروع کنید تا کمترین ریسک را داشته باشید.
  • هم‌ترازی رویدادهای آنالیتیکس از ابتدا انجام شود تا مقایسهٔ دقیق پیش و پس مهاجرت میسر شود.
  • فیچر فلگ و rollout مرحله‌ای را در مرکز استراتژی قرار دهید.
  • ابزارهای پروفایلینگ JS و ابزارهای دیباگ برای پل‌های نیتیو آماده کنید.

جمع‌بندی

تجربهٔ مشابه Uber Eats نشان می‌دهد که معماری WebView تک‌صفحه‌ای هدایت‌شده توسط نیتیو می‌تواند میانهٔ مناسبی بین چابکی توسعه و کیفیت تجربهٔ کاربر فراهم آورد، مشروط بر اینکه زیرساخت، فرهنگ مهندسی و ابزارها آماده باشند. قبل از پیاده‌سازی گسترده، سناریوها را ارزیابی کرده و با پیاده‌سازی آزمایشی و معیارهای روشن حرکت کنید تا مزایا در مقیاس محقق شود.