मैक्रोबेंचमार्क लिखें

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

लाइब्रेरी, मानदंड के नतीजों को Android Studio कंसोल और ज़्यादा जानकारी वाली JSON फ़ाइल में आउटपुट करती है. यह ट्रेस फ़ाइलें भी उपलब्ध कराता है, जिन्हें Android Studio में लोड करके उनका विश्लेषण किया जा सकता है.

लगातार इंटिग्रेशन में मानदंड में बताए गए तरीके के मुताबिक, लगातार इंटिग्रेशन (सीआई) एनवायरमेंट में Macrobenchmark लाइब्रेरी का इस्तेमाल करें.

बेसलाइन प्रोफ़ाइलें जनरेट करने के लिए, Macrobenchmark का इस्तेमाल किया जा सकता है. सबसे पहले, Macrobenchmark लाइब्रेरी सेट अप करें. इसके बाद, बेसलाइन प्रोफ़ाइल बनाई जा सकती है.

Jetpack Compose की मदद से बनाए गए यूज़र इंटरफ़ेस (यूआई) की जांच करने के लिए, Macrobenchmark का इस्तेमाल करने का सुझाव दिया जाता है. Compose नोड के साथ इंटरैक्ट करने वाले यूआई ऑटोमेटर टेस्ट लिखने का तरीका जानने के लिए, इंटरऑपरेबिलिटी देखें.

प्रोजेक्ट सेटअप

हमारा सुझाव है कि आप Android Studio के नए वर्शन के साथ Macrobenchmark का इस्तेमाल करें.

Macrobenchmark मॉड्यूल सेट अप करना

मैक्रोबेंचमार्क के लिए, com.android.test मॉड्यूल की ज़रूरत होती है. यह आपके ऐप्लिकेशन के कोड से अलग होता है. यह मॉड्यूल, आपके ऐप्लिकेशन की परफ़ॉर्मेंस को मापने वाले टेस्ट चलाने के लिए ज़िम्मेदार होता है.

Android Studio में, Macrobenchmark मॉड्यूल के सेटअप को आसान बनाने के लिए एक टेंप्लेट उपलब्ध है. बेंचमार्किंग मॉड्यूल टेंप्लेट, आपके प्रोजेक्ट में अपने-आप एक मॉड्यूल बनाता है. इससे, ऐप्लिकेशन मॉड्यूल से बनाए गए ऐप्लिकेशन को मेज़र किया जाता है. इसमें ऐप्लिकेशन के स्टार्ट होने का सैंपल बेंचमार्क भी शामिल होता है.

नया मॉड्यूल बनाने के लिए, मॉड्यूल टेंप्लेट का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:

1. Android Studio में प्रोजेक्ट पैनल में जाकर, अपने प्रोजेक्ट या मॉड्यूल पर राइट क्लिक करें. इसके बाद, नया > मॉड्यूल को चुनें.

2. टेंप्लेट पैनल में जाकर, बेंचमार्क को चुनें. आपके पास टारगेट ऐप्लिकेशन को अपनी ज़रूरत के मुताबिक बनाने का विकल्प होता है. इसका मतलब है कि जिस ऐप्लिकेशन की परफ़ॉर्मेंस की जांच करनी है उसे अपनी ज़रूरत के मुताबिक बनाया जा सकता है. साथ ही, नए Macrobenchmark मॉड्यूल के लिए, पैकेज और मॉड्यूल के नाम को भी अपनी ज़रूरत के मुताबिक बनाया जा सकता है.

3. पूरा करें पर क्लिक करें.

ऐप्लिकेशन सेट अप करना

किसी ऐप्लिकेशन की परफ़ॉर्मेंस की जांच करने के लिए, ऐप्लिकेशन को profileable होना चाहिए. इसे मैक्रोबेंचमार्क का टारगेट कहा जाता है. इससे परफ़ॉर्मेंस पर असर डाले बिना, ट्रेस की पूरी जानकारी पढ़ी जा सकती है. मॉड्यूल विज़र्ड, ऐप्लिकेशन की AndroidManifest.xml फ़ाइल में <profileable> टैग अपने-आप जोड़ देता है.

पक्का करें कि टारगेट ऐप्लिकेशन में ProfilerInstaller 1.3 या इसके बाद का वर्शन शामिल हो. Macrobenchmark लाइब्रेरी को प्रोफ़ाइल कैप्चर करने, रीसेट करने, और शेडर कैश मेमोरी को मिटाने की सुविधा चालू करने के लिए, इसकी ज़रूरत होती है.

बेंचमार्क किए गए ऐप्लिकेशन को, रिलीज़ के लिए तैयार वर्शन या प्रोडक्शन के जितना हो सके उतना करीब कॉन्फ़िगर करें. इसे डीबग न किए जा सकने वाले के तौर पर सेट अप करें. साथ ही, काट-छांट की सुविधा चालू करें. इससे परफ़ॉर्मेंस बेहतर होती है. आम तौर पर, ऐसा करने के लिए रिलीज़ वैरिएंट की एक कॉपी बनाई जाती है. यह कॉपी, रिलीज़ वैरिएंट की तरह ही काम करती है. हालांकि, इसे डीबग पासकोड की मदद से स्थानीय तौर पर साइन किया जाता है. इसके अलावा, initWith का इस्तेमाल करके, Gradle को यह काम करने का निर्देश दिया जा सकता है:

buildTypes {
    getByName("release") {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"))
    }

    create("benchmark") {
        initWith(getByName("release"))
        signingConfig = signingConfigs.getByName("debug")
    }
}

buildTypes {
    release {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "keep-rules.pro"
        )
        // In real app, this would use its own release keystore
        signingConfig = signingConfigs.getByName("debug")
        baselineProfile.automaticGenerationDuringBuild = true
    }
}
build.gradle.kts

यह पक्का करने के लिए कि मानदंड को चलाने से आपके ऐप्लिकेशन का सही वैरिएंट बनता है और उसकी जांच होती है, जैसा कि इमेज 2 में दिखाया गया है, यह तरीका अपनाएं:

1. Gradle सिंक करें.
2. बिल्ड के वैरिएंट पैनल खोलें.
3. ऐप्लिकेशन और Macrobenchmark मॉड्यूल, दोनों के लिए मानदंड वैरिएंट चुनें.

(ज़रूरी नहीं) मल्टी-मॉड्यूल ऐप्लिकेशन सेट अप करना

अगर आपके ऐप्लिकेशन में एक से ज़्यादा Gradle मॉड्यूल हैं, तो पक्का करें कि आपकी बिल्ड स्क्रिप्ट को पता हो कि किस बिल्ड वैरिएंट को कंपाइल करना है. matchingFallbacks प्रॉपर्टी को अपने :macrobenchmark और :app मॉड्यूल के benchmark बिल्ड टाइप में जोड़ें. आपके बाकी Gradle मॉड्यूल का कॉन्फ़िगरेशन पहले जैसा ही हो सकता है.

create("benchmark") {
    initWith(getByName("release"))
    signingConfig = signingConfigs.getByName("debug")

    matchingFallbacks += listOf("release")
 }

benchmark {
    initWith buildTypes.release
    signingConfig signingConfigs.debug

    matchingFallbacks = ['release']
 }

इसके बिना, हाल ही में जोड़े गए benchmark बिल्ड टाइप की वजह से बिल्ड फ़ेल हो जाता है और गड़बड़ी का यह मैसेज दिखता है:

> Could not resolve project :shared.
     Required by:
         project :app
      > No matching variant of project :shared was found.
      ...

अपने प्रोजेक्ट में बिल्ड के वैरिएंट चुनते समय, :app और :macrobenchmark मॉड्यूल के लिए benchmark चुनें. साथ ही, अपने ऐप्लिकेशन में मौजूद अन्य मॉड्यूल के लिए release चुनें, जैसा कि इमेज 3 में दिखाया गया है:

ज़्यादा जानकारी के लिए, वैरिएंट मैचिंग से जुड़ी बिल्ड की गड़बड़ियों को ठीक करना लेख पढ़ें.

(ज़रूरी नहीं) ऐप्लिकेशन टाइप सेट अप करना

अगर आपके ऐप्लिकेशन में कई ऐप्लिकेशन टाइप सेट हैं, तो :macrobenchmark मॉड्यूल को कॉन्फ़िगर करें. इससे मॉड्यूल को पता चल पाएगा कि आपके ऐप्लिकेशन के किस ऐप्लिकेशन टाइप को बनाना और मानदंड तय करना है.

इस पेज पर दिए गए उदाहरणों में, :app मॉड्यूल में दो ऐप्लिकेशन टाइप का इस्तेमाल किया गया है: demo और production. इन्हें यहां दिए गए स्निपेट में दिखाया गया है:

flavorDimensions += "environment"
productFlavors {
    create("demo") {
        dimension = "environment"
        // ...
    }
    create("production") {
        dimension = "environment"
        // ...
    }
}

flavorDimensions 'environment'
productFlavors {
    demo {
        dimension 'environment'
        // ...
    }

    production {
        dimension 'environment'
        // ...
    }
}

इस कॉन्फ़िगरेशन के बिना, आपको बिल्ड से जुड़ी गड़बड़ी मिल सकती है. यह गड़बड़ी, कई Gradle मॉड्यूल की वजह से होने वाली गड़बड़ी जैसी होती है:

Could not determine the dependencies of task ':macrobenchmark:connectedBenchmarkAndroidTest'.
> Could not determine the dependencies of null.
   > Could not resolve all task dependencies for configuration ':macrobenchmark:benchmarkTestedApks'.
      > Could not resolve project :app.
        Required by:
            project :macrobenchmark
         > The consumer was configured to find a runtime of a component, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'benchmark', attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.3.0'. However we cannot choose between the following variants of project :app:
             -   demoBenchmarkRuntimeElements
             -   productionBenchmarkRuntimeElements
           All of them match the consumer attributes:
           ...

यहां दिए गए दो सेक्शन में, कई ऐप्लिकेशन टाइप के साथ मानदंड को कॉन्फ़िगर करने के तरीके बताए गए हैं.

missingDimensionStrategy का इस्तेमाल करना

:macrobenchmark मॉड्यूल के defaultConfig में missingDimensionStrategy तय करने से, बिल्ड सिस्टम को फ़्लेवर डाइमेंशन पर फ़ॉलबैक करने का निर्देश मिलता है. अगर आपको मॉड्यूल में डाइमेंशन नहीं मिलते हैं, तो बताएं कि आपको किन डाइमेंशन का इस्तेमाल करना है. यहां दिए गए उदाहरण में, production फ़्लेवर को डिफ़ॉल्ट डाइमेंशन के तौर पर इस्तेमाल किया गया है:

defaultConfig {
    missingDimensionStrategy("environment", "production")
}

defaultConfig {
    missingDimensionStrategy "environment", "production"
}

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

:macrobenchmark मॉड्यूल में ऐप्लिकेशन टाइप तय करना

अगर आपको अन्य ऐप्लिकेशन टाइप बनाने और उनकी परफ़ॉर्मेंस की तुलना करनी है, तो उन्हें :macrobenchmark मॉड्यूल में तय करें. इसे :app मॉड्यूल की तरह ही तय करें. हालांकि, productFlavors को सिर्फ़ dimension को असाइन करें. कोई अन्य सेटिंग ज़रूरी नहीं है:

flavorDimensions += "environment"
productFlavors {
    create("demo") {
        dimension = "environment"
    }
    create("production") {
        dimension = "environment"
    }
}

flavorDimensions 'environment'
productFlavors {
    demo {
        dimension 'environment'
    }

    production {
        dimension 'environment'
    }
}

प्रोजेक्ट को तय और सिंक करने के बाद, बिल्ड के वैरिएंट पैनल से काम का वैरिएंट चुनें. जैसा कि इमेज 4 में दिखाया गया है:

ज़्यादा जानकारी के लिए, वैरिएंट मैचिंग से जुड़ी बिल्ड की गड़बड़ियों को ठीक करना लेख पढ़ें.

मैक्रोबेंचमार्क क्लास बनाना

बेंचमार्क टेस्टिंग की सुविधा, Macrobenchmark लाइब्रेरी में मौजूद MacrobenchmarkRule JUnit4 नियम एपीआई के ज़रिए उपलब्ध कराई जाती है. इसमें measureRepeated तरीका शामिल होता है. इसकी मदद से, टारगेट ऐप्लिकेशन को चलाने और उसकी परफ़ॉर्मेंस की जांच करने के लिए, अलग-अलग शर्तें तय की जा सकती हैं.

आपको कम से कम टारगेट ऐप्लिकेशन का packageName, आपको क्या metrics मेज़र करना है, और मानदंड को कितनी iterations चलाना है, यह बताना होगा.

Kotlin

@LargeTest
@RunWith(AndroidJUnit4::class)
class SampleStartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() = benchmarkRule.measureRepeated(
        packageName = TARGET_PACKAGE,
        metrics = listOf(StartupTimingMetric()),
        iterations = DEFAULT_ITERATIONS,
    ) {
        // starts default launch activity
        uiAutomator { startApp(TARGET_PACKAGE) }
    }
}
SampleStartupBenchmark.kt

बेंचमार्क को पसंद के मुताबिक बनाने के सभी विकल्पों के बारे में जानने के लिए, बेंचमार्क को पसंद के मुताबिक बनाएं सेक्शन देखें.

Compose यूज़र इंटरफ़ेस (यूआई) के इंटरैक्शन की परफ़ॉर्मेंस का आकलन करना

पिछले उदाहरण में ऐप्लिकेशन के स्टार्टअप को मेज़र किया गया है. हालांकि, आपको अक्सर यूज़र इंटरफ़ेस (यूआई) की परफ़ॉर्मेंस को मेज़र करना होगा. जैसे, स्क्रोल करते समय फ़्रेम ड्रॉप (जैंक).

Jetpack Compose ऐप्लिकेशन की परफ़ॉर्मेंस का आकलन करने के लिए, यूज़र इंटरफ़ेस (यूआई) ऑटोमेटर का इस्तेमाल किया जा सकता है. इससे सीधे तौर पर Compose नोड के साथ इंटरैक्ट किया जा सकता है. जैसे, LazyColumn को स्क्रोल करते समय FrameTimingMetric को मेज़र करना. इसके बारे में यहां दिए गए स्निपेट में बताया गया है.

@LargeTest
@RunWith(AndroidJUnit4::class)
class ComposeScrollBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun scrollLazyColumn() = benchmarkRule.measureRepeated(
        packageName = "com.example.compose.app",
        metrics = listOf(FrameTimingMetric()),
        iterations = 5,
        startupMode = StartupMode.WARM,
        setupBlock = { pressHome() }
    ) {
        startActivityAndWait()

        // Find the Compose node using the testTag defined in your app
        val lazyColumn = device.findObject(By.res("my_lazy_column"))

        // Simulate a scroll gesture to measure FrameTimingMetric
        lazyColumn.setGestureMargin(device.displayWidth / 5)
        lazyColumn.fling(Direction.DOWN)
    }
}

बेंचमार्क टेस्ट रन करना

अपने डिवाइस पर ऐप्लिकेशन की परफ़ॉर्मेंस को मेज़र करने के लिए, Android Studio से टेस्ट चलाएं. बेंचमार्क को उसी तरह चलाया जा सकता है जिस तरह किसी अन्य @Test को चलाया जाता है. इसके लिए, अपनी टेस्ट क्लास या तरीके के बगल में मौजूद गटर ऐक्शन का इस्तेमाल करें, जैसा कि इमेज 5 में दिखाया गया है.

कमांड लाइन से Gradle मॉड्यूल में सभी मानदंड भी चलाए जा सकते हैं. इसके लिए, connectedCheck कमांड को एक्ज़ीक्यूट करें:

./gradlew :macrobenchmark:connectedCheck

यहां दिया गया कमांड चलाकर, एक टेस्ट चलाया जा सकता है:

./gradlew :macrobenchmark:connectedCheck -P android.testInstrumentationRunnerArguments.class=com.example.macrobenchmark.startup.SampleStartupBenchmark#startup

लगातार इंटिग्रेशन में मानदंड चलाने और उनकी निगरानी करने के तरीके के बारे में जानने के लिए, लगातार इंटिग्रेशन में मानदंड देखें.

बेंचमार्क के नतीजे

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

ट्रेस लोड होने के बाद, Android Studio आपको विश्लेषण के लिए प्रोसेस चुनने के लिए कहता है. चुने गए विकल्प में, टारगेट ऐप्लिकेशन की प्रोसेस की जानकारी पहले से भरी होती है. जैसा कि इमेज 7 में दिखाया गया है:

ट्रेस फ़ाइल लोड होने के बाद, Studio सीपीयू प्रोफ़ाइलर टूल में नतीजे दिखाता है:

JSON रिपोर्ट और प्रोफ़ाइलिंग ट्रेस भी डिवाइस से होस्ट पर अपने-आप कॉपी हो जाते हैं. ये होस्ट मशीन पर इस जगह पर लिखे जाते हैं:

project_root/module/build/outputs/connected_android_test_additional_output/debugAndroidTest/connected/device_id/

ट्रेस फ़ाइलों को मैन्युअल तरीके से ऐक्सेस करना

अगर आपको ट्रेस फ़ाइल का विश्लेषण करने के लिए Perfetto टूल का इस्तेमाल करना है, तो आपको कुछ और चरणों को पूरा करना होगा. Perfetto की मदद से, ट्रेस के दौरान डिवाइस पर होने वाली सभी प्रोसेस की जांच की जा सकती है. वहीं, Android Studio का सीपीयू प्रोफ़ाइलर, सिर्फ़ एक प्रोसेस की जांच करता है.

अगर Android Studio या Gradle कमांड लाइन से टेस्ट को शुरू किया जाता है, तो ट्रेस फ़ाइलें डिवाइस से होस्ट पर अपने-आप कॉपी हो जाती हैं. इन्हें होस्ट मशीन पर इस जगह पर लिखा जाता है:

project_root/module/build/outputs/connected_android_test_additional_output/debugAndroidTest/connected/device_id/TrivialStartupBenchmark_startup[mode=COLD]_iter002.perfetto-trace

होस्ट सिस्टम में ट्रेस फ़ाइल होने पर, उसे Android Studio में खोला जा सकता है. इसके लिए, मेन्यू में जाकर फ़ाइल > खोलें पर जाएं. इसमें प्रोफ़ाइलर टूल का व्यू दिखता है, जो पिछले सेक्शन में दिखाया गया है.

कॉन्फ़िगरेशन से जुड़ी गड़बड़ियां

अगर ऐप्लिकेशन को गलत तरीके से कॉन्फ़िगर किया गया है, तो Macrobenchmark गलत या अधूरी जानकारी देने के बजाय, गड़बड़ी की जानकारी देता है. जैसे, डीबग करने लायक या प्रोफ़ाइल न बनाने लायक. androidx.benchmark.suppressErrors आर्ग्युमेंट की मदद से, इन गड़बड़ियों को दबाया जा सकता है.

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

मानदंडों को पसंद के मुताबिक बनाना

measureRepeated फ़ंक्शन कई पैरामीटर स्वीकार करता है. इनसे यह तय होता है कि लाइब्रेरी कौनसी मेट्रिक इकट्ठा करती है, आपका ऐप्लिकेशन कैसे शुरू और कंपाइल होता है या मानदंड कितनी बार चलता है.

मेट्रिक कैप्चर करना

मेट्रिक, आपके मानदंड से निकाली गई मुख्य जानकारी होती है. ये मेट्रिक उपलब्ध हैं:

• StartupTimingMetric
• FrameTimingMetric
• TraceSectionMetric

मेट्रिक के बारे में ज़्यादा जानने के लिए, मैक्रोबेंचमार्क मेट्रिक कैप्चर करना लेख पढ़ें.

कस्टम इवेंट की मदद से, ट्रेस डेटा को बेहतर बनाना

अपने ऐप्लिकेशन को कस्टम ट्रेस इवेंट के साथ इंस्ट्रुमेंट करना फ़ायदेमंद हो सकता है. ये इवेंट, बाकी ट्रेस रिपोर्ट के साथ दिखते हैं. साथ ही, इनसे आपके ऐप्लिकेशन से जुड़ी समस्याओं का पता लगाने में मदद मिल सकती है. कस्टम ट्रेस इवेंट बनाने के बारे में ज़्यादा जानने के लिए, कस्टम इवेंट तय करना लेख पढ़ें.

CompilationMode

मैक्रोबेंचमार्क, CompilationMode तय कर सकते हैं. इससे यह तय होता है कि ऐप्लिकेशन के कितने हिस्से को DEX बाइट कोड (APK में मौजूद बाइट कोड फ़ॉर्मैट) से मशीन कोड (पहले से कंपाइल किए गए C++ की तरह) में पहले से कंपाइल करना ज़रूरी है.

डिफ़ॉल्ट रूप से, Macrobenchmarks को CompilationMode.DEFAULT के साथ चलाया जाता है. इससे Android 7 (एपीआई लेवल 24) और इसके बाद के वर्शन पर, बेसलाइन प्रोफ़ाइल इंस्टॉल हो जाती है. हालांकि, इसके लिए बेसलाइन प्रोफ़ाइल उपलब्ध होनी चाहिए. अगर Android 6 (एपीआई लेवल 23) या इससे पहले के वर्शन का इस्तेमाल किया जा रहा है, तो कंपाइलेशन मोड, डिफ़ॉल्ट सिस्टम के तौर पर APK को पूरी तरह से कंपाइल करता है.

अगर टारगेट ऐप्लिकेशन में बेसलाइन प्रोफ़ाइल और ProfileInstaller लाइब्रेरी, दोनों मौजूद हैं, तो बेसलाइन प्रोफ़ाइल इंस्टॉल की जा सकती है.

Android 7 और इसके बाद के वर्शन पर, CompilationMode को पसंद के मुताबिक बनाया जा सकता है. इससे उपयोगकर्ता के डिवाइस पर पहले से कंपाइल किए गए डेटा की मात्रा पर असर पड़ता है. इससे, अहेड-ऑफ़-टाइम (एओटी) कंपाइलेशन या जेआईटी कैश मेमोरी के अलग-अलग लेवल की नकल की जा सकती है. CompilationMode.Full, CompilationMode.Partial, CompilationMode.None, और CompilationMode.Ignore देखें.

यह सुविधा, एआरटी कंपाइलेशन कमांड पर आधारित है. हर मानदंड शुरू होने से पहले, प्रोफ़ाइल डेटा को मिटा देता है. इससे यह पक्का करने में मदद मिलती है कि मानदंडों के बीच कोई रुकावट न हो.

StartupMode

किसी गतिविधि को शुरू करने के लिए, पहले से तय किया गया स्टार्टअप मोड पास किया जा सकता है: COLD, WARM या HOT. यह पैरामीटर, टेस्ट की शुरुआत में गतिविधि के लॉन्च होने और प्रोसेस की स्थिति में बदलाव करता है.

स्टार्टअप के टाइप के बारे में ज़्यादा जानने के लिए, ऐप्लिकेशन के स्टार्टअप में लगने वाला समय लेख पढ़ें.

सैंपल

• GitHub पर मौजूद रिपॉज़िटरी के Macrobenchmark सैंपल में, एक सैंपल प्रोजेक्ट उपलब्ध है.
• Jetpack Compose और व्यू में, स्टार्टअप और स्क्रोल की परफ़ॉर्मेंस को मापने के लिए, Macrobenchmark का इस्तेमाल करने वाली असल दुनिया की केस स्टडी के लिए, हीरो बेंचमार्क देखें.

सुझाव/राय दें या शिकायत करें

Jetpack Macrobenchmark से जुड़ी समस्याओं की शिकायत करने या सुविधाओं के अनुरोध सबमिट करने के लिए, समस्याओं को ट्रैक करने वाला सार्वजनिक टूल देखें.

आपके लिए सुझाव

• ध्यान दें: JavaScript बंद होने पर, लिंक टेक्स्ट दिखता है
• Jetpack Compose के हीरो बेंचमार्क
• Macrobenchmark मेट्रिक कैप्चर करना
• बेसलाइन प्रोफ़ाइलें बनाना {:#creating-profile-rules}
• Macrobenchmark लाइब्रेरी की मदद से, मेज़रमेंट को ऑटोमेट करना {:#measuring-optimization}