मेट्रिक, आपके मानदंड से निकाली गई मुख्य तरह की जानकारी होती है. इन्हें measureRepeated फ़ंक्शन में List के तौर पर पास किया जाता है. इससे एक साथ कई मेज़र की गई मेट्रिक तय की जा सकती हैं. बेंचमार्क चलाने के लिए, कम से कम एक तरह की मेट्रिक ज़रूरी है.
नीचे दिया गया कोड स्निपेट, फ़्रेम टाइमिंग और कस्टम ट्रेस सेक्शन की मेट्रिक कैप्चर करता है:
Kotlin
benchmarkRule.measureRepeated( packageName = TARGET_PACKAGE, metrics = listOf( FrameTimingMetric(), TraceSectionMetric("RV CreateView"), TraceSectionMetric("RV OnBindView"), ), iterations = 5, // ... )
Java
benchmarkRule.measureRepeated( TARGET_PACKAGE, // packageName Arrays.asList( // metrics new StartupTimingMetric(), new TraceSectionMetric("RV CreateView"), new TraceSectionMetric("RV OnBindView"), ), 5, // Iterations // ... );
इस उदाहरण में, RV CreateView और RV OnBindView, ट्रैक किए जा सकने वाले उन ब्लॉक के आईडी हैं जिन्हें RecyclerView में तय किया गया है. createViewHolder() तरीके के सोर्स कोड से पता चलता है कि अपने कोड में ट्रैक किए जा सकने वाले ब्लॉक कैसे तय किए जा सकते हैं.
StartupTimingMetric, TraceSectionMetric, FrameTimingMetric, और PowerMetric के बारे में इस दस्तावेज़ में आगे बताया गया है.
मेट्रिक की पूरी सूची देखने के लिए, Metric की सबक्लास देखें.
बेंचमार्क के नतीजे, Android Studio में दिखते हैं. इन्हें पहली इमेज में दिखाया गया है. अगर एक से ज़्यादा मेट्रिक तय की जाती हैं, तो उन सभी को आउटपुट में शामिल किया जाता है.
TraceSectionMetric और FrameTimingMetric के नतीजे.StartupTimingMetric
StartupTimingMetric
इन वैल्यू के साथ, ऐप्लिकेशन के शुरू होने में लगने वाले समय की मेट्रिक कैप्चर करता है:
timeToInitialDisplayMs: सिस्टम को लॉन्च करने का इंटेंट मिलने से लेकर, डेस्टिनेशनActivityका पहला फ़्रेम रेंडर होने तक का समय.timeToFullDisplayMs: सिस्टम को लॉन्च करने का अनुरोध मिलने से लेकर, ऐप्लिकेशन केreportFullyDrawn()तरीके का इस्तेमाल करके पूरी तरह से रेंडर होने तक का समय.reportFullyDrawn()कॉल के बाद या उसमें शामिल पहले फ़्रेम को रेंडर करने के बाद, मेज़रमेंट बंद हो जाता है. ऐसा हो सकता है कि यह मेज़रमेंट, Android 10 (एपीआई लेवल 29) और उससे पहले के वर्शन पर उपलब्ध न हो.
StartupTimingMetric, स्टार्टअप के इटरेशन से कम से कम, मीडियन, और ज़्यादा से ज़्यादा वैल्यू दिखाता है. स्टार्टअप में हुए सुधार का आकलन करने के लिए, आपको माध्यिका वैल्यू पर ध्यान देना चाहिए. ऐसा इसलिए, क्योंकि ये वैल्यू स्टार्टअप में लगने वाले सामान्य समय का सबसे सही अनुमान देती हैं. ऐप्लिकेशन स्टार्टअप समय को बेहतर बनाने के बारे में ज़्यादा जानने के लिए, ऐप्लिकेशन स्टार्टअप समय लेख पढ़ें.
StartupTimingMetric नतीजे.FrameTimingMetric
FrameTimingMetric
यह बेंचमार्क से जनरेट किए गए फ़्रेम से टाइमिंग की जानकारी कैप्चर करता है. जैसे, स्क्रोलिंग या ऐनिमेशन. साथ ही, यह इन वैल्यू को आउटपुट करता है:
frameOverrunMs: इससे पता चलता है कि किसी फ़्रेम को रेंडर करने में कितना समय लगा. पॉज़िटिव नंबर से पता चलता है कि फ़्रेम ड्रॉप हो गया है और जंक या स्टटर दिख रहा है. नेगेटिव नंबर से पता चलता है कि कोई फ़्रेम, तय समयसीमा से कितना पहले रेंडर हो गया. ध्यान दें: यह सुविधा सिर्फ़ Android 12 (एपीआई लेवल 31) और इसके बाद के वर्शन पर उपलब्ध है.frameDurationCpuMs: यूज़र इंटरफ़ेस (यूआई) थ्रेड औरRenderThread, दोनों पर सीपीयू में फ़्रेम को रेंडर होने में लगने वाला समय.
इन मेज़रमेंट को 50वें, 90वें, 95वें, और 99वें पर्सेंटाइल के डिस्ट्रिब्यूशन में इकट्ठा किया जाता है.
रेंडर होने में ज़्यादा समय लेने वाले फ़्रेम का पता लगाने और उन्हें बेहतर बनाने के तरीके के बारे में ज़्यादा जानने के लिए, रेंडर होने में ज़्यादा समय लगना लेख पढ़ें.
FrameTimingMetric नतीजे.TraceSectionMetric
TraceSectionMetric
से यह पता चलता है कि दिए गए sectionName से मेल खाने वाला ट्रेस सेक्शन कितनी बार हुआ और इसमें कितना समय लगा. समय के लिए, यह कम से कम, मीडियन, और ज़्यादा से ज़्यादा समय को मिलीसेकंड में दिखाता है. ट्रेस सेक्शन को फ़ंक्शन कॉल trace(sectionName) या Trace.beginSection(sectionName) और Trace.endSection() के बीच के कोड या उनके एसिंक वैरिएंट से तय किया जाता है. यह हमेशा मेज़रमेंट के दौरान कैप्चर किए गए ट्रेस सेक्शन के पहले इंस्टेंस को चुनता है. यह डिफ़ॉल्ट रूप से, आपके पैकेज से सिर्फ़ ट्रेस सेक्शन आउटपुट करता है. आपके पैकेज से बाहर की प्रोसेस को शामिल करने के लिए, targetPackageOnly = false सेट करें.
ट्रेसिंग के बारे में ज़्यादा जानकारी के लिए, सिस्टम ट्रेसिंग की खास जानकारी और कस्टम इवेंट तय करना लेख पढ़ें.
TraceSectionMetric नतीजे.PowerMetric
PowerMetric से, टेस्ट की अवधि के दौरान पावर कैटगरी के लिए, पावर या ऊर्जा में हुए बदलाव का पता चलता है.
चुनी गई हर कैटगरी को, मेज़र किए जा सकने वाले सब-कंपोनेंट में बांटा जाता है. साथ ही, न चुनी गई कैटगरी को "न चुनी गई" मेट्रिक में जोड़ा जाता है.
इन मेट्रिक से, पूरे सिस्टम में बैटरी की खपत का पता चलता है. इससे यह पता नहीं चलता कि हर ऐप्लिकेशन में बैटरी की कितनी खपत हुई. ये मेट्रिक, Pixel 6, Pixel 6 Pro, और इसके बाद के वर्शन वाले डिवाइसों पर ही उपलब्ध हैं:
power<category>Uw: इस कैटगरी में टेस्ट के दौरान, बैटरी की खपत कितनी हुई.energy<category>Uws: इस कैटगरी में टेस्ट के दौरान, हर यूनिट समय में ट्रांसफ़र की गई ऊर्जा की मात्रा.
कैटगरी में ये शामिल हैं:
CPUDISPLAYGPUGPSMEMORYMACHINE_LEARNINGNETWORKUNCATEGORIZED
कुछ कैटगरी, जैसे कि CPU के लिए, यह पता लगाना मुश्किल हो सकता है कि अन्य प्रोसेस ने कितना काम किया और आपके ऐप्लिकेशन ने कितना. इस समस्या को कम करने के लिए, गैर-ज़रूरी ऐप्लिकेशन और खातों को हटाएं या उन पर पाबंदी लगाएं.
PowerMetric नतीजे.आपके लिए सुझाव
- ध्यान दें: JavaScript बंद होने पर लिंक का टेक्स्ट दिखता है
- बेसलाइन प्रोफ़ाइलें बनाना {:#creating-profile-rules}
- Macrobenchmark लिखना
- ऐप्लिकेशन के शुरू होने की प्रोसेस का विश्लेषण और ऑप्टिमाइज़ेशन {:#app-startup-analysis-optimization}