الملفات الشخصية الأساسية المرجعية باستخدام مكتبة مقاييس الأداء المجمّعة

ننصح باستخدام مقياس أداء 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 إلى تقديم results غير صحيحة، لأنّه تتم مشاركة الموارد مع الجهاز المضيف.

في لقطة الشاشة التالية، يمكنك الاطّلاع على النتائج مباشرةً في "استوديو Android" لتطبيق Now in Android sample الذي تم تشغيله على Google Pixel 7. تُظهر النتائج أنّ بدء تشغيل التطبيق يكون أسرع عند استخدام "ملفات الأداء الأساسية" (229.0 ملي ثانية) مقارنةً بعدم إجراء عملية الترجمة (324.8 ملي ثانية).

الشكل 1. نتائج ColdStartupBenchmark التي تعرض الوقت المستغرَق للعرض الأوّلي بدون تجميع (324 ملي ثانية) والتجميع الكامل (315 ملي ثانية) والتجميع الجزئي (312 ملي ثانية) والملفات الشخصية الأساسية (229 ملي ثانية).

ملاحظة: يمكنك أيضًا استرداد النتائج كملف JSON لتحليلها كجزء من مسار عملية التكامل المستمر (CI). لمزيد من المعلومات، يُرجى الاطّلاع على مقالة قياس الأداء في عملية التطوير المتكامل (CI).

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

الوقت المستغرَق حتى العرض الكامل

يقيس المثال السابق الوقت المستغرَق للعرض الأولي (TTID)، وهو الوقت الذي يستغرقه التطبيق لإنشاء أول لقطة له. ومع ذلك، لا يعكس ذلك بالضرورة الوقت الذي يستغرقه المستخدم لبدء التفاعل مع تطبيقك. إنّ مقياس الوقت المستغرَق للعرض الكامل (TTFD) أكثر فائدة في قياس مسارات الرموز البرمجية اللازمة لتحسين حالة التطبيق القابلة للاستخدام بالكامل.

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

للحصول على استراتيجيات حول إعداد التقارير عند اكتمال رسم واجهة مستخدم التطبيق بالكامل، يُرجى الاطّلاع على مقالة تحسين دقة توقيت بدء التشغيل.