আপনার বিল্ড স্পিড অপ্টিমাইজ করা

বিল্ড করার সময় বেশি লাগলে ডেভেলপমেন্ট প্রসেস ধীর হয়ে যায়। এই পৃষ্ঠায় বিল্ড স্পিড সংক্রান্ত সমস্যা সমাধান করার কিছু কৌশল দেওয়া হয়েছে।

আপনার অ্যাপের বিল্ড স্পিড উন্নত করার সাধারণ প্রসেস হল:

1. কয়েকটি ধাপ অনুসরণ করে আপনার বিল্ড কনফিগারেশন অপ্টিমাইজ করুন যা বেশিরভাগ Android Studio প্রোজেক্টের ক্ষেত্রে অবিলম্বে কার্যকর হয়।
2. আপনার প্রজেক্ট বা ওয়ার্কস্টেশনের জন্য নির্দিষ্ট হতে পারে এমন কিছু আরও কঠিন বোতলনেক শনাক্ত ও ডায়াগনসিস করতে আপনার বিল্ড প্রোফাইল করুন।

আপনার অ্যাপ ডেভেলপ করার সময়, যখনই সম্ভব Android 7.0 (API লেভেল 24) বা তার পরবর্তী যেকোনও ভার্সনে চলা ডিভাইসে ডিপ্লয় করুন। Android প্ল্যাটফর্মের নতুন ভার্সন আপনার অ্যাপে আপডেট পুশ করার জন্য আরও ভাল মেকানিক্স প্রয়োগ করে, যেমন Android Runtime (ART) এবং একাধিক DEX ফাইলের জন্য নেটিভ সহায়তা।

মনে রাখবেন: প্রথম ক্লিন বিল্ডের পরে, আপনি হয়ত লক্ষ্য করবেন যে পরবর্তী বিল্ড, ক্লিন ও ইনক্রিমেন্টাল, দু'টিই অনেক দ্রুত পারফর্ম করছে, এমনকি এই পৃষ্ঠায় বর্ণিত অপ্টিমাইজেশনের কোনওটি ব্যবহার না করেও। এর কারণ হল, Gradle ডেমন পারফর্ম্যান্স বাড়ানোর জন্য "ওয়ার্ম-আপ" পিরিয়ড থাকে—অন্যান্য JVM প্রসেসের মতো।

আপনার বিল্ড কনফিগারেশন অপ্টিমাইজ করা

আপনার Android Studio প্রোজেক্টের বিল্ড স্পিড উন্নত করতে এইসব পরামর্শ অনুসরণ করুন।

আপনার টুল আপ-টু-ডেট রাখুন

প্রায় প্রতিটি আপডেটের সাথে Android টুলে বিল্ড অপ্টিমাইজেশন ও নতুন ফিচার যোগ করা হয়। এই পৃষ্ঠায় দেওয়া কিছু পরামর্শে ধরে নেওয়া হয়েছে যে আপনি লেটেস্ট ভার্সন ব্যবহার করছেন। লেটেস্ট অপ্টিমাইজেশনের সুবিধা নিতে, নিম্নলিখিত বিষয়গুলি আপ-টু-ডেট রাখুন:

• Android Studio ও SDK টুল
• Android Gradle প্লাগ-ইন

kapt-এর পরিবর্তে KSP ব্যবহার করুন

Kotlin অ্যানোটেশন প্রসেসিং টুল (kapt), Kotlin সিম্বল প্রসেসর (KSP)-এর থেকে অনেক বেশি ধীরে কাজ করে। আপনি যদি অ্যানোটেটেড Kotlin সোর্স কোড লেখেন এবং এমন টুলিং ব্যবহার করেন যা অ্যানোটেশন প্রসেস করে (যেমন Room) যা KSP-তে কাজ করে, তাহলে আপনাকে KSP-তে মাইগ্রেট করতে হবে।

অপ্রয়োজনীয় রিসোর্স কম্পাইল করা এড়িয়ে চলুন

আপনি পরীক্ষা করছেন না এমন রিসোর্স কম্পাইল ও প্যাকেজ করা এড়িয়ে চলুন, যেমন অতিরিক্ত ভাষা সংক্রান্ত লোকালাইজেশন ও স্ক্রিন-ডেন্সিটি রিসোর্স। পরিবর্তে, আপনার "dev" ফ্লেভারের জন্য শুধুমাত্র একটি ভাষা রিসোর্স এবং স্ক্রিন ডেনসিটি উল্লেখ করুন, যেমনটি নিম্নলিখিত স্যাম্পেলে দেখানো হয়েছে:

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 ছবি ডিকম্প্রেস করার সময় ডিভাইসের CPU ব্যবহারের পরিমাণ সামান্য বাড়তে পারে। সহজে আপনার ছবিকে WebP-তে কনভার্ট করতে Android Studio ব্যবহার করুন।

PNG ক্রাঞ্চিং বন্ধ করুন

আপনি PNG ছবিকে WebP-তে কনভার্ট না করলেও প্রতিবার অ্যাপ বিল্ড করার সময় অটোমেটিক ছবি কম্প্রেশন বন্ধ করে দিয়ে বিল্ড করার প্রসেস দ্রুত করতে পারবেন।

আপনি Android Gradle plugin 3.0.0 বা এর পরের যেকোনও ভার্সন ব্যবহার করলে, "debug" বিল্ডের জন্য ডিফল্ট হিসেবে 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 হিসেবে সেট করতে হবে।

JVM প্যারালাল গার্বেজ কালেক্টর নিয়ে এক্সপেরিমেন্ট করা

Gradle-এর ব্যবহার করা অপ্টিমাল JVM গার্বেজ কালেক্টর কনফিগার করার মাধ্যমে বিল্ড পারফর্ম্যান্স উন্নত করা যেতে পারে। JDK 8 ডিফল্ট হিসেবে প্যারালাল গার্বেজ কালেক্টর ব্যবহার করার জন্য কনফিগার করা থাকলেও, JDK 9 এবং তার পরবর্তী ভার্সন G1 গার্বেজ কালেক্টর ব্যবহার করার জন্য কনফিগার করা থাকে।

বিল্ড পারফর্ম্যান্স উন্নত করার জন্য, আমরা সমান্তরাল গার্বেজ কালেক্টরের সাথে আপনার Gradle বিল্ড টেস্ট করার সাজেশন দিই। gradle.properties-এ নিম্নলিখিতগুলি সেট করুন:

org.gradle.jvmargs=-XX:+UseParallelGC

এই ফিল্ডে আগে থেকেই অন্য বিকল্প সেট করা থাকলে, নতুন বিকল্প যোগ করুন:

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

বিভিন্ন কনফিগারেশনের সাথে বিল্ড স্পিড পরিমাপ করতে, আপনার বিল্ড প্রোফাইল করুন দেখুন।

JVM হিপ সাইজ বাড়ানো

আপনি যদি দেখেন যে বিল্ড খুব ধীরে ধীরে হচ্ছে এবং বিশেষ করে গার্বেজ কালেকশন আপনার বিল্ড অ্যানালাইজার ফলাফলে বিল্ড টাইমের ১৫%-এর বেশি সময় নিচ্ছে, তাহলে আপনাকে জাভা ভার্চুয়াল মেশিন (JVM) হিপ সাইজ বাড়াতে হবে। gradle.properties ফাইলে, সীমা ৪, ৬ বা ৮ গিগাবাইটে সেট করুন যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:

org.gradle.jvmargs=-Xmx6g

তারপর, বিল্ড স্পিড উন্নত হয়েছে কিনা তা পরীক্ষা করুন। সর্বোত্তম হিপ সাইজ নির্ধারণ করার সবচেয়ে সহজ উপায় হল, অল্প পরিমাণে সীমা বাড়ানো এবং তারপরে পর্যাপ্ত বিল্ড স্পিড ইমপ্রুভমেন্টের জন্য পরীক্ষা করা।

আপনি যদি JVM প্যারালাল গার্বেজ কালেক্টর-ও ব্যবহার করেন, তাহলে পুরো লাইনটি এমন দেখতে হবে:

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

HeapDumpOnOutOfMemoryError ফ্ল্যাগ চালু করে আপনি JVM মেমরি সংক্রান্ত সমস্যা বিশ্লেষণ করতে পারবেন। এটি করলে, মেমরি শেষ হয়ে গেলে JVM একটি হিপ ডাম্প তৈরি করবে।

নন-ট্রানজিটিভ R ক্লাস ব্যবহার করুন

একাধিক মডিউল সহ অ্যাপের জন্য দ্রুত বিল্ড পেতে ট্রানজিটিভ নয় এমন R ক্লাস ব্যবহার করুন। এটি করলে, রিসোর্স ডুপ্লিকেট হওয়া আটকানো যায়, কারণ প্রতিটি মডিউলের R ক্লাসে শুধুমাত্র নিজস্ব রিসোর্সের রেফারেন্স থাকে এবং এর ডিপেন্ডেন্সি থেকে কোনও রেফারেন্স নেওয়া হয় না। এর ফলে দ্রুত বিল্ড তৈরি করা যায় এবং কম্পাইলেশন এড়ানোর সুবিধা পাওয়া যায়। Android Gradle প্লাগ-ইন 8.0.0 এবং তার পরবর্তী যেকোনও ভার্সনে এটি ডিফল্ট অ্যাকশন।

Android Studio Bumblebee থেকে শুরু করে, নতুন প্রোজেক্টের জন্য নন-ট্রানজিটিভ R ক্লাস ডিফল্ট হিসেবে চালু থাকে। Android Studio-এর আগের ভার্সন দিয়ে তৈরি করা প্রোজেক্টের জন্য, রিফ্যাক্টর করুন > নন-ট্রানজিটিভ R ক্লাসে মাইগ্রেট করুন বিকল্পে গিয়ে নন-ট্রানজিটিভ R ক্লাস ব্যবহার করতে সেগুলি আপডেট করুন।

অ্যাপ রিসোর্স ও R ক্লাস সম্পর্কে আরও জানতে, অ্যাপ রিসোর্সের ওভারভিউ দেখুন।

নন-কনস্ট্যান্ট R ক্লাস ব্যবহার করা

Java কম্পাইলেশনের ইনক্রিমেন্টালিটি উন্নত করতে এবং আরও নির্ভুল রিসোর্স সঙ্কোচনের অনুমতি দিতে অ্যাপ এবং টেস্টে নন-কনস্ট্যান্ট R ক্লাস ফিল্ড ব্যবহার করুন। R ক্লাস ফিল্ড লাইব্রেরির জন্য সবসময় ধ্রুবক হয় না, কারণ সেই লাইব্রেরির উপর নির্ভর করে এমন অ্যাপ বা টেস্টের জন্য APK প্যাকেজ করার সময় রিসোর্সগুলিকে নম্বর দেওয়া হয়। Android Gradle Plugin 8.0.0 ও তার পরবর্তী যেকোনও ভার্সনে এটি ডিফল্ট আচরণ।

Jetifier ফ্ল্যাগ বন্ধ করুন

বেশিরভাগ প্রোজেক্ট সরাসরি AndroidX লাইব্রেরি ব্যবহার করে বলে, আরও ভালো বিল্ড পারফর্ম্যান্সের জন্য আপনি Jetifier ফ্ল্যাগ সরিয়ে দিতে পারেন। Jetifier ফ্ল্যাগ সরিয়ে দিতে, আপনার gradle.properties ফাইলে android.enableJetifier=false সেট করুন।

বিল্ড অ্যানালাইজার চেক করে দেখতে পারে যে ফ্ল্যাগটি নিরাপদে সরানো যাবে কিনা যাতে আপনার প্রোজেক্টের বিল্ড পারফর্ম্যান্স আরও ভালো হয় এবং রক্ষণাবেক্ষণ না করা Android সাপোর্ট লাইব্রেরি থেকে মাইগ্রেট করা যায়। বিল্ড অ্যানালাইজার সম্পর্কে আরও জানতে, বিল্ড পারফর্ম্যান্স সংক্রান্ত সমস্যার সমাধান করুন দেখুন।

কনফিগারেশন ক্যাশে ব্যবহার করা

কনফিগারেশন ক্যাশে Gradle-কে বিল্ড টাস্ক গ্রাফ সম্পর্কে তথ্য রেকর্ড করতে এবং পরবর্তী বিল্ডে এটি আবার ব্যবহার করতে দেয়, তাই Gradle-কে আবার পুরো বিল্ডটি পুনরায় কনফিগার করতে হবে না।

কনফিগারেশন ক্যাশে চালু করতে, এই ধাপগুলি অনুসরণ করুন:

1. সব প্রোজেক্ট প্লাগ-ইন মানানসই কিনা তা চেক করুন।

   আপনার প্রোজেক্ট কনফিগারেশন ক্যাশের সাথে মানানসই কিনা তা চেক করতে বিল্ড অ্যানালাইজার ব্যবহার করুন। প্রোজেক্টের জন্য ফিচারটি চালু করা যাবে কিনা তা নির্ধারণ করতে বিল্ড অ্যানালাইজার টেস্ট বিল্ডের একটি ক্রম চালায়। কাজ করে এমন প্লাগ-ইনের তালিকা দেখতে সমস্যা #১৩৪৯০ দেখুন।

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 Plugin 8.1-এ কনফিগারেশন ক্যাশে সংক্রান্ত সমস্যা

Gradle 8.1-এ কনফিগারেশন ক্যাশে স্থিতিশীল হয়ে গেছে এবং ফাইল API ট্র্যাকিং চালু করা হয়েছে। কনফিগারেশন ইনপুট ফাইল ট্র্যাক করার জন্য Gradle-এর মাধ্যমে File.exists(), File.isDirectory() ও File.list()-এর মতো কল রেকর্ড করা হয়।

Android Gradle Plugin (AGP) 8.1 কিছু ফাইলের জন্য এই File API ব্যবহার করে যেগুলিকে Gradle-এর ক্যাশে ইনপুট হিসেবে বিবেচনা করা উচিত নয়। Gradle 8.1 এবং তার পরবর্তী ভার্সনের সাথে ব্যবহার করা হলে এটি অতিরিক্ত ক্যাশে অবৈধকরণ ট্রিগার করে, বিল্ড পারফরম্যান্স স্লো করে দেয়। AGP 8.1-এ নিম্নলিখিত বিষয়গুলিকে ক্যাশে ইনপুট হিসেবে বিবেচনা করা হয়:

আপনি যদি এই API বা এই API ব্যবহার করে এমন কোনও প্লাগ-ইন ব্যবহার করেন, তাহলে আপনার বিল্ড টাইমে রিগ্রেশন হতে পারে, কারণ এই API ব্যবহার করে কিছু বিল্ড লজিক অতিরিক্ত ক্যাশে ইনভ্যালিডেশন ট্রিগার করতে পারে। এইসব প্যাটার্ন এবং কীভাবে বিল্ড লজিক ঠিক করতে হয় অথবা সাময়িকভাবে ফাইল API ট্র্যাকিং বন্ধ করতে হয়, সেই বিষয়ে আলোচনা করতে বিল্ড কনফিগারেশন ইনপুট ট্র্যাকিংয়ে উন্নতি লিঙ্কটি দেখুন।