Electron مقابل التطبيقات الأصلية: هل فرق الأداء حقيقي؟
لسنوات عديدة، دار نقاش حاد في مجتمع تطوير البرمجيات: Electron مقابل التطبيقات الأصلية (Native). تم بناء تطبيقات سطح المكتب العملاقة الحديثة مثل Visual Studio Code و Slack و Discord و Teams على Electron، وهو إطار عمل يتيح للمطورين بناء تطبيقات سطح مكتب متعددة المنصات باستخدام تقنيات الويب.
في الوقت نفسه، يشتكي المستخدمون والمطورون على حد سواء بشكل متكرر من أن تطبيقات Electron “منتفخة” و"بطيئة" و"مستهلكة للذاكرة العشوائية (RAM)". على الجانب الآخر تقف التطبيقات الأصلية، المكتوبة خصيصاً لنظام تشغيل مستهدف (باستخدام Swift/Objective-C لنظام macOS، و Kotlin/C# لنظام Windows/Android، و C++/Qt لنظام Linux).
إذن، هل فرق الأداء حقيقي؟ أم أنه مبالغ فيه؟ في هذه المقالة، سنغوص في الهندسة المعمارية، واستخدام الذاكرة، وأوقات البدء، واستهلاك الموارد لكلا النهجين لمعرفة الحقيقة.
1. المخطط المعماري: الاختلاف الجوهري
لفهم فجوة الأداء، يجب أن ننظر أولاً إلى كيفية عمل هذه التطبيقات تحت الغطاء.
Electron: متصفح ويب في صندوق
تطبيق Electron هو في الأساس نسخة معبأة من Chromium (المتصفح مفتوح المصدر الذي يقف وراء Google Chrome) مدمج مع بيئة تشغيل Node.js.
- العملية الرئيسية (Main Process): تقوم بتشغيل بيئة Node.js، وإدارة دورة حياة التطبيق والتفاعلات مع النظام.
- عمليات العرض (Renderer Processes): تقوم بتشغيل نسخ من Chromium، وعرض واجهة المستخدم تماماً مثل صفحة الويب.
هذا يعني أنه عند تشغيل تطبيق Electron واحد، فإنك تقوم بتشغيل متصفح ويب وخادم خلفي في نفس الوقت.
التطبيقات الأصلية: التحدث مباشرة إلى العتاد
تترجم التطبيقات الأصلية مباشرة إلى لغة الآلة أو تستهدف آلات افتراضية محسنة (مثل JVM أو .NET CLR) التي تعمل بأقل قدر من الحمل الإضافي. وهي تستخدم محرك عرض واجهة المستخدم الأصلي لنظام التشغيل (مثل Cocoa على macOS أو WinUI على Windows) بدلاً من عرض HTML داخل حاوية متصفح.
2. استهلاك الذاكرة (جدل الذاكرة العشوائية)
النقد الأكثر شيوعاً لـ Electron هو استخدام الذاكرة. هذا الاختلاف حقيقي 100% وقابل للقياس.
- الحد الأدنى لـ Electron: يستهلك تطبيق Electron فارغ وجديد عادةً ما بين 80 ميجابايت إلى 120 ميجابايت من الذاكرة العشوائية. هذا لأن التطبيق يجب أن يحمل محرك عرض Chromium، ومحرك JavaScript (V8)، و Node.js في الذاكرة حتى قبل عرض بكسل واحد من واجهة المستخدم الخاصة بك.
- الحد الأدنى للتطبيقات الأصلية: يمكن لتطبيق سطح مكتب أصلي تم بناؤه باستخدام Swift (لنظام macOS) أو C++ (لنظام Windows) العمل بسهولة باستخدام أقل من 10 إلى 15 ميجابايت من الذاكرة العشوائية.
عندما ترفع هذا إلى الاستخدام اليومي، فإن تشغيل ثلاثة أو أربعة تطبيقات Electron (مثل Slack و Discord و VS Code و Spotify) يمكن أن يستهلك بسهولة 1.5 جيجابايت إلى 2 جيجابايت من الذاكرة العشوائية فقط للحفاظ على نشاط بيئات التشغيل الخاصة بها. بالنسبة للمستخدمين الذين لديهم ذاكرة عشوائية بسعة 8 جيجابايت، فإن هذا يخلق عقبة أداء كبيرة.
3. أوقات بدء التشغيل وسرعة التنفيذ
سرعة بدء التشغيل البارد
نظراً لأن Electron يجب أن يبدأ تشغيل محرك المتصفح ويهيئ سياق Node.js، فإنه يعاني من تأخير ملحوظ في “بدء التشغيل البارد”. عادةً ما يستغرق وقت البدء هذا ما بين 1 إلى 3 ثوانٍ. أما التطبيقات الأصلية، نظراً لعدم وجود حمل تهيئة لبيئة التشغيل، فتبدأ على الفور تقريباً (غالباً في 100 إلى 300 مللي ثانية).
عبء المعالجة والتنفيذ
يستخدم Chromium محرك V8 من Google لترجمة JavaScript في الوقت الفعلي (JIT) إلى لغة الآلة. بينما يعد V8 سريعاً بشكل لا يصدق بالنسبة لمحرك JavaScript، إلا أنه لا يمكنه مطابقة السرعة الخام للتعليمات البرمجية الأصلية المترجمة مسبقاً (AOT) (مثل C++ أو Swift).
علاوة على ذلك، نظراً لأن Electron يعتمد على لغة تحتوي على جامع المهملات (JavaScript)، فسيوجه المستخدمون أحياناً بعض التقطيعات البسيطة عندما يقوم جامع المهملات بتنظيف الذاكرة غير المستخدمة. تستخدم اللغات الأصلية مثل C++ إدارة الذاكرة اليدوية، ويستخدم Swift نظام عد المراجع التلقائي (ARC)، وكلاهما يتجنب فترات التوقف الناتجة عن جمع المهملات.
4. حجم الحزمة (المساحة المستهلكة على القرص)
حجم ملف تثبيت التطبيق يمثل تبايناً صارخاً آخر:
- Electron: نظراً لأن كل تطبيق Electron يجب أن يحزم Chromium و Node.js بداخلة، فإن الحد الأدنى لحجم التنزيل يبلغ حوالي 50 ميجابايت إلى 80 ميجابايت، ويصل فك الضغط إلى أكثر من 150 ميجابايت على القرص.
- التطبيقات الأصلية: لا يحتاج التطبيق الأصلي إلى حزم بيئة تشغيل لأنه يستخدم المكتبات المدمجة في نظام التشغيل. يمكن لأداة أصلية تعمل بكامل وظائفها أن تكون بسهولة أقل من 5 ميجابايت.
5. إذا كانت التطبيقات الأصلية متفوقة، فلماذا يحظى Electron بشعبية كبيرة؟
مع كل عيوب الأداء هذه، لماذا لا تزال عمالقة الصناعة تختار Electron؟
- سرعة المطورين: كتابة التعليمات البرمجية مرة واحدة باستخدام HTML/CSS/JavaScript ونشرها على macOS و Windows و Linux يوفر للشركات الملايين من تكاليف التطوير.
- توفر المطورين: هناك عدد أكبر بكثير من مطوري الويب (HTML/CSS/JS) مقارنة بمطوري macOS الأصلية (Swift) أو Windows الأصلية (C++).
- واجهة مستخدم متناسقة: يضمن Electron أن يبدو تطبيقك ويعمل بنفس الطريقة تماماً عبر جميع أنظمة التشغيل.
الخلاصة: هل فرق الأداء حقيقي؟
نعم، فرق الأداء بين تطبيقات Electron والتطبيقات الأصلية حقيقي للغاية. التطبيقات الأصلية أسرع بلا شك، وتستهلك جزءاً بسيطاً من الذاكرة، وتبدأ بشكل أسرع، وتأخذ مساحة أقل على القرص.
ومع ذلك، بالنسبة للعديد من الشركات، فإن كفاءة المطورين، وسرعة طرح المنتج في السوق، والاتساق بين المنصات الذي يقدمه Electron يفوق تكاليف الأداء هذه. بالنسبة للمطور أو المستخدم، يرجع الاختيار إلى المفاضلة بين: الراحة وسرعة التطوير مقابل كفاءة الموارد والسرعة الفائقة.