मैक्रोबेंचमार्क मेट्रिक कैप्चर करें

मेट्रिक, आपके मानदंड से निकाली गई मुख्य तरह की जानकारी होती है. इन्हें measureRepeated फ़ंक्शन में List के तौर पर पास किया जाता है. इससे एक साथ कई मेज़र की गई मेट्रिक तय की जा सकती हैं. तुलना करने के लिए, कम से कम एक तरह की मेट्रिक ज़रूरी है.

यहां दिए गए कोड स्निपेट में, Jetpack Compose के लेज़ी लेआउट इंटरफ़ेस के लिए फ़्रेम टाइमिंग और कस्टम ट्रेस सेक्शन की मेट्रिक कैप्चर की गई हैं:

@OptIn(ExperimentalMetricApi::class)
    @Test
    fun scrollComposeList() {
        benchmarkRule.measureRepeated(
            // [START_EXCLUDE]
            packageName = TARGET_PACKAGE,
            metrics = listOf(
                FrameTimingMetric(),
                // Measure power usage. This is supported on Pixel 6 and later.
                PowerMetric(PowerMetric.Type.Power(
                    mapOf(
                        PowerCategory.CPU to PowerCategoryDisplayLevel.TOTAL,
                        PowerCategory.DISPLAY to PowerCategoryDisplayLevel.TOTAL,
                        PowerCategory.GPU to PowerCategoryDisplayLevel.TOTAL,
                        PowerCategory.NETWORK to PowerCategoryDisplayLevel.TOTAL,
                    )
                )),
                // Measure custom trace sections by name EntryRow (which is added to the EntryRow composable).
                // Mode.Sum measures combined duration and also how many times it occurred in the trace.
                // This way, you can estimate whether a composable recomposes more than it should.
                TraceSectionMetric("EntryRowCustomTrace", TraceSectionMetric.Mode.Sum),
                // This trace section takes into account the SQL wildcard character %,
                // which can find trace sections without the full name.
                // This way, you can measure composables produced by the composition tracing
                // and measure how long they took and how many times they recomposed.
                // WARNING: This metric only shows results when running with composition tracing, otherwise it won't be visible in the outputs.
                TraceSectionMetric("%EntryRow%", TraceSectionMetric.Mode.Sum),
            ),
            // Try switching to different compilation modes to see the effect
            // it has on frame timing metrics.
            compilationMode = CompilationMode.None(),
            startupMode = StartupMode.WARM, // restarts activity each iteration
            iterations = DEFAULT_ITERATIONS,
            // [END_EXCLUDE]
            setupBlock = {
                uiAutomator {
                    // Before starting to measure, navigate to the UI to be measured.
                    startIntent(Intent("$packageName.COMPOSE_ACTIVITY"))
                }
            }
        ) {
            uiAutomator {
                onElement { isScrollable }.fling(Direction.DOWN)
            }
        }
    }

यहां दिए गए उदाहरण में, EntryRowCustomTrace एक कस्टम ट्रेस सेक्शन को दिखाता है. इसे कंपोज़ेबल आइटम लेयर में, स्टैंडर्ड Kotlin trace(sectionName) { ... } ब्लॉक रैपर का इस्तेमाल करके तय किया गया है. TraceSectionMetric के लिए डेटा देने के लिए, आपको अपने ऐप्लिकेशन के प्रोडक्शन कोडबेस में मौजूद टारगेट यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को स्टैंडर्ड Jetpack रनटाइम trace ब्लॉक रैपर के अंदर रैप करना होगा:

@Composable
private fun EntryRow(entry: Entry, modifier: Modifier = Modifier) = trace("EntryRowCustomTrace") {
    Card(modifier = modifier) {
        Row(verticalAlignment = Alignment.CenterVertically) {
            Text(
                text = entry.contents,
                modifier = Modifier
                    .padding(16.dp)
                    .wrapContentSize()
            )

            Spacer(modifier = Modifier.weight(1f))

            Checkbox(
                checked = false,
                onCheckedChange = {},
                modifier = Modifier.padding(16.dp)
            )
        }
    }
}

टेस्ट के नतीजे, Android Studio में Benchmark टर्मिनल टैब में सीधे तौर पर दिखते हैं. जैसा कि पहले फ़िगर में दिखाया गया है. अगर एक से ज़्यादा मेट्रिक तय की गई हैं, तो उनके सभी कंप्यूटेड डेटा पॉइंट को खास जानकारी वाली विंडो में एक साथ दिखाया जाता है.

पहली इमेज. मॉडर्न कंपोज़ लेआउट के लिए, TraceSectionMetric और FrameTimingMetric के कंसोल के मिले-जुले नतीजे.

StartupTimingMetric, FrameTimingMetric, TraceSectionMetric, और PowerMetric के बारे में यहां पूरी जानकारी दी गई है. उपलब्ध बेंचमार्क मेट्रिक की पूरी सूची देखने के लिए, एपीआई रेफ़रंस में Metric के सबक्लास देखें.

StartupTimingMetric

StartupTimingMetric, ऐप्लिकेशन के शुरू होने में लगने वाले समय की मेट्रिक को इन वैल्यू के साथ कैप्चर करता है:

• timeToInitialDisplayMs: सिस्टम को ऐप्लिकेशन लॉन्च करने का अनुरोध मिलने से लेकर, डेस्टिनेशन स्क्रीन का पहला फ़्रेम रेंडर होने तक का समय.
• timeToFullDisplayMs: सिस्टम को लॉन्च करने का अनुरोध मिलने से लेकर, ऐप्लिकेशन के पूरी तरह से लोड होने तक का समय. यह समय, प्लैटफ़ॉर्म के इंटरनल रिपोर्टिंग सिस्टम का इस्तेमाल करके तय किया जाता है. पूरी तरह से ड्रॉ किए गए सिग्नल के बाद या उसमें शामिल पहले फ़्रेम को रेंडर करने के बाद, मेज़रमेंट बंद हो जाता है.

StartupTimingMetric, स्टार्टअप के इटरेशन से कम से कम, मीडियन, और ज़्यादा से ज़्यादा वैल्यू दिखाता है. स्टार्टअप में हुए सुधार का आकलन करने के लिए, हमेशा मीडियन वैल्यू पर फ़ोकस करें. इससे, सामान्य तौर पर उपयोगकर्ता के स्टार्टअप समय का सबसे अच्छा अनुमान मिलता है.

Compose-first आर्किटेक्चर में, activity.reportFullyDrawn को मैन्युअल तरीके से शुरू करने की कोशिश न करें. इसके बजाय, अपने स्क्रीन कंपोज़ेबल में Compose-safe एसिंक्रोनस यूटिलिटी ReportDrawn, ReportDrawnWhen या ReportDrawnAfter का इस्तेमाल करें. इससे Macrobenchmark को अपने-आप यह सिग्नल मिल जाएगा कि आपका एसिंक्रोनस नेटवर्क डेटा या जटिल यूआई स्टेट रेंडर हो गई हैं.

शुरू होने की परफ़ॉर्मेंस का विश्लेषण करने और उसे ऑप्टिमाइज़ करने के बारे में ज़्यादा जानने के लिए, ऐप्लिकेशन स्टार्टअप समय लेख पढ़ें.

FrameTimingMetric

FrameTimingMetric, बेंचमार्क जर्नी से जनरेट किए गए फ़्रेम से, सटीक टाइमिंग की जानकारी कैप्चर करता है. जैसे, किसी सूची को स्क्रोल करना या यूज़र इंटरफ़ेस (यूआई) के लेआउट का ऐनिमेशन. साथ ही, यह डाइग्नोस्टिक की इन वैल्यू को आउटपुट करता है:

• frameOverrunMs: इससे पता चलता है कि किसी फ़्रेम को रेंडर करने में कितना समय लगा. पॉज़िटिव नंबर से पता चलता है कि फ़्रेम ड्रॉप हो गया है. साथ ही, इससे दिखने में जैंक या स्टट्रिंग की समस्या होती है. नेगेटिव नंबर से पता चलता है कि सबसिस्टम के हार्डवेयर की समयसीमा के मुकाबले, फ़्रेम कितनी तेज़ी से रेंडर हुआ. ध्यान दें: यह मेट्रिक सिर्फ़ Android 12 (एपीआई लेवल 31) और उसके बाद के वर्शन पर उपलब्ध है.
• frameDurationCpuMs: यह वह समय होता है जब फ़्रेम को सीपीयू पर ऐक्टिव तौर पर प्रोसेस किया जाता है. इसमें ऐप्लिकेशन के मुख्य यूज़र इंटरफ़ेस (यूआई) थ्रेड और Compose RenderThread, दोनों शामिल होते हैं.

इन मेज़रमेंट को 50वें, 90वें, 95वें, और 99वें पर्सेंटाइल के डिस्ट्रिब्यूशन में इकट्ठा किया जाता है:

frameDurationCpuMs P50 3.5, P90 6.0, P95 6.4, P99 11.0
frameOverrunMs P50 -11.6, P90 -7.2, P95 -7.1, P99 -1.2

Jetpack Compose लेआउट हाइरारकी को ऑप्टिमाइज़ करते समय, सबसे खराब परफ़ॉर्म करने वाले फ़्रेम (P95 और P99 बाउंड) देखें. अगर ज़्यादा पर्सेंटाइल पर frameOverrunMs में अचानक बढ़ोतरी होती है, तो इसका मतलब है कि स्क्रोल करने के ऐनिमेशन के दौरान, रीकंपोज़िशन की वजह से मुख्य थ्रेड रुक रही है.

स्लो फ़्रेम की पहचान करने और उन्हें ठीक करने के बारे में ज़्यादा जानकारी के लिए, Jetpack Compose की परफ़ॉर्मेंस देखें.

TraceSectionMetric

एक्सपेरिमेंट के तौर पर उपलब्ध: यह क्लास एक्सपेरिमेंट के तौर पर उपलब्ध है.

TraceSectionMetric, किसी खास ट्रेस सेक्शन के होने की संख्या और उसे पूरा होने में लगने वाले समय को कैप्चर करता है. समय ट्रैक करने के लिए, यह मिलीसेकंड में कम से कम, मीडियन, और ज़्यादा से ज़्यादा समय दिखाता है. टारगेट ट्रेस सेक्शन को फ़ंक्शन कॉल trace(sectionName) या Trace.beginSection(sectionName) और Trace.endSection() के बीच की लोअर-लेवल ब्लॉक बाउंड्री या उनके एसिंक वैरिएंट से तय किया जाता है.

EntryRowCustomTraceCount min 20.0, median 28.0, max 50.0
EntryRowCustomTraceSumMs min 34.9, median 44.4, max 66.6

डिफ़ॉल्ट रूप से, यह मेट्रिक सिर्फ़ उन ट्रेस सेक्शन को आउटपुट करती है जिन्हें सीधे तौर पर आपके ऐप्लिकेशन पैकेज बाइनरी से कंपाइल किया गया है. अगर आपको अपने ऐप्लिकेशन के पैकेज की सीमा से बाहर की प्रोसेस शामिल करनी हैं, तो targetPackageOnly = false प्रॉपर्टी सेट करें.

Jetpack Compose Runtime Tracing पर काम करते समय, कंपोज़िशन ट्रेसिंग चालू करके, सिस्टम ट्रेस ग्राफ़ में अलग-अलग कंपोज़ेबल फ़ंक्शन दिखाए जा सकते हैं. इसके लिए, मैन्युअल ट्रेस रैपर लिखने की ज़रूरत नहीं होती.

मैन्युअल प्रोफ़ाइलर ट्रेस के लिए, अपने टारगेट ऐप्लिकेशन में androidx.compose.runtime:runtime-tracing डिपेंडेंसी जोड़ना काफ़ी है. हालांकि, मैक्रोबेंचमार्क रन के दौरान इन ट्रेस को प्रोग्राम के हिसाब से कैप्चर करने के लिए, आपको अपने बेंचमार्क मॉड्यूल में अतिरिक्त कॉन्फ़िगरेशन की ज़रूरत होगी.

सेटअप करने के बारे में पूरी जानकारी के लिए, Jetpack Macrobenchmark की मदद से ट्रेस कैप्चर करना लेख पढ़ें.

PowerMetric

एक्सपेरिमेंट के तौर पर उपलब्ध: यह क्लास एक्सपेरिमेंट के तौर पर उपलब्ध है.

PowerMetric, मैक्रोबेंचमार्क के रन के दौरान पावर या एनर्जी में हुए बदलाव को कैप्चर करता है. चुनी गई हर कैटगरी को, मेज़र किए जा सकने वाले हार्डवेयर कॉम्पोनेंट में बांटा जाता है. वहीं, न चुनी गई कैटगरी को "नहीं चुनी गई" बकेट में ग्रुप किया जाता है.

हार्डवेयर से जुड़ी ज़रूरी शर्तें: ये मेट्रिक, हर ऐप्लिकेशन के हिसाब से कैलकुलेट करने के बजाय, पूरे सिस्टम के हिसाब से कैलकुलेट करती हैं. इसलिए, डेटा कलेक्शन सिर्फ़ Google Pixel 6, Pixel 6 Pro, और इसके बाद के फ़िज़िकल डिवाइसों से इकट्ठा किया जाता है.

यह मेट्रिक, हर कैटगरी के लिए दो मेज़रमेंट दिखाती है:

• power<category>Uw: इस कैटगरी में टेस्ट के दौरान खर्च हुई बैटरी की मात्रा (माइक्रोनॉट में मेज़र की जाती है).
• energy<category>Uws: इस कैटगरी में टेस्ट के दौरान, समय की हर यूनिट के हिसाब से ट्रांसफ़र की गई ऊर्जा की कुल मात्रा (इसे माइक्रोवॉट-सेकंड में मेज़र किया जाता है).

कैटगरी में ये शामिल हैं:

• CPU
• DISPLAY
• GPU
• GPS
• MEMORY
• MACHINE_LEARNING
• NETWORK
• UNCATEGORIZED

कुछ कैटगरी, जैसे कि CPU के लिए, यह पता लगाना मुश्किल हो सकता है कि अन्य प्रोसेस ने कितना काम किया और आपके ऐप्लिकेशन ने कितना. इस रुकावट को कम करने के लिए, गैर-ज़रूरी ऐप्लिकेशन और खातों को हटाएं या उन पर पाबंदी लगाएं.

powerCategoryCpuUw min 300.2, median 346.1, max 519.6
powerCategoryDisplayUw min 319.8, median 325.8, max 329.7
powerCategoryGpuUw min 18.8, median 23.3, max 36.9
powerCategoryNetworkUw min 97.3, median 123.3, max 681.3
powerTotalUw min 1234.8, median 1316.6, max 2112.4
powerUnselectedUw       min  483.3,  median  512.6,  max  561.7

मुख्य सबसिस्टम का विश्लेषण किया जा रहा है

PowerMetric से, दी गई पावर कैटगरी के लिए, टेस्ट की अवधि के दौरान पावर या ऊर्जा में हुए बदलाव का पता चलता है. चुनी गई हर कैटगरी को, मेज़र किए जा सकने वाले सब-कंपोनेंट में बांटा जाता है. साथ ही, न चुनी गई कैटगरी को "न चुनी गई" मेट्रिक में जोड़ा जाता है.

टर्मिनल के आउटपुट, आपके अनुरोध किए गए कॉन्फ़िगरेशन से मैप होते हैं:

• powerCategoryCpuUw: टेस्ट के दौरान सीपीयू ने कितनी बैटरी खर्च की.
• powerCategoryGpuUw: आपके टेस्ट के दौरान, जीपीयू ने कितनी बिजली का इस्तेमाल किया.
• powerUnselectedUw: यह सभी उपलब्ध हार्डवेयर कैटगरी के ज़रिए इस्तेमाल की गई कुल पावर होती है. हालांकि, इन्हें शुरू करने के लिए आपने मैप में साफ़ तौर पर अनुरोध नहीं किया था.

रन के दौरान, हार्डवेयर रेल पर डेटा में अचानक होने वाली बढ़ोतरी को रोकने के लिए, स्क्रीन की रोशनी को एक तय वैल्यू पर लॉक करें. साथ ही, डिवाइस के तापमान को स्थिर रखें. इसके अलावा, Macrobenchmark लूप शुरू करने से पहले, बैकग्राउंड में चल रही अन्य प्रोसेस बंद करें.

अन्य संसाधन

कॉन्टेंट देखना

• Macrobenchmark मेट्रिक (व्यू) कैप्चर करना