দীর্ঘ বিল্ড সময় আপনার উন্নয়ন প্রক্রিয়া ধীর. এই পৃষ্ঠাটি গতির প্রতিবন্ধকতাগুলি সমাধান করতে সহায়তা করার জন্য কিছু কৌশল সরবরাহ করে।
আপনার অ্যাপের বিল্ড স্পিড উন্নত করার সাধারণ প্রক্রিয়া নিম্নরূপ:
- কিছু পদক্ষেপ গ্রহণ করে আপনার বিল্ড কনফিগারেশন অপ্টিমাইজ করুন যা অবিলম্বে বেশিরভাগ Android স্টুডিও প্রকল্পগুলিকে উপকৃত করে৷
- আপনার প্রকল্প বা ওয়ার্কস্টেশনের জন্য নির্দিষ্ট হতে পারে এমন কিছু জটিল বাধা শনাক্ত করতে এবং নির্ণয় করতে আপনার বিল্ড প্রোফাইল করুন ।
আপনার অ্যাপ ডেভেলপ করার সময়, যখনই সম্ভব Android 7.0 (API লেভেল 24) বা উচ্চতর চলমান ডিভাইসে স্থাপন করুন। Android প্ল্যাটফর্মের নতুন সংস্করণগুলি আপনার অ্যাপে আপডেটগুলি পুশ করার জন্য আরও ভাল মেকানিক্স প্রয়োগ করে, যেমন Android রানটাইম (ART) এবং একাধিক DEX ফাইলের জন্য নেটিভ সমর্থন৷
দ্রষ্টব্য: আপনার প্রথম পরিচ্ছন্ন বিল্ডের পরে, আপনি লক্ষ্য করতে পারেন যে পরবর্তী বিল্ডগুলি, পরিষ্কার এবং বর্ধিত উভয়ই, এই পৃষ্ঠায় বর্ণিত কোনো অপ্টিমাইজেশন ব্যবহার না করেও অনেক দ্রুত কাজ করে। এর কারণ হল গ্রেডল ডেমনের কার্যক্ষমতা বৃদ্ধির একটি "ওয়ার্ম-আপ" সময়কাল রয়েছে - অন্যান্য JVM প্রক্রিয়ার মতো।
আপনার বিল্ড কনফিগারেশন অপ্টিমাইজ করুন
আপনার অ্যান্ড্রয়েড স্টুডিও প্রকল্পের বিল্ড গতি উন্নত করতে এই টিপস অনুসরণ করুন।
আপনার টুল আপ টু ডেট রাখুন
অ্যান্ড্রয়েড টুলগুলি প্রায় প্রতিটি আপডেটের সাথে বিল্ড অপ্টিমাইজেশান এবং নতুন বৈশিষ্ট্যগুলি গ্রহণ করে৷ এই পৃষ্ঠার কিছু টিপস ধরে নেয় আপনি সর্বশেষ সংস্করণ ব্যবহার করছেন। সাম্প্রতিক অপ্টিমাইজেশানগুলির সুবিধা নিতে, নিম্নলিখিতগুলি আপ টু ডেট রাখুন:
kapt এর পরিবর্তে KSP ব্যবহার করুন
Kotlin অ্যানোটেশন প্রসেসিং টুল (kapt) Kotlin Symbol Processor (KSP)-এর তুলনায় উল্লেখযোগ্যভাবে ধীর। আপনি যদি টীকাযুক্ত কোটলিন উত্স লিখছেন এবং কেএসপি সমর্থন করে এমন টীকা (যেমন রুম ) প্রসেস করে এমন টুলিং ব্যবহার করছেন, আপনি KSP-তে স্থানান্তর করতে চাইবেন।
অপ্রয়োজনীয় সম্পদ সংকলন এড়িয়ে চলুন
অতিরিক্ত ভাষা স্থানীয়করণ এবং স্ক্রিন-ঘনত্বের সংস্থানগুলির মতো আপনি পরীক্ষা করছেন না এমন সংস্থানগুলি সংকলন এবং প্যাকেজিং এড়িয়ে চলুন। পরিবর্তে, আপনার "দেব" স্বাদের জন্য শুধুমাত্র একটি ভাষা সংস্থান এবং পর্দার ঘনত্ব নির্দিষ্ট করুন, যেমনটি নিম্নলিখিত নমুনায় দেখানো হয়েছে:
গ্রোভি
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") } ... } }
গ্র্যাডল প্লাগইন পোর্টালকে সর্বশেষে রেখে পরীক্ষা করুন
অ্যান্ড্রয়েডে, সমস্ত প্লাগইন 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") } }
আপনার প্রকল্পে একটি গতিশীল সংস্করণ কোড কীভাবে সেট করবেন তা শিখতে GitHub-এ setVersionsFromTask রেসিপিটি দেখুন।
স্ট্যাটিক নির্ভরতা সংস্করণ ব্যবহার করুন
যখন আপনি আপনার build.gradle ফাইলগুলিতে নির্ভরতা ঘোষণা করেন, তখন গতিশীল সংস্করণ নম্বর ব্যবহার করা এড়িয়ে চলুন (যার শেষে প্লাস চিহ্ন রয়েছে, যেমন 'com.android.tools.build:gradle:2.+' )। গতিশীল সংস্করণ নম্বরগুলি ব্যবহার করার ফলে অপ্রত্যাশিত সংস্করণ আপডেট হতে পারে, সংস্করণের পার্থক্যগুলি সমাধান করতে অসুবিধা হতে পারে এবং গ্র্যাডল আপডেটের জন্য পরীক্ষা করার কারণে ধীরগতির বিল্ড হতে পারে। পরিবর্তে স্ট্যাটিক সংস্করণ নম্বর ব্যবহার করুন.
লাইব্রেরি মডিউল তৈরি করুন
আপনার অ্যাপে কোড খুঁজুন যা আপনি একটি Android লাইব্রেরি মডিউলে রূপান্তর করতে পারেন। এইভাবে আপনার কোড মডুলারাইজ করা বিল্ড সিস্টেমকে শুধুমাত্র আপনার পরিবর্তন করা মডিউলগুলিকে কম্পাইল করতে এবং ভবিষ্যতের বিল্ডের জন্য সেই আউটপুটগুলিকে ক্যাশে করার অনুমতি দেয়। আপনি যখন সেই অপ্টিমাইজেশনটি সক্ষম করবেন তখন মডুলারাইজেশন সমান্তরাল প্রকল্প বাস্তবায়নকে আরও কার্যকর করে তোলে।
কাস্টম বিল্ড লজিকের জন্য কাজ তৈরি করুন
আপনি একটি বিল্ড প্রোফাইল তৈরি করার পরে, যদি বিল্ড প্রোফাইল দেখায় যে বিল্ড সময়ের একটি অপেক্ষাকৃত দীর্ঘ অংশ **প্রকল্প কনফিগারিং** পর্বে ব্যয় করা হয়েছে, আপনার build.gradle স্ক্রিপ্টগুলি পর্যালোচনা করুন এবং একটি কাস্টম গ্রেডল টাস্কে অন্তর্ভুক্ত করার জন্য কোডটি সন্ধান করুন . একটি টাস্কে কিছু বিল্ড লজিক সরানোর মাধ্যমে, আপনি নিশ্চিত করতে সাহায্য করেন যে টাস্কটি শুধুমাত্র প্রয়োজন হলেই চলে, ফলাফল পরবর্তী বিল্ডগুলির জন্য ক্যাশে করা যেতে পারে এবং আপনি সমান্তরাল প্রজেক্ট এক্সিকিউশন সক্ষম করলে সেই বিল্ড লজিক সমান্তরালভাবে চালানোর যোগ্য হয়ে ওঠে। কাস্টম বিল্ড লজিকের জন্য ট্যাক্স সম্পর্কে আরও জানতে, অফিসিয়াল গ্রেডল ডকুমেন্টেশন পড়ুন।
টিপ: আপনার বিল্ডে যদি প্রচুর পরিমাণে কাস্টম টাস্ক অন্তর্ভুক্ত থাকে, তাহলে আপনি কাস্টম টাস্ক ক্লাস তৈরি করে আপনার build.gradle ফাইলগুলিকে ডিক্লাটার করতে চাইতে পারেন। project-root /buildSrc/src/main/groovy/ ডিরেক্টরিতে আপনার ক্লাস যোগ করুন; Gradle স্বয়ংক্রিয়ভাবে আপনার প্রকল্পের সমস্ত build.gradle ফাইলের জন্য ক্লাসপথে সেই ক্লাসগুলিকে অন্তর্ভুক্ত করে।
ছবিগুলিকে WebP-এ রূপান্তর করুন
WebP হল একটি ইমেজ ফাইল ফরম্যাট যা ক্ষতিকর কম্প্রেশন (যেমন JPEG) এবং সেইসাথে স্বচ্ছতা (যেমন PNG) প্রদান করে। WebP JPEG বা PNG এর চেয়ে ভালো কম্প্রেশন প্রদান করতে পারে।
বিল্ড-টাইম কম্প্রেশন সঞ্চালন না করে ইমেজ ফাইলের আকার হ্রাস করা আপনার বিল্ডের গতি বাড়াতে পারে, বিশেষ করে যদি আপনার অ্যাপ প্রচুর ইমেজ রিসোর্স ব্যবহার করে। যাইহোক, WebP ছবিগুলিকে ডিকম্প্রেস করার সময় আপনি ডিভাইস CPU ব্যবহারে সামান্য বৃদ্ধি লক্ষ্য করতে পারেন। আপনার ছবিগুলিকে সহজেই WebP-এ রূপান্তর করতে Android স্টুডিও ব্যবহার করুন৷
PNG ক্রাঞ্চিং অক্ষম করুন
আপনি যদি আপনার PNG ছবিগুলিকে WebP-এ রূপান্তর না করেন, তবুও আপনি প্রতিবার আপনার অ্যাপ তৈরি করার সময় স্বয়ংক্রিয় চিত্র সংকোচন নিষ্ক্রিয় করে আপনার নির্মাণের গতি বাড়াতে পারেন৷
আপনি যদি অ্যান্ড্রয়েড গ্রেডল প্লাগইন 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 হিসাবে সেট করতে হবে৷
JVM সমান্তরাল আবর্জনা সংগ্রহকারীর সাথে পরীক্ষা করুন
Gradle দ্বারা ব্যবহৃত সর্বোত্তম JVM আবর্জনা সংগ্রহকারী কনফিগার করে বিল্ড কর্মক্ষমতা উন্নত করা যেতে পারে। যদিও JDK 8 ডিফল্টরূপে সমান্তরাল আবর্জনা সংগ্রহকারী ব্যবহার করার জন্য কনফিগার করা হয়েছে, JDK 9 এবং উচ্চতর G1 আবর্জনা সংগ্রহকারী ব্যবহার করার জন্য কনফিগার করা হয়েছে।
সম্ভাব্যভাবে বিল্ড কর্মক্ষমতা উন্নত করতে, আমরা আপনার গ্রেডল বিল্ডগুলি সমান্তরাল আবর্জনা সংগ্রহকারীর সাথে পরীক্ষা করার পরামর্শ দিই। gradle.properties এ নিম্নলিখিত সেট করুন:
org.gradle.jvmargs=-XX:+UseParallelGC
যদি এই ক্ষেত্রে অন্য বিকল্পগুলি ইতিমধ্যেই সেট করা থাকে তবে একটি নতুন বিকল্প যোগ করুন:
org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC
বিভিন্ন কনফিগারেশনের সাথে বিল্ডের গতি পরিমাপ করতে, আপনার বিল্ড প্রোফাইল দেখুন।
JVM হিপের আকার বাড়ান
আপনি যদি ধীর বিল্ডগুলি লক্ষ্য করেন, এবং বিশেষ করে আবর্জনা সংগ্রহ আপনার বিল্ড অ্যানালাইজার ফলাফলে বিল্ড সময়ের 15% এরও বেশি সময় নেয়, তাহলে আপনার জাভা ভার্চুয়াল মেশিন (JVM) হিপের আকার বৃদ্ধি করা উচিত। gradle.properties ফাইলে, নিম্নলিখিত উদাহরণে দেখানো হিসাবে সীমাটি 4, 6, বা 8 গিগাবাইটে সেট করুন:
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 এবং উচ্চতর ডিফল্ট আচরণ।
অ্যান্ড্রয়েড স্টুডিও বাম্বলবি দিয়ে শুরু করে, নতুন প্রজেক্টের জন্য ডিফল্টরূপে নন-ট্রানজিটিভ R ক্লাস চালু থাকে। অ্যান্ড্রয়েড স্টুডিওর পূর্ববর্তী সংস্করণগুলির সাথে তৈরি করা প্রকল্পগুলির জন্য, রিফ্যাক্টর > নন-ট্রানজিটিভ আর ক্লাসে মাইগ্রেট করে নন-ট্রানজিটিভ R ক্লাসগুলি R করার জন্য সেগুলিকে আপডেট করুন।
অ্যাপ রিসোর্স এবং R ক্লাস সম্পর্কে আরও জানতে, অ্যাপ রিসোর্স ওভারভিউ দেখুন।
অ ধ্রুবক R ক্লাস ব্যবহার করুন
জাভা সংকলনের বর্ধনশীলতা উন্নত করতে এবং আরও সুনির্দিষ্ট সম্পদ সঙ্কুচিত করার অনুমতি দিতে অ্যাপ্লিকেশন এবং পরীক্ষাগুলিতে অ-স্থির R ক্লাস ক্ষেত্রগুলি ব্যবহার করুন। R ক্লাস ক্ষেত্রগুলি লাইব্রেরির জন্য সবসময় ধ্রুবক থাকে না, কারণ সেই লাইব্রেরির উপর নির্ভর করে অ্যাপ বা পরীক্ষার জন্য APK প্যাকেজ করার সময় সংস্থানগুলি সংখ্যায়িত হয়। এটি অ্যান্ড্রয়েড গ্রেডল প্লাগইন 8.0.0 এবং উচ্চতর ডিফল্ট আচরণ।
জেটিফায়ার পতাকা নিষ্ক্রিয় করুন
যেহেতু বেশিরভাগ প্রকল্প সরাসরি AndroidX লাইব্রেরি ব্যবহার করে, আপনি আরও ভাল বিল্ড পারফরম্যান্সের জন্য Jetifier পতাকাটি সরাতে পারেন। জেটিফায়ার পতাকা সরাতে, আপনার gradle.properties ফাইলে android.enableJetifier=false সেট করুন।
বিল্ড বিশ্লেষক আপনার প্রকল্পটিকে আরও ভাল বিল্ড পারফরম্যান্স এবং অপরিবর্তিত অ্যান্ড্রয়েড সমর্থন লাইব্রেরি থেকে দূরে স্থানান্তর করতে সক্ষম করতে পতাকাটি নিরাপদে সরানো যায় কিনা তা দেখতে একটি পরীক্ষা করতে পারে৷ বিল্ড অ্যানালাইজার সম্পর্কে আরও জানতে, বিল্ড পারফরম্যান্সের সমস্যা সমাধান দেখুন।
কনফিগারেশন ক্যাশে ব্যবহার করুন
কনফিগারেশন ক্যাশে গ্র্যাডলকে বিল্ড টাস্ক গ্রাফ সম্পর্কে তথ্য রেকর্ড করতে দেয় এবং পরবর্তী বিল্ডগুলিতে এটি পুনরায় ব্যবহার করতে দেয়, তাই গ্র্যাডলকে পুরো বিল্ডটি পুনরায় কনফিগার করতে হবে না।
কনফিগারেশন ক্যাশে সক্ষম করতে, এই পদক্ষেপগুলি অনুসরণ করুন:
- সমস্ত প্রকল্প প্লাগইনগুলি সামঞ্জস্যপূর্ণ কিনা তা পরীক্ষা করুন৷
আপনার প্রকল্প কনফিগারেশন ক্যাশের সাথে সামঞ্জস্যপূর্ণ কিনা তা পরীক্ষা করতে বিল্ড অ্যানালাইজার ব্যবহার করুন। বিল্ড বিশ্লেষক প্রকল্পের জন্য বৈশিষ্ট্যটি চালু করা যেতে পারে কিনা তা নির্ধারণ করতে পরীক্ষার বিল্ডগুলির একটি ক্রম চালায়। সমর্থিত প্লাগইনগুলির একটি তালিকার জন্য সমস্যা #13490 দেখুন৷
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 8.1 এবং Android Gradle Plugin 8.1-এ কনফিগারেশন ক্যাশে সমস্যা চালু করা হয়েছে
Gradle 8.1-এ কনফিগারেশন ক্যাশে স্থিতিশীল হয়ে উঠেছে এবং ফাইল API ট্র্যাকিং চালু করেছে। File.exists() , File.isDirectory() এবং File.list() এর মতো কলগুলি গ্র্যাডল দ্বারা কনফিগারেশন ইনপুট ফাইল ট্র্যাক করার জন্য রেকর্ড করা হয়।
অ্যান্ড্রয়েড গ্রেডল প্লাগইন (এজিপি) 8.1 কিছু ফাইলের জন্য এই File এপিআই ব্যবহার করে যেগুলি গ্রেডলকে ক্যাশে ইনপুট হিসাবে বিবেচনা করা উচিত নয়। Gradle 8.1 এবং উচ্চতরের সাথে ব্যবহার করার সময় এটি অতিরিক্ত ক্যাশে অকার্যকরতা ট্রিগার করে, বিল্ড কর্মক্ষমতা ধীর করে দেয়। AGP 8.1-এ নিম্নলিখিতগুলিকে ক্যাশে ইনপুট হিসাবে বিবেচনা করা হয়:
| ইনপুট | ইস্যু ট্র্যাকার | মধ্যে স্থির |
| $GRADLE_USER_HOME/android/FakeDependency.jar | ইস্যু #289232054 | AGP 8.2 |
| cmake আউটপুট | ইস্যু #287676077 | AGP 8.2 |
| $GRADLE_USER_HOME/.android/analytics.settings | ইস্যু #278767328 | AGP 8.3 |
আপনি যদি এই APIগুলি ব্যবহার করেন বা এই APIগুলি ব্যবহার করে এমন একটি প্লাগইন ব্যবহার করেন তবে আপনি আপনার বিল্ড টাইমে একটি রিগ্রেশন অনুভব করতে পারেন, কারণ এই APIগুলি ব্যবহার করে কিছু বিল্ড লজিক অতিরিক্ত ক্যাশে অবৈধতা ট্রিগার করতে পারে। দয়া করে এই প্যাটার্নগুলির আলোচনার জন্য বিল্ড কনফিগারেশন ইনপুট ট্র্যাকিংয়ের উন্নতিগুলি দেখুন এবং কীভাবে বিল্ড লজিক ঠিক করতে হয়, বা ফাইল API ট্র্যাকিং সাময়িকভাবে অক্ষম করুন৷