আপনার বিল্ড প্রোফাইল

বৃহত্তর প্রকল্পগুলি, বা যেগুলি প্রচুর কাস্টম বিল্ড লজিক প্রয়োগ করে, আপনাকে বাধাগুলি খুঁজে পেতে বিল্ড প্রক্রিয়াটি আরও গভীরভাবে দেখার প্রয়োজন হতে পারে। বিল্ড লাইফসাইকেলের প্রতিটি ধাপ এবং প্রতিটি বিল্ড টাস্ক সম্পাদন করতে Gradle কতক্ষণ সময় নেয় তা প্রোফাইলিং করে আপনি এটি করতে পারেন। উদাহরণস্বরূপ, যদি আপনার বিল্ড প্রোফাইল দেখায় যে Gradle আপনার প্রোজেক্ট কনফিগার করার জন্য অনেক বেশি সময় ব্যয় করছে, তাহলে এটি আপনাকে কনফিগারেশন পর্বের বাইরে কাস্টম বিল্ড লজিক সরানোর পরামর্শ দিতে পারে। অতিরিক্তভাবে, যদি mergeDevDebugResources টাস্কটি প্রচুর পরিমাণে বিল্ড টাইম খরচ করে, তাহলে এটি নির্দেশ করতে পারে যে আপনাকে হয় আপনার ছবিগুলিকে WebP-এ রূপান্তর করতে হবে বা PNG ক্রাঞ্চিং অক্ষম করতে হবে ।

আপনি যদি অ্যান্ড্রয়েড স্টুডিও 4.0 বা উচ্চতর ব্যবহার করেন, তাহলে বিল্ড পারফরম্যান্সের সমস্যাগুলি তদন্ত করার সর্বোত্তম উপায় হল বিল্ড অ্যানালাইজার ব্যবহার করা ।

এছাড়াও, অ্যান্ড্রয়েড স্টুডিওর বাইরে আপনার বিল্ড প্রোফাইল করার জন্য দুটি বিকল্প রয়েছে:

  1. স্বতন্ত্র gradle-profiler টুল , আপনার বিল্ডের গভীর বিশ্লেষণের জন্য একটি শক্তিশালী টুল।

  2. Gradle --profile বিকল্প , একটি সুবিধাজনক টুল যা Gradle কমান্ড লাইন থেকে উপলব্ধ।

স্বতন্ত্র gradle-profiler টুল ব্যবহার করে

আপনাকে সর্বোত্তম বিল্ড স্পিড প্রদান করে এমন প্রজেক্ট সেটআপ খুঁজে পেতে, আপনাকে Gradle profiler ব্যবহার করতে হবে, Gradle বিল্ডের জন্য প্রোফাইলিং এবং বেঞ্চমার্কিং তথ্য সংগ্রহের জন্য একটি টুল। Gradle প্রোফাইলার আপনাকে বিল্ড দৃশ্যকল্প তৈরি করতে এবং সেগুলিকে একাধিকবার চালানোর অনুমতি দেয়, ফলাফলের মধ্যে উচ্চ পার্থক্য রোধ করে এবং ফলাফলের পুনরুত্পাদনযোগ্যতা নিশ্চিত করে।

বেঞ্চমার্কিং মোড পরিষ্কার এবং ক্রমবর্ধমান বিল্ড সম্পর্কে তথ্য সংগ্রহ করতে ব্যবহার করা উচিত, যখন প্রোফাইলিং মোড CPU স্ন্যাপশট সহ রান সম্পর্কে আরও দানাদার তথ্য সংগ্রহ করতে ব্যবহার করা যেতে পারে।

বেঞ্চমার্কিংয়ের জন্য কিছু প্রকল্প সেটআপ কনফিগারেশনের মধ্যে রয়েছে:

  • প্লাগইন সংস্করণ
  • গ্রেডল সংস্করণ
  • JVM সেটিংস (স্তূপের আকার, পারমজেনের আকার, আবর্জনা সংগ্রহ, ইত্যাদি)
  • গ্রেডেল কর্মীদের সংখ্যা ( org.gradle.workers.max )
  • পারফরম্যান্সকে আরও অপ্টিমাইজ করতে প্রতি-প্লাগইন বিকল্প

শুরু হচ্ছে

  • এই নির্দেশাবলী অনুসরণ করে gradle-profiler ইনস্টল করুন
  • চালান: gradle-profiler --benchmark --project-dir <root-project> :app:assembleDebug

এটি একটি সম্পূর্ণ আপ-টু-ডেট বিল্ডকে বেঞ্চমার্ক করবে কারণ --benchmark মাঝখানে প্রকল্প পরিবর্তন না করে একাধিকবার টাস্ক চালায়। তারপর এটি profile-out/ ডিরেক্টরির অধীনে একটি এইচটিএমএল রিপোর্ট তৈরি করবে যা আপনাকে বিল্ডের সময় দেখাবে।

বেঞ্চমার্কের জন্য আরও উপযোগী হতে পারে এমন অন্যান্য পরিস্থিতি রয়েছে:

  • আপনি আপনার বেশিরভাগ কাজ যেখানে করেন এমন একটি ক্লাসের মেথড বডিতে কোড পরিবর্তন হয়।
  • আপনার প্রোজেক্ট জুড়ে ব্যবহৃত একটি মডিউলে API পরিবর্তন হয়। যদিও আপনার নিজের কোডে পরিবর্তনের চেয়ে কম ঘন ঘন, এটি একটি বড় প্রভাব ফেলে এবং এটি পরিমাপ করা দরকারী।
  • UI কাজের পুনরাবৃত্তির অনুকরণ করতে লেআউট সম্পাদনা।
  • স্ট্রিং সম্পাদনা অনুবাদ কাজের সাথে কাজ করার অনুকরণ করতে।
  • বিল্ডে পরিবর্তনগুলি অনুকরণ করতে ক্লিন বিল্ডগুলি (যেমন, Android Gradle প্লাগইন আপডেট, Gradle আপডেট, বা buildSrc অধীনে আপনার নিজস্ব বিল্ড কোডে সম্পাদনা)।

এই ব্যবহারের ক্ষেত্রে বেঞ্চমার্ক করার জন্য, আপনি একটি দৃশ্যকল্প তৈরি করতে পারেন যা gradle-profiler এক্সিকিউশন চালানোর জন্য ব্যবহার করা হবে এবং যা আপনার উত্সগুলিতে উপযুক্ত পরিবর্তনগুলি প্রযোজ্য। আপনি নীচের কিছু সাধারণ পরিস্থিতি পরীক্ষা করতে পারেন।

বিভিন্ন মেমরি/সিপিইউ সেটিংস প্রোফাইলিং

বিভিন্ন মেমরি এবং CPU সেটিংস বেঞ্চমার্ক করার জন্য, আপনি একাধিক পরিস্থিতি তৈরি করতে পারেন যা 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 প্লাগইন সংস্করণ প্রোফাইলিং

গ্র্যাডল প্লাগইনের সংস্করণ পরিবর্তন করা বিল্ড টাইমকে কীভাবে প্রভাবিত করে তা খুঁজে বের করার জন্য, বেঞ্চমার্ক করার জন্য একটি দৃশ্য তৈরি করুন। প্লাগইন সংস্করণটিকে দৃশ্যকল্প থেকে ইনজেকশনযোগ্য করার জন্য কিছু প্রস্তুতির প্রয়োজন। আপনার রুট 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"
    }
}

এখন আপনি দৃশ্যকল্প ফাইল থেকে অ্যান্ড্রয়েড গ্রেডল প্লাগইন এবং কোটলিন গ্র্যাডল প্লাগইন সংস্করণগুলি নির্দিষ্ট করতে পারেন এবং দৃশ্যকল্পটি উত্স ফাইলগুলিতে একটি নতুন পদ্ধতি যুক্ত করতে পারেন:

# <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"
}

একটি বর্ধিত বিল্ড প্রোফাইলিং

বেশিরভাগ বিল্ড ক্রমবর্ধমান, এটি প্রোফাইলের সবচেয়ে গুরুত্বপূর্ণ পরিস্থিতিগুলির মধ্যে একটি করে তোলে। ক্রমবর্ধমান বিল্ড প্রোফাইল করার জন্য গ্রেডল প্রোফাইলারের ব্যাপক সমর্থন রয়েছে। এটি একটি মেথড বডি পরিবর্তন করে, একটি নতুন পদ্ধতি যোগ করে, বা লেআউট বা স্ট্রিং রিসোর্স পরিবর্তন করে স্বয়ংক্রিয়ভাবে একটি সোর্স ফাইলে পরিবর্তনগুলি প্রয়োগ করতে সক্ষম। উদাহরণস্বরূপ, আপনি এই মত ক্রমবর্ধমান পরিস্থিতি তৈরি করতে পারেন:

# <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 রিপোর্ট তৈরি করবে।

আপনি অন্যান্য সেটিংসের সাথে ক্রমবর্ধমান পরিস্থিতি একত্রিত করতে পারেন, যেমন স্তূপের আকার, কর্মীদের সংখ্যা, বা গ্রেডল সংস্করণ:

# <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"]
}

একটি পরিষ্কার বিল্ড প্রোফাইলিং

একটি পরিষ্কার বিল্ড বেঞ্চমার্ক করার জন্য, আপনি একটি দৃশ্যকল্প তৈরি করতে পারেন যা গ্রেডল-প্রোফাইলার এক্সিকিউশন চালাতে ব্যবহার করা হবে:

# <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. নিম্নলিখিত কমান্ডটি প্রবেশ করে একটি পরিষ্কার বিল্ড সম্পাদন করুন। আপনি আপনার বিল্ড প্রোফাইল করার সময়, আপনার প্রতিটি বিল্ড আপনার প্রোফাইলের মধ্যে একটি পরিষ্কার বিল্ড করা উচিত কারণ যখন একটি টাস্কের ইনপুট (যেমন সোর্স কোড) পরিবর্তন হয় না তখন গ্রেডল কাজগুলি এড়িয়ে যায়। সুতরাং, ইনপুট পরিবর্তন ছাড়াই একটি দ্বিতীয় বিল্ড সবসময় দ্রুত চলে কারণ কাজগুলি পুনরায় চালানো হচ্ছে না। সুতরাং আপনার বিল্ডগুলির মধ্যে clean টাস্ক চালানো নিশ্চিত করে যে আপনি সম্পূর্ণ বিল্ড প্রক্রিয়াটি প্রোফাইল করেছেন। 
    // On Mac or Linux, run the Gradle wrapper using "./gradlew".
gradlew clean
  3. নিম্নলিখিত পতাকাগুলির সাথে আপনার পণ্যের স্বাদগুলির একটি ডিবাগ বিল্ড চালান, যেমন "dev" ফ্লেভার:
    gradlew --profile --offline --rerun-tasks assembleFlavorDebug
    • --profile : প্রোফাইলিং সক্ষম করে।
    • --offline : অনলাইন নির্ভরতা আনা থেকে Gradle অক্ষম করে। এটি নিশ্চিত করে যে গ্রেডল আপনার নির্ভরতা আপডেট করার চেষ্টা করার কারণে যে কোনও বিলম্ব আপনার প্রোফাইলিং ডেটাতে হস্তক্ষেপ করবে না। Gradle ইতিমধ্যেই আপনার নির্ভরতা ডাউনলোড এবং ক্যাশে করেছে তা নিশ্চিত করার জন্য আপনার ইতিমধ্যে একবার আপনার প্রকল্প তৈরি করা উচিত।
    • --rerun-tasks : Gradle কে সমস্ত টাস্ক পুনরায় চালু করতে এবং যেকোন টাস্ক অপটিমাইজেশন উপেক্ষা করতে বাধ্য করে।

  4. চিত্র 1. প্রজেক্ট ভিউ প্রোফাইল রিপোর্টের অবস্থান নির্দেশ করে।

    বিল্ড সম্পূর্ণ হওয়ার পরে, প্রজেক্ট উইন্ডোটি ব্যবহার করুন project-root /build/reports/profile/ ডিরেক্টরিতে নেভিগেট করুন (চিত্র 1 এ দেখানো হয়েছে)।

  5. profile- timestamp .html ফাইলটিতে ডান ক্লিক করুন এবং ব্রাউজারে খুলুন > ডিফল্ট নির্বাচন করুন। প্রতিবেদনটি চিত্র 2-এ দেখানো একটির মতো হওয়া উচিত। আপনি আপনার বিল্ড সম্পর্কে জানতে প্রতিবেদনের প্রতিটি ট্যাব পরিদর্শন করতে পারেন, যেমন টাস্ক এক্সিকিউশন ট্যাব যা দেখায় যে প্রতিটি বিল্ড টাস্ক সম্পাদন করতে গ্র্যাডল কত সময় নিয়েছে।

    চিত্র 2. একটি ব্রাউজারে একটি প্রতিবেদন দেখা।

  6. ঐচ্ছিক: আপনার প্রকল্পে কোনো পরিবর্তন করার আগে বা কনফিগারেশন তৈরি করার আগে, ধাপ 3-এ কমান্ডটি পুনরাবৃত্তি করুন, কিন্তু --rerun-tasks পতাকাটি বাদ দিন। যেহেতু Gradle সেই কাজগুলিকে পুনঃনির্বাহ না করে সময় বাঁচানোর চেষ্টা করে যার ইনপুটগুলি পরিবর্তিত হয়নি (এগুলি রিপোর্টের টাস্ক এক্সিকিউশন ট্যাবে UP-TO-DATE হিসাবে নির্দেশিত হয়েছে, যেমন চিত্র 3 এ দেখানো হয়েছে), আপনি সনাক্ত করতে পারেন কোন কাজগুলি কাজ করা যখন তাদের উচিত নয়। উদাহরণস্বরূপ, যদি :app:processDevUniversalDebugManifest UP-TO-DATE হিসাবে চিহ্নিত করা না থাকে, তাহলে এটি পরামর্শ দিতে পারে যে আপনার বিল্ড কনফিগারেশন প্রতিটি বিল্ডের সাথে ম্যানিফেস্টকে গতিশীলভাবে আপডেট করছে। যাইহোক, প্রতিটি বিল্ডের সময় কিছু কাজ চালানো প্রয়োজন, যেমন :app:checkDevDebugManifest ।

    চিত্র 3. টাস্ক এক্সিকিউশনের ফলাফল দেখা।

এখন আপনার কাছে একটি বিল্ড প্রোফাইল রিপোর্ট আছে, আপনি রিপোর্টের প্রতিটি ট্যাবে তথ্য পরিদর্শন করে অপ্টিমাইজেশনের সুযোগগুলি খুঁজতে শুরু করতে পারেন৷ কিছু বিল্ড সেটিংসের জন্য পরীক্ষা-নিরীক্ষার প্রয়োজন কারণ সুবিধাগুলি প্রকল্প এবং ওয়ার্কস্টেশনের মধ্যে আলাদা হতে পারে। উদাহরণস্বরূপ, একটি বড় কোডবেস সহ প্রকল্পগুলি অব্যবহৃত কোড সরাতে এবং অ্যাপের আকার সঙ্কুচিত করার জন্য কোড সঙ্কুচিত করে উপকৃত হতে পারে। যাইহোক, ছোট প্রকল্পগুলি সম্পূর্ণভাবে কোড সঙ্কুচিত করা অক্ষম করে আরও উপকৃত হতে পারে। উপরন্তু, Gradle হিপের আকার বাড়ানো ( org.gradle.jvmargs ব্যবহার করে) কম মেমরির মেশিনে কর্মক্ষমতাকে নেতিবাচকভাবে প্রভাবিত করতে পারে।

আপনার বিল্ড কনফিগারেশনে একটি পরিবর্তন করার পরে, উপরের ধাপগুলি পুনরাবৃত্তি করে এবং একটি নতুন বিল্ড প্রোফাইল তৈরি করে আপনার পরিবর্তনগুলির ফলাফলগুলি পর্যবেক্ষণ করুন৷ উদাহরণস্বরূপ, চিত্র 4 এই পৃষ্ঠায় বর্ণিত কিছু মৌলিক অপ্টিমাইজেশন প্রয়োগ করার পরে একই নমুনা অ্যাপের জন্য একটি প্রতিবেদন দেখায়।

চিত্র 4. বিল্ড স্পিড অপ্টিমাইজ করার পর একটি নতুন রিপোর্ট দেখা।