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

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

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

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

Kotlin

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

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

Groovy

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
    }
}

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

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

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

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

Kotlin

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

    matchingFallbacks += listOf("release")
 }

Groovy

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. इन्हें यहां दिए गए स्निपेट में दिखाया गया है:

Kotlin

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

Groovy

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 फ़्लेवर को डिफ़ॉल्ट डाइमेंशन के तौर पर इस्तेमाल किया गया है:

Kotlin

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

Groovy

defaultConfig {
    missingDimensionStrategy "environment", "production"
}

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

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

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

Kotlin

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

Groovy

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

    production {
        dimension 'environment'
    }
}

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

प्रॉडक्ट के वैरिएंट के साथ प्रोजेक्ट के लिए मानदंड वैरिएंट, जिसमें productionBenchmark और रिलीज़ को चुना गया है.
चौथी इमेज. प्रॉडक्ट के वैरिएंट के साथ प्रोजेक्ट के लिए मानदंड वैरिएंट, "productionBenchmark" और "release" को चुना गया है.

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

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

बेंचमार्क टेस्टिंग की सुविधा, 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) }
    }
}

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

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

टेस्ट क्लास के बगल में मौजूद गटर ऐक्शन की मदद से, Macrobenchmark चलाएं.
पांचवीं इमेज. टेस्ट क्लास के बगल में मौजूद गटर ऐक्शन की मदद से, Macrobenchmark चलाएं.

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

./gradlew :macrobenchmark:connectedCheck

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

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

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

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

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

मैक्रोबेंचमार्क स्टार्टअप के नतीजे.
छठी इमेज. Macrobenchmark स्टार्टअप के नतीजे.

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

Studio में ट्रेस प्रोसेस चुनने की सुविधा.
सातवीं इमेज. Studio में ट्रेस प्रोसेस चुनने की सुविधा.

ट्रेस फ़ाइल लोड होने के बाद, 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 फ़ंक्शन में कई पैरामीटर इस्तेमाल किए जा सकते हैं. इनसे यह तय होता है कि लाइब्रेरी कौनसी मेट्रिक इकट्ठा करती है, आपका ऐप्लिकेशन कैसे शुरू और कंपाइल होता है या मानदंड कितनी बार चलता है.

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

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

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

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

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

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 देखें.

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

StartupMode

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

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

सैंपल

GitHub पर मौजूद रिपॉज़िटरी के Macrobenchmark सैंपल में, एक सैंपल प्रोजेक्ट उपलब्ध है.

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

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

आगे बढ़ें
मेट्रिक कैप्चर करें