बिल्ड की स्पीड ऑप्टिमाइज़ करें

लंबे समय तक बने रहने से आपकी डेवलपमेंट प्रोसेस धीमी हो जाती है. इस पेज में कुछ ऐसी तकनीकें दी गई हैं जिनकी मदद से बिल्ड स्पीड अड़चनों को दूर करें.

ऐप्लिकेशन की बिल्ड स्पीड को बेहतर बनाने की सामान्य प्रोसेस यहां दी गई है:

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

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

ध्यान दें: पहली बार क्लीन बिल्ड के बाद, आपको यह साफ़ और इंंक्रीमेंटल, दोनों तरह से बिल्ड करता है. आपके किसी भी टूल का इस्तेमाल किए बिना भी यह तेज़ी से काम करता है. इस पेज पर दिए गए ऑप्टिमाइज़ेशन के बारे में बताया गया है. ऐसा इसलिए है, क्योंकि ग्रेडल डीमन वह "खास जानकारी" देता है परफ़ॉर्मेंस में बढ़ोतरी की अवधि—जो अन्य जेवीएम की तरह है प्रोसेस.

अपने बिल्ड कॉन्फ़िगरेशन को ऑप्टिमाइज़ करें

बिल्ड को बेहतर बनाने के लिए इन सुझावों को अपनाएं आपके Android Studio प्रोजेक्ट के कितने काम हैं.

अपने टूल को अप-टू-डेट रखें

Android के टूल को बिल्ड ऑप्टिमाइज़ेशन और नई सुविधाएं मिलती हैं. हर अपडेट. इस पेज पर दी गई कुछ सलाह में यह माना गया है कि आप सबसे नए वर्शन का इस्तेमाल कर रहे हैं वर्शन है. नए ऑप्टिमाइज़ेशन का फ़ायदा पाने के लिए, यह जानकारी बनाए रखें इस तारीख तक:

• Android Studio और SDK टूल
• Android Gradle प्लग इन

Kapt के बजाय KSP का उपयोग करें

Kotlin एनोटेशन प्रोसेसिंग टूल (kapt), Kotlin की तुलना में काफ़ी धीमा है सिंबल प्रोसेसर (KSP). अगर आपने Kotlin सोर्स की व्याख्या की है और उस टूल का इस्तेमाल किया है व्याख्याओं को प्रोसेस करता है (जैसे कि Room) जो केएसपी के साथ काम करता है, तो आपको केएसपी में माइग्रेट करना होगा.

गैर-ज़रूरी संसाधनों को कंपाइल करने से बचें

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

android {
    ...
    productFlavors {
        dev {
            ...
            // The following configuration limits the "dev" flavor to using
            // English stringresources and xxhdpi screen-density resources.
            resourceConfigurations "en", "xxhdpi"
        }
        ...
    }
}

android {
    ...
    productFlavors {
        create("dev") {
            ...
            // The following configuration limits the "dev" flavor to using
            // English stringresources and xxhdpi screen-density resources.
            resourceConfigurations("en", "xxhdpi")
        }
        ...
    }
}

Gradle प्लग इन पोर्टल को अंतिम रूप देने के साथ प्रयोग करें

Android में, सभी प्लग इन google() और mavenCentral() डेटा स्टोर करने की जगहें. हालांकि, आपके बिल्ड में जिनका समाधान gradlePluginPortal() सेवा.

Gradle, डेटा स्टोर करने की जगह को उसी क्रम में खोजता है जिस क्रम में उसे खोजा जाता है, इसलिए, अगर डेटा स्टोर करने की पहले से सूची में शामिल डेटा स्टोर करने की जगहों को शामिल किया जाता है, तो बिल्ड की परफ़ॉर्मेंस बेहतर हो जाती है ज़्यादातर प्लग इन. इसलिए, gradlePluginPortal() के साथ प्रयोग करें अपने settings.gradle में रिपॉज़िटरी ब्लॉक में डालकर एंट्री करें फ़ाइल से लिए जाते हैं. ज़्यादातर मामलों में, यह अनावश्यक प्लगिन खोजों की संख्या को कम करता है और आपकी बिल्ड स्पीड को बेहतर बनाता है.

Gradle, एक से ज़्यादा डेटा स्टोर करने की जगहों में कैसे नेविगेट करता है, इस बारे में ज़्यादा जानकारी के लिए यहां देखें डेटा स्टोर करने की एक से ज़्यादा जगहों का एलान करना Gradle दस्तावेज़ में देखा जा सकता है.

डीबग बिल्ड के साथ स्टैटिक बिल्ड कॉन्फ़िगरेशन वैल्यू का इस्तेमाल करें

उन प्रॉपर्टी के लिए हमेशा स्टैटिक वैल्यू का इस्तेमाल करें जो मेनिफ़ेस्ट फ़ाइल या रिसॉर्स फ़ाइलों में जाती हैं डीबग बिल्ड टाइप.

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

  ...
  // Use a filter to apply onVariants() to a subset of the variants.
  onVariants(selector().withBuildType("release")) { variant ->
      // Because an app module can have multiple outputs when using multi-APK, versionCode
      // is only available on the variant output.
      // Gather the output when we are in single mode and there is no multi-APK.
      val mainOutput = variant.outputs.single { it.outputType == OutputType.SINGLE }

      // Create the version code generating task.
      val versionCodeTask = project.tasks.register("computeVersionCodeFor${variant.name}", VersionCodeTask::class.java) {
          it.outputFile.set(project.layout.buildDirectory.file("versionCode${variant.name}.txt"))
      }

      // Wire the version code from the task output.
      // map will create a lazy Provider that:
      // 1. Runs just before the consumer(s), ensuring that the producer (VersionCodeTask) has run
      //    and therefore the file is created.
      // 2. Contains task dependency information so that the consumer(s) run after the producer.
      mainOutput.versionCode.set(versionCodeTask.flatMap { it.outputFile.map { it.asFile.readText().toInt() } })
  }
  ...

  abstract class VersionCodeTask : DefaultTask() {

    @get:OutputFile
    abstract val outputFile: RegularFileProperty

    @TaskAction
    fun action() {
        outputFile.get().asFile.writeText("1.1.1")
    }
  }

स्टैटिक डिपेंडेंसी वर्शन का इस्तेमाल करें

अपनी build.gradle फ़ाइलों में डिपेंडेंसी का एलान करते समय, डाइनैमिक वर्शन का इस्तेमाल करने से बचें संख्याएं (वे जिनके अंत में प्लस का चिह्न होता है, जैसे 'com.android.tools.build:gradle:2.+'). डायनमिक वर्शन नंबरों का इस्तेमाल करने से, अनचाहे वर्शन अपडेट हो सकते हैं और वर्शन रिज़ॉल्व करने में समस्या आ सकती है और रेंडर होने में ज़्यादा समय लग सकता है, क्योंकि यह Gradle अपडेट की जांच करता है. इसके बजाय, स्टैटिक वर्शन नंबरों का इस्तेमाल करें.

लाइब्रेरी मॉड्यूल बनाएं

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

कस्टम बिल्ड लॉजिक के लिए टास्क बनाएं

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

सलाह: अगर आपके बिल्ड में कई कस्टम टास्क शामिल हैं, तो आपको कस्टम टास्क क्लास बनाकर, अपनी build.gradle फ़ाइलों को व्यवस्थित करना चाहते हैं. अपनी क्लास को इसमें जोड़ें project-root/buildSrc/src/main/groovy/ डायरेक्ट्री; Gradle, इन क्लास को सभी के लिए अपने-आप क्लासपाथ में शामिल कर लेता है आपके प्रोजेक्ट में build.gradle फ़ाइलें हैं.

इमेज को WebP में बदलें

WebP एक इमेज फ़ाइल है ऐसा फ़ॉर्मैट जो कम क्वालिटी वाली कंप्रेस करने के साथ-साथ पारदर्शिता भी उपलब्ध कराता है, जैसे कि JPEG (जैसे PNG). JPEG या PNG के मुकाबले WebP बेहतर तरीके से कंप्रेस कर सकता है.

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

PNG क्रंचिंग बंद करें

अगर इमेज को PNG फ़ॉर्मैट में नहीं बदला जाता है, तो WebP में इमेज जोड़ने की अनुमति दें. इसके बाद भी अपने-आप जनरेट होने की सुविधा को बंद करके, बिल्ड की स्पीड बढ़ाई जा सकती है हर बार ऐप्लिकेशन बनाने पर इमेज को कंप्रेस करने की सुविधा मिलती है.

अगर Android Gradle प्लग इन 3.0.0 का इस्तेमाल किया जा रहा है या ज़्यादा, तो "डीबग" के लिए, PNG क्रंचिंग डिफ़ॉल्ट रूप से बंद रहती है बिल्ड टाइप. इसे बंद करने के लिए अन्य बिल्ड टाइप के लिए ऑप्टिमाइज़ेशन, अपनी build.gradle फ़ाइल में यह जोड़ें:

android {
    buildTypes {
        release {
            // Disables PNG crunching for the "release" build type.
            crunchPngs false
        }
    }
}

android {
    buildTypes {
        getByName("release") {
            // Disables PNG crunching for the "release" build type.
            isCrunchPngs = false
        }
    }
}

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

जेवीएम पैरलल गार्बेज कलेक्टर के साथ प्रयोग करें

बिल्ड की परफ़ॉर्मेंस को बेहतर बनाने के लिए, Gradle में इस्तेमाल किए जाने वाले सबसे सही JVM गार्बेज कलेक्टर को कॉन्फ़िगर किया जा सकता है. JDK 8 को डिफ़ॉल्ट रूप से, पैरलल गार्बेज कलेक्टर का इस्तेमाल करने के लिए कॉन्फ़िगर किया गया है. वहीं, JDK 9 और उसके बाद के वर्शन को इस्तेमाल करने के लिए कॉन्फ़िगर किया गया G1 गार्बेज कलेक्टर है.

हमारा सुझाव है कि बिल्ड की परफ़ॉर्मेंस को बेहतर बनाने के लिए, अपने Gradle बिल्ड को टेस्ट करना, गार्बेज कलेक्टर. gradle.properties में यह सेट करें:

org.gradle.jvmargs=-XX:+UseParallelGC

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

org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC

अलग-अलग कॉन्फ़िगरेशन की मदद से बिल्ड की स्पीड मापने के लिए, यहां देखें अपने बिल्ड को प्रोफ़ाइल बनाएं.

जेवीएम हीप साइज़ को बढ़ाना

अगर रेंडर होने में ज़्यादा समय लगता है और खास तौर पर, तो कचरा इकट्ठा करने में 15% से ज़्यादा अपने वर्कआउट को बिल्ड ऐनालाइज़र नतीजे हैं, तो आपको Java Virtual Machine (JVM) हीप साइज़ बढ़ाना चाहिए. gradle.properties फ़ाइल में, फ़ाइल की सीमा 4, 6 या 8 गीगाबाइट (जीबी) पर सेट करें जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है:

org.gradle.jvmargs=-Xmx6g

इसके बाद, बिल्ड की स्पीड में सुधार करने की जांच करें. सबसे बेहतर हीप का पता लगाने का सबसे आसान तरीका साइज़, सीमा को थोड़ा सा बढ़ाना है और फिर उसकी जांच करके ज़रूरत के मुताबिक बिल्ड गति में सुधार हुआ.

अगर आपको यह भी इस्तेमाल करना है, जेवीएम पैरलल गार्बेज कलेक्टर, तो पूरी लाइन इस तरह से दिखनी चाहिए:

org.gradle.jvmargs=-Xmx6g -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 -XX:+UseParallelGC -XX:MaxMetaspaceSize=1g

HeapDumpOnOutOfMemoryError को चालू करके जेवीएम की मेमोरी की गड़बड़ियों का विश्लेषण करने की सुविधा फ़्लैग करें. ऐसा करने से जेवीएम, मेमोरी खत्म होने पर हीप डंप जनरेट करेगा.

असंक्रामक R क्लास का इस्तेमाल करें

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

Android Studio Bumblebee की शुरुआत में, नए प्रोजेक्ट के लिए नॉन-ट्रांज़िव R क्लास डिफ़ॉल्ट रूप से चालू रहेगी. Android Studio के पुराने वर्शन में बनाए गए प्रोजेक्ट के लिए, ऐसी स्थिति का इस्तेमाल करने के लिए अपडेट करें जो अस्थायी न हो R क्लास के लिए, Refactor > में जाएं नॉन-ट्रांज़िटिव R क्लास पर माइग्रेट करें.

ऐप्लिकेशन के संसाधनों और R क्लास के बारे में ज़्यादा जानने के लिए, यहां देखें ऐप्लिकेशन के संसाधनों की खास जानकारी.

अनिश्चित R क्लास का इस्तेमाल करना

नॉन-कॉन्सटेंट R क्लास का इस्तेमाल करें ऐप्लिकेशन में फ़ील्ड शामिल किए जा सकते हैं और Java को कंपाइल करने की प्रोसेस को बेहतर बनाने के लिए, उसकी जांच की जा सकती है साथ ही, इससे रिसॉर्स को ज़्यादा सटीक तरीके से छोटा करने में मदद मिलती है. R क्लास फ़ील्ड लाइब्रेरी के लिए हमेशा स्थिर नहीं होते, क्योंकि संसाधनों को संख्या दी जाती है जब ऐप्लिकेशन या टेस्ट के लिए APK की पैकेजिंग की जाएगी, जो उस लाइब्रेरी पर निर्भर करता है. यह 'Android Gradle प्लग इन 8.0.0' और इसके बाद वाले वर्शन में डिफ़ॉल्ट तौर पर काम करता है.

Jetifier फ़्लैग बंद करें

चूंकि ज़्यादातर प्रोजेक्ट सीधे AndroidX लाइब्रेरी का उपयोग करते हैं, इसलिए आप Jetifier फ़्लैग की मदद से बिल्ड की बेहतर परफ़ॉर्मेंस के लिए अनुरोध किया जा सकता है. हटाने के लिए Jetifier फ़्लैग, android.enableJetifier=false को अपने gradle.properties फ़ाइल.

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

कॉन्फ़िगरेशन कैश का इस्तेमाल करना

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

कॉन्फ़िगरेशन कैश मेमोरी को चालू करने के लिए, यह तरीका अपनाएं:

1. जांचें कि सभी प्रोजेक्ट प्लगिन साथ काम करते हैं या नहीं.

   इसका इस्तेमाल करें Analytics बनाएं, ताकि यह पता लगाया जा सके कि प्रोजेक्ट, कॉन्फ़िगरेशन कैश मेमोरी के साथ काम करता हो. बिल्ड ऐनालाइज़र टेस्ट का क्रम चलाता है यह तय करता है कि इस सुविधा को प्रोजेक्ट के लिए चालू किया जा सकता है या नहीं. यहां जाएं: समस्या #13490: इस्तेमाल किए जा सकने वाले प्लगिन की सूची.

2. gradle.properties फ़ाइल में यह कोड जोड़ें:

     org.gradle.configuration-cache=true
     # Use this flag carefully, in case some of the plugins are not fully compatible.
     org.gradle.configuration-cache.problems=warn

कॉन्फ़िगरेशन कैश मेमोरी के चालू होने पर, पहली बार प्रोजेक्ट को चलाने पर बिल्ड आउटपुट Calculating task graph as no configuration cache is available for tasks का कहना है. इस दौरान रन करने के बाद, बिल्ड आउटपुट में Reusing configuration cache दिखता है.

कॉन्फ़िगरेशन कैश के बारे में ज़्यादा जानने के लिए, ब्लॉग पोस्ट देखें कॉन्फ़िगरेशन को कैश मेमोरी में सेव करने की जानकारी और Gradle दस्तावेज़ कॉन्फ़िगरेशन कैश मेमोरी.

Gradle 8.1 और 'Android Gradle प्लग इन 8.1' में कॉन्फ़िगरेशन की कैश मेमोरी की समस्याएं आई

Gradle 8.1 में कॉन्फ़िगरेशन की कैश मेमोरी स्थिर हो गई और फ़ाइल एपीआई की सुविधा भी शुरू की गई ट्रैकिंग. File.exists(), File.isDirectory(), और File.list() जैसे कॉल यह रिकॉर्ड कर रहे हैं: कॉन्फ़िगरेशन इनपुट फ़ाइलों को ट्रैक करने के लिए Gradle.

'Android Gradle प्लग इन (AGP)' 8.1, कुछ फ़ाइलों के लिए इन File एपीआई का इस्तेमाल करता है, जिन्हें Gradle को करना चाहिए इन्हें कैश इनपुट नहीं माना जाता. इसके साथ इस्तेमाल किए जाने पर, कैश मेमोरी में सेव किए गए अमान्य होने की अतिरिक्त गड़बड़ी ट्रिगर हो जाती है Gradle 8.1 और उसके बाद वाले वर्शन, बिल्ड की परफ़ॉर्मेंस धीमी हो रही है. इन्हें एजीपी 8.1 में कैश इनपुट माना जाता है:

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