لمحة عن إدارة الذاكرة

يُعدّ تحسين الذاكرة أمرًا بالغ الأهمية لتقديم تجارب ألعاب مستقرة وعالية الأداء على Android. يقدّم هذا الدليل نظرة عامة على أهمية كفاءة الذاكرة، وكيفية إدارة نظام التشغيل Android لحدود ذاكرة العمليات وفرضها، والحدود الجديدة التي تم عرضها في Google Play Console لمساعدتك في مراقبة الجودة الفنية للعبتك وتحسينها.

أهمية تحسين الذاكرة

يُعدّ تحسين ذاكرة لعبتك أمرًا ضروريًا للحفاظ على معدّل الحفاظ على اللاعبين وتوسيع نطاق توافق الأجهزة والامتثال لمعايير الجودة على مستوى النظام الأساسي:

• منع بدء التشغيل البارد (تجربة المستخدم ومعدّل الحفاظ على المستخدمين): عندما ينتقل اللاعب مؤقتًا من لعبتك (على سبيل المثال، للردّ على إشعار أو الاطّلاع على رسالة)، يضع نظام التشغيل عملية اللعبة في الخلفية. إذا كان استهلاك الذاكرة في الخلفية للعبة مرتفعًا جدًا، ستعطي أداة Low Memory Killer (LMK) في النظام الأولوية لإنهاء عملية اللعبة لاستعادة ذاكرة الوصول العشوائي (RAM) للمهام في المقدّمة. في المرة التالية التي يستأنف فيها المستخدم اللعب، يجب أن تخضع اللعبة لعملية تشغيل على البارد طويلة، بدلاً من استئناف سلس وفوري، ما يعني إعادة تحميل أصول الرسومات الثقيلة والصوت والملفات الثنائية لمحرك اللعبة بالكامل من مساحة التخزين. يؤدي الحفاظ على انخفاض استخدام الذاكرة في الخلفية إلى منع عمليات الإنهاء الصامتة في الخلفية، ما يحافظ على حالة المستخدم ويضمن إمكانية استئناف اللاعبين لجلساتهم على الفور. لمزيد من التفاصيل حول سلوك أداة LMK في النظام، يُرجى الاطّلاع على دليل Android Vitals - Low memory killers.
• استقرار المنظومة المتكاملة والجهاز: يؤدي الاستخدام غير الفعّال للذاكرة وتسرب الذاكرة إلى تدهور الحالة العامة للنظام. عندما تكون ذاكرة النظام شحيحة، يواجه النظام ضغطًا شديدًا، ما يؤدي إلى انخفاض معدّل الإطارات وتلعثم واجهة المستخدم وحدوث أعطال في الصوت. إذا كان ضغط الذاكرة شديدًا جدًا، ستنهي أداة Low Memory Killer (LMK) في النظام العمليات في الخلفية بشكلٍ صارم، ما يجبر التطبيقات الأخرى على بدء التشغيل البارد ببطء وفقدان حالة المستخدم عندما ينتقل اللاعبون بين المهام.
• عمليات الإنهاء على مستوى النظام الأساسي: بدءًا من Android 17 (المستوى 37 من واجهة برمجة التطبيقات)، أصبح النظام أكثر استباقية بشأن إنهاء العمليات التي تستخدم الكثير من الذاكرة. إذا كان استهلاك لعبتك للذاكرة مرتفعًا جدًا، يمكن لنظام التشغيل إنهاء عمليتها فجأة بدون إنشاء تتبع تسلسل استدعاء الدوال البرمجية عادي.
• توافق الأجهزة: في حين أنّ الأجهزة الرائدة تتضمّن ذاكرة وصول عشوائي (RAM) بسعة تتراوح بين 12 غيغابايت و16 غيغابايت، يستخدم جزء كبير من جمهور الألعاب العالمي أجهزة تتضمّن ذاكرة وصول عشوائي (RAM) بسعة 4 غيغابايت أو 6 غيغابايت. تضمن إدارة الذاكرة بشكلٍ صحيح إمكانية الوصول إلى لعبتك واستجابتها على جميع مستويات الأجهزة بدون الحاجة إلى حِزم مواد عرض معقدة ومنفصلة.

التعرّف على الذاكرة في Android

لتصميم استراتيجيات فعّالة لتحديد ميزانية الذاكرة، على المطوّرين فهم كيفية إدارة نظام Android الأساسي للذاكرة الفعلية وكيفية قياس استهلاك لعبتك النشط للذاكرة.

المفاهيم الأساسية للذاكرة في Android

للاطّلاع على المفاهيم الأساسية المتعلقة بإدارة الذاكرة على مستوى النظام الأساسي، يُرجى مراجعة مستند النظرة العامة على إدارة الذاكرة الرسمي. يغطّي هذا المرجع أربعة مجالات معمارية:

• نظرة عامة على الذاكرة: يستخدم Android الترحيل وتقسيم الذاكرة (mmap) لإدارة ذاكرة الوصول العشوائي (RAM). لا يتيح نظام Android ملف تبديل تقليديًا على القرص، بل يعتمد بدلاً من ذلك على ضغط الصفحات (باستخدام zRAM) واستعادة الصفحات لتحرير الذاكرة الفعلية.
• توزيع الذاكرة بين العمليات: يشارك Android ذاكرة الوصول العشوائي (RAM) على مستوى النظام بأكمله. يخصّص النظام مساحات تخزين مؤقتة معيّنة لتنفيذ الآلة الافتراضية Dalvik أو ART، مع السماح لبيئات التطوير الأصلية (مثل محركات ألعاب C++) بطلب الذاكرة من مساحة التخزين المؤقتة للنظام الأصلية.
• إدارة ذاكرة التطبيق: بموجب نموذج متعدد العمليات، يتوقّع Android من التطبيقات مراقبة حالة دورة حياتها بشكلٍ ديناميكي و إصدار الموارد غير الضرورية طوعًا (مثل الرسومات النقطية و الرسومات غير المخزّنة مؤقتًا) للحفاظ على سلامة النظام.
• نظرة عامة على العمليات والتعليمات البرمجية: يصنّف النظام العمليات في تسلسل هرمي استنادًا إلى مستوى ظهورها وأهميتها الحالية للمستخدم، ما يحدّد العمليات التي يتم إبقاؤها نشطة والعمليات التي يتم إنهاؤها أولاً في حالات نقص الذاكرة.

مقياس إجمالي استهلاك الذاكرة

يقيّم أداة Memory Limiter في Android 17 على مستوى النظام الأساسي استهلاك العمليات باستخدام إجمالي استهلاك الذاكرة بدلاً من إجمالي الحجم المقيم (RSS) أو حجم الذاكرة الافتراضية.

إجمالي استهلاك الذاكرة = الحجم المقيم المجهول (RssAnon) + التبديل غير المضغوط (VmSwap)

لمنع الألعاب من تجاوز الحدود التي يفرضها النظام الأساسي، على المطوّرين فهم ما تمثله هذه المقاييس بالضبط على مستوى النظام. لمزيد من المعلومات حول هذه المقاييس وعمليات تخصيص ذاكرة الوصول العشوائي (RAM) الفعلية وكيفية التعامل مع الصفحات المستندة إلى الملفات، يُرجى الاطّلاع على مقالة فهم مقياسَي الحجم المقيم (RSS) والتبديل في دليل مراقبة استخدام الذاكرة.

قيود الذاكرة

للحفاظ على استقرار النظام وضمان عدم استهلاك التطبيقات لموارد مفرطة، يفرض نظام Android الأساسي حدودًا للذاكرة على العمليات قيد التشغيل.

أداة Memory Limiter في Android 17 والإصدارات الأحدث

يفرض Android 17 والإصدارات الأحدث حدودًا صارمة للذاكرة لكل تطبيق باستخدام Linux cgroup v2 لمنع التطبيقات الفردية من التسبب في عدم استقرار النظام بأكمله. لمزيد من التفاصيل حول التنفيذ الفني، يُرجى الاطّلاع على دليل AOSP Memory Limiter ومقالة منح الأولوية لكفاءة الذاكرة: خطوات أساسية لنظام Android 17 في المدونة.

• الآلية: تراقب أداة Memory Limiter جميع عمليات التطبيق وتخصّص الحدود بشكلٍ ديناميكي استنادًا إلى حالة دورة حياة العملية:
  • العمليات المرئية (في المقدّمة): من المتوقّع أن تشغّل عمليات التطبيق التي تعرض حاليًا واجهة مستخدم مجموعة عمل أكبر من الموارد، ويتم منحها حدًا أكثر سخاءً.
  • العمليات غير المرئية (في الخلفية أو الخدمات): تخضع عمليات التطبيق التي تنفّذ عملاً نشطًا بدون عرض واجهة مستخدم لميزانية أكثر صرامة وأكثر تقييدًا.
• سمات النواة: تعتمد الخدمة على سمتَين رئيسيتَين:
  • memory.high: حدّ أقصى مرن. عند تجاوز هذا الحد، تقلّل النواة من سرعة العملية وتحاول استعادة الذاكرة بشكلٍ صارم. يمكن أن تؤدي عملية الاستعادة هذه إلى تدهور أداء اللعبة.
  • memory.swap.max: يفرض حدًا أقصى صارمًا على مساحة التبديل أو zRAM التي يمكن أن تستخدمها العملية.
• سلوك الإنهاء: إذا استمرت إحدى العمليات في تخصيص ذاكرة مجهولة بعد memory.high واستنفدت سعة التبديل، ستفشل عمليات التخصيص، وسيوقف نظام التشغيل العملية بدون إشعار. يتم تسجيل عملية الإنهاء هذه باستخدام ApplicationExitInfo ضمن سبب الخروج من Memory Limiter (المتاح بدءًا من Android 17، الربع الرابع من عام 2026).

مراقبة استخدام الذاكرة

لتحسين ذاكرة لعبتك بشكلٍ فعّال، عليك أولاً فهم كيفية قياس نظام Android الأساسي لاستهلاكها للذاكرة. يعدّل Android 17 مقياس فرض الذاكرة لتتبُّع مجموع الحجم المقيم المجهول (RssAnon) والتبديل غير المضغوط (VmSwap)، باستثناء الذاكرة المستندة إلى الملفات أو الذاكرة الخاصة بوحدة معالجة الرسومات (GPU). يوضّح هذا الدليل كيفية الاستفادة من الأدوات على مستوى النظام، مثل Perfetto وmeminfo، وتنفيذ واجهات برمجة التطبيقات التشخيصية، مثل ProfilingManager وonTrimMemory، واستخراج عمليات تخصيص الذاكرة الدقيقة في Unity وUnreal Engine. تعرَّف على كيفية تحديد ملف أداء لعبتك بدقة وتجنُّب حالات التلعثم في الأداء المرتبطة باستطلاع الذاكرة التقليدي في وقت التشغيل.

لمزيد من المعلومات، يُرجى الاطّلاع على مراقبة استخدام الذاكرة.

استراتيجيات تقليل الذاكرة

في حين أنّ محركات الألعاب تسهّل عملية التطوير من عدّة منصات، يمكن أن يؤدي التعامل التلقائي مع الذاكرة إلى تفعيل حدود الذاكرة على مستوى نظام التشغيل. توضّح هذه الصفحة خطوات التحسين العملية المصمّمة خصيصًا لـ Unity وUnreal Engine. تعرَّف على سبب إمكانية أن يؤدي الاعتماد على onTrimMemory المستند إلى Java إلى حدوث حالات توقف تام في Unity، وكيفية استخدام عمليات معاودة الاتصال بدورة الحياة الأصلية بدلاً من ذلك. ستتعرّف أيضًا على عمليات التحسين الرئيسية على مستوى مواد العرض، مثل استخدام ضغط نسيج ASTC 8x8 وإعداد عمليات إلغاء تحميل مواد العرض، للحفاظ على تشغيل لعبتك بسلاسة على جميع مستويات الأجهزة.