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

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

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

कंटिन्यूअस इंटिग्रेशन (सीआई) एनवायरमेंट में 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 लाइब्रेरी को होती है, ताकि वह प्रोफ़ाइल कैप्चर कर सके, रीसेट कर सके, और शेडर कैश को मिटा सके.

बेनकमाक किए गए ऐप्लिकेशन को रिलीज़ वर्शन या प्रोडक्शन के हिसाब से कॉन्फ़िगर करें. इसे डीबग नहीं किए जा सकने वाले फ़ॉर्मैट में सेट अप करें. साथ ही, इसे छोटा करने की सुविधा चालू करें. इससे परफ़ॉर्मेंस बेहतर होती है. आम तौर पर, ऐसा रिलीज़ वैरिएंट की कॉपी बनाकर किया जाता है. यह वैरिएंट, रिलीज़ वैरिएंट की तरह ही काम करता है. हालांकि, इसे डीबग कुंजियों के साथ स्थानीय तौर पर साइन किया जाता है. इसके अलावा, 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 {
    getByName("release") {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
        // In real app, this would use its own release keystore
        signingConfig = signingConfigs.getByName("debug")
    }
}
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 में दिखाया गया है:

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

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

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

बेंचमार्क टेस्टिंग, Macrobenchmark लाइब्रेरी में मौजूद MacrobenchmarkRule JUnit4 नियम API के ज़रिए की जाती है. इसमें 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,
        setupBlock = {
            // Press home button before each run to ensure the starting activity isn't visible.
            pressHome()
        }
    ) {
        // starts default launch activity
        startActivityAndWait()
    }
}
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 की तरह ही बेंचमार्क चलाए जा सकते हैं. इसके लिए, अपनी टेस्ट क्लास या तरीके के बगल में मौजूद गटर ऐक्शन का इस्तेमाल करें. इसे इमेज 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 ट्रेस प्रोसेस चुनने की सुविधा.

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

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

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

• StartupTimingMetric
• FrameTimingMetric
• TraceSectionMetric

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

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

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

CompilationMode

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

डिफ़ॉल्ट रूप से, मैक्रोबेंचमार्क 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 से जुड़ी समस्याओं की शिकायत करने या सुविधाओं के लिए अनुरोध सबमिट करने के लिए, समस्याओं को ट्रैक करने वाला सार्वजनिक टूल देखें.