मुझे ऐसा लगता है कि ज्यादातर लोग केवल तभी से निपटने के लिए शुरू करते हैं जब परियोजना में कुछ जोड़ने की आवश्यकता होती है या कुछ अचानक टूट जाता है - और समस्या को "ओवरवर्क द्वारा अधिग्रहित" हल करने के बाद अनुभव सुरक्षित रूप से भूल जाता है। इसके अलावा, इंटरनेट पर कई उदाहरण अत्यधिक विशिष्ट मंत्रों के समान हैं जो कि क्या हो रहा है की समझ नहीं जोड़ते हैं:

android { compileSdkVersion 28 defaultConfig { applicationId "com.habr.hello" minSdkVersion 20 targetSdkVersion 28 } buildTypes { release { minifyEnabled false } } } 

मैं विस्तार से वर्णन नहीं करने जा रहा हूं कि ऊपर प्रत्येक पंक्ति क्या है - ये एंड्रॉइड प्लगइन के कार्यान्वयन के निजी विवरण हैं। कुछ और मूल्यवान है - सब कुछ कैसे व्यवस्थित किया जाता है इसकी समझ। जानकारी विभिन्न साइटों / आधिकारिक प्रलेखन / पालना और इसके लिए प्लग इन के स्रोतों पर बिखरी हुई है - सामान्य तौर पर, यह थोड़ा अधिक सार्वभौमिक ज्ञान है जिसे मैं भूलना नहीं चाहता।

आगे के पाठ को उन लोगों के लिए एक धोखा पत्र के रूप में माना जा सकता है जो केवल प्रवणता में महारत हासिल कर रहे हैं या पहले से ही भूल गए हैं।

उपयोगी लिंक

• आधिकारिक दस्तावेज काफी बड़ा है, लेकिन कुछ स्थानों पर विवरणों की कमी हो सकती है।
• github , javadoc पर स्रोत कोड - ग्रूवी में गतिशील टाइपिंग के कारण, विकास वातावरण हमेशा उपलब्ध फ़ील्ड / विधियों की सूची देने में सक्षम होता है, और विधियों और तर्क प्रकारों (क्लोजर क्लोजर) के संक्षिप्त नामों द्वारा यह समझना हमेशा संभव नहीं होता है कि उनकी आवश्यकता क्यों है।
• उदाहरणों के एक समूह के साथ एक हब पर एक लेख "बिल्डिंग और परीक्षण के साथ परीक्षण" पुस्तक के दूसरे अध्याय का अनुवाद है। पुस्तक को भी पढ़ा जा सकता है, यह स्वतंत्र रूप से उपलब्ध है।
• एक और लेख - buildSrc के बारे में

कंसोल

एंड्रॉइड स्टूडियो / आईडीईए श्रमसाध्य रूप से डेवलपर से धीरे-धीरे कमांड को छुपाता है, और यहां तक ​​कि बिल्ड.ग्रेडल फ़ाइलों को बदलते समय यह प्रोजेक्ट को बेवकूफ या पुनरारंभ करना शुरू कर देता है।

ऐसे मामलों में, कंसोल से कॉलिंग ग्रेड बहुत आसान और तेज है। ग्रेडर रैपर आमतौर पर प्रोजेक्ट के साथ आता है और लिनक्स / मैकोस / विंडो में ठीक काम करता है, जब तक कि बाद में आपको रैपर के बजाय बैट फाइल को कॉल करने की आवश्यकता नहीं होती है।

चुनौती कार्य

 ./gradlew tasks 

उपलब्ध कार्यों को लिखता है।

 ./gradlew subprojectName:tasks --all 

आप एक अलग सबप्रोजेक्ट के कार्य प्रदर्शित कर सकते हैं, और यहां तक ​​कि --all विकल्प के साथ, माध्यमिक वाले सहित सभी कार्य प्रदर्शित किए जाएंगे।

आप किसी भी कार्य को कॉल कर सकते हैं, और सभी कार्य जिस पर यह निर्भर करता है उसे कहा जाएगा।

 ./gradlew app:assembleDevelopDebug 

यदि आप पूरा नाम लिखने के लिए बहुत आलसी हैं, तो आप छोटे अक्षर निकाल सकते हैं:

 ./gradlew app:assembleDD 

यदि ओले स्पष्ट रूप से अनुमान नहीं लगा सकते हैं कि उनके पास कौन सा कार्य है, तो यह उपयुक्त विकल्पों की एक सूची प्रदर्शित करेगा।

लॉगिंग

कार्य शुरू करते समय कंसोल में प्रदर्शित जानकारी की मात्रा लॉगिंग के स्तर पर बहुत अधिक निर्भर करती है।
डिफ़ॉल्ट एक के अलावा, वहाँ -q, -w, -i, -d , कुआं, या --quiet, --warn, --info, --debug जानकारी की बढ़ती मात्रा में हैं। जटिल परियोजनाओं पर, -d के साथ आउटपुट मेगाबाइट से अधिक ले सकता है, और इसलिए इसे तुरंत एक फ़ाइल में सहेजना और कीवर्ड खोजने के लिए वहां देखना बेहतर है:

 ./gradlew app:build -d > myLog.txt 

यदि एक अपवाद कहीं फेंक दिया जाता है, तो विकल्प -s स्टैकट्रेस के लिए।

आप लॉग को स्वयं लिख सकते हैं:

 logger.warn('A warning log message.') 

लकड़हारा SLF4J का कार्यान्वयन है।

ग्रूवी

build.gradle फ़ाइलों में क्या होता है यह सिर्फ ग्रूवी कोड है।

किसी कारण से, ग्रूवी, एक प्रोग्रामिंग भाषा के रूप में, बहुत लोकप्रिय नहीं है, हालांकि, जैसा कि मुझे लगता है, यह अपने आप में कम से कम एक छोटे से अध्ययन के योग्य है। 2003 में भाषा का जन्म हुआ और धीरे-धीरे विकसित हुआ। दिलचस्प विशेषताएं:

• लगभग कोई भी java कोड मान्य groovy कोड है। यह काम करने वाले कोड को सहजता से लिखने में बहुत मदद करता है।
• इसके साथ ही स्थैतिक, गतिशील टाइपिंग का समर्थन खांचे में किया जाता है, String a = "a" बजाय String a = "a" आप सुरक्षित रूप से डी def a = "a" या यहां तक ​​कि def map = ['one':1, 'two':2, 'list' = [1,false]] लिख सकते हैं def map = ['one':1, 'two':2, 'list' = [1,false]]
• ऐसे क्लोजर हैं जिनके लिए आप निष्पादन के संदर्भ को गतिशील रूप से निर्धारित कर सकते हैं। वही android {...} ब्लॉक क्लोजर लेते हैं और फिर उन्हें किसी ऑब्जेक्ट के लिए निष्पादित करते हैं।
• स्ट्रिंग्स "$a, ${b}" , मल्टीलाइन स्ट्रिंग्स """yep, ${c}""" का इंटरपोलेशन है, और साधारण जावा स्ट्रिंग्स को एकल उद्धरणों द्वारा तैयार किया गया है: 'text'
• विस्तार के तरीकों की एक झलक है। मानक भाषा संग्रह में पहले से ही कोई, हर, प्रत्येक, findAll जैसी विधियाँ हैं। मुझे व्यक्तिगत रूप से, विधियों के नाम असामान्य लगते हैं, लेकिन मुख्य बात यह है कि वे हैं ।
• स्वादिष्ट शक्करयुक्त चीनी, कोड बहुत छोटा और सरल होता है। आपको सूची और हैश [a,b,c], [key1: value1, key2: value2] की घोषणा के लिए फ़ंक्शन के तर्कों के चारों ओर कोष्ठक लिखने की ज़रूरत नहीं है [a,b,c], [key1: value1, key2: value2] अच्छा सिंटैक्स है: [a,b,c], [key1: value1, key2: value2]

सामान्य तौर पर, पायथन / जावास्क्रिप्ट जैसी भाषाओं ने आसमान छू लिया है और ग्रूवी ने नहीं - यह मेरे लिए एक रहस्य है। अपने समय के लिए, जब जावा में लैम्ब्डा भी नहीं था, और कोटलिन / स्काला जैसे विकल्प अभी दिखाई दे रहे थे या मौजूद नहीं थे, ग्रूवी को वास्तव में एक दिलचस्प भाषा की तरह दिखना था।

यह ग्रूवी सिंटैक्स और डायनेमिक टाइपिंग का लचीलापन था जो हमें ग्रेडेल में संक्षिप्त डीएसएल बनाने की अनुमति देता था।

ग्रैडल के आधिकारिक दस्तावेज में अब कोटलिन पर उदाहरणों की नकल की जाती है, और ऐसा लगता है कि इसे स्विच करने की योजना बनाई गई है, लेकिन कोड अब इतना सरल नहीं दिखता है और सामान्य कोड की तरह अधिक हो जाता है:

 task hello { doLast { println "hello" } } 

बनाम

 tasks.register("hello") { doLast { println("hello") } } 

हालाँकि, क्रैडल में नाम बदलने की अभी योजना नहीं है।

विधानसभा चरणों

वे आरंभीकरण, विन्यास और निष्पादन में विभाजित हैं।

विचार यह है कि प्रवण एक चक्रीय निर्भरता ग्राफ एकत्र करता है और उनमें से केवल आवश्यक न्यूनतम कॉल करता है। अगर मैं सही तरीके से समझूं, तो इनिशियलाइज़ेशन स्टेज उस समय होता है, जब build.gradle से कोड निष्पादित होता है।

उदाहरण के लिए, यह:

 copy { from source to dest } 

या इस तरह:

 task epicFail { copy{ from source to dest } } 

शायद यह स्पष्ट नहीं है, लेकिन इसके बाद के संस्करण की शुरुआत धीमी हो जाएगी। प्रत्येक इनिशियलाइज़ेशन में फ़ाइलों की प्रतिलिपि बनाने में संलग्न न होने के लिए, आपको doLast{...} या doFirst{...} को कार्य में ब्लॉक करने की आवश्यकता है - फिर कोड को एक क्लोजर में लपेटा जाएगा और यह तब कहा जाएगा जब कार्य पूरा हो जाएगा।

 task properCopy { doLast { copy { from dest to source } } } 

या तो

 task properCopy(type: Copy) { from dest to source } 

पुराने उदाहरणों में, doLast बजाय << ऑपरेटर देख सकते हैं, लेकिन बाद में उन्होंने स्पष्ट व्यवहार के कारण इसे छोड़ दिया।

 task properCopy << { println("files copied") } 

tasks.all

doLast और doFirst साथ क्या मजेदार है, आप किसी भी कार्य पर किसी तरह की कार्रवाई कर सकते हैं:

 tasks.all { doFirst { println("task $name started") } } 

IDE बताता है कि tasks में एक whenTaskAdded(Closure ...) विधि है, लेकिन all(Closure ...) विधि अधिक दिलचस्प काम करती है - सभी मौजूदा कार्यों के लिए क्लोजर को बुलाया जाता है, साथ ही जब उन्हें जोड़ा जाता है तो नए कार्यों के लिए।

एक कार्य बनाएं जो सभी कार्यों की निर्भरता को प्रिंट करता है:

 task printDependencies { doLast { tasks.all { println("$name dependsOn $dependsOn") } } } 

या तो:

 task printDependencies { doLast { tasks.all { Task task -> println("${task.name} dependsOn ${task.dependsOn}") } } } 

यदि tasks.all{} रनटाइम ( doLast ब्लॉक में) कहा जाता है, तो हम सभी कार्यों और निर्भरताओं को देखेंगे।
यदि आप doLast बिना भी doLast (यानी, आरंभीकरण के दौरान), तो मुद्रित कार्यों में निर्भरता की कमी हो सकती है, क्योंकि वे अभी तक जोड़े नहीं गए हैं।

अरे हाँ, व्यसनों! यदि कोई अन्य कार्य हमारे कार्यान्वयन के परिणामों पर निर्भर होना चाहिए, तो यह निर्भरता जोड़ने के लायक है:

 anotherTask.dependsOn properCopy 

या इस तरह भी:

 tasks.all{ task -> if (task.name.toLowerCase().contains("debug")) { task.dependsOn properCopy } } 

आदानों, आउटपुट और वृद्धिशील विधानसभा

हर बार एक सामान्य कार्य कहा जाएगा। यदि आप निर्दिष्ट करते हैं कि फ़ाइल A के आधार पर कोई कार्य फ़ाइल B उत्पन्न करता है, तो इन फ़ाइलों को परिवर्तित नहीं होने पर कार्य को छोड़ देगा। और वर्गीकृत फ़ाइल संशोधन तिथि की जांच नहीं करता है, लेकिन इसकी सामग्री।

 task generateCode(type: Exec) { commandLine "generateCode.sh", "input.txt", "output.java" inputs.file "input.txt" output.file "output.java" } 

इसी तरह, आप फ़ोल्डर्स, साथ ही कुछ मान निर्दिष्ट कर सकते हैं: inputs.property(name, value) ।

कार्य विवरण

जब कॉलिंग ./gradlew tasks --all मानक कार्यों का एक सुंदर वर्णन है और किसी भी तरह से समूहीकृत हैं। आपके कार्यों के लिए, यह बहुत सरलता से जोड़ा गया है:

 task hello { group "MyCustomGroup" description "Prints 'hello'" doLast{ print 'hello' } } 

task.enabled

आप कार्य को "बंद" कर सकते हैं - फिर भी इसकी निर्भरता को ऊपर कहा जाएगा, लेकिन यह स्वयं नहीं होगा।

 taskName.enabled false 

कई परियोजनाएं (मॉड्यूल)

मल्टी-प्रोजेक्ट प्रलेखन में बनाता है

मुख्य परियोजना में, आप कई और मॉड्यूल रख सकते हैं। उदाहरण के लिए, यह एंड्रॉइड प्रोजेक्ट्स में उपयोग किया जाता है - रूट प्रोजेक्ट में लगभग कुछ भी नहीं है, एंड्रॉइड प्लगइन सबप्रोजेक्ट में शामिल है। यदि आप एक नया मॉड्यूल जोड़ना चाहते हैं, तो आप एक और जोड़ सकते हैं, और वहां, उदाहरण के लिए, आप एंड्रॉइड प्लगइन को भी कनेक्ट कर सकते हैं, लेकिन इसके लिए अन्य सेटिंग्स का उपयोग कर सकते हैं।

एक और उदाहरण: जब jitpack का उपयोग करके किसी प्रोजेक्ट को प्रकाशित किया जाता है, तो रूट प्रोजेक्ट एक बच्चे के मॉड्यूल को प्रकाशित करने के लिए किन सेटिंग्स के साथ वर्णन करता है, जो प्रकाशन पर संदेह भी नहीं कर सकता है।

बाल मॉड्यूल सेटिंग में निर्दिष्ट किए गए हैं। क्रम:

 include 'name' 

यहाँ परियोजनाओं के बीच निर्भरता के बारे में और पढ़ें ।

buildSrc

अगर build.gradle में बहुत सारे कोड हैं या इसे डुप्लिकेट किया गया है, तो इसे एक अलग मॉड्यूल में ले जाया जा सकता है। हमें जादू नाम buildSrc साथ एक फ़ोल्डर की आवश्यकता है, जिसमें आप कोड को ग्रूवी या जावा में रख सकते हैं। (अच्छी तरह से, या बल्कि, buildSrc/src/main/java/com/smth/ code में, buildSrc/src/test जोड़े जा सकते हैं)। यदि आप कुछ और चाहते हैं, उदाहरण के लिए, अपने कार्य को स्कैला पर लिखें या कुछ निर्भरता का उपयोग करें, तो सीधे buildSrc आपको build.gradle बनाने और build.gradle आवश्यक निर्भरता निर्दिष्ट करने / प्लग इन सक्षम करने की आवश्यकता है।

दुर्भाग्य से, buildSrc में एक परियोजना के साथ buildSrc आईडीई संकेत के साथ बेवकूफ बना सकता है, वहां आपको आयात और कक्षाएं / कार्य लिखना होगा वहां से build.gradle इसे सामान्य build.gradle में भी आयात करना build.gradle । import com.smth.Taskname मुश्किल नहीं है, आपको बस इसे याद रखने की जरूरत है और इस बात की पहेली नहीं है कि buildSrc से कार्य क्यों नहीं मिला)।

इस कारण से, पहले कुछ ऐसा लिखना सुविधाजनक है जो build.gradle में सीधे काम करता है, और उसके बाद ही कोड को buildSrc स्थानांतरित करें।

स्वयं का कार्य प्रकार

कार्य DefaultTask से विरासत में मिला है, जिसमें कई, कई फ़ील्ड, विधियाँ और अन्य चीज़ें हैं। AbstractTask कोड DefaultTask से विरासत में मिला है।

उपयोगी बिंदु:

• inputs और outputs को मैन्युअल रूप से जोड़ने के बजाय outputs आप फ़ील्ड और एनोटेशन का उपयोग कर सकते हैं: @Input, @OutputFile , आदि।
• कार्य निष्पादित होने पर विधि को चलाया जाएगा: @TaskAction ।
• सुविधाजनक तरीके जैसे copy{from ... , into... } अभी भी कॉल किया जा सकता है, लेकिन आपको प्रोजेक्ट के लिए उन्हें स्पष्ट रूप से कॉल करना होगा: project.copy{...}

जब कोई व्यक्ति build.gradle में हमारे कार्य के लिए लिखता है

 taskName { ... //some code } 

configure(Closure) विधि को कार्य पर कहा जाता है।

मुझे यकीन नहीं है कि यह सही दृष्टिकोण है, लेकिन अगर कार्य में कई क्षेत्र हैं जिनकी पारस्परिक स्थिति को गेट्टर-सेटरों के साथ नियंत्रित करना मुश्किल है, तो यह विधि को फिर से परिभाषित करने के लिए काफी सुविधाजनक लगता है:

 override def configure(Closure closure){ def result = super().configure(closure) //    / - return result; } 

और लिखते भी हैं

 taskName.fieldName value 

तब configure विधि अभी भी कहा जाएगा।

खुद का प्लगइन

एक कार्य की तरह, आप अपना स्वयं का प्लगइन लिख सकते हैं, जो कुछ को कॉन्फ़िगर करेगा या कार्य बनाएगा। उदाहरण के लिए, android{...} में जो कुछ हो रहा है वह पूरी तरह से एक गुण है काला जादू एंड्रॉइड प्लग-इन, जो इसके अलावा ऐप जैसे कार्यों का एक पूरा गुच्छा बनाता है: स्वाद के सभी संभावित संयोजनों / बिल्ड प्रकार / डिमेनस्टियन के लिए assDDevelopDebug। आपके प्लगइन को लिखने में कुछ भी जटिल नहीं है, एक बेहतर समझ के लिए आप अन्य प्लगइन्स का कोड देख सकते हैं।

एक तीसरा चरण है - आप कोड को buildSrc में नहीं buildSrc , लेकिन इसे एक अलग परियोजना बना सकते हैं। फिर, https://jitpack.io या कुछ और का उपयोग करके, प्लगइन प्रकाशित करें और इसे दूसरों के समान कनेक्ट करें।

अंत

ऊपर दिए गए उदाहरणों में टाइपोस और अशुद्धि शामिल हो सकते हैं। व्यक्तिगत नोट में लिखें या ctrl+enter साथ चिह्नित ctrl+enter - मैं इसे सही कर दूंगा। विशिष्ट उदाहरणों को प्रलेखन से लिया गया है, और इस लेख को "कैसे करें" की एक छोटी सूची के रूप में देखें।