उत्पाद प्रकारों से अलग प्रकार के निर्माण क्यों अलग हैं?

Question

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

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

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

कुछ ठोस उदाहरण है कि मेरे भ्रम की स्थिति पैदा:

• signingConfig संपत्ति दोनों प्रकार के और उत्पाद जायके ... लेकिन minifyEnabled निर्माण (? और, मुझे लगता है, shrinkResources) में स्थापित किया जा सकता केवल किया जा सकता है निर्माण प्रकार में कॉन्फ़िगर किया गया।

• applicationId केवल उत्पाद के स्वादों में निर्दिष्ट किया जा सकता है ... और applicationIdSuffix केवल निर्माण प्रकारों में निर्दिष्ट किया जा सकता है !?

वास्तविक प्रश्न (रों):

को देखते हुए उपरोक्त उदाहरण: वहाँ निर्माण प्रकार की भूमिकाओं उत्पाद जायके बनाम के बीच स्पष्ट अंतर है?

यदि हां, तो इसे समझने का सबसे अच्छा तरीका क्या है?

यदि नहीं, तो अंततः निर्माण प्रकारों और उत्पाद स्वादों को एक कॉन्फ़िगर करने योग्य डीएसएल ऑब्जेक्ट में विलय करने की योजना है?

Answer 1

@ कॉमन्सवेयर ने टिप्पणियों में क्या कहा, इसका विस्तार करना मूलभूत विचार यह है कि निर्माण प्रकार आपके एप्लिकेशन के विभिन्न निर्माण के लिए हैं जो कार्यात्मक रूप से अलग नहीं हैं - यदि आपके पास अपने ऐप का डिबग और रिलीज़ संस्करण है, तो वे ' एक ही ऐप फिर से करें, लेकिन एक में डिबगिंग कोड, शायद अधिक लॉगिंग इत्यादि शामिल हैं, और दूसरा सुव्यवस्थित और अनुकूलित है और संभवतः ProGuard के माध्यम से obfuscated है। स्वाद के साथ, इरादा यह है कि ऐप कुछ तरीकों से काफी अलग है। सबसे स्पष्ट उदाहरण आपके ऐप का एक भुगतान बनाम एक मुफ़्त संस्करण होगा, लेकिन डेवलपर्स इसे वितरित किए जा रहे हैं (जो ऐप-एप बिलिंग एपीआई उपयोग को प्रभावित कर सकता है) के आधार पर भिन्न हो सकता है।

ऐसे डेवलपर हैं जो अलग-अलग ग्राहकों के लिए एक समान ऐप के कई, कई अलग-अलग संस्करण बनाते हैं - एक उदाहरण एक साधारण ऐप हो सकता है जो वेब संस्करण में एक वेब पेज खोलता है, जिसमें प्रत्येक संस्करण के लिए अलग-अलग यूआरएल और ब्रांडिंग होते हैं - - यह स्वाद का एक अच्छा उपयोग है।

दोहराए जाने के लिए, यदि यह "एक ही अनुप्रयोग" है, तो कुछ अंतर जो मॉड्यूल के लिए महत्वपूर्ण नहीं हैं, और विशेष रूप से यदि किसी के अलावा सभी प्रकार के सभी प्रकार आपके परीक्षण और विकास के उपयोग के लिए हैं और केवल एक संस्करण है अंतिम उपयोगकर्ताओं को तैनात किया जाएगा, फिर यह निर्माण प्रकारों के लिए एक अच्छा उम्मीदवार है।यदि यह "एक अलग" एप्लिकेशन है और उपयोगकर्ताओं को कई रूपों को तैनात किया जाएगा, तो शायद यह उत्पाद स्वाद के लिए एक उम्मीदवार है।

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

Answer 2

buildType कॉन्फ़िगर कैसे हम अपने एप्लिकेशन

• shrinkResources
• progaurdFile
• आदि

स्वाद कॉन्फ़िगर विभिन्न वर्गों और संसाधनों पैकेज।

• Flavor1 में अपने MainActivity कुछ कर सकते हैं, और Flavor2 विभिन्न कार्यान्वयन

• differente ऐप्लिकेशन का नाम

• आदि में

प्रत्येक उत्पाद स्वाद का अपना मान हो सकते हैं निम्नलिखित गुणों में से, दूसरों के बीच, जो defaultConfig से समान गुणों पर आधारित हैं:

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName