Android ऐप्लिकेशन आम तौर पर Gradle बिल्ड का इस्तेमाल करके बनाए जाते हैं सिस्टम. बिल्ड को कॉन्फ़िगर करने के तरीके के बारे में विस्तार से जानने से पहले, हम बिल्ड के पीछे के सिद्धांतों को एक्सप्लोर करें, ताकि आप सिस्टम को पूरी तरह से देख सकें.
बिल्ड क्या है?
बिल्ड सिस्टम आपके सोर्स कोड को एक्ज़ीक्यूटेबल ऐप्लिकेशन में बदल देता है. इसमें अक्सर कई टूल शामिल होते हैं. इनकी मदद से, अपने ऐप्लिकेशन का विश्लेषण किया जा सकता है, उसे कंपाइल किया जा सकता है, लिंक किया जा सकता है, और उसे पैकेज किया जा सकता है ऐप्लिकेशन या लाइब्रेरी से ऐक्सेस किया जा सकता है. Gradle, टास्क को व्यवस्थित करने और चलाने के लिए, टास्क पर आधारित अप्रोच का इस्तेमाल करता है ये कमांड ध्यान में रखें.
Tasks, उन कमांड को इनकैप्सुलेट करते हैं जो उनके इनपुट का अनुवाद करते हैं
आउटपुट. प्लग इन, टास्क और उनके कॉन्फ़िगरेशन को तय करते हैं. लागू किया जा रहा है
आपके बिल्ड में मौजूद प्लगिन उसके टास्क को रजिस्टर करता है. साथ ही, उसका इस्तेमाल करके उन्हें एक साथ कनेक्ट करता है
इनपुट और आउटपुट.. उदाहरण के लिए, Android Gradle प्लग इन (AGP) लागू करना
आपकी बिल्ड फ़ाइल में APK बनाने के लिए ज़रूरी सभी टास्क रजिस्टर हो जाएंगे, या
Android लाइब्रेरी. java-library
प्लगिन की मदद से, Java सोर्स से जार बनाया जा सकता है
कोड. Kotlin और अन्य लैंग्वेज के लिए मिलते-जुलते प्लगिन मौजूद हैं, लेकिन अन्य प्लगिन
प्लगिन बढ़ाने के लिए होते हैं. उदाहरण के लिए, protobuf
प्लगिन का मकसद
मौजूदा प्लगिन, जैसे कि AGP या java-library
के लिए प्रोटोबफ़ सुविधा का इस्तेमाल किया जा सकता है.
Gradle, कॉन्फ़िगरेशन के बजाय कंवेंशन को प्राथमिकता देता है, इसलिए प्लगिन सही तरीके से काम करते हैं डिफ़ॉल्ट मान बॉक्स से बाहर होंगे, लेकिन आप बिल्ड को एलान वाली डोमेन के हिसाब से भाषा (डीएसएल). DSL को डिज़ाइन किया गया है इसलिए, आप यह तय कर सकते हैं कि क्या बनाना है, न कि क्या बनाना है. इसमें लॉजिक प्लगिन "कैसे" को मैनेज करते हैं. वह कॉन्फ़िगरेशन कई अपने प्रोजेक्ट (और सबप्रोजेक्ट) में फ़ाइलें बनाएं.
टास्क के इनपुट, फ़ाइलों, डायरेक्ट्री, और कोड में बदली गई अन्य जानकारी हो सकती है Java के टाइप (इंटीजर, स्ट्रिंग या कस्टम क्लास). आउटपुट सिर्फ़ डायरेक्ट्री हो सकते हैं या फ़ाइलों को डिस्क पर लिखना होगा. किसी टास्क आउटपुट को दूसरे टास्क में जोड़ना टास्क इनपुट के तौर पर, टास्क को एक साथ लिंक करता है, ताकि किसी एक को दूसरे टास्क से पहले चलाना पड़े.
हालांकि, Gradle, आपके बिल्ड में आर्बिट्रेरी कोड और टास्क से जुड़ी जानकारी लिखने में मदद करता है फ़ाइलें हैं, तो इससे टूलिंग के लिए आपके बिल्ड और बनाए रखने के लिए किया जा सकता है. उदाहरण के लिए, प्लगिन के अंदर कोड के लिए टेस्ट लिखे जा सकते हैं लेकिन बिल्ड फ़ाइलों में नहीं. इसके बजाय, आपको बिल्ड लॉजिक और टास्क पर पाबंदी लगानी चाहिए प्लगिन (जो आपने या किसी अन्य व्यक्ति ने तय किया हो) के बारे में एलान किया हो. साथ ही, यह भी बताया हो कि आपको अपनी बिल्ड फ़ाइलों में उस लॉजिक का इस्तेमाल करना है.
Gradle बिल्ड चलने पर क्या होता है?
Gradle बिल्ड तीन चरणों में चलता है. इनमें से हर चरण के अलग-अलग चरण लागू होते हैं, को अपलोड करें, जिसे आपने अपनी बिल्ड फ़ाइलों में तय किया है.
- प्रोसेस शुरू करने से यह तय होता है कि कौनसे प्रोजेक्ट और सब-प्रोजेक्ट बिल्ड सेट अप कर सकता है. साथ ही, ऐसे क्लासपाथ सेट अप कर सकता है जिनमें आपकी बिल्ड फ़ाइलें शामिल हों और प्लगिन. इस चरण में, उस सेटिंग फ़ाइल पर फ़ोकस किया जाता है जिसमें आपने अपने प्रोजेक्ट का एलान किया बिल्ड और उन जगहों की जानकारी जहां से प्लगिन और लाइब्रेरी फ़ेच की जाएंगी.
- कॉन्फ़िगरेशन से हर प्रोजेक्ट के टास्क रजिस्टर किए जाते हैं और बिल्ड एक्ज़ीक्यूट किया जाता है फ़ाइल का इस्तेमाल करें. यह समझना ज़रूरी है कि आपके कॉन्फ़िगरेशन कोड के पास, तैयार किए गए डेटा या फ़ाइलों का ऐक्सेस नहीं है को लागू करते हैं.
- काम करने का तरीका, असल "इमारत" की प्रक्रिया करता है आपके ऐप्लिकेशन की सूची में शामिल है. आउटपुट कॉन्फ़िगरेशन, टास्क का डायरेक्टेड एकाइक्लिक ग्राफ़ (डीएजी) है, बिल्ड के उन सभी ज़रूरी चरणों को दिखाता है जिनका अनुरोध उपयोगकर्ता ने किया था ( कमांड लाइन पर या बिल्ड फ़ाइलों में डिफ़ॉल्ट के तौर पर दिए गए टास्क). यह ग्राफ़, टास्क के बीच के संबंध को दिखाता है, भले ही वह टास्क के या अपने इनपुट और आउटपुट के आधार पर तैयार करें. अगर किसी टास्क में ऐसा इनपुट हो किसी दूसरे टास्क का आउटपुट है, तो इसे दूसरे टास्क के बाद चलाया जाना चाहिए. यह इस चरण में, ग्राफ़ में बताए गए क्रम में पुराने टास्क होते हैं; अगर किसी टास्क को पिछली बार एक्ज़ीक्यूशन के बाद से इनपुट नहीं बदले हैं, इसलिए Gradle इसे छोड़ देगा.
ज़्यादा जानकारी के लिए, Gradle बिल्ड लाइफ़साइकल देखें.
कॉन्फ़िगरेशन DSL
कॉन्फ़िगर करने के लिए Gradle, डोमेन के हिसाब से खास भाषा (डीएसएल) का इस्तेमाल करता है बिल्ड. एलान वाला यह तरीका अपनाने के बजाय, डेटा को तय करने पर फ़ोकस किया जाता है चरण-दर-चरण (ज़रूरी) निर्देश लिखना चाहिए.
DSL सभी के लिए, डोमेन विशेषज्ञों और प्रोग्रामर के लिए, एक छोटी भाषा परिभाषित करते हुए किसी प्रोजेक्ट में योगदान दें जो और प्राकृतिक तरीके से आता है. Gradle प्लग इन, डीएसएल को बढ़ाने के लिए, डेटा को कॉन्फ़िगर कर सकती हैं उनकी ज़रूरतें पूरी होती हैं.
उदाहरण के लिए, आपके बिल्ड के Android वाले हिस्से को कॉन्फ़िगर करने का तरीका कुछ ऐसा दिख सकता है:
Kotlin
android { namespace = "com.example.app" compileSdk = 34 // ... defaultConfig { applicationId = "com.example.app" minSdk = 34 // ... } }
ग्रूवी
android { namespace 'com.example.myapplication' compileSdk 34 // ... defaultConfig { applicationId "com.example.myapplication" minSdk 24 // ... } }
पर्दे के पीछे, डीएसएल कोड ऐसा होता है:
fun Project.android(configure: ApplicationExtension.() -> Unit) {
...
}
interface ApplicationExtension {
var compileSdk: Int
var namespace: String?
val defaultConfig: DefaultConfig
fun defaultConfig(configure: DefaultConfig.() -> Unit) {
...
}
}
डीएसएल में हर ब्लॉक को एक ऐसे फ़ंक्शन से दिखाया जाता है जो लैम्डा को उसे कॉन्फ़िगर करें और ऐक्सेस करने के लिए उसी नाम की प्रॉपर्टी. इससे कोड आपकी बिल्ड फ़ाइलों में मौजूद कोड किसी डेटा स्पेसिफ़िकेशन जैसा लगता है.
बाहरी डिपेंडेंसी
Maven के बिल्ड सिस्टम ने एक डिपेंडेंसी स्पेसिफ़िकेशन जोड़ा है, स्टोरेज और मैनेजमेंट सिस्टम. लाइब्रेरी यहां सेव की जाती हैं डेटा स्टोर करने की जगहें (सर्वर या डायरेक्ट्री) जिनमें मेटाडेटा शामिल है. और दूसरी लाइब्रेरी पर निर्भरताओं के साथ काम करते हैं. यह तय करें कि कौनसा खोजने के लिए डेटा स्टोर करने की जगह, जिन डिपेंडेंसी का इस्तेमाल करना है उनके वर्शन, और बिल्ड सिस्टम उन्हें बिल्ड के दौरान डाउनलोड कर लेता है.
Maven आर्टफ़ैक्ट की पहचान, ग्रुप के नाम (कंपनी, डेवलपर वगैरह), आर्टफ़ैक्ट से की जाती है
उस आर्टफ़ैक्ट का नाम (लाइब्रेरी का नाम) और उसका वर्शन जोड़ सकते हैं. आम तौर पर, यह
group:artifact:version
के तौर पर दिखाया जाता है.
इससे बिल्ड मैनेजमेंट में काफ़ी सुधार होता है. आपने अक्सर ऐसा सुना होगा डेटा स्टोर करने की जगहों को "Maven रिपॉज़िटरी" कहा जाता है, लेकिन यहां पर सब कुछ आर्टफ़ैक्ट को पैकेज करके पब्लिश किया जाता है. डेटा स्टोर करने की इन जगहों और मेटाडेटा को कई बिल्ड सिस्टम में फिर से इस्तेमाल किया गया है. इनमें Gradle शामिल है (और Gradle, डेटा स्टोर करने की जगहों की पूरी जानकारी देता है. डेटा स्टोर करने की सार्वजनिक जगहों पर, डेटा स्टोर करने की सुविधा सभी के लिए उपलब्ध होती है. कंपनी डेटा स्टोर करने की जगह पर, इंटरनल डिपेंडेंसी को निजी रखा जाता है.
अपने प्रोजेक्ट को सब-प्रोजेक्ट में मॉड्युलेट भी किया जा सकता है (इसे Android Studio में "मॉड्यूल" भी कहा जाता है) का इस्तेमाल इस रूप में भी किया जा सकता है: निर्भरता. हर सब-प्रोजेक्ट ऐसा आउटपुट देता है (जैसे कि जार) जिसे सब-प्रोजेक्ट या आपके टॉप-लेवल प्रोजेक्ट का इस्तेमाल किया जाता है. इससे बिल्ड टाइम बढ़ सकता है इसके लिए, उन हिस्सों को अलग किया जा सकता है जिन्हें फिर से बनाने की ज़रूरत है. साथ ही, आवेदन में ज़िम्मेदारियों को पूरा करना.
हम बिल्ड जोड़ें में डिपेंडेंसी तय करने के तरीके के बारे में ज़्यादा जानकारी देंगे डिपेंडेंसी.
वैरिएंट बनाएं
जब आप कोई Android ऐप्लिकेशन बनाते हैं, तो आम तौर पर आप Android ऐप्लिकेशन के एक से ज़्यादा वर्शन वैरिएंट. वैरिएंट का कोड अलग-अलग होता है या उन्हें अलग-अलग कोड से बनाया जाता है विकल्प, बिल्ड टाइप और प्रॉडक्ट फ़्लेवर से मिलकर बनाए जाते हैं.
बिल्ड के टाइप, बिल्ड के एलान किए गए विकल्पों में अलग-अलग होते हैं. डिफ़ॉल्ट रूप से, एजीपी "रिलीज़" सेट अप करता है और "डीबग" का उपयोग कर सकते हैं, लेकिन आप उन्हें समायोजित कर सकते हैं और अधिक (शायद स्टेजिंग या इंटरनल टेस्टिंग के लिए उपलब्ध है).
डीबग बिल्ड आपके ऐप्लिकेशन को छोटा या उलझा नहीं करता, जिससे साथ ही, सभी सिंबल को पहले जैसा ही बनाए और सेव करके रखा जाए. यह ऐप्लिकेशन, " "debuggable", इसे सामान्य डीबग कुंजी से साइन किया जाता है. साथ ही, डिवाइस पर ऐप्लिकेशन फ़ाइलें इंस्टॉल की हैं. इससे लोगों को एक्सप्लोर करने ऐप्लिकेशन चलाते समय फ़ाइलों और डेटाबेस में सेव किए गए डेटा को सेव करता है.
रिलीज़ बिल्ड ऐप्लिकेशन को ऑप्टिमाइज़ करता है, उस पर आपकी रिलीज़ कुंजी से हस्ताक्षर करता है और इंस्टॉल की गई ऐप्लिकेशन फ़ाइलों की सुरक्षा करती है.
प्रॉडक्ट के फ़्लेवर का इस्तेमाल करके, शामिल किए गए सोर्स और डिपेंडेंसी को बदला जा सकता है अलग-अलग वर्शन का इस्तेमाल करें. उदाहरण के लिए, हो सकता है कि आप "डेमो" बनाना और "पूरा" हो सकता है अपने ऐप्लिकेशन के लिए फ़्लेवर या शायद "मुफ़्त" और "पैसे चुकाकर" फ़्लेवर. आप अपना कॉमन सोर्स "मुख्य" में लिखते हैं सोर्स सेट डायरेक्ट्री, और फ़्लेवर के आधार पर सेट किए गए सोर्स सेट में सोर्स को बदलें या जोड़ें.
AGP, बिल्ड टाइप और प्रॉडक्ट के फ़्लेवर के हर कॉम्बिनेशन के लिए वैरिएंट बनाता है. अगर आपने
अगर आप फ़्लेवर तय नहीं करते हैं, तो वैरिएंट के नाम बिल्ड टाइप के नाम पर रखे जाते हैं. अगर आपको
दोनों के बारे में बताते हैं, तो वैरिएंट का नाम <flavor><Buildtype>
है. उदाहरण के लिए, बिल्ड के साथ
टाइप release
और debug
के साथ-साथ demo
और full
फ़्लेवर का इस्तेमाल करके, AGP नए फ़ॉर्मैट का इस्तेमाल करेगा
वैरिएंट:
demoRelease
demoDebug
fullRelease
fullDebug
अगले चरण
अब जब आपने बिल्ड के सिद्धांत देख लिए हैं, तो Android बिल्ड के स्ट्रक्चर किया जा सकता है.