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

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

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

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

Groovy

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 Studio، انقر على الرابط تتبُّع تنفيذ الدوال البرمجية أو تتبُّع أخذ عيّنات من سلسلة استدعاء الدوال البرمجية في نتائج الاختبار المعياري المصغّر.

MethodTracing

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

يتم إنشاء الملفات الشخصية بالتسلسل بعد قياس الرمز، لذا يعرض الاختبار نتائج دقيقة للتوقيت ولإنشاء الملفات الشخصية.

تكون ميزة "تتبُّع أسلوب التنفيذ" مفعَّلة تلقائيًا.

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

StackSampling

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

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

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

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

  • androidx.benchmark.profiling.sampleFrequency

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

  • androidx.benchmark.profiling.sampleDurationSeconds

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

  • androidx.benchmark.profiling.skipWhenDurationRisksAnr

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

ما مِن قيود مفروضة

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

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