कोटलिन ग्रैडल निर्भरताओं में "कार्यान्वयन" क्या है?

Question

मैं नई कोटलिन प्रोजेक्ट शुरू करने के लिए एंड्रॉइड स्टूडियो 3.0 पूर्वावलोकन का उपयोग कर रहा हूं। जैसा कि मैं build.gradle में निर्भरता जोड़ने की कोशिश करता हूं, मैंने सामान्य compile की बजाय implementation दायरा देखा।

androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', { 
    exclude group: 'com.android.support', module: 'support-annotations' 
}) 
implementation 'com.android.support:appcompat-v7:25.3.1' 
testImplementation 'junit:junit:4.12' 

वहाँ भी androidTestImplementation और testImplementation गुंजाइश है।

अंत में, मैं तीसरे पक्ष निर्भरताओं को जोड़ने के लिए compile जोड़ता हूं और यह काम करता है।

compile 'io.reactivex.rxjava2:rxandroid:2.0.1' 

तो मेरी सवाल कर रहे हैं ..

• क्या implementation, androidTestImplementation, और testImplementation गुंजाइश है?
• क्या यह compile, testCompile, और androidTestCompile से अलग है?
• मुझे अपनी कोटलिन परियोजना के लिए किस का उपयोग करना चाहिए?

संपादित करें: मेरा बुरा, यह सवाल कोटलिन विशिष्ट नहीं है। यह नया Android Gradle Plugin configuration है।

Answer 1

यह कोटलिन के लिए विशिष्ट नहीं है, लेकिन एंड्रॉइड के लिए नई ग्रैडल प्लगइन के साथ करना है।

compile, provided और apk अब बहिष्कृत हैं।
उपयोग implementation या api बजाय compile, compileOnly बजाय provided, और runtimeOnly बजाय apk।

इसका कारण बहु-मॉड्यूल बिल्ड को तेज करना है। मॉड्यूल A दिया गया है जो मॉड्यूल B पर निर्भर करता है जो बदले में मॉड्यूल C पर निर्भर करता है, मॉड्यूल C में परिवर्तन मॉड्यूल A के एक पुन: संकलन को ट्रिगर करेगा। यदि A सीधे C का उपयोग नहीं करता है, तो C परिवर्तनों के साथ पुन: संकलित करने के लिए A की आवश्यकता नहीं है।

implementation विन्यास वास्तव में यह सुनिश्चित करता है: यदि आप B में implementation project(':C') निर्दिष्ट करते हैं, आप A से C उपयोग नहीं कर सकते और आप अनावश्यक मॉड्यूल के निर्माण से बचें। एक बड़ी बहु-मॉड्यूल परियोजना में यह बहुत समय बचा सकता है।

अधिक जानकारी के लिए Migrate to the new Gradle plugin देखें।

Answer 2

gradle v3.0.0-alpha1 का पहला संस्करण compile का उपयोग करने के लिए उपयोग किया जाता था लेकिन इसे अब हटा दिया गया है।

क्यों?

compile कॉन्फ़िगरेशन में दिखाई देने वाली निर्भरताओं को लाइब्रेरी के उपभोक्ताओं के लिए पारस्परिक रूप से उजागर किया जाएगा, और ऐसा उपभोक्ताओं के संकलन वर्गपंथ पर दिखाई देगा। कार्यान्वयन विन्यास में पाए गए निर्भरता, दूसरी ओर, उपभोक्ताओं के संपर्क में नहीं आएगी, और इसलिए उपभोक्ताओं के संकलन वर्गपाथ में रिसाव नहीं करेंगे।

चलो इसे समझने के लिए एक उदाहरण लें। मान लीजिए, मैंने Library_Image_Upload बनाया है जो सर्वर पर Image uploading का समर्थन करता है। मैंने Library_Image_Upload में lib का उपयोग किया जो सभी नेटवर्क संचालन का समर्थन करता है। मेरी लाइब्रेरी केवल छवि अपलोड का उपयोग करती है और छवियों को अपलोड करने का एक सुविधाजनक तरीका प्रदान करती है। अब के रूप में मैं अपने Library_Image_Upload परियोजना में Library_Network lib इस्तेमाल किया, इस lib उपयोग करने वाले सभी Image Uploading की कार्यक्षमता सभी नेटवर्क संचालन के साथ कि किसी को भी उपयोग कर सकते हैं (महत्वपूर्ण) होगा। बाद में मैंने सोचा कि Library_NetworkLibrary_Magic_Image के रूप में बेहतर विकल्प है और इसका उपयोग किया जाता है। तो Library_Network द्वारा उजागर किए गए सभी एपीआई फ़ंक्शंस चले गए हैं और जो भी उन कार्यों का उपयोग कर रहा है, को तोड़ दिया है।

implementation कई लाभ के साथ आता है:

• निर्भरता अब और उपभोक्ताओं के संकलन classpath में रिसाव नहीं है, ताकि आप कभी गलती से
• तेज़ संकलन कम classpath आकार
करने के लिए धन्यवाद एक सकर्मक निर्भरता पर निर्भर करेगा
• कार्यान्वयन निर्भरता में परिवर्तन होने पर कम पुनर्मूल्यांकन: उपभोक्ताओं को
• क्लीनर प्रकाशन: जब नए मेवेन-प्रकाशित प्लगइन के साथ संयोजन में उपयोग किया जाता है, जावा पुस्तकालयों पी पीओएम फाइलों को roduce जो लाइब्रेरी के खिलाफ संकलन करने के लिए आवश्यक है और रनटाइम पर लाइब्रेरी का उपयोग करने के लिए क्या आवश्यक है के बीच में अंतर है (दूसरे शब्दों में, लाइब्रेरी को संकलित करने के लिए आवश्यक चीज़ों को मिश्रण न करें और इसके खिलाफ संकलन करने के लिए क्या आवश्यक है पुस्तकालय)।

अधिक जानने के लिए The Java Library Plugin

पढ़ा तो मुझे लगता है कि आप सभी तीन सवालों का जवाब दिया है।

मुझे उम्मीद है कि यह मदद करता है।