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

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

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

कंटिन्यूअस इंटिग्रेशन (सीआई) एनवायरमेंट में Macrobenchmark लाइब्रेरी का इस्तेमाल करें. इसके बारे में कंटिन्यूअस इंटिग्रेशन में परफ़ॉर्मेंस की जांच करना लेख में बताया गया है.

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

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

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

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

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

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

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

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

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

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

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

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

किसी ऐप्लिकेशन की परफ़ॉर्मेंस की तुलना करने के लिए, उसे Macrobenchmark का टारगेट कहा जाता है. इसके लिए, ऐप्लिकेशन को 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 मॉड्यूल हैं, तो पक्का करें कि आपकी बिल्ड स्क्रिप्ट को पता हो कि किस बिल्ड वैरिएंट को कंपाइल करना है. :macrobenchmark और :app मॉड्यूल के benchmark बिल्ड टाइप में matchingFallbacks प्रॉपर्टी जोड़ें. आपके बाकी 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 चुनें. जैसा कि तीसरे फ़िगर में दिखाया गया है:

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

(ज़रूरी नहीं) प्रॉडक्ट के फ़्लेवर सेट अप करना

अगर आपने अपने ऐप्लिकेशन में प्रॉडक्ट के कई फ़्लेवर सेट किए हैं, तो :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 UI के साथ इंटरैक्शन की परफ़ॉर्मेंस का आकलन करना

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

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

@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 में दिखाया गया है.

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

./gradlew :macrobenchmark:connectedCheck

नीचे दिए गए कोड को लागू करके, एक टेस्ट चलाया जा सकता है:

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

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

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

बेंचमार्क टेस्ट पूरा होने के बाद, मेट्रिक सीधे तौर पर Android Studio में दिखती हैं. साथ ही, CI के इस्तेमाल के लिए 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 में खोला जा सकता है. इसके लिए, मेन्यू में File > Open पर क्लिक करें. इसमें पिछले सेक्शन में दिखाई गई प्रोफ़ाइलर टूल व्यू को दिखाया गया है.

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

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

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

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

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

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

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

• StartupTimingMetric
• FrameTimingMetric
• TraceSectionMetric

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

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

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

CompilationMode

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

डिफ़ॉल्ट रूप से, Macrobenchmark को 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 Sample में, एक सैंपल प्रोजेक्ट उपलब्ध है.

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

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

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

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