ننصحك باستخدام مقاييس الأداء الإجمالية في Jetpack لاختبار أداء التطبيق عند تفعيل ملفّات الأداء الأساسي، ثم مقارنة هذه النتائج بمقياس أداء مع إيقاف ملفّات الأداء الأساسي. باستخدام هذا النهج، يمكنك قياس وقت بدء تشغيل التطبيق، سواءً الوقت المستغرَق للعرض الأولي أو الكامل، أو قياس أداء عرض وقت التشغيل لمعرفة ما إذا كانت اللقطات التي يتم إنشاؤها يمكن أن تتسبب في حدوث تقطُّع.
تتيح لك اختبارات الأداء على مستوى التطبيق التحكّم في عملية تجميع القياس المُسبَق باستخدام واجهة برمجة التطبيقات
CompilationMode
. استخدِم قيمًا مختلفة من CompilationMode
لمقارنة
الأداء بحالات الترجمة المختلفة. يوضّح مقتطف الرمز التالي كيفية استخدام المَعلمة CompilationMode
لقياس فائدة ملفّات CompilationMode
الشخصية الأساسية:
@RunWith(AndroidJUnit4ClassRunner::class) class ColdStartupBenchmark { @get:Rule val benchmarkRule = MacrobenchmarkRule() // No ahead-of-time (AOT) compilation at all. Represents performance of a // fresh install on a user's device if you don't enable Baseline Profiles— // generally the worst case performance. @Test fun startupNoCompilation() = startup(CompilationMode.None()) // Partial pre-compilation with Baseline Profiles. Represents performance of // a fresh install on a user's device. @Test fun startupPartialWithBaselineProfiles() = startup(CompilationMode.Partial(baselineProfileMode = BaselineProfileMode.Require)) // Partial pre-compilation with some just-in-time (JIT) compilation. // Represents performance after some app usage. @Test fun startupPartialCompilation() = startup( CompilationMode.Partial( baselineProfileMode = BaselineProfileMode.Disable, warmupIteration = 3 ) ) // Full pre-compilation. Generally not representative of real user // experience, but can yield more stable performance metrics by removing // noise from JIT compilation within benchmark runs. @Test fun startupFullCompilation() = startup(CompilationMode.Full()) private fun startup(compilationMode: CompilationMode) = benchmarkRule.measureRepeated( packageName = "com.example.macrobenchmark.target", metrics = listOf(StartupTimingMetric()), compilationMode = compilationMode, iterations = 10, startupMode = StartupMode.COLD, setupBlock = { pressHome() } ) { // Waits for the first rendered frame, which represents time to initial display. startActivityAndWait() // Waits for content to be visible, which represents time to fully drawn. device.wait(Until.hasObject(By.res("my-content")), 5_000) } }
في لقطة الشاشة التالية، يمكنك الاطّلاع على النتائج مباشرةً في "استوديو Android" لتطبيق Now in Android sample الذي تم تشغيله على Google Pixel 7. تُظهر النتائج أنّ بدء تشغيل التطبيق يكون أسرع عند استخدام "ملفات الأداء الأساسي" (229.0 ملي ثانية) مقارنةً بعدم إجراء عملية الترجمة (324.8 ملي ثانية).
على الرغم من أنّ المثال السابق يعرض نتائج بدء تشغيل التطبيق التي تم تسجيلها باستخدام
StartupTimingMetric
، هناك مقاييس مهمة أخرى تستحقّ المراجعة،
مثل FrameTimingMetric
. لمزيد من المعلومات عن جميع أنواع
المقاييس، يُرجى الاطّلاع على مقالة تسجيل مقاييس الأداء الإجمالي.
وقت ظهور الإعلان على الشاشة بالكامل
يقيس المثال السابق الوقت المستغرَق للعرض الأولي (TTID)، وهو الوقت الذي يستغرقه التطبيق لإنشاء إطاره الأول. ومع ذلك، لا يعكس ذلك بالضرورة الوقت الذي يستغرقه المستخدم لبدء التفاعل مع تطبيقك. إنّ مقياس الوقت المستغرَق للعرض الكامل (TTFD) أكثر فائدة في قياس مسارات الرموز البرمجية اللازمة لتحسين حالة التطبيق القابلة للاستخدام بالكامل.
ننصحك بتحسين كلاً من TTID وTTFD، لأنّهما مهمّان. يساعد القيمة المنخفضة لملف TTID المستخدم في معرفة أنّ التطبيق يتم تشغيله فعليًا. من المهم إبقاء وقت الاستجابة للتفاعل مع التطبيق قصيرًا للمساعدة في ضمان تفاعل المستخدم مع التطبيق بشكل سريع.
للحصول على استراتيجيات حول إعداد التقارير عند اكتمال رسم واجهة مستخدم التطبيق بالكامل، يُرجى الاطّلاع على مقالة تحسين دقة توقيت بدء التشغيل.
أفلام مُقترَحة لك
- ملاحظة: يتم عرض نص الرابط عندما تكون لغة JavaScript غير مفعّلة.
- [كتابة اختبار أداء على مستوى التطبيق][11]
- [تسجيل مقاييس الأداء الإجمالي][12]
- [تحليل بدء تشغيل التطبيق وتحسينه {:#app-startup-analysis-optimization}][13]