मैक्रोबेंचमार्क इंस्ट्रूमेंटेशन के आर्ग्युमेंट

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

android {
    defaultConfig {
        // ...
        testInstrumentationRunnerArguments["androidx.benchmark.dryRunMode.enable"] = "true"
    }
}

Android Studio से बेंचमार्क चलाते समय, इंस्ट्रुमेंटेशन के तर्क भी सेट अप किए जा सकते हैं. तर्क बदलने के लिए, यह तरीका अपनाएं:

  1. बदलाव करें पर क्लिक करके, रन कॉन्फ़िगरेशन में बदलाव करें. इसके बाद, कॉन्फ़िगरेशन पर क्लिक करें.
    रन कॉन्फ़िगरेशन में बदलाव करना
    पहली इमेज. रन कॉन्फ़िगरेशन में बदलाव करें.
  2. ज़्यादा इंस्ट्रुमेंटेशन के आर्ग्युमेंट पर क्लिक करके, इंस्ट्रुमेंटेशन के आर्ग्युमेंट में बदलाव करें.
    इंस्ट्रुमेंटेशन के तर्कों में बदलाव करना
    दूसरी इमेज. इंस्ट्रुमेंटेशन के आर्ग्युमेंट में बदलाव करें.
  3. इंस्ट्रुमेंटेशन के अतिरिक्त पैरामीटर में जाकर, जोड़ें पर क्लिक करके, ज़रूरी इंस्ट्रुमेंटेशन आर्ग्युमेंट जोड़ें.
    ज़रूरी इंस्ट्रुमेंटेशन आर्ग्युमेंट जोड़ें
    तीसरी इमेज. ज़रूरी इंस्ट्रूमेंटेशन आर्ग्युमेंट जोड़ें.

अगर कमांड लाइन से मैक्रोबेंचमार्क चलाया जा रहा है, तो -P android.testInstrumentationRunnerArguments.[name of the argument] का इस्तेमाल करें:

./gradlew :benchmark:connectedAndroidTest -P android.testInstrumentationRunnerArguments.androidx.benchmark.enabledRules=BaselineProfile

अगर am instrument कमांड को सीधे तौर पर लागू किया जा रहा है (ऐसा सीआई टेस्टिंग एनवायरमेंट में हो सकता है), तो -e के साथ am instrument को आर्ग्युमेंट पास करें:

adb shell am instrument -e androidx.benchmark.enabledRules BaselineProfile -w com.example.macrobenchmark/androidx.test.runner.AndroidJUnitRunner

सीआई में बेंचमार्क कॉन्फ़िगर करने के बारे में ज़्यादा जानकारी के लिए, सीआई में बेंचमार्किंग लेख पढ़ें

androidx.benchmark.compilation.enabled

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

  • आर्ग्युमेंट का टाइप: बूलियन
  • डिफ़ॉल्ट रूप से यह इस पर सेट होता है: true

androidx.benchmark.dryRunMode.enable

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

  • आर्ग्युमेंट का टाइप: बूलियन
  • डिफ़ॉल्ट रूप से यह इस पर सेट होता है: false

androidx.benchmark.enabledRules

इस विकल्प की मदद से, सिर्फ़ एक तरह के टेस्ट के लिए रन को फ़िल्टर किया जा सकता है: बेसलाइन प्रोफ़ाइल जनरेशन या मैक्रोबेंचमार्क टेस्ट. कॉमा लगाकर अलग की गई सूचियां भी इस्तेमाल की जा सकती हैं.

  • ऑर्ग्युमेंट का टाइप: स्ट्रिंग
  • उपलब्ध विकल्प:
    • Macrobenchmark
    • BaselineProfile
  • डिफ़ॉल्ट रूप से: तय नहीं किया गया

androidx.benchmark.fullTracing.enable

यह कुकी, androidx.tracing.perfetto ट्रेसपॉइंट चालू करती है. जैसे, Jetpack Compose कंपोज़िशन ट्रेसिंग.

आपको अपना प्रोजेक्ट सेट अप करना होगा, ताकि बेंचमार्क से कंपोज़िशन ट्रेसिंग कैप्चर की जा सके. ज़्यादा जानकारी के लिए, Jetpack Macrobenchmark की मदद से ट्रेस कैप्चर करना लेख पढ़ें.

  • आर्ग्युमेंट का टाइप: बूलियन
  • डिफ़ॉल्ट रूप से: false

androidx.benchmark.killExistingPerfettoRecordings

Benchmark, डिफ़ॉल्ट रूप से किसी भी मौजूदा Perfetto (सिस्टम ट्रेस) रिकॉर्डिंग को बंद कर देता है. ऐसा इसलिए किया जाता है, ताकि नई ट्रेसिंग शुरू करते समय कोई रुकावट न आए. इस सुविधा को बंद करने के लिए, false पास करें.

  • आर्ग्युमेंट का टाइप: बूलियन
  • डिफ़ॉल्ट रूप से यह इस पर सेट होता है: true

androidx.benchmark.profiling.mode

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

  • आर्ग्युमेंट का टाइप: स्ट्रिंग
  • उपलब्ध विकल्प:
    • MethodTracing
    • StackSampling
    • None
  • डिफ़ॉल्ट रूप से यह इस पर सेट होता है: None

androidx.benchmark.startupProfiles.enable

इस विकल्प की मदद से, बेंचमार्किंग के दौरान स्टार्टअप प्रोफ़ाइल जनरेट करने की सुविधा बंद की जा सकती है.

  • आर्ग्युमेंट का टाइप: बूलियन
  • डिफ़ॉल्ट रूप से यह इस पर सेट होता है: true

androidx.benchmark.suppressErrors

यह कॉमा लगाकर अलग की गई गड़बड़ियों की ऐसी सूची स्वीकार करता है जिन्हें चेतावनियों में बदला जा सकता है.

  • आर्ग्युमेंट का टाइप: स्ट्रिंग की सूची

  • उपलब्ध विकल्प:

    • DEBUGGABLE

      DEBUGGABLE गड़बड़ी से पता चलता है कि टारगेट पैकेज, मेनिफ़ेस्ट में debuggable=true के साथ चल रहा है. इससे डीबग करने की सुविधाओं के लिए, रनटाइम परफ़ॉर्मेंस में काफ़ी गिरावट आती है. इस गड़बड़ी से बचने के लिए, debuggable=false के साथ बेंचमार्क चलाएं. डबग किए जा सकने वाले तर्क से, एक्ज़ीक्यूशन की स्पीड पर असर पड़ता है. इसका मतलब है कि बेंचमार्क में हुए सुधार, असल उपयोगकर्ता के अनुभव पर लागू नहीं हो सकते या रिलीज़ की परफ़ॉर्मेंस कम हो सकती है.

    • LOW-BATTERY

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

    • EMULATOR

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

    • NOT-PROFILEABLE

      टारगेट पैकेज $packageName, <profileable shell=true> के बिना चल रहा है. Android 10 और 11 पर, Profileable की ज़रूरत होती है. इससे Macrobenchmark, टारगेट प्रोसेस से ट्रेस की ज़्यादा जानकारी कैप्चर कर पाता है. जैसे, ऐप्लिकेशन या लाइब्रेरी में तय किए गए सिस्टम ट्रेसिंग सेक्शन. इस गड़बड़ी को बहुत सावधानी से छिपाएं.

    • METHOD-TRACING-ENABLED

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

  • डिफ़ॉल्ट रूप से: खाली सूची

additionalTestOutputDir

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

  • आर्ग्युमेंट का टाइप: पाथ स्ट्रिंग
  • डिफ़ॉल्ट रूप से: टेस्ट APK की बाहरी डायरेक्ट्री

लिसनर

अगर बेंचमार्क के चलने के दौरान, बैकग्राउंड में कोई ऐसा काम होता है जो बेंचमार्क से जुड़ा नहीं है, तो आपको बेंचमार्क के नतीजे अलग-अलग मिल सकते हैं.

बेंचमार्किंग के दौरान बैकग्राउंड में होने वाले काम को बंद करने के लिए, listener इंस्ट्रूमेंटेशन के तर्क के टाइप को androidx.benchmark.junit4.SideEffectRunListener पर सेट करें.

  • आर्ग्युमेंट का टाइप: स्ट्रिंग
  • उपलब्ध विकल्प:
    • androidx.benchmark.junit4.SideEffectRunListener
  • डिफ़ॉल्ट रूप से: तय नहीं किया गया
पीछे जाएं
अपना ऐप्लिकेशन कंट्रोल करें