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

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

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

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

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

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

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

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

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

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

  • الأحداث المخصّصة: في حال تحديد الأحداث المخصّصة الأحداث التي يجب تسجيلها في لعبتك، عليك تفعيل علامة -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: تردّد وحدة المعالجة المركزية (CPU)
    • gfx: رسومات
    • hal: وحدات الأجهزة
    • idle: وحدة معالجة مركزية (CPU) غير نشِطة
    • 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 بدلاً من أحادية الاتجاه. (ينطبق ذلك فقط في حال استخدام Unity). توفّر IL2CPP تجربة أفضل أداء تنفيذ النصوص البرمجية في C#
  • تحويل لعبتك إلى سلاسل محادثات لمزيد من التفاصيل، راجِع معدل الإطارات الاتساق.

اتساق عدد اللقطات في الثانية

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

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

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

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

مخطّط بياني لسلاسل المحادثات
ضمن عملية تتبُّع النظام

الشكل 1. تقرير النظام الأساسي للعبة تتضمّن سلسلة محادثات واحدة

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

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

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

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

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

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

مخطّط بياني لسلاسل المحادثات
ضمن عملية تتبُّع النظام

الشكل 2. تقرير النظام الأساسي للعبة متعددة السلاسل

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مخطّط بياني لسلاسل المحادثات
ضمن عملية تتبُّع النظام

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

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

تسرد معظم الأجهزة وحدات المعالجة المركزية البطيئة قبل وحدات المعالجة المركزية السريعة، ولكن لا يمكنك افتراض أن يستخدم نظام SOC في جهازك هذا الطلب. للتحقّق من ذلك، يمكنك تشغيل أوامر مشابهة للأوامر كما هو موضح في استكشاف هيكل وحدة المعالجة المركزية (CPU) الرمز على 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) و/أو وحدة معالجة الرسومات، ما قد يؤدي إلى تؤثر في الألعاب بطرق غير متوقعة. ألعابًا تتضمن رسومات معقدة الحساب أو نشاط الشبكة المستمر غالبًا.

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

أولاً، عليك تعريف الكائن 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;
        }
    }
};

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

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

لتحديد ما إذا كان بإمكانك تحسين سرعة عرض الإطارات في لعبتك، أكمِل الخطوات التالية:

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

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

    الشكل 5. تقرير نظام التشغيل يُظهر موردًا احتياطيًا مكتئبًا بشكل زائد ممتلئ بشكل دوري بحيث لا يمكن قبول أوامر الرسم

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

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

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

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

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

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

سلاسة العرض

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

مخطّط بياني للإطارات
غياب نافذة Vsync لأنهم بدأوا الرسم في وقت متأخر جدًا

الشكل 6. تقرير عن النظام يعرض كيف يمكن أن يفوت أحد الإطار حدث Vsync

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

لمعالجة هذا الموقف، استخدِم تتبُّع سرعة إطار Android. API، التي تعرض دائمًا إطارًا جديدًا على واجهة موجة VSync

حالة الذاكرة

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

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

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

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

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

مخطّط بياني
تقرير النظام

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

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

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

مصادر إضافية

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

الفيديوهات

  • العرض التقديمي حول Systrace للألعاب من مؤتمر Android Game Developer Summit لعام 2018