अपने बिल्ड की प्रोफ़ाइल बनाएं

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

अगर इसका इस्तेमाल किया जा रहा है, तो Android Studio 4.0 या इसके बाद वाला वर्शन, बिल्ड परफ़ॉर्मेंस की जांच करने का सबसे अच्छा तरीका है बिल्ड ऐनालाइज़र का इस्तेमाल करना होता है.

इसके अलावा, संगठन से बाहर अपने बिल्ड की प्रोफ़ाइल बनाने के दो विकल्प हैं Android स्टूडियो:

  1. एक अलग gradle-profiler टूल, आपके बिल्ड के बारे में गहराई से विश्लेषण करने के लिए एक बेहतरीन ��ूल.

  2. Gradle --profile विकल्प, यह Gradle कमांड लाइन से उपलब्ध एक आसान टूल है.

स्टैंडअलोन gradle-profiler टूल का इस्तेमाल करना

आपको सबसे अच्छी बिल्ड स्पीड देने वाले प्रोजेक्ट का सेटअप ढूंढने के लिए, आपको Gradle प्रोफ़ाइलर का इस्तेमाल करना चाहिए, यह एक ऐसा टूल है जो Gradle बिल्ड के लिए प्रोफ़ाइलिंग और मानदंड की जानकारी इकट्ठा करता है. Gradle प्रोफ़ाइलर टूल, बिल्ड की स्थितियां बनाने और उन्हें एक से ज़्यादा बार चलाने की सुविधा देता है समय होता है, जिससे नतीजों के बीच ज़्यादा फ़र्क़ नहीं पड़ता और प्रजनन क्षमता बढ़ती है नतीजों में से एक को चुनें.

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

मानदंड के लिए, प्रोजेक्ट सेट अप के कुछ कॉन्फ़िगरेशन ये हैं:

  • प्लग इन वर्शन
  • Gradle वर्शन
  • जेवीएम सेटिंग (हीप साइज़, पर्मजेन साइज़, गार्बेज कलेक्शन वगैरह)
  • Gradle कर्मियों की संख्या (org.gradle.workers.max)
  • परफ़ॉर्मेंस को और ऑप्टिमाइज़ करने के लिए हर प्लगिन के विकल्प

शुरू करना

  • इन निर्देशों का पालन करके, Gradle-profiler इंस्टॉल करें
  • दौड़ें: gradle-profiler --benchmark --project-dir <root-project> :app:assembleDebug

यह एक पूरी तरह से अप-टू-डेट बिल्ड को बेंचमार्क करेगा, क्योंकि --benchmark कई बार टास्क असाइन किया जा सकता है. इसके लिए, आपको प्रोजेक्ट में कोई बदलाव नहीं करना होगा. तो profile-out/ डायरेक्ट्री ��ें, एक एचटीएमएल रिपोर्ट जनरेट करने पर आपको बिल्ड टाइम.

ऐसे और भी मामले हैं जो बेंचमार्क करने के लिए ज़्यादा काम के हो सकते हैं:

  • क्लास के किसी खास हिस्से में कोड में बदलाव होता है, जहां आपका ज़्यादातर काम होता है.
  • एपीआई, आपके पूरे प्रोजेक्ट में इस्तेमाल होने वाले मॉड्यूल में बदलाव करता है. हालांकि कम खुद के कोड में बार-बार बदलाव नहीं करते, तो इसका ज़्यादा असर पड़ता है और यह इससे मदद मिलती है.
  • यूज़र इंटरफ़ेस (यूआई) के काम को दोहराने के लिए, लेआउट में बदलाव किए जाते हैं.
  • अनुवाद वाले काम को सिम्युलेट करने के लिए, स्ट्रिंग में बदलाव किए गए हैं.
  • क्लीन बिल्ड अपने-आप लागू होने वाले बदलावों को सिम्युलेट करता है (उदाहरण के लिए, Android Gradle प्लगिन अपडेट, Gradle अपडेट या अपने बिल्ड कोड में बदलाव करना buildSrc से कम).

इस्तेमाल के इन उदाहरणों को बेंचमार्क करने के लिए, एक ऐसा उदाहरण बनाया जा सकता है जो इसका इस्तेमाल, gradle-profiler को लागू करने के लिए किया जाता है. जो सही है आपके सोर्स में हुए बदलाव. यहां दी गई कुछ सामान्य स्थितियों की जांच की जा सकती है.

अलग-अलग मेमोरी/सीपीयू सेटिंग की प्रोफ़ाइल बनाना

अलग-अलग मेमोरी और सीपीयू सेटिंग की तुलना करने के लिए, ऐसी कई स्थितियां जो org.gradle.jvmargs के लिए अलग-अलग वैल्यू का इस्तेमाल करती हैं. इसके लिए उदाहरण के लिए, आप स्थितियां बना सकते हैं:

# <root-project>/scenarios.txt
clean_build_2gb_4workers {
    tasks = [":app:assembleDebug"]
    gradle-args = ["--max-workers=4"]
    jvm-args = ["-Xmx2048m"]
    cleanup-tasks = ["clean"]
}
clean_build_parallelGC {
    tasks = [":app:assembleDebug"]
    jvm-args = ["-XX:+UseParallelGC"]
    cleanup-tasks = ["clean"]
}

clean_build_G1GC_4gb {
    tasks = [":app:assembleDebug"]
    jvm-args = ["-Xmx4096m", "-XX:+UseG1GC"]
    cleanup-tasks = ["clean"]
}

gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt चल रहा है तीन स्थितियों को पूरा करेगा. साथ ही, आपके पास यह तुलना करने का विकल्प है कि इनमें से हर सेटअप के लिए, :app:assembleDebug की ज़रूरत होती है.

Gradle प्लग इन के अलग-अलग वर्शन की पहचान करना

यह पता लगाने के लिए कि Gradle प्लग इन के वर्शन को बदलने से क्या असर पड़ता है बनाने के लिए, मानदंड के लिए एक स्थिति बनाएं. इसके लिए कुछ स्थिति से प्लगिन वर्शन को इंजेक्ट करने लायक बनाने के लिए तैयारी करना. चैनल के आपका रूट Build.gradle:

# <root-project>/build.gradle
buildscript {
    def agpVersion = providers.systemProperty("agpVersion").forUseAtConfigurationTime().orNull ?: '4.1.0'

    ext.kotlin = providers.systemProperty('kotlinVersion').forUseAtConfigurationTime().orNull ?: '1.4.0'

    dependencies {
        classpath "com.android.tools.build:gradle:$agpVersion"
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin"
    }
}

अब आपके पास 'Android Gradle प्लग इन' और Kotlin Gradle प्लग इन तय करने का विकल्प है वर्शन फ़ाइल से वर्शन डाउनलोड करें और स्थिति में सोर्स फ़ाइलें:

# <root-project>/scenarios.txt
non_abi_change_agp4.1.0_kotlin1.4.10 {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    System-properties {
      "agpVersion" = "4.1.0"
      "kotlinVersion" = "1.4.10"
}

non_abi_change_agp4.2.0_kotlin1.4.20 {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    System-properties {
      "agpVersion" = "4.2.0-alpha16"
      "kotlinVersion" = "1.4.20"
}

इंक्रीमेंटल बिल्ड की प्रोफ़ाइल बनाना

ज़्यादातर बिल्ड इंंक्रीमेंटल होते हैं. इसलिए, यह सबसे ज़रूरी है प्रोफ़ाइल के लिए स्थितियां. Gradle प्रोफ़ाइलर, 18 साल से कम उम्र के दर्शकों के लिए प्रोफ़ाइलिंग इंक्रीमेंटल बिल्ड का इस्तेमाल करते हैं. यह तरीका मुख्य भाग, कोई नई विधि जोड़ना या कोई लेआउट या स्ट्रिंग संसाधन बदलना. इसके लिए उदाहरण के लिए, आप इस तरह के बढ़ते हुए स्थितियां बना सकते हैं:

# <root-project>/scenarios.txt
non_abi_change {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to = ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
}

abi_change {
    tasks = [":app:assembleDebug"]
    apply-abi-change-to = ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
}

layout_change {
    tasks = [":app:assembleDebug"]
    apply-android-layout-change-to = "app/src/main/res/your_layout_file.xml"
}
string_resource_change {
    tasks = [":app:assembleDebug"]
    apply-android-resource-value-change-to = "app/src/main/res/values/strings.xml"
}

gradle-profiler --benchmark --project-dir &lt;root-project> --scenario-file scenarios.txt चल रहा है मानदंड डेटा के साथ HTML रिपोर्ट जनरेट करेगा.

इंक्रीमेंटल स्थितियों को अन्य सेटिंग के साथ जोड़ा जा सकता है, जैसे कि हीप साइज़, वर्कर की संख्या या Gradle वर्शन:

# <root-project>/scenarios.txt
non_abi_change_4g {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx4096m"]
}

non_abi_change_4g_8workers {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx4096m"]
    gradle-args = ["--max-workers=8"]
}

non_abi_change_3g_gradle67 {
    tasks = [":app:assembleDebug"]
    apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
                              "app/src/main/java/com/example/your_app/your_code_file.kt"]
    jvm-args = ["-Xmx3072m"]
    version = ["6.7"]
}

क्लीन बिल्ड की प्रोफ़ाइल बनाना

एक बेहतर बिल्ड को बेंचमार्क करने के लिए, एक ऐसा उदाहरण बनाया जा सकता है जो Gradle-profiler एक्ज़ीक्यूशन को चलाने के लिए इस्तेमाल किया जाता है:

# <root-project>/scenarios.txt
clean_build {
    tasks = [":app:assembleDebug"]
    cleanup-tasks = ["clean"]
}

इस उदाहरण को चलाने के लिए, नीच�� दिए गए कमांड का इस्तेमाल करें:

gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt

Gradle --profile विकल्प इस्तेमाल करना

Gradle कमांड लाइन से बिल्ड प्रोफ़ाइल जनरेट करने और देखने के लिए, यहां बताया गया तरीका अपनाएं:

  1. अपने प्रोजेक्ट के रूट में कमांड-लाइन टर्मिनल खोलें.
  2. निम्न आदेश डालकर साफ़ बिल्ड चलाएं. प्रोफ़ाइल बनाने के दौरान आपको अपनी सभी प्रोफ़ाइल के बीच एक क्लीन बिल्ड करना चाहिए क्योंकि Gradle, टास्क को तब छोड़ देता है, जब किसी टास्क (जैसे कि सोर्स कोड) के इनपुट काम नहीं करते बदलें. इस तरह, इनपुट में बदलाव किए बिना दूसरा बिल्ड हमेशा तेज़ी से काम करता है, क्योंकि टास्क फिर से नहीं चलाए जा रहे हैं. इसलिए, clean टास्क को इनके बीच चलाया जा रहा है आपके बिल्ड पक्का करते हैं कि आप बिल्ड प्रोसेस को पूरी तरह से प्रोफ़ाइल में रखें. 
    // On Mac or Linux, run the Gradle wrapper using "./gradlew".
gradlew clean
  3. अपने प्रॉडक्ट के किसी एक फ़्लेवर का डीबग बिल्ड पूरा करें, जैसे कि "डेवलपर" फ़्लेवर, इन फ़्लैग के साथ: 
    gradlew --profile --offline --rerun-tasks assembleFlavorDebug
    • --profile: प्रोफ़ाइल बनाने की सुविधा चालू करती है.
    • --offline: Gradle को ऑनलाइन फ़ेच करने से बंद करता है निर्भरता. यह Gradle की वजह से होने वाली देरी से ज़्यादा ज़रूरी है अपनी डिपेंडेंसी अपडेट करने की कोशिश करने से, आपकी प्रोफ़ाइलिंग डेटा. आपको अपना प्रोजेक्ट पहले ही बना लेना चाहिए पक्का करें कि Gradle ने आपकी डिपेंडेंसी को पहले ही डाउनलोड और कैश मेमोरी में सेव किया हो.
    • --rerun-tasks: Gradle को सभी टास्क फिर से चलाने और अनदेखा करने में मदद मिलती है किसी भी टास्क को ऑप्टिमाइज़ कर सकता है.

  4. पहला डायग्राम. इसकी जगह को दिखाने वाला प्रोजेक्ट व्यू प्रोफ़ाइल रिपोर्ट.

    बिल्ड पूरा होने के बाद, प्रोजेक्ट विंडो का इस्तेमाल करके, project-root/build/reports/profile/ डायरेक्ट्री (इस रूप में) पहली इमेज में दिखाया गया है).

  5. profile-timestamp.html फ़ाइल पर राइट क्लिक करें और इसे चुनें ब्राउज़र में खोलें > डिफ़ॉल्ट. रिपोर्ट इससे मिलती-जुलती होनी चाहिए दूसरी इमेज में दिखाया गया है. रिपोर्ट में मौजूद हर टैब की जांच करके, यह पता लगाया जा सकता है कि बिल्ड, जैसे कि टास्क एक्ज़ीक्यूशन टैब, जो दिखाता है कि Gradle ने कितना समय लिया का इस्तेमाल करें.

    दूसरा डायग्राम. ब्राउज़र में रिपोर्ट देखना.

  6. ज़रूरी नहीं: अपने प्रोजेक्ट या बिल्ड में कोई बदलाव करने से पहले कॉन्फ़िगरेशन के लिए, तीसरे चरण में दिए गए निर्देश को दोहराएं, लेकिन --rerun-tasks फ़्लैग. क्योंकि Gradle, समय बचाने की कोशिश करता है उन टास्क को फिर से लागू करना जिनके इनपुट में कोई बदलाव नहीं हुआ है. इन्हें इस तरह से दिखाया गया है रिपोर्ट के टास्क एक्ज़ीक्यूट करना टैब में UP-TO-DATE, जैसा कि दिखाया गया है तीसरी इमेज में दिखाया गया है). नहीं होना चाहिए. उदाहरण के लिए, अगर :app:processDevUniversalDebugManifest को इसके तौर पर मार्क नहीं किया गया है UP-TO-DATE, यह सुझाव दे सकता है कि आपका बिल्ड कॉन्फ़िगरेशन हर बिल्ड के साथ मेनिफ़ेस्ट को डाइनैमिक तरीके से अपडेट करना. हालांकि, कुछ टास्क के लिए हर बिल्ड के दौरान ट्रिगर होता है, जैस��� कि :app:checkDevDebugManifest.

    तीसरी इमेज. टास्क लागू होने के नतीजे देखे जा रहे हैं.

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

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

चौथी इमेज. बिल्ड को ऑप्टिमाइज़ करने के बाद नई रिपोर्ट देखना स्पीड.