الکترون در مقابل برنامههای بومی: آیا تفاوت عملکرد واقعی است؟
سالهاست که بحث داغی در جامعه توسعه نرمافزار جریان دارد: الکترون در مقابل بومی (Native). غولهای دسکتاپ مدرن مانند Visual Studio Code، Slack، Discord و Teams بر روی الکترون ساخته شدهاند؛ فریمورکی که به توسعهدهندگان اجازه میدهد با استفاده از فناوریهای وب، برنامههای دسکتاپ چندسکویی بسازند.
در عین حال، کاربران و توسعهدهندگان به طور مکرر از اینکه برنامههای الکترون “سنگین”، “کند” و “حریص رم (RAM)” هستند، شکایت دارند. در طرف دیگر، برنامههای بومی قرار دارند که به طور خاص برای یک سیستمعامل هدف نوشته شدهاند (با استفاده از Swift/Objective-C برای macOS، Kotlin/C# برای Windows/Android و C++/Qt برای Linux).
بنابراین، آیا تفاوت عملکرد واقعی است؟ یا یک بزرگنمایی است؟ در این پست، ما به اعماق معماری، میزان مصرف حافظه، زمان راهاندازی و ردپای منابع هر دو رویکرد خواهیم رفت تا حقیقت را دریابیم.
۱. طرح معماری: تفاوت اصلی
برای درک شکاف عملکرد، ابتدا باید بررسی کنیم که این برنامهها در پشت صحنه چگونه اجرا میشوند.
الکترون: یک مرورگر وب در یک جعبه
یک برنامه الکترون در واقع یک نمونه بستهبندی شده از کرومیوم (مرورگر متنباز پشت گوگل کروم) همراه با محیط زمان اجرای Node.js است.
- فرآیند اصلی (Main Process) محیط Node.js را اجرا میکند و چرخه حیات برنامه و تعاملات سیستم را مدیریت مینماید.
- فرآیندهای رندرکننده (Renderer Processes) نمونههای کرومیوم را اجرا میکنند و رابط کاربری را درست مانند یک صفحه وب رندر مینمایند.
این بدان معناست که وقتی یک برنامه الکترون تک را اجرا میکنید، همزمان در حال اجرای یک مرورگر وب و یک سرور بکاند هستید.
بومی: گفتگوی مستقیم با سختافزار
برنامههای بومی مستقیماً به کد ماشین کامپایل میشوند یا ماشینهای مجازی بهینهسازی شده (مانند JVM یا .NET CLR) را هدف قرار میدهند که با حداقل بار اضافی اجرا میشوند. آنها از موتور رندر رابط کاربری بومی سیستمعامل (مانند Cocoa در macOS یا WinUI در Windows) به جای رندر کردن HTML در داخل یک کانتینر مرورگر استفاده میکنند.
۲. مصرف حافظه (بحث داغ رم)
رایجترین انتقاد به الکترون، میزان مصرف حافظه آن است. این تفاوت ۱۰۰٪ واقعی و قابل اندازهگیری است.
- پایه مصرف الکترون: یک برنامه الکترون خالی و تازه راهاندازی شده معمولاً بین ۸۰ تا ۱۲۰ مگابایت رم مصرف میکند. دلیل آن این است که برنامه باید موتور رندر کرومیوم، موتور جاوا اسکریپت (V8) و Node.js را قبل از نمایش حتی یک پیکسل از رابط کاربری در حافظه بارگذاری کند.
- پایه مصرف بومی: یک برنامه دسکتاپ بومی ساخته شده با Swift (برای macOS) یا C++ (برای Windows) میتواند به راحتی با مصرف کمتر از ۱۰ تا ۱۵ مگابایت رم راهاندازی و اجرا شود.
وقتی این را به استفاده روزمره تعمیم دهید، اجرای سه یا چهار برنامه الکترون (مانند Slack، Discord، VS Code و Spotify) میتواند به راحتی ۱.۵ تا ۲ گیگابایت رم را فقط برای فعال نگه داشتن محیطهای اجرای آنها مصرف کند. برای کاربرانی که ۸ گیگابایت رم دارند، این امر یک گلگاه عملکردی جدی ایجاد میکند.
۳. زمان راهاندازی و سرعت اجرا
سرعت راهاندازی اولیه (Cold Boot)
از آنجا که الکترون باید موتور مرورگر را بوت کرده و زمینه Node.js را مقداردهی اولیه کند، از تاخیر محسوس در راهاندازی اولیه رنج میبرد. این زمان معمولاً بین ۱ تا ۳ ثانیه طول میکشد. برنامههای بومی بدون وجود چنین بار اضافی برای راهاندازی محیط اجرا، تقریباً به طور آنی (اغلب در ۱۰۰ تا ۳۰۰ میلیثانیه) راهاندازی میشوند.
بار پردازشی و سرعت اجرا
کرومیوم از موتور V8 گوگل برای کامپایل در زمان (JIT) جاوا اسکریپت به کد ماشین استفاده میکند. اگرچه V8 برای یک موتور جاوا اسکریپت فوقالعاده سریع است، اما نمیتواند با سرعت خام کد بومی که از قبل کامپایل شده است (AOT) مانند C++ یا Swift رقابت کند.
علاوه بر این، از آنجا که الکترون به یک زبان دارای مدیریت حافظه خودکار (جاوا اسکریپت) متکی است، کاربران گاهی اوقات هنگام پاکسازی حافظه استفاده نشده توسط Garbage Collector، لکنتهای بسیار کوچکی را تجربه میکنند. زبانهای بومی مانند C++ از مدیریت حافظه دستی استفاده میکنند و Swift از شمارش ارجاع خودکار (ARC) بهره میبرد که هر دو مانع از توقفهای ناشی از Garbage Collection میشوند.
۴. اندازه بسته نصب (ردپای دیسک)
اندازه فایل نصب برنامه یکی دیگر از تضادهای آشکار است:
- الکترون: از آنجا که هر برنامه الکترون باید کرومیوم و Node.js را درون خود بستهبندی کند، حداقل حجم دانلود حدود ۵۰ تا ۸۰ مگابایت است که پس از استخراج روی دیسک به بیش از ۱۵۰ مگابایت میرسد.
- بومی: یک برنامه بومی نیازی به بستهبندی محیط زمان اجرا ندارد زیرا از کتابخانههای داخلی سیستمعامل استفاده میکند. یک ابزار بومی با عملکرد کامل میتواند به راحتی زیر ۵ مگابایت حجم داشته باشد.
۵. اگر بومی برتر است، چرا الکترون اینقدر محبوب است؟
با وجود تمام این نقاط ضعف عملکردی، چرا غولهای صنعت همچنان الکترون را انتخاب میکنند؟
۱. سرعت توسعه: یک بار نوشتن کد با HTML/CSS/JavaScript و انتشار آن برای macOS، Windows و Linux میلیونها دلار در هزینههای توسعه شرکتها صرفهجویی میکند. ۲. نیروی کار در دسترس: تعداد توسعهدهندگان وب (HTML/CSS/JS) بسیار بیشتر از توسعهدهندگان بومی macOS (Swift) یا Windows (C++) است. ۳. رابط کاربری یکپارچه: الکترون تضمین میکند که برنامه شما در تمام سیستمعاملها دقیقاً ظاهر و رفتار یکسانی خواهد داشت.
نتیجهگیری: آیا تفاوت عملکرد واقعی است؟
بله، تفاوت عملکرد بین الکترون و برنامههای بومی بسیار واقعی است. برنامههای بومی بدون شک سریعتر هستند، کسری از حافظه را مصرف میکنند، سریعتر راهاندازی میشوند و فضای دیسک کمتری را اشغال میکنند.
با این حال، برای بسیاری از کسبوکارها، کارایی توسعهدهندگان، سرعت عرضه به بازار و یکپارچگی چندسکویی ارائه شده توسط الکترون، بر این هزینههای عملکردی میچربد. به عنوان یک توسعهدهنده یا کاربر، انتخاب نهایی به یک تعادل بستگی دارد: راحتی و سرعت توسعه در مقابل کارایی منابع و سرعت خام.