ضبط تتبُّع النظام

يمكنك إعداد تتبُّع النظام لتسجيل ملف تعريف وحدة المعالجة المركزية (CPU) وسلسلة المحادثات لتطبيقك خلال فترة زمنية قصيرة. وبعد ذلك يمكنك استخدام تقرير الإخراج من نظام تتبُّع النظام لتحسين أداء لعبتك.

إعداد عملية تتبُّع النظام المستنِدة إلى الألعاب

تتوفر أداة Systrace بطريقتين:

وSystrace هي أداة منخفضة المستوى يمكنها:

  • يقدِّم معلومات موثوقة: يلتقط Systrace المخرجات مباشرةً من النواة، لذا تكون المقاييس التي يلتقطها متطابقة تقريبًا مع المقاييس التي ستسجّلها سلسلة من استدعاءات النظام.
  • تستهلك موارد قليلة. تقدّم Systrace قدرًا منخفضًا جدًا من النفقات العامة على الجهاز، وعادةً ما تكون أقل من 1%، لأنّها تبثّ البيانات إلى مخزن احتياطي في الذاكرة.

الإعدادات المثلى

من المهم إعطاء الأداة مجموعة معقولة من الوسيطات:

  • الفئات: أفضل مجموعة من الفئات المطلوب تفعيلها لتتبع نظام مستند إلى الألعاب هي: {sched وfreq وidle وam وwm وgfx وview وsync وbinder_driver وhal وdalvik}.
  • حجم ذاكرة التخزين المؤقت: القاعدة العامة هي أن حجم ذاكرة التخزين المؤقت الذي يبلغ 10 ميغابايت لكل وحدة معالجة مركزية (CPU) يسمح بتتبع مدته حوالي 20 ثانية. على سبيل المثال، إذا كان الجهاز يحتوي على وحدتَي معالجة مركزية (CPU) رباعية النواة (إجمالي 8 نوى)، تكون القيمة المناسبة لتمريرها إلى برنامج systrace هي 80,000 كيلوبايت (80 ميغابايت).

    إذا كانت لعبتك تبدِّل السياق كثيرًا، زِد سعة التخزين المؤقت إلى 15 ميغابايت لكل وحدة معالجة مركزية.

  • الأحداث المخصّصة: في حال تحديد أحداث مخصّصة لتسجيلها في لعبتك، عليك تفعيل علامة -a التي تسمح لـ Systrace بتضمين هذه الأحداث المخصّصة في تقرير النتائج.

إذا كنت تستخدم برنامج سطر الأوامر systrace، استخدِم الأمر التالي لتسجيل تتبُّع النظام الذي يطبّق أفضل الممارسات لمجموعة الفئات وحجم المخزن المؤقت والأحداث المخصّصة:

python systrace.py -a com.example.myapp -b 80000 -o my_systrace_report.html \
  sched freq idle am wm gfx view sync binder_driver hal dalvik

إذا كنت تستخدم تطبيق نظام Systrace على أحد الأجهزة، فأكمل الخطوات التالية لتسجيل تتبّع نظام يطبّق أفضل الممارسات لمجموعة الفئات وحجم المخزن المؤقت والأحداث المخصّصة:

  1. فعِّل الخيار تتبُّع التطبيقات التي يمكن تصحيح الأخطاء بها.

    لاستخدام هذا الإعداد، يجب أن يكون حجم الجهاز 256 ميغابايت أو 512 ميغابايت (حسب ما إذا كانت وحدة المعالجة المركزية (CPU) تحتوي على 4 أو 8 نوى أم لا)، ويجب أن تكون كل جزء من الذاكرة بحجم 64 ميغابايت متاحًا كقطعة متجاورة.

  2. اختر الفئات، ثم فعِّل الفئات في القائمة التالية:

    • am: مدير النشاط
    • binder_driver: برنامج تشغيل Binder Kernel
    • dalvik: جهاز افتراضي من Dalvik
    • freq: تردد وحدة المعالجة المركزية
    • gfx: الرسومات
    • hal: وحدات الأجهزة
    • idle: وحدة المعالجة المركزية غير نشطة
    • sched: جدولة وحدة المعالجة المركزية (CPU)
    • sync: المزامنة
    • view: الاطّلاع على النظام
    • wm: مدير النوافذ
  3. فعِّل ميزة تتبُّع التسجيلات.

  4. تحميل اللعبة

  5. يمكنك إجراء التفاعلات في لعبتك بما يتوافق مع أسلوب اللعب الذي تريد قياس أداء الجهاز الخاص به.

  6. بعد وقت قصير من مصادفة سلوك غير مرغوب فيه في لعبتك، عليك إيقاف ميزة "تتبُّع النظام".

لقد سجّلت إحصاءات الأداء اللازمة لتحليل المشكلة بشكل أكبر.

لتوفير مساحة على القرص، تحفظ عمليات تتبُّع النظام على الجهاز الملفات بتنسيق تتبُّع مضغوط (*.ctrace). لفك ضغط هذا الملف عند إنشاء تقرير، استخدِم برنامج سطر الأوامر وضمِّن خيار --from-file:

python systrace.py --from-file=/data/local/traces/my_game_trace.ctrace \
  -o my_systrace_report.html

تحسين جوانب أداء معيّنة

يسلط هذا القسم الضوء على العديد من المخاوف الشائعة بشأن الأداء في الألعاب على الأجهزة الجوّالة ويصف كيفية تحديد هذه الجوانب في لعبتك وتحسينها.

سرعة التحميل

يريد اللاعبون الدخول في أسرع وقت ممكن أثناء تشغيل اللعبة، لذا من المهم تحسين أوقات تحميل اللعبة قدر الإمكان. تساعد عادةً الإجراءات التالية في أوقات التحميل:

  • نفِّذ التحميل الكسول. في حال استخدام مواد العرض نفسها في مشاهد أو مستويات متتالية في لعبتك، يمكنك تحميل مواد العرض هذه مرة واحدة فقط.
  • تقليل حجم مواد العرض: وبهذه الطريقة، يمكنك تجميع النُسخ غير المضغوطة من مواد العرض هذه مع حزمة APK الخاصة باللعبة.
  • استخدِم طريقة ضغط فعّالة للقرص: ومن الأمثلة على هذه الطريقة zlib.
  • استخدام IL2CPP بدلاً من mono (ينطبق فقط في حال استخدام Unity). يوفر IL2CPP أداء تنفيذ أفضل لنصوص C# البرمجية الخاصة بك.
  • استخدام سلاسل محادثات متعددة في لعبتك: لمزيد من التفاصيل، يُرجى الاطّلاع على قسم تناسق الإطارات.

اتساق معدل عرض الإطارات

إنّ تحقيق معدّل عرض إطارات ثابت لذلك من أهم فوائد تجربة اللعب. لتسهيل تحقيق هذا الهدف، اتبع أساليب التحسين التي تمت مناقشتها في هذا القسم.

تعدد سلاسل المحادثات

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

يعرض النظام الذي يظهر في الشكل 1 سلوكًا نموذجيًا للعبة يتم تشغيلها على وحدة معالجة مركزية (CPU) واحدة فقط في كل مرة:

رسم تخطيطي للسلاسل
ضمن تتبع النظام

الشكل 1. تقرير Systrace للعبة ذات سلسلة واحدة

لتحسين أداء لعبتك، يمكنك استخدام سلاسل المحادثات المتعددة في لعبتك. عادةً ما يكون أفضل نموذج هو الحصول على سلسلتين:

  • سلسلة محادثات لعبة تحتوي على الوحدات الرئيسية للعبتك وترسل أوامر العرض.
  • سلسلة تعليمات العرض التي تتلقى أوامر العرض وتحوّلها إلى أوامر رسومات يمكن أن تستخدمها وحدة معالجة الرسومات في الجهاز لعرض مشهد.

تتوسع واجهة برمجة تطبيقات Vulkan بناءً على هذا النموذج، نظرًا لقدرتها على دفع موردين احتياطيين مشتركين بالتوازي. وباستخدام هذه الميزة، يمكنك توزيع خيوط عرض متعددة عبر وحدات معالجة مركزية متعددة، ما يؤدي إلى تحسين وقت عرض المشهد.

يمكنك أيضًا إجراء بعض التغييرات الخاصة بمحرّك البحث لتحسين أداء سلاسل التعليمات المتعدِّدة في لعبتك:

  • إذا كنت تطوِّر لعبتك باستخدام محرّك ألعاب Unity، فعِّل الخيارَين العرض المتعدّد السلاسل وتغيير إعدادات وحدة معالجة الرسومات.
  • إذا كنت تستخدم محرك عرض مخصّصًا، احرص على محاذاة مسار أوامر العرض ومسار أوامر الرسومات بشكل صحيح، وإلا فقد يؤدي ذلك إلى حدوث تأخير في عرض مَشاهد لعبتك.

بعد تطبيق هذه التغييرات، يُفترض أن ترى لعبتك تشغل وحدتَي معالجة مركزية على الأقل في الوقت نفسه، كما هو موضَّح في الشكل 2:

رسم تخطيطي للسلاسل
ضمن تتبع النظام

الشكل 2. تقرير Systrace للعبة ذات سلاسل محادثات متعددة

جارٍ تحميل عنصر في واجهة المستخدم

رسم تخطيطي لحزمة إطارات ضمن تتبُّع نظام
الشكل 3. تقرير Systrace للعبة فيديو تعرض العشرات من عناصر واجهة المستخدم في الوقت نفسه

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

تقرير Systrace الموضح في الشكل 3 هو مثال لإطار واجهة المستخدم الذي يحاول عرض عدد كبير جدًا من العناصر بالنسبة إلى إمكانات الجهاز المحمول.

من الأفضل تقليل وقت تحديث واجهة المستخدم إلى 2-3 ميلي ثانية. يمكنك تحقيق هذه التحديثات السريعة من خلال إجراء تحسينات مشابهة لما يلي:

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

استهلاك الطاقة

حتى بعد إجراء التحسينات التي تمت مناقشتها في القسم السابق، قد تلاحظ تدهور معدل عرض الإطارات في لعبتك خلال أول 45 إلى 50 دقيقة من اللعب. علاوة على ذلك، قد يبدأ الجهاز في الارتفاع واستهلاك المزيد من طاقة البطارية بمرور الوقت.

في كثير من الحالات، ترتبط هذه المجموعة غير المرغوب فيها من الطاقة الحرارية واستهلاك الطاقة بكيفية توزيع أعباء عمل اللعبة على وحدات المعالجة المركزية للجهاز. لزيادة كفاءة استهلاك الطاقة في لعبتك، يمكنك تطبيق أفضل الممارسات الموضحة في الأقسام التالية.

الاحتفاظ بسلاسل البيانات التي تكون كبيرة في الذاكرة في وحدة معالجة مركزية واحدة

في العديد من الأجهزة المحمولة، توجد ذاكرات التخزين المؤقت L1 على وحدات معالجة مركزية محددة، وتوجد ذاكرات التخزين المؤقت L2 على مجموعة من وحدات المعالجة المركزية التي تتشارك الساعة. لزيادة نتائج ذاكرة التخزين المؤقت L1 إلى أقصى حد، من الأفضل بشكل عام الإبقاء على السلسلة الرئيسية للعبتك، بالإضافة إلى أي سلاسل تعليمات أخرى ذات حجم كبير في الذاكرة، تعمل على وحدة معالجة مركزية واحدة.

تأجيل العمل قصير المدة إلى وحدات المعالجة المركزية (CPU) ذات الطاقة الأقل

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

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

يوضح التقرير المثالي المعروض في الشكل 4 لعبة تستفيد من وحدات المعالجة المركزية السريعة. مع ذلك، يولّد مستوى النشاط المرتفع هذا قدرًا كبيرًا من القوة والحرارة بسرعة.

رسم تخطيطي للسلاسل
ضمن تتبع النظام

الشكل 4. تقرير Systrace يعرض تخصيص سلاسل محادثات دون المستوى لوحدات المعالجة المركزية (CPU) للجهاز

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

تسرد معظم الأجهزة وحدات المعالجة المركزية البطيئة قبل وحدات المعالجة المركزية السريعة، ولكن لا يمكنك افتراض أنّ وحدة المعالجة المركزية (SOC) في جهازك تستخدم هذا الترتيب. للتحقق، قم بتشغيل أوامر مشابهة لتلك التي تظهر في رمز اكتشاف طوبولوجيا وحدة المعالجة المركزية هذا على GitHub.

بعد أن تعرِّف وحدات المعالجة المركزية (CPU) إلى وحدات المعالجة المركزية البطيئة على جهازك، يمكنك الإعلان عن التقاربات بين سلاسل المحادثات القصيرة المدة، وهذا ما تتّبعه أداة جدولة الأجهزة. للقيام بذلك، أضف الرمز التالي داخل كل سلسلة محادثات:

#include <sched.h>
#include <sys/types.h>
#include <unistd.h>

pid_t my_pid; // PID of the process containing your thread.

// Assumes that cpu0, cpu1, cpu2, and cpu3 are the "slow CPUs".
cpu_set_t my_cpu_set;
CPU_ZERO(&my_cpu_set);
CPU_SET(0, &my_cpu_set);
CPU_SET(1, &my_cpu_set);
CPU_SET(2, &my_cpu_set);
CPU_SET(3, &my_cpu_set);
sched_setaffinity(my_pid, sizeof(cpu_set_t), &my_cpu_set);

الإجهاد الحراري

قد يؤدي ارتفاع درجة حرارة الأجهزة إلى تقييد وحدة المعالجة المركزية (CPU) و/أو وحدة معالجة الرسومات (GPU)، ما قد يؤثر في الألعاب بطرق غير متوقَّعة. من المرجح أن تواجه الألعاب التي تتضمن رسومات معقدة أو عمليات حوسبة ثقيلة أو نشاطًا مستدامًا على الشبكة.

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

أولاً، عليك تعريف الكائن PowerManager وإعداده بطريقة onCreate(). أضِف أداة معالجة الحالة الحرارية إلى الكائن.

Kotlin

class MainActivity : AppCompatActivity() {
    lateinit var powerManager: PowerManager

    override fun onCreate(savedInstanceState: Bundle?) {
        powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
        powerManager.addThermalStatusListener(thermalListener)
    }
}

Java

public class MainActivity extends AppCompatActivity {
    PowerManager powerManager;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE);
        powerManager.addThermalStatusListener(thermalListener);
    }
}

حدد الإجراءات التي يجب اتخاذها عندما يكتشف المستمع تغيير الحالة. إذا كانت لعبتك تستخدم لغة C/C+ + ، يمكنك إضافة رمز إلى مستويات الحالة الحرارية في onThermalStatusChanged() من أجل استدعاء رمز اللعبة الأصلي باستخدام JNI، أو استخدام Thermal API.

Kotlin

val thermalListener = object : PowerManager.OnThermalStatusChangedListener() {
    override fun onThermalStatusChanged(status: Int) {
        when (status) {
            PowerManager.THERMAL_STATUS_NONE -> {
                // No thermal status, so no action necessary
            }

            PowerManager.THERMAL_STATUS_LIGHT -> {
                // Add code to handle light thermal increase
            }

            PowerManager.THERMAL_STATUS_MODERATE -> {
                // Add code to handle moderate thermal increase
            }

            PowerManager.THERMAL_STATUS_SEVERE -> {
                // Add code to handle severe thermal increase
            }

            PowerManager.THERMAL_STATUS_CRITICAL -> {
                // Add code to handle critical thermal increase
            }

            PowerManager.THERMAL_STATUS_EMERGENCY -> {
                // Add code to handle emergency thermal increase
            }

            PowerManager.THERMAL_STATUS_SHUTDOWN -> {
                // Add code to handle immediate shutdown
            }
        }
    }
}

Java

PowerManager.OnThermalStatusChangedListener thermalListener =
    new PowerManager.OnThermalStatusChangedListener () {

    @Override
    public void onThermalStatusChanged(int status) {

        switch (status)
        {
            case PowerManager.THERMAL_STATUS_NONE:
                // No thermal status, so no action necessary
                break;

            case PowerManager.THERMAL_STATUS_LIGHT:
                // Add code to handle light thermal increase
                break;

            case PowerManager.THERMAL_STATUS_MODERATE:
                // Add code to handle moderate thermal increase
                break;

            case PowerManager.THERMAL_STATUS_SEVERE:
                // Add code to handle severe thermal increase
                break;

            case PowerManager.THERMAL_STATUS_CRITICAL:
                // Add code to handle critical thermal increase
                break;

            case PowerManager.THERMAL_STATUS_EMERGENCY:
                // Add code to handle emergency thermal increase
                break;

            case PowerManager.THERMAL_STATUS_SHUTDOWN:
                // Add code to handle immediate shutdown
                break;
        }
    }
};

وقت استجابة اللمس للعرض

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

لتحديد ما إذا كان بإمكانك تحسين وتيرة عرض اللقطات في لعبتك، يُرجى إكمال الخطوات التالية:

  1. إنشاء تقرير Systrace يتضمّن الفئتين gfx وinput. وتضم هذه الفئات قياسات مفيدة بشكل خاص لتحديد وقت الاستجابة باللمس على العرض.
  2. راجِع القسم "SurfaceView" في تقرير Systrace. يتسبب المخزن المؤقت المكتظ

    رسم تخطيطي لقائمة انتظار
المخزن المؤقت ضمن تتبع النظام

    الشكل 5. تقرير Systrace يعرض موردًا احتياطيًا بشكل مفرط يكون ممتلئًا بشكل دوري جدًا بحيث لا يمكن قبول أوامر الرسم

للحدّ من هذا التناقض في وتيرة عرض اللقطات، يُرجى إكمال الإجراءات الموضّحة في الأقسام التالية:

دمج واجهة برمجة التطبيقات Android Frame Pacing API في لعبتك

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

تقليل درجة دقة مواد العرض التي لا تعتمد على واجهة المستخدم في اللعبة

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

مع ذلك، يجب عدم تقليل درجة دقة عناصر واجهة المستخدم في اللعبة. ومن المهم الحفاظ على سُمك الخط في هذه العناصر من أجل الحفاظ على حجم هدف اللمس كبير بما يكفي لجميع اللاعبين.

سهولة العرض

عندما يتم تثبيت SurfaceFlinger على مخزن مؤقت للشاشة لعرض مشهد في لعبتك، يزيد نشاط وحدة المعالجة المركزية (CPU) عن كثب. إذا حدث هذا الارتفاع في نشاط وحدة المعالجة المركزية (CPU) بوتيرة غير متساوية، من المحتمل حدوث تقطع في لعبتك. يوضح الرسم التخطيطي في الشكل 6 سبب حدوث ذلك:

رسم تخطيطي للإطارات التي تفتقر إلى
نافذة Vsync لأنها بدأت في الرسم بعد فوات الأوان

الشكل 6. تقرير Systrace يوضّح كيف يمكن لإطار معيّن أن يفوتك بيانات Vsync

إذا بدأ الإطار في الرسم بعد فوات الأوان، حتى بضع ثوانٍ، قد يفوتك نافذة العرض التالية. يجب أن ينتظر الإطار بعد ذلك حتى يتم عرض Vsync التالي (33 مللي ثانية عند تشغيل لعبة بمعدل 30 لقطة في الثانية)، ما يتسبب في حدوث تأخير ملحوظ من منظور اللاعب.

لمعالجة هذا الموقف، يمكنك استخدام واجهة برمجة التطبيقات لـ Android Frame Pacing التي تقدّم دائمًا إطارًا جديدًا على الواجهة الموجية لـ VSync.

حالة الذاكرة

عند تشغيل لعبتك لفترة زمنية طويلة، من الممكن أن يواجه الجهاز أخطاءً خارج الذاكرة.

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

لمزيد من المعلومات، راجِع إدارة الذاكرة بفعالية في الألعاب.

حالة سلسلة المحادثات

عند التنقّل بين العناصر النموذجية لتقرير Systrace، يمكنك عرض مقدار الوقت الذي تقضيه سلسلة محادثات معيّنة في كل حالة لسلسلة محادثات ممكنة من خلال اختيار السلسلة ضمن التقرير، كما هو موضّح في الشكل 7:

رسم تخطيطي لتقرير نظام

الشكل 7. تقرير Systrace يوضّح كيف يؤدي اختيار سلسلة محادثات إلى عرض التقرير لملخّص حالة لسلسلة المحادثات هذه.

كما هو موضّح في الشكل 7، قد تجد أنّ سلاسل المحادثات في لعبتك ليست في حالة "تشغيل" أو "قابل للتشغيل" بالمعدّل المطلوب. تعرض القائمة التالية العديد من الأسباب الشائعة التي قد تؤدي إلى نقل مؤشر ترابط معين بشكل دوري إلى حالة غير معتادة:

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

مراجع إضافية

لمعرفة المزيد من المعلومات حول تحسين أداء لعبتك، يمكنك الاطّلاع على الموارد الإضافية التالية:

الفيديوهات الطويلة

  • عرض تقديمي عن Systrace for Games من مؤتمر Android Game Developer Summit لعام 2018