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

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

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

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

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

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

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

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

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

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

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

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

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

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

قيود الذاكرة

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

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

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

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

حدود الذاكرة الجديدة في مؤشرات Play Console الحيوية

لمساعدة المطوّرين في تحديد مشاكل الذاكرة بشكلٍ استباقي، يقدّم Google Play مقاييس جديدة في مؤشرات Android الحيوية في Play Console. يتتبّع Play Console المئوي 90 (P90) من استهلاك الذاكرة المجهولة RSS + مساحة الإبدال لجلسات لعبتك لتحديد القيم المتطرفة.

يتم توسيع نطاق حدود التحذير والإنفاذ استنادًا إلى سعة ذاكرة الوصول العشوائي (RAM) الفعلية للجهاز وحالات العمليات. تنطبق هذه الحدود في مرحلتَين مختلفتَين.

للاطّلاع على الإرشادات التفصيلية وحدود الذاكرة، يُرجى مراجعة مؤشرات Android الحيوية - ما هي حدود السلوك السيئ؟.

خدمات يلاحظها المستخدم

الخدمات التي يمكن ملاحظتها هي عمليات مهمة في الخلفية يعتبر نظام Android أنّ المستخدم يلاحظها. تشمل هذه الحالة جميع العمليات قيد التشغيل:

  • الخدمات التي تعمل في المقدّمة (FGS)
  • المهام المُعجَّلة
  • مهام نقل البيانات التي يبدأها المستخدم
  • الخدمات المرتبطة بالنظام أو الخدمات المرتبطة بتطبيقات أخرى

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

متطلبات R8

لتقليل حجم الرمز الثانوي وتقليل النفقات العامة الأساسية لعملية Java، يقيّم Google Play Console تحسين الرموز البرمجية كجزء من إرشادات جودة التطبيق. لمزيد من التفاصيل حول ضبط مسار الإنشاء، يُرجى الاطّلاع على دليل تفعيل تحسين التطبيق باستخدام R8.

لضبط R8 في مشروعك، يُرجى اتّباع دليل تفعيل تحسين التطبيق باستخدام R8. لتفعيل إعدادات التصغير والتحسين المتقدّمة، يُرجى الاطّلاع على استخدام R8 في الوضع الكامل. لتحديد القواعد التي تمنع R8 من إخفاء الفئات أو إزالة الرموز البرمجية غير المستخدَمة، يُرجى استخدام أداة تحليل إعدادات R8.

متطلبات الصور النقطية

تمثّل الصور النقطية جزءًا كبيرًا من استخدام الذاكرة في الألعاب الحديثة عالية الدقة. نظرًا إلى أنّ بيانات وحدات البكسل في الصور النقطية يتم تخزينها مباشرةً في الكومة الأصلية غير المُدارة على Android 8.0 (مستوى واجهة برمجة التطبيقات 26) والإصدارات الأحدث، يمكن أن يؤدي تحميل الصور غير المحسّن إلى تجاوز العمليات لحدود الذاكرة على مستوى النظام الأساسي. للاطّلاع على أفضل الممارسات المتعلّقة بتغيير حجم الصور وتخزينها مؤقتًا، يُرجى مراجعة تحسين استخدام الصور.

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

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

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

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

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

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