قیمتهای بالای RAM و مصرف بیشتر حافظه در ویندوز 11: چرا برنامهها به حافظه بیشتری نیاز دارند؟
برخی از محبوبترین برنامههای ویندوز ۱۱ آنقدر از رم استفاده میکنند که میتوانند بر عملکرد کامپیوتر شما تأثیر بگذارند
قیمتهای بالای RAM و مصرف بیشتر حافظه در ویندوز 11: چرا برنامهها به حافظه بیشتری نیاز دارند؟
برخی از محبوبترین برنامههای ویندوز ۱۱ آنقدر از رم استفاده میکنند که میتوانند بر عملکرد کامپیوتر شما تأثیر بگذارند و این واقعیت که قیمت رم در حال افزایش است، اوضاع را حتی بدتر میکند. این مشکل به دلیل روند ترجیح توسعهدهندگان به برنامههای وب به جای برنامههای بومی در ویندوز است.
مطالب مشابه: اخبار RAM
به گزارش اپست به نقل از windowslatest ، گزارش شد که برنامههایی مانند Discord، Teams و WhatsApp جدید، حتی در پسزمینه، چقدر رم زیادی مصرف میکنند. عامل مشترک در اینجا این است که این برنامهها محور ارتباطات هستند و همانطور که انتظار میرود، حتی زمانی که از آنها استفاده نمیکنید، باید فعال نگه داشته شوند.
مطالب مشابه: اخبار ویندوز 11
با این حال، آزمایش ما ثابت کرد که نسخههای بومی برنامهها (مانند WhatsApp قدیمی) رم زیادی مصرف نمیکنند. اینها برخی از پرکاربردترین برنامههای ویندوز هستند، صرف نظر از اینکه افراد در چه حوزهای هستند.
مطالب مشابه : اخبار ویندوز
پس چرا این برنامهها نسخههای بومی ندارند؟ آیا ساخت نسخههای بومی و بهینه شده برای محبوبترین سیستم عامل دسکتاپ برای این شرکتها اینقدر دشوار است؟ بدترین مصرفکنندگان رم در ویندوز ۱۱
زمان مناسبتری برای صحبت در مورد استفاده از رم وجود نداشته است، زیرا این یک ارتقاء سختافزاری بسیار گران برای رایانههای شخصی و لپتاپها میشود. و با خروج میکرون از تجارت رم مصرفی، این وضعیت بدتر هم شده است.
ویندوز ۱۱ پیش از این به دلیل نیاز به رم بالاتر در زمان عرضه مورد انتقاد قرار گرفته بود، اما در سال ۲۰۲۵، اوضاع بدتر شده است زیرا برنامههای ارتباطی اصلی در ویندوز مانند یک منبع رایگان، از رم استفاده میکنند.
دیسکورد همیشه حدود ۱ گیگابایت رم استفاده میکند و خوشبختانه به ۴ گیگابایت رم میرسد.
دیسکورد، که در بین گیمرها و جوامع آنلاین مشهور است، سادهترین گزینه برای انتخاب است زیرا این شرکت قبلاً مشکل رم را پذیرفته است. کلاینت ویندوز بر اساس الکترون ساخته شده است، به این معنی که شما یک نمونه مرورگر کرومیوم به علاوه Node.js را به عنوان یک برنامه دسکتاپ اجرا میکنید. هر سرور، کانال و هر ویژگی اضافی که باز میکنید، تبهای بیشتری به آن مرورگر داخلی اضافه میکند.
دیسکورد به کاربران گفته است که استفاده عادی کمتر از ۱ گیگابایت رم نیاز دارد، اما در شرایط واقعی، این مقدار میتواند به ۴ گیگابایت برسد، که این همان زمانی است که شرکت شروع به آزمایش بدنام «راهاندازی خودکار وقتی حافظه از ۴ گیگابایت فراتر رود» کرد.
اگر برنامه حداقل یک ساعت باز بوده باشد، ۳۰ دقیقه بیکار باشید و در حال مکالمه نباشید، دیسکورد در یک بازه ۲۴ ساعته، بیصدا خود را یک بار راهاندازی مجدد میکند تا حافظه را آزاد کند.
این شرکت توضیح میدهد که این راهاندازی مجدد با حسن نیت انجام شده است. با این حال، ما احساس میکنیم که این یک راه حل موقت برای یک مشکل اساسی است. در هر صورت، توسعهدهندگان دیسکورد مشغول رفع نشتهای حافظه واقعی بودهاند و ادعا میکنند که حدود ۵٪ کاهش در استفاده از حافظه با درصد بالا را نشان میدهند.
با این اوصاف، الکترون یک پشته مرورگر کامل برای هر برنامه است، بنابراین کامپیوتر شما در نهایت برای رندر کردن یک رابط کاربری چت، هزینه یک موتور رندر، یک زمان اجرای جاوا اسکریپت و جعبههای امنیتی را پرداخت میکند.
خبر خوب این است که Discord میخواهد اوضاع را درست کند، اما خبر بد این است که این شرکت با وجود ۱۰ سال حضور در این صنعت، دقیقاً سودآور نیست. بنابراین نمیتوانیم واقعاً انتظار داشته باشیم که این شرکت روی یک برنامه بومی سرمایهگذاری کند. این شرکت همچنین برنامه بومی macOS ندارد.
واتساپ از یک برنامه بومی سریع به یک وبرپِر کند تبدیل شد.
واتساپ برای ویندوز نوع دیگری از تراژدی است، زیرا قبلاً خوب بود. کلاینت قدیمی مبتنی بر UWP و WinUI سبک، سریع و در ویندوز ۱۱ کاملاً مناسب بود. حتی در استفاده سنگین روزانه، با صدها چت و گروه فعال، معمولاً کمتر از ۱۰۰ مگابایت در حالت بیکار و حدود ۲۵۰ مگابایت در هنگام پیمایش سریع مکالمات طولانی باقی میماند.
سپس Meta نسخه جدید را که به عنوان یک وبرپِر WebView2 ساخته شده بود، ارسال کرد که به سادگی web.whatsapp.com را در یک کانتینر مبتنی بر Chromium بارگذاری میکند. در آزمایش ما، برنامه جدید قبل از اینکه حتی وارد سیستم شوید، حدود ۳۰۰ مگابایت از رم را اشغال میکند. به محض اینکه چتها همگامسازی میشوند و شروع به اسکرول کردن میکنید، به راحتی به ۱.۲ گیگابایت میرسد و مصرف CPU بسیار بیشتر از قبل میشود.
مشکلات عملکرد به حافظه دسترسی تصادفی (RAM) محدود نمیشوند. رابط کاربری (UI) به نظر میرسد با نرخ فریم بسیار پایینتری اجرا میشود، جابجایی چتها تأخیر قابل مشاهدهای دارد، و حتی روی سختافزارهای نسبتاً خوب، حس دائمی سنگینی را بر جای میگذارد. بستن پنجره در واقع برنامه را کاملاً نمیبندد. این کار آن را به سینی سیستم (tray) کوچک میکند و بخشی از حافظه RAM را در پسزمینه رزرو نگه میدارد تا بتواند اعلانها را از طریق سرویسکارها (service workers) دریافت کند، چیزی که برنامه بومی (native app) به آن نیازی نداشت.
همه این اتفاقات به بهانه «سادهسازی توسعه» و استفاده مجدد از پایگاه کد (codebase) وب رخ داد، اما برای کاربران، یک پسرفت تمام و کمال است. متا همچنان در macOS یک برنامه واتساپ بومی (native) ارائه میکند. در ویندوز، پلتفرمی با کاربران بسیار بیشتر، بهترین کاری که در حال حاضر میتوانند انجام دهند، یک پنجره مرورگر است. این صرفاً تنبلی از جانب متا است و اینطور هم نیست که این شرکت از پس هزینهاش برنیاید.
تیمز؛ حتی مایکروسافت هم اهمیت نمیدهد
سپس مایکروسافت تیمز (Microsoft Teams) وجود دارد که از الکترون (Electron) به سمت WebView2 حرکت کرد. این ممکن است روی کاغذ شبیه به پیشرفت به نظر برسد. با این حال، در واقعیت، به تمام معنا هنوز یک برنامه وب است. تیمز بهطور معمول در حالت بیکاری (idle) حدود ۱ گیگابایت رَم را اشغال میکند.
مایکروسافت به جای بازنویسی، مشکل را با بازسازی ساختار اپلیکیشن تصدیق کرد. با شروع اوایل سال ۲۰۲۶، تیمز یک فرایند جدید به نام ms-teams_modulehost.exe را معرفی خواهد کرد که ویژگیهای تماس را به طور جداگانه از فرایند اصلی ms-teams.exe مدیریت میکند.
این واقعیت را تغییر نمیدهد که هنوز همهچیز بر بستر WebView2 در حال اجرا است، با همان عوامل معمول در پسزمینه.
ما نمیدانیم در مورد این وضعیت چه بگوییم، به خصوص وقتی مایکروسافت مشتریان سازمانی خود را دارد که برای ارتباطات روزمره کاملاً به تیمز (Teams) متکی هستند.
در حال حاضر، ما انتظار نداریم که مایکروسافت اهمیتی بدهد که آیا توسعهدهندگان دیگر برنامههای بومی (native) ویندوز میسازند یا اینکه برنامههای بومی موجود خود را به برنامههای تحت وب (web apps) منتقل میکنند، مانند کاری که متا (Meta) انجام داد.
حقیقت این است که مرورگرهای وب این روزها مقدار ظالمانهای از رم را مصرف میکنند، و هر برنامهای که بر اساس آن ساخته شود، به راحتی رم را میبلعد. بدترین نوع این برنامهها، برنامههای ارتباطی هستند، زیرا عملاً باید همیشه روشن باشند.
چرا تمام برنامههای مدرن ویندوز اینقدر رم مصرف میکنند؟
اکثر برنامههای جدید ویندوز که امروزه در فروشگاه مایکروسافت (Microsoft Store) هستند، در واقع برنامههای واقعی ویندوز نیستند، بلکه موتورهای مرورگر هستند.
- دیسکورد (Discord) از الکترون (Electron) استفاده میکند.
- واتساپ (WhatsApp) و تیمز (Teams) از WebView2 استفاده میکنند.
- بسیاری از برنامههای کوچکتر از PWAها (Progressive Web Apps) استفاده میکنند.
اما همه اینها یک ویژگی مشترک دارند: تعبیه کردن یک محیط کامل کرومیوم (Chromium) در داخل برنامه.
هر برنامه الکترون (Electron) موتور جاوا اسکریپت، رندرکننده GPU، پشته شبکه، خط لوله صوتی و زیرفرآیندهای سَندباکسشده (sandboxed subprocesses) خود را دارد. حتی یک عنصر کوچک در رابط کاربری میتواند به دلیل استانداردهای امنیتی مرورگرهای مدرن، یک فرآیند دیگر ایجاد کند. هر چت، سرور، کانال، نمای تماس یا پنل تنظیمات در واقع یک دنیای سَندباکسشده جداگانه است. بنابراین، مصرف حافظه به صورت افقی (horizontal) رشد میکند زیرا ویژگیها به صورت موازی اجرا میشوند.
WebView2، چارچوبی که توسط تیمز و واتساپ استفاده میشود، از باز کردن یک کپی کامل از کرومیوم اجتناب میکند، اما طراحی کلی مشابه باقی میماند. ممکن است فکر کنید واتساپ جدید در ویندوز یک لیست ساده از چتها است. در واقعیت، آن یک تب مرورگر کوچک است که تمام لایههای کروم در زیر آن در حال اجرا هستند.
PWAs (اپلیکیشنهای وب پیشرو)، مانند اپلیکیشن ردیت روی ویندوز، به همین شکل رفتار میکنند، زیرا آنها نیز به معماری چندفرآیندی کرومیوم و سرویسورکرهای پسزمینه (Background Service Workers) وابسته هستند.
از لحاظ فنی، WebView2 از Electron بهتر است
از آنجا که هر اپلیکیشن Electron مانند یک مرورگر کامل باز میشود، حجم و مصرف رم را افزایش میدهد، اما در رفتار چندسکویی (cross-platform) در ویندوز، macOS و لینوکس ثابت و یکپارچه خواهد بود. اپلیکیشنهای WebView2 از نصب موجود Microsoft Edge (Chromium) در ویندوز برای رندر کردن محتوای وب در داخل اپلیکیشنهای بومی استفاده میکنند. بنابراین، از آنجا که مرورگر اختصاصی خود را باز نمیکند، سربار (overhead) و حجم اشغالی (footprint) را کاهش میدهد. البته، محدودیت کوچکی در قابلیت حمل (portability) وجود دارد زیرا این روش وابسته به ویندوز است و به رانتایم Edge نیاز دارد.
در هر صورت، این معماریها به طور تصادفی ناکارآمد نیستند. توسعهدهندگان این را میدانند و وجود دارد تا از نقاط ضعف (exploits) و مسائل امنیتی جلوگیری کند.
مرورگرهای مدرن جداسازی فرآیند (process isolation) را پیادهسازی میکنند تا از تعامل صفحات مخرب با آنچه کاربر در حال مشاهده است، جلوگیری کنند. آنها استخرهای حافظه (memory pools) را در سراسر جعبههای شنی (sandboxes) تقسیم میکنند. آنها رندرینگ (rendering) را از منطق (logic) و منطق را از ذخیرهسازی (storage) دور نگه میدارند. این استفاده اضافی از منابع، بهایی است که باید برای امنیت بپردازیم. بنابراین، هنگامی که یک موتور مرورگر را به عنوان بنیان برای یک اپلیکیشن دسکتاپ انتخاب میکنید، مصرف بیش از حد رم اجتنابناپذیر است.
برنامههای جاوااسکریپت مدرن نیز سهم خود را از رم میبرند
علاوه بر همه اینها، فریمورکهای مدرن جاوااسکریپت سهم منصفانه خود را از رم میبرند. باندلهای بزرگ (Large bundles)، الگوریتمهای سنگین مقایسه تفاوت (heavy diffing algorithms)، لایههای DOM مجازی (virtual DOM layers)، و ماشینهای وضعیت سمت کلاینت (client-side state machines) همگی بر مصرف رم بالا و از قبل موجود مرورگر انباشته میشوند. اساساً، حتی اپلیکیشنهای پوشش وب (web wrapper) که به خوبی بهینهسازی شدهاند نیز یک مصرف حافظه پایه بالا دارند.
نشتهای حافظه همهجا هستند
نشت حافظه (Memory leaks) زمانی اتفاق میافتد که ارجاعات جاوااسکریپت به درستی آزاد نشوند یا زمانی که شنوندگان رویداد (event listeners) در طول زمان انباشته میشوند. این امر زمانی که فریمورکها اشیاء بیکار (idle objects) را در کشهای داخلی خود زنده نگه میدارند، شایع است. همچنین زمانی رخ میدهد که فرآیندهای مرورگر در طول جلسات طولانیمدت (long-running sessions) نتوانند حافظه را آزاد کنند.
به محض شروع نشت حافظه، آنها به افزایشهای چند گیگابایتی تبدیل میشوند، مانند مواردی که در دیسکورد دیدیم. این امر در اپلیکیشنهای Electron، Chromium Embedded Framework (CEF) و WebView2 رایج است، و ابزارهای اشکالزدایی (debugging) برای پشتههای (stacks) پیچیده JS به هیچ وجه به اندازه اشکالزداهای بومی (native debuggers) بالغ نیستند.
حقیقت ناراحتکننده این است که ما میدانیم شرکتها مصرف رم را زیر نظر دارند، و تنها کاری که میتوانند انجام دهند این است که وصلههایی (patches) را منتشر کنند که ممکن است حوزههای کوچک مسائل حافظه را برطرف کنند. اما کل پشته اطلاعات زیادی را پشت تجریدها (abstractions) پنهان میکند.
شما نمیتوانید ببینید که کرومیوم در سطح پایین چه کاری انجام میدهد. نمیتوانید رندر کننده آن را وادار کنید که حافظه را به صورت تهاجمیتر آزاد کند. نمیتوانید مدل چند فرآیندی را بازنویسی کنید. یک محدودیت اجتنابناپذیر برای میزان بهینهسازی فریمورک برای مصرف حافظه وجود دارد.
چرا شرکتها به جای اپلیکیشنهای بومی (Native)، همچنان اپلیکیشنهای وب (Web Apps) را منتشر میکنند؟
با وجود تمام این مشکلات، ممکن است تعجب کنید که چرا شرکتها به هر حال اپلیکیشنهای وب را توسعه میدهند. آیا برای آنها داشتن یک رابط کاربری روان برای کاربرانشان ارزشمند نیست؟
پاسخ ساده هزینه است. یک کد بیس (codebase) جاوا اسکریپت میتواند از لحاظ فنی با کمترین تغییرات روی ویندوز، مکاواس و لینوکس اجرا شود. استخدام توسعهدهندگان جاوا اسکریپت بسیار آسانتر از توسعهدهندگان C++ است.
آموزش و به کارگیری نیروهای جدید سریعتر است و چرخههای توسعه کوتاهتر خواهند بود. همچنین، تیمها قادر خواهند بود ویژگیها را به طور همزمان برای تمام پلتفرمها عرضه کنند. اکثر شرکتها تحت فشار هستند تا اپلیکیشنهای خود را سریعتر ارائه دهند و در آن زمان، توسعه اپلیکیشنهای بومی یک راهحل عملی نیست.
شرکتها در مورد ثبات برند (brand consistency) نیز بحث میکنند، که راستش را بخواهید بیمعنی است. ایده این است که شرکتها میخواهند رابط کاربری آنها در هر دستگاهی یکسان به نظر برسد. “وب رپرها” (Web wrappers) میتوانند این کار را انجام دهند. اما پلتفرمهای سیستم عامل مختلف ظاهر متفاوتی دارند، البته نه در ویندوز، که آن خود ماجرای دیگری است. برای یک مثال بهتر، به طراحی “شیشه مایع” (Liquid Glass) اپل فکر کنید. کل سیستم عامل این طراحی را دارد، اما اگر اپلیکیشن یک برند ظاهری کاملاً متفاوت داشته باشد، از تجربه کاربری میکاهد.
غمانگیزترین بخش این است که شرکتها دیگر اپلیکیشنهای بومی ویندوز را در اولویت نمیبینند. ما قبلاً شاهد بودیم که متا، واتساپ UWP را بازنشسته کرد، علیرغم اینکه عمدتاً خوب کار میکرد. مسنجر به طور کامل از فروشگاه مایکروسافت ناپدید شد. فیسبوک و اینستاگرام اکنون “وب رپر” هستند.
حتی مایکروسافت هم خود پیشتاز نیست، زیرا تیمز (Teams) هنوز یک اپلیکیشن WebView2 است، و لینکدین (LinkedIn)، که آن را با یک قرارداد تمام نقد به مبلغ ۲۶.۲ میلیارد دلار خریداری کرد، صرفاً یک “وب رپر” است.
چیزی که در حد شوخی است، این است که نمای Agenda آتی در پنل اعلانهای ویندوز ۱۱ به جای XAML/WinUI بومی، از WebView2 استفاده میکند. این یک بخش واقعی از سیستم عامل است که مایکروسافت آن را به عنوان یک “وب رپر” ساخته است. حتی وقتی با آن تعامل میکنید، رم بیشتری مصرف میکند. آیا جای سرزنش شرکت متا یا سایر شرکتها باقی میماند؟
کاتالوگ برنامههای اپل بهینهتر و بومیسازی شده است
کاربران اپل نسبت به برنامههای با کیفیت پایین تحمل بسیار کمتری دارند. آنها تجربههای بومی (Native)، سریع و روان را طلب میکنند. این فشار توسعهدهندگان را وادار میکند تا روی برنامههای بومی macOS سرمایهگذاری کنند، حتی زمانی که پرهزینهتر است. دشواری ساخت برنامههای بومی در macOS نیز به این مسئله اضافه میشود.
با کمال تعجب، توسعه برنامههای بومی ویندوز آسانتر از برنامههای macOS است. دلیل این امر فراهم کردن یک اکوسیستم یکپارچه توسط مایکروسافت با فریمورکهای بالغی مانند .NET، WPF و UWP/WinUI است. همه اینها به طور محکمی با ویژوال استودیو ادغام شدهاند و سازگاری گستردهای با نسخههای قدیمیتر نیز دارند.
توسعه macOS نیازمند کار با Cocoa و APIهای Swift/Objective-C از طریق Xcode است، که قوانین سختگیرانهتری برای سندباکسسازی، امضا و توزیع در اپ استور دارد. همچنین توسعهدهندگان ویندوز به پشتیبانی زبانهای برنامهنویسی گستردهتری با محدودیتهای سختگیرانه (gatekeeping constraints) بسیار کمتری دسترسی دارند. همانطور که انتظار میرود، توسعهدهندگان macOS به دلیل اکوسیستم سختگیرانه اپل و استفاده از APIهای مختص پلتفرم، باید با منحنی یادگیری شیبدارتری دست و پنجه نرم کنند.
اما کاربران ویندوز به نرمافزارهای دسکتاپ مبتنی بر وب عادت کردهاند و توسعهدهندگان از این موضوع آگاه هستند. تا زمانی که برنامه کار میکند، حتی اگر کندتر باشد، بازخورد منفی (backlash) ملایم است. بنابراین، شرکتها با سرمایهگذاری کمتر در این بخش، پاسخ مناسبی میدهند.
همه اینها به دلیل دلیل اولیه اپل برای عرضه نکردن کامپیوترهای ارزان قیمت (Budget PCs) است. اکنون، اکثر مشتریان آنها قدرت خرید بالاتری دارند و کل شرکت به عنوان یک برند لوکس دیده میشود، و به همین دلیل است که مک بوک ارزان قیمت (budget MacBook) آینده میتواند باعث سردرد جدی برای تولیدکنندگان کامپیوترهای شخصی شود.
متقاعد کردن شرکتها و توسعهدهندگانشان برای نوشتن کدهای بومی (Native) برای ویندوز، صرفاً به خاطر بهینهسازی و مصرف کمتر رم، غیرواقعی میشود؛ زیرا مدل مبتنی بر مرورگر ارزانتر است، میتواند به هر جایی ارسال شود و کاربران هم به اندازه قبل اعتراض نمیکنند.
قیمتهای رم در حال افزایش هستند و این وضعیت قرار نیست تغییر کند.
زمانبندی این مسائل از این بدتر نمیشد. قیمت رم در بسیاری موارد تقریباً دو برابر شده است که عمدتاً ناشی از کاهش عرضه به مصرفکنندگان عادی، چرخههای قیمتگذاری تهاجمی DDR5، و مهمتر از همه تقاضای بسیار زیادی است که توسط مراکز داده هوش مصنوعی ایجاد شده است. تولیدکنندگان حافظه اکنون تراشههای سازمانی با حاشیه سود بالا را در اولویت قرار میدهند.
هیچ راهحل جادویی برای وضعیت کنونی برنامههای ویندوز وجود ندارد. مایکروسافت بزرگترین نقش را در این میان ایفا میکند، چرا که ما هیچ منفعتی برای توسعهدهندگان نمیبینیم. این شرکت میتواند توسعهدهندگان را دوباره به سمت ابزارهای بومی سوق دهد، WinUI را اصلاح کند تا جذابتر شود، و با رفع مشکلات قدیمی در ویندوز نشان دهد که کیفیت اصلی سیستم هنوز اهمیت دارد.
اگر ویندوز قرار است در دنیایی مبتنی بر برنامههای مرورگرمحور باشد، ابتدا خود پلتفرم باید پیشگام باشد و به کاربران و توسعهدهندگان پایهای بهتر برای کار ارائه دهد.
