গ্রেডল বিল্ড ওভারভিউ, গ্রেডল বিল্ড ওভারভিউ

অ্যান্ড্রয়েড অ্যাপ্লিকেশনগুলি সাধারণত গ্রেডল বিল্ড সিস্টেম ব্যবহার করে তৈরি করা হয়। আপনার বিল্ড কীভাবে কনফিগার করবেন তার বিশদ বিবরণে ডুব দেওয়ার আগে, আমরা বিল্ডের পিছনের ধারণাগুলি অন্বেষণ করব যাতে আপনি সম্পূর্ণ সিস্টেমটি দেখতে পারেন।

বিল্ড কী?

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

টাস্কগুলি এমন কমান্ডগুলিকে ধারণ করে যা তাদের ইনপুটগুলিকে আউটপুটে রূপান্তর করে। প্লাগইনগুলি কাজ এবং তাদের কনফিগারেশন সংজ্ঞায়িত করে। আপনার বিল্ডে একটি প্লাগইন প্রয়োগ করলে এর কাজগুলি নিবন্ধিত হয় এবং তাদের ইনপুট এবং আউটপুট ব্যবহার করে সেগুলিকে একত্রিত করে। উদাহরণস্বরূপ, আপনার বিল্ড ফাইলে Android Gradle Plugin (AGP) প্রয়োগ করলে একটি APK, অথবা একটি Android Library তৈরি করার জন্য প্রয়োজনীয় সমস্ত কাজ নিবন্ধিত হবে। java-library প্লাগইন আপনাকে জাভা সোর্স কোড থেকে একটি জার তৈরি করতে দেয়। Kotlin এবং অন্যান্য ভাষার জন্য অনুরূপ প্লাগইন বিদ্যমান, তবে অন্যান্য প্লাগইনগুলি প্লাগইনগুলিকে প্রসারিত করার জন্য তৈরি। উদাহরণস্বরূপ, protobuf প্লাগইনটি AGP বা java-library মতো বিদ্যমান প্লাগইনগুলিতে protobuf সমর্থন যোগ করার জন্য তৈরি।

গ্রেডল কনফিগারেশনের চেয়ে কনভেনশন পছন্দ করে, তাই প্লাগইনগুলি বাক্সের বাইরে ভালো ডিফল্ট মান সহ আসবে, তবে আপনি একটি ঘোষণামূলক ডোমেন-স্পেসিফিক ল্যাঙ্গুয়েজ (DSL) এর মাধ্যমে বিল্ডটি আরও কনফিগার করতে পারেন। DSL এমনভাবে ডিজাইন করা হয়েছে যাতে আপনি কীভাবে তৈরি করবেন তার পরিবর্তে কী তৈরি করবেন তা নির্দিষ্ট করতে পারেন। প্লাগইনগুলির লজিক "কিভাবে" পরিচালনা করে। সেই কনফিগারেশনটি আপনার প্রকল্পের (এবং উপ-প্রকল্পের) বেশ কয়েকটি বিল্ড ফাইল জুড়ে নির্দিষ্ট করা হয়েছে।

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

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

যখন একটি গ্রেডল বিল্ড চলে তখন কী হয়?

গ্রেডল বিল্ড তিনটি ধাপে চলে। এই প্রতিটি ধাপ আপনার বিল্ড ফাইলে সংজ্ঞায়িত কোডের বিভিন্ন অংশ কার্যকর করে।

• ইনিশিয়ালাইজেশন নির্ধারণ করে যে বিল্ডে কোন প্রকল্প এবং উপ-প্রকল্পগুলি অন্তর্ভুক্ত করা হয়েছে এবং আপনার বিল্ড ফাইল এবং প্রয়োগকৃত প্লাগইন ধারণকারী ক্লাসপাথ সেট আপ করে। এই পর্যায়টি একটি সেটিংস ফাইলের উপর ফোকাস করে যেখানে আপনি প্রকল্পগুলি তৈরি করার ঘোষণা দেন এবং প্লাগইন এবং লাইব্রেরিগুলি কোথায় আনবেন তা নির্ধারণ করেন।
• কনফিগারেশন প্রতিটি প্রকল্পের জন্য কাজ নিবন্ধন করে এবং ব্যবহারকারীর বিল্ড স্পেসিফিকেশন প্রয়োগ করার জন্য বিল্ড ফাইলটি কার্যকর করে। এটা বোঝা গুরুত্বপূর্ণ যে আপনার কনফিগারেশন কোডটি কার্যকর করার সময় তৈরি ডেটা বা ফাইলগুলিতে অ্যাক্সেস পাবে না।
• এক্সিকিউশন আপনার অ্যাপ্লিকেশনের প্রকৃত "বিল্ডিং" সম্পাদন করে। কনফিগারেশনের আউটপুট হল একটি ডাইরেক্টেড অ্যাসাইক্লিক গ্রাফ (DAG) টাস্ক, যা ব্যবহারকারীর অনুরোধ করা সমস্ত প্রয়োজনীয় বিল্ড ধাপগুলি (কমান্ড লাইনে প্রদত্ত কাজগুলি অথবা বিল্ড ফাইলগুলিতে ডিফল্ট হিসাবে) উপস্থাপন করে। এই গ্রাফটি টাস্কের মধ্যে সম্পর্ককে প্রতিনিধিত্ব করে, হয় টাস্কের ঘোষণায় স্পষ্টভাবে, অথবা এর ইনপুট এবং আউটপুটের উপর ভিত্তি করে। যদি কোনও টাস্কের এমন একটি ইনপুট থাকে যা অন্য টাস্কের আউটপুট, তাহলে এটি অবশ্যই অন্য টাস্কের পরে চলতে হবে। এই পর্যায়টি গ্রাফে সংজ্ঞায়িত ক্রমে পুরানো কাজগুলি চালায়; যদি কোনও টাস্কের ইনপুটগুলি তার শেষ এক্সিকিউশনের পর থেকে পরিবর্তিত না হয়, তাহলে গ্র্যাডেল এটি এড়িয়ে যাবে।

আরও তথ্যের জন্য গ্রেডল বিল্ডের জীবনচক্র দেখুন।

কনফিগারেশন ডিএসএল

গ্র্যাডেল বিল্ড কনফিগার করার জন্য একটি ডোমেন-স্পেসিফিক ল্যাঙ্গুয়েজ (DSL) ব্যবহার করে। এই ঘোষণামূলক পদ্ধতিটি ধাপে ধাপে (অপরিহার্য) নির্দেশাবলী লেখার পরিবর্তে আপনার ডেটা নির্দিষ্ট করার উপর জোর দেয়। আপনি কোটলিন বা গ্রুভি ব্যবহার করে আপনার বিল্ড ফাইলগুলি লিখতে পারেন, তবে আমরা দৃঢ়ভাবে কোটলিন ব্যবহার করার পরামর্শ দিচ্ছি।

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

উদাহরণস্বরূপ, আপনার বিল্ডের অ্যান্ড্রয়েড অংশটি কনফিগার করার সময় এটি দেখতে এরকম হতে পারে:

android {
    namespace = "com.example.app"
    compileSdk {
        version = release(36) {
            minorApiLevel = 1
        }
    }
    // ...

    defaultConfig {
        applicationId = "com.example.app"
        minSdk {
            version = release(23)
        }
        targetSdk {
            version = release(36)
        }
        // ...
    }
}

android {
    namespace = 'com.example.app'
    compileSdk {
        version = release(36) {
            minorApiLevel = 1
        }
    }
    // ...

    defaultConfig {
        applicationId = 'com.example.app'
        minSdk {
            version = release(23)
        }
        targetSdk {
            version = release(36)
        }
        // ...
    }
}

পর্দার আড়ালে, DSL কোডটি এর অনুরূপ:

fun Project.android(configure: ApplicationExtension.() -> Unit) {
    ...
}

interface ApplicationExtension {
    var namespace: String?

    fun compileSdk(configure: CompileSdkSpec.() -> Unit) {
        ...
    }

    val defaultConfig: DefaultConfig

    fun defaultConfig(configure: DefaultConfig.() -> Unit) {
        ...
    }
}

DSL-এর প্রতিটি ব্লক একটি ফাংশন দ্বারা প্রতিনিধিত্ব করা হয় যা কনফিগার করতে একটি ল্যাম্বডা এবং এটি অ্যাক্সেস করতে একই নামের একটি বৈশিষ্ট্য ব্যবহার করে। এটি আপনার বিল্ড ফাইলের কোডটিকে ডেটা স্পেসিফিকেশনের মতো মনে করে।

বাহ্যিক নির্ভরতা

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

ম্যাভেন আর্টিফ্যাক্টগুলিকে গ্রুপের নাম (কোম্পানি, ডেভেলপার, ইত্যাদি), আর্টিফ্যাক্টের নাম (লাইব্রেরির নাম) এবং সেই আর্টিফ্যাক্টের সংস্করণ দ্বারা চিহ্নিত করা হয়। এটি সাধারণত group:artifact:version হিসাবে উপস্থাপিত হয়।

এই পদ্ধতিটি বিল্ড ম্যানেজমেন্টকে উল্লেখযোগ্যভাবে উন্নত করে। আপনি প্রায়শই "Maven repositories" নামে এই ধরনের রিপোজিটরি শুনতে পাবেন, তবে এটি সম্পূর্ণরূপে আর্টিফ্যাক্টগুলি কীভাবে প্যাকেজ এবং প্রকাশ করা হয় তার উপর নির্ভর করে। এই রিপোজিটরি এবং মেটাডেটা গ্র্যাডেল সহ বেশ কয়েকটি বিল্ড সিস্টেমে পুনঃব্যবহার করা হয়েছে (এবং গ্র্যাডেল এই রিপোজিটরিগুলিতে প্রকাশ করতে পারে)। পাবলিক রিপোজিটরিগুলি সকলের জন্য শেয়ারিং ব্যবহারের অনুমতি দেয় এবং কোম্পানির রিপোজিটরিগুলি অভ্যন্তরীণ নির্ভরতাগুলিকে ঘরে রাখে।

আপনি আপনার প্রকল্পটিকে সাবপ্রজেক্টে (অ্যান্ড্রয়েড স্টুডিওতে "মডিউল" নামেও পরিচিত) মডুলারাইজ করতে পারেন, যা নির্ভরতা হিসেবেও ব্যবহার করা যেতে পারে। প্রতিটি সাবপ্রজেক্ট আউটপুট (যেমন জার) তৈরি করে যা সাবপ্রজেক্ট বা আপনার শীর্ষ-স্তরের প্রকল্প দ্বারা গ্রাস করা যেতে পারে। এটি কোন অংশগুলি পুনর্নির্মাণ করা প্রয়োজন তা আলাদা করে নির্মাণের সময় উন্নত করতে পারে, সেইসাথে অ্যাপ্লিকেশনে আরও ভালভাবে পৃথক দায়িত্ব নির্ধারণ করতে পারে।

আমরা Add build dependencies- এ নির্ভরতা কীভাবে নির্দিষ্ট করতে হয় সে সম্পর্কে আরও বিস্তারিতভাবে আলোচনা করব।

বিল্ড ভেরিয়েন্ট

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

বিল্ডের ধরণ ঘোষিত বিল্ড বিকল্পগুলিতে পরিবর্তিত হয়। ডিফল্টরূপে, AGP "রিলিজ" এবং "ডিবাগ" বিল্ডের ধরণ সেট আপ করে, তবে আপনি সেগুলি সামঞ্জস্য করতে পারেন এবং আরও যোগ করতে পারেন (সম্ভবত স্টেজিং বা অভ্যন্তরীণ পরীক্ষার জন্য)।

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

একটি রিলিজ বিল্ড অ্যাপ্লিকেশনটিকে অপ্টিমাইজ করে, আপনার রিলিজ কী দিয়ে সাইন করে এবং ইনস্টল করা অ্যাপ্লিকেশন ফাইলগুলিকে সুরক্ষিত করে।

পণ্যের স্বাদ ব্যবহার করে, আপনি অ্যাপ্লিকেশনের জন্য অন্তর্ভুক্ত উৎস এবং নির্ভরতা রূপগুলি পরিবর্তন করতে পারেন। উদাহরণস্বরূপ, আপনি আপনার অ্যাপ্লিকেশনের জন্য "ডেমো" এবং "পূর্ণ" স্বাদ তৈরি করতে চাইতে পারেন, অথবা সম্ভবত "বিনামূল্যে" এবং "প্রদত্ত" স্বাদ তৈরি করতে পারেন। আপনি আপনার সাধারণ উৎসটি একটি "প্রধান" উৎস সেট ডিরেক্টরিতে লিখুন এবং স্বাদের নাম অনুসারে একটি উৎস সেটে উৎসটি ওভাররাইড করুন বা যোগ করুন।

AGP বিল্ড টাইপ এবং প্রোডাক্ট ফ্লেভারের প্রতিটি সংমিশ্রণের জন্য ভ্যারিয়েন্ট তৈরি করে। যদি আপনি ফ্লেভার সংজ্ঞায়িত না করেন, তাহলে ভ্যারিয়েন্টের নামকরণ করা হয় বিল্ড টাইপ অনুসারে। যদি আপনি উভয়ই সংজ্ঞায়িত করেন, তাহলে ভ্যারিয়েন্টের নামকরণ করা হয় <flavor><Buildtype> । উদাহরণস্বরূপ, বিল্ড টাইপ release এবং debug এবং flavors demo এবং full সহ, AGP ভ্যারিয়েন্ট তৈরি করবে:

• demoRelease
• demoDebug
• fullRelease
• fullDebug

পরবর্তী পদক্ষেপ

এখন যেহেতু আপনি বিল্ড ধারণাগুলি দেখেছেন, আপনার প্রকল্পের অ্যান্ড্রয়েড বিল্ড কাঠামোটি একবার দেখে নিন।