آموزش ۵۰۰+ سوال و جواب مصاحبه ریکت نیتیو (React Native) سال ۲۰۲۶ - آخرین آپدیت

پوشش جامع حوزه‌های آزمون

این مخزن آزمون‌های تمرینی دقیقاً بر اساس تحلیل‌های فنی و عمق مهندسی مورد نیاز در مصاحبه‌های توسعه موبایل سطح بالا ساختار یافته است:

• مبانی React Native (۲۰٪): معماری هسته JSX، کامپوننت‌های Functional و Class، تایپینگ پیچیده Props، چرخه حیات State محلی و مکانیسم‌های Bridge/Architecture.

• ناوبری و مسیریابی (۱۵٪): ساختارهای React Navigation، وضعیت Stack Navigator، پیکربندی Bottom Tab Navigator، لایه‌های Drawer Navigator و وضعیت‌های مسیریابی عمیق.

• مدیریت وضعیت و ذخیره‌سازی (۱۰٪): پیاده‌سازی‌های مقیاس‌پذیر Redux، استفاده از React Context API برای وضعیت‌های جهانی، ذخیره‌سازی پایدار با AsyncStorage و مدیریت حافظه محلی دستگاه.

• بهینه‌سازی عملکرد (۲۰٪): استراتژی‌های پیشرفته Memoization، تنظیم دقیق shouldComponentUpdate، پیاده‌سازی React.memo، بارگذاری تنبل (Lazy Loading) دارایی‌های سنگین، بهینه‌سازی FlatLists و مدیریت نرخ فریم (60 FPS).

• عیب‌یابی و رفع خطا (۱۰٪): ابزارهای دیباگ نیتیو، مرزهای مدیریت خطای تدافعی (Error Boundaries)، پیاده‌سازی لاگ‌های کرش و پروفایلینگ پیشرفته با Chrome DevTools.

• شبکه و دریافت داده‌ها (۱۰٪): پیاده‌سازی‌های Asynchronous Fetch API، نمونه‌های سفارشی Axios، کوئری‌ها و Mutationهای GraphQL و یکپارچه‌سازی امن با APIهای بک‌اند.

• امنیت و بهترین تمرین‌ها (۵٪): ذخیره‌سازی سخت‌افزاری امن، روتین‌های رمزنگاری، کنترل دسترسی توکن‌های موبایل و معیارهای سخت‌گیرانه کیفیت کد.

• مفاهیم و کتابخانه‌های پیشرفته (۱۰٪): هوک‌های سفارشی (Custom Hooks)، توزیع React Native Web برای کراس‌پلتفرم، رندرینگ UI با کارایی بالا از طریق Reanimated و پیکربندی‌های React Native Maps.

درباره این دوره

موفقیت در مصاحبه شغلی React Native بسیار فراتر از دانستن نحوه ساخت ویوهای ساده UI است. تیم‌های مهندسی مدرن به دنبال توسعه‌دهندگانی هستند که گلوگاه‌های عملکرد موبایل، نشت حافظه (Memory Leaks)، سربار ارتباطی Bridge و مدیریت وضعیت پیچیده در پلتفرم‌های مختلف را عمیقاً درک کنند. من این بانک سوالات جامع را ایجاد کردم تا آمادگی فنی دقیقی را که برای مواجهه با معماران ارشد موبایل و مدیران مهندسی با اعتماد به نفس کامل نیاز دارید، در اختیار شما قرار دهم.

با ۵۵۰ سوال تمرینی واقع‌بینانه، چالش‌برانگیز و اورجینال، این دوره بسیار فراتر از دانستن سینتکس‌های پایه است. تمرکز اصلی من بر تحلیل‌های معماری، سناریوهای پروفایلینگ دنیای واقعی، عیب‌یابی باگ‌های پیچیده کراس‌پلتفرم و نوشتن کدهای با کارایی بالا است که اپلیکیشن را با سرعت ۶۰ فریم بر ثانیه اجرا می‌کند. هر سوال همراه با یک تحلیل فنی جامع است که توضیح می‌دهد چرا یک رویکرد خاص موفق می‌شود و چرا روش‌های جایگزین در یک اپلیکیشن تجاری (Production) شکست می‌خورند. چه به دنبال نقش متخصص React Native باشید، چه مهندس فرانت‌اند کراس‌پلتفرم، این منبع تمرین‌های سخت‌گیرانه‌ای را فراهم می‌کند که برای قبولی در اولین تلاش در مصاحبه‌های فنی ضروری است.

نمونه سوالات تمرینی

برای درک عمق و ماهیت تحلیلی توضیحات ارائه شده در این دوره، این سه نمونه سوال سطح بالا را بررسی کنید.

سوال ۱: بهینه‌سازی رندرینگ FlatList برای ویوهای عمیقاً تو در تو

یک اپلیکیشن موبایل تجاری، فیدی پویا از آیتم‌ها را با استفاده از یک FlatList استاندارد نمایش می‌دهد. هنگامی که کاربر از ۵۰ آیتم عبور می‌کند، نرخ فریم UI به شدت به زیر ۶۰ FPS کاهش یافته و باعث لرزش (Stuttering) مشهود می‌شود. هر آیتم شامل متن پویا و یک تصویر است. کدام بهینه‌سازی برای تثبیت نرخ فریم موثرترین روش است؟

• الف) جایگزینی کل FlatList با یک ScrollView استاندارد که شامل کامپوننت‌های فرزند مپ شده باشد.

• ب) پیاده‌سازی React.memo روی کامپوننت آیتم لیست و ارائه یک تابع مقایسه‌ای سفارشی برای جلوگیری از رندرهای مجدد غیرضروری.

• ج) قرار دادن هر رشته متنی در کامپوننت آیتم در یک بلوک اختصاصی React Context provider.

• د) اجبار به رندر مجدد جهانی اپلیکیشن با فراخوانی یک callback خالی setState در هندلر onScroll لیست.

• ه) افزایش مقدار prop initialNumToRender به ۱۰۰ برای اطمینان از رندر تمام المان‌ها در حافظه از ابتدا.

• و) تبدیل تمام کامپوننت‌های Functional در سلسله مراتب لیست به کامپوننت‌های Class استاندارد و بهینه‌نشده.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل correctness: FlatList در React Native ویوهای آیتم را بازیافت می‌کند، اما اگر خود آیتم‌ها محاسبات پیچیده انجام دهند یا هنگام جابجایی داده‌های خارج از صفحه به طور غیرضروری رندر شوند، رشته JavaScript دچار گلوگاه می‌شود. استفاده از React.memo تضمین می‌کند که آیتم تنها زمانی رندر شود که Propsهای داده‌ای آن واقعاً تغییر کرده باشند و بدین ترتیب چرخه‌های حیاتی اجرای رشته JS حفظ شود.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: جایگزینی FlatList با ScrollView باعث حذف کامل Lazy Loading می‌شود و تمام آیتم‌ها را همزمان رندر می‌کند که در مجموعه‌ داده‌های بزرگ منجر به کرش Out-of-memory می‌شود.

  • گزینه ج نادرست است: تو در تو کردن تعداد زیادی Context provider باعث ایجاد درخت‌های کامپوننت عمیق و سربار می‌شود که عملکرد رندرینگ را کاهش می‌دهد.

  • گزینه د نادرست است: فراخوانی setState در هندلر فعال onScroll، صف رندر را با آپدیت‌ها پر کرده و رشته را کاملاً قفل می‌کند.

  • گزینه ه نادرست است: مقدار بسیار بالای initialNumToRender زمان لود اولیه صفحه را کند کرده و حافظه Heap اولیه زیادی مصرف می‌کند.

  • گزینه و نادرست است: کامپوننت‌های Functional به همراه هوک‌های Memoization مناسب، عملکردی مشابه یا بهتر از کامپوننت‌های Class دارند.

سوال ۲: شناسایی نشت حافظه (Memory Leak) با استفاده از Cleanup در هوک‌های سفارشی

یک توسعه‌دهنده هوکی سفارشی می‌سازد که یک اتصال WebSocket پایدار برای استریم قیمت‌های لحظه‌ای ارزهای دیجیتال برقرار می‌کند. کاربران گزارش می‌دهند که جابجایی بین صفحات باعث کند شدن اپلیکیشن و در نهایت کرش به دلیل مصرف بالای حافظه می‌شود. بررسی کد هوک نشان می‌دهد که یک نمونه WebSocket جدید در بلوک useEffect هنگام mount باز می‌شود. علت ریشه‌ای چیست؟

• الف) پروتکل WebSocket ذاتاً با روتین‌های تخصیص حافظه سیستم‌عامل‌های موبایل ناسازگار است.

• ب) هوک useEffect به صورت ناهمگام اجرا می‌شود و به یک قفل همگام‌سازی صریح نیاز دارد.

• ج) هوک نتوانسته است یک تابع cleanup برگرداند که اتصال WebSocket فعال را هنگام unmount شدن کامپوننت ببندد.

• د) هوک‌های سفارشی React هرگز نباید اتصالات شبکه ناهمگام را در کامپوننت‌های Functional مدیریت کنند.

• ه) آرایه وابستگی‌های (Dependency array) هوک شامل تعداد زیادی رشته ساده است که باعث سردرگمی Garbage Collection می‌شود.

• و) آپدیت‌های وضعیت دریافتی از شبکه برای ذخیره‌سازی همزمان در متغیرهای AsyncStorage محلی بیش از حد سریع هستند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• دلیل correctness: وقتی کامپوننتی که از این هوک استفاده می‌کند هنگام ناوبری unmount می‌شود، بلوک useEffect در حافظه باقی می‌ماند اگر خودش را پاکسازی نکرده باشد. با حذف تابع return که socket.close() را اجرا کند، اتصال قدیمی باز می‌ماند و در پس‌زمینه به گوش دادن ادامه می‌دهد و هر بار که کاربر به آن صفحه مراجعه کند، یک نشت حافظه شدید ایجاد می‌شود.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: WebSockets به طور بهینه روی پلتفرم‌های موبایل اجرا می‌شوند؛ مشکل مدیریت چرخه حیات است، نه سازگاری پروتکل.

  • گزینه ب نادرست است: useEffect الگوهای ناهمگام را به طور طبیعی مدیریت می‌کند؛ افزودن قفل همگام‌سازی رشته در JS استاندارد پشتیبانی نمی‌شود.

  • گزینه د نادرست است: مدیریت چرخه‌های شبکه یکی از کاربردهای اصلی هوک‌های سفارشی و افکت‌های فانکشنال است.

  • گزینه ه نادرست است: متغیرهای Primitive به راحتی توسط Garbage Collector پاک می‌شوند و باعث نشت حافظه Heap نیتیو نمی‌شوند.

  • گزینه و نادرست است: داده‌های استریم باید به وضعیت محلی کامپوننت هدایت شوند، نه اینکه مستقیماً از طریق AsyncStorage کند در زمان آپدیت‌های سریع ذخیره شوند.

سوال ۳: معماری Redux و مدیریت Side-Effect با Bridgeهای نیتیو

یک اپلیکیشن سازمانی نیاز دارد یک Payload حجیم از پروفایل کاربر را از یک Endpoint گراف‌کیوال (GraphQL) دریافت کرده و توکن‌های خاصی را در یک Keychain سخت‌افزاری امن ذخیره کند. کدام انتخاب معماری از بهترین تمرین‌ها برای دیسپچ کردن اکشن‌ها و مدیریت Side-effectها بدون مسدود کردن تعاملات UI پیروی می‌کند؟

• الف) اجرای کل منطق دریافت شبکه مستقیماً داخل فایل Redux reducer اصلی.

• ب) دیسپچ یک اکشن همگام (Synchronous) که رشته اصلی UI را با یک حلقه while طولانی تا زمان رسیدن داده‌ها متوقف کند.

• ج) استفاده از یک لایه Middleware ناهمگام مانند Redux Thunk یا Redux Saga برای جداسازی دریافت شبکه و عملیات نوشتن امن از کامپوننت‌های UI.

• د) پاس دادن مستقیم اشیای Promise جاوااسکریپت به عنوان جفت‌های کلید-مقدار در درخت وضعیت Redux store.

• ه) حذف کامل Redux و استفاده از متغیرهای globalThis برای به اشتراک‌گذاری وضعیت بین صفحات.

• و) انتقال کل لایه شبکه به کد layout بریج نیتیو iOS و Android با استفاده از ویرایش‌های دستی C++.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• دلیل correctness: ردیوسرهای Redux باید توابع خالص (Pure) و همگام باقی بمانند که تغییرات وضعیت را بدون Side-effect محاسبه کنند. استفاده از Middleware ناهمگام مانند Redux Thunk یا Saga اجازه می‌دهد عملیات پیچیده (مانند فراخوانی API و ذخیره داده در حافظه امن) را کاملاً از لایه View جدا کنید و UI را سریع و پاسخگو نگه دارید.

• دلیل نادرست بودن سایر گزینه‌ها:

  • گزینه الف نادرست است: قرار دادن دریافت‌های شبکه ناهمگام در یک ردیوسر، قانون بنیادین Pure بودن ردیوسر را نقض کرده و باعث تغییرات غیرقابل پیش‌بینی در وضعیت می‌شود.

  • گزینه ب نادرست است: مسدود کردن حلقه اجرای تک‌رشته‌ای JS با یک حلقه while همگام، UI موبایل را فوراً منجمد کرده و منجر به بسته شدن اپلیکیشن توسط OS می‌شود.

  • گزینه د نادرست است: درخت وضعیت Redux باید داده‌های قابل سریال‌سازی (Serializable) داشته باشد؛ Promiseها غیرقابل سریال‌سازی هستند و ابزارهای توسعه و لایه‌های Persistence را مختل می‌کنند.

  • گزینه ه نادرست است: تکیه بر متغیرهای جهانی JS مدل رندرینگ واکنشی React را دور می‌زند و باعث می‌شود المان‌های UI هنگام تغییر داده‌ها آپدیت نشوند.

  • گزینه و نادرست است: نوشتن کد C++ برای یک دریافت API استاندارد، پیچیدگی مهندسی غیرضروری ایجاد کرده و قابلیت نگهداری کراس‌پلتفرم را از بین می‌برد.

چه انتظاراتی داشته باشید

• به آزمون‌های مصاحبه‌ای خوش آمدید تا شما را برای تست‌های عملی سوالات مصاحبه React Native آماده کنیم.

• شما می‌توانید هر تعداد بار که بخواهید در آزمون‌ها شرکت کنید.

• این یک بانک سوالات عظیم و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق و فنی است.

• کاملاً سازگار با اپلیکیشن Udemy در موبایل.

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.