محرك Nitro: إعادة تعريف الأداء في هندسة Expo الجديدة
غوص عميق في كيفية قيام محرك Nitro بإلغاء عبء الـ bridge باستخدام JSI و C++ لإنشاء native modules فائقة السرعة. تعرف على سبب كون هذا هو التطور القادم لتطوير React Native عالي الأداء.

محرك Nitro: إعادة تعريف الأداء في هندسة Expo الجديدة
لسنوات، تعايشنا مع ما يسمى بـ "Bridge Tax" (ضريبة الجسر). إذا كنت تعمل في منظومة React Native لفترة طويلة مثلي، فأنت تعرف القصة: تكتب native module عالي الأداء، لتشاهد هبوط عدد الإطارات (frames) بسبب عبء الـ JSON serialization والـ asynchronous batching.
مع التحول إلى الـ New Architecture و JSI (JavaScript Interface)، تغيرت قواعد اللعبة. ولكن مؤخراً، كنت أتعمق في Nitro Engine، وأشعر أنه الاختراق الذي كنا ننتظره حقاً. إنه ليس مجرد تحسين؛ بل هو إعادة تفكير جذرية في كيفية تواصل كود JS و Native.
لماذا Nitro؟ مشكلة عنق الزجاجة (Bottleneck)
حتى مع TurboModules، غالباً ما تكون هناك طبقة من الـ boilerplate والـ codegen التي قد تبدو مقيدة. عندما أبني شيئاً يتطلب حسابات ثقيلة — مثل معالجة الصور في الوقت الفعلي أو بيانات الحساسات عالية التردد — لا أريد "غلافاً" (wrapper)، بل أريد وصولاً مباشراً.
Nitro، الذي بدأه Marc Rousavy وتم اعتماده داخل منظومة Expo عالية الأداء، هو محرك C++ centric مصمم لجعل الـ native modules سريعة تماماً مثل استدعاء function محلية. فهو يتجاوز الـ bridge التقليدي تماماً ويستخدم JSI لعرض C++ HostObjects مباشرة لبيئة تشغيل JavaScript.
الاختراق الهندسي: Zero-Copy
الجزء الأكثر إثارة للإعجاب في تصميم Nitro هو التركيز على الـ Zero-Copy. في عالم الـ bridge القديم، إذا مررت array كبيرة من JS إلى Native، كان على المحرك تحويلها إلى string، تمريرها، ثم تحليلها (parse) مرة أخرى إلى native type.
مع Nitro و JSI، نحن نتشارك الذاكرة. عندما أقوم بتعريف Nitro module، فأنا فعلياً أقوم بإنشاء C++ object يعامله محرك JS كعنصر من الدرجة الأولى (first-class citizen).
كيف يبدو الكود
على عكس إعداد TurboModule القياسي الذي قد يبدو وكأنه كتابة Java/Obj-C مع الكثير من الكود المساعد، يستفيد Nitro من لغة C++ الحديثة لتعريف الواجهة. إليك نظرة مفاهيمية على كيفية تنفيذ دالات رياضية عالية السرعة:
من ناحية JavaScript، يبدو الأمر كالسحر. لا يوجد NativeModules.MyFastModule.calculateComplexPhysics(). بدلاً من ذلك، أنت تتعامل مع object متزامن (synchronous) ومعرف الأنواع (typed).
لماذا يهم هذا مطوري Expo
كانت Expo تدفع حدود الـ "Managed Workflow" لفترة طويلة. ولكن بالنسبة لأولئك منا الذين يقومون بالمهام الثقيلة (heavy lifting)، كان الـ managed workflow يبدو أحياناً كقفص ذهبي. يغير Nitro ذلك من خلال توفير طريقة قياسية وفائقة السرعة لحقن منطق C++ في تطبيقات Expo دون إفساد تجربة المطور.
- Type Safety: يضمن codegen الخاص بـ Nitro بقاء أنواع TypeScript وأنواع C++ متزامنة. لا مزيد من الانهيارات أثناء التشغيل لأنك مررت
stringفي مكان كان يتوقعint. - Synchronous Execution: أحياناً يكون
async/awaitعائقاً وليس ميزة. يسمح Nitro باستدعاءات متزامنة لمنطق الـ native، وهو أمر بالغ الأهمية للحسابات التي تمنع واجهة المستخدم (UI-blocking) أو المنطق المرتبط بمعدل الإطارات (frame-rate). - Modern C++: يشجع على استخدام معايير C++17/20 الحديثة، مما يجعل جانب الـ native أنظف بكثير وأسهل في الصيانة من أنماط JNI (Java Native Interface) القديمة.
تجربتي: "إحساس" الأداء
قمت مؤخراً بإعادة بناء (refactored) وحدة معالجة إشارات من TurboModule قياسي إلى Nitro-based Hybrid Object. الفرق لم يكن فقط في أرقام الاختبارات (benchmarks)؛ بل كان في استجابة واجهة المستخدم (responsiveness). عندما لا يضطر thread الـ JS لانتظار الـ bridge لإخلاء طابوره، يبدو كل شيء "سريعاً وسلساً".
نحن ننتقل نحو عصر يذوب فيه الفرق بين "Native" و "JavaScript". مع Nitro، أصبح كود الـ native ببساطة امتداداً لقدرات بيئة تشغيل JS.
الخاتمة
إذا كنت تبني تطبيقاً ينقل الكثير من البيانات أو يتطلب معالجة في الوقت الفعلي، فإن Nitro Engine هو صديقك المفضل. إنه يمثل نضج الهندسة الجديدة (New Architecture)، متجاوزاً مجرد "إصلاح الـ bridge" نحو نواة C++ عالية الأداء لمنظومة React Native بالكامل.
حان الوقت للتوقف عن التفكير في الـ native modules كـ "إضافات" (plugins) والبدء في التفكير فيها كـ "امتدادات" عالية الأداء لمنطقك البرمجي. Nitro هو المحرك الذي يجعل ذلك ممكناً.