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

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

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

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

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

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

हमारा सुझाव है कि आप Macrobenchmark के साथ Android Studio का नया वर्शन इस्तेमाल करें. इससे आपको आईडीई की उन सुविधाओं का ऐक्सेस मिलेगा जो Macrobenchmark के साथ इंटिग्रेट होती हैं.

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

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

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

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

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

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

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

पहली इमेज. बेंचमार्क मॉड्यूल टेंप्लेट.

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

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

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

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

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

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

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

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

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

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

    production {
        dimension 'environment'
    }
}

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

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

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

Macrobenchmark क्लास बनाना

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

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

@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

@LargeTest
@RunWith(AndroidJUnit4.class)
public class SampleStartupBenchmark {
    @Rule
    public MacrobenchmarkRule benchmarkRule = new MacrobenchmarkRule();

    @Test
    public void startup() {
        benchmarkRule.measureRepeated(
            /* packageName */ TARGET_PACKAGE,
            /* metrics */ Arrays.asList(new StartupTimingMetric()),
            /* iterations */ 5,
            /* measureBlock */ scope -> {
                // starts default launch activity
                scope.startActivityAndWait();
                return Unit.INSTANCE;
            }
        );
    }
}

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

बेंचमार्क चलाना

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

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

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

./gradlew :macrobenchmark:connectedCheck

कोई एक टेस्ट चलाने के लिए, यह कमांड एक्ज़ीक्यूट करें:

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

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

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

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

छठी इमेज. Macrobenchmark के स्टार्टअप के नतीजे.

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

सातवीं इमेज. 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 में फ़ाइल > खोलें मेन्यू से खोला जा सकता है. इससे, प्रोफ़ाइलर टूल का वह व्यू दिखता है जो पिछले सेक्शन में दिखाया गया था.

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

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

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

बेंचमार्क को पसंद के मुताबिक बनाना

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

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

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

• StartupTimingMetric
• FrameTimingMetric
• TraceSectionMetric

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

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

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

CompilationMode

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

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

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

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

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

StartupMode

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

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

सैंपल

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

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

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