إضافة مقاييس أداء مصغَّرة

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

لاختيار إعدادات محلّل الأداء، أضِف وسيطة مشغّل قياس حالة التطبيق androidx.benchmark.profiling.mode مع إحدى MethodTracing (تلقائي) أو StackSampling أو None، كما هو موضّح في المقتطف التالي.

لمزيد من المعلومات حول الخيارات، يُرجى الاطّلاع على مقالة تسجيل طرق Java/Kotlin. تُعادل MethodTracing عملية التتبُّع، وتُعادل StackSampling عملية أخذ العيّنات كما هو محدّد في ذلك المستند.

أنيق

android {
    defaultConfig {
        // must be one of: 'None', 'StackSampling', or 'MethodTracing'
        testInstrumentationRunnerArguments["androidx.benchmark.profiling.mode"]= 'StackSampling'
    }
}

Kotlin

android {
    defaultConfig {
        // must be one of: 'None', 'StackSampling', or 'MethodTracing'
        testInstrumentationRunnerArguments["androidx.benchmark.profiling.mode"] = "StackSampling"
    }
}

عند تحديد أداء اختبار معياري، يتم نسخ ملف .trace الناتج إلى المضيف في الدليل بجانب نتائج JSON. لفحص نتائج تحديد الأداء في "استوديو Android"، انقر على الرابط تتبُّع الطريقة أو تتبُّع أخذ عيّنات من المكدس في نتائج الاختبار المعياري الدقيق.

MethodTracing

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

يحدث تحديد الأداء بالتسلسل بعد قياس الرمز البرمجي، لذا يعرض الاختبار نتائج دقيقة لكل من التوقيت وتحديد الأداء.

تكون ميزة تتبُّع الطريقة مفعَّلة تلقائيًا.

ملاحظة: في بعض إصدارات نظام التشغيل Android وART، تكون ميزة تتبُّع الطريقة غير مفعَّلة تلقائيًا. وفي هذه الحالات، يعرض "استوديو Android" تحذيرًا.

StackSampling

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

باستخدام أخذ عيّنات من المكدس، يأخذ الاختبار المعياري عيّنات من مكدسات الطلبات بعد اكتمال عملية الإحماء. يمكنك التحكّم في سلوك أخذ العيّنات، مثل تكرار العيّنات و مدة أخذ العيّنات، باستخدام وسيطات قياس حالة التطبيق.

على Android 10 (المستوى 29 من واجهة برمجة التطبيقات) والإصدارات الأحدث، يستخدم أخذ عيّنات من المكدس Simpleperf لأخذ عيّنات من مكدسات طلبات التطبيق، بما في ذلك رمز C++ البرمجي. على Android 9 (المستوى 28 من واجهة برمجة التطبيقات) والإصدارات الأقدم، يستخدم Debug.startMethodTracingSampling لتسجيل عيّنات المكدس.

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

  • androidx.benchmark.profiling.sampleFrequency

    • عدد عيّنات المكدس التي سيتم تسجيلها في الثانية
    • نوع الوسيطة: عدد صحيح
    • القيمة التلقائية هي 1000 عينة في الثانية.

  • androidx.benchmark.profiling.sampleDurationSeconds

    • مدة تشغيل الاختبار المعياري
    • نوع الوسيطة: عدد صحيح
    • القيمة التلقائية هي 5 ثوانٍ.

  • androidx.benchmark.profiling.skipWhenDurationRisksAnr

    • يتخطّى تتبُّع الطريقة عندما يكون من المحتمل أن يتسبب في حدوث خطأ ANR. يجب أن يبقى هذا الخيار مفعَّلاً لعمليات تشغيل التكامل المستمر، لأنّ أخطاء ANR يمكن أن تسبب مشاكل أثناء عمليات تشغيل التكامل المستمر الطويلة.
    • نوع الوسيطة: قيمة منطقية
    • القيمة التلقائية هي true

بدون

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

السابق
كتابة مقياس أداء
التالي
وسيطات أدوات قياس الأداء المصغّرة