लाइब्रेरी के लेखकों के लिए ऑप्टिमाइज़ेशन

लाइब्रेरी के लेखक के तौर पर, आपको यह पक्का करना होगा कि ऐप्लिकेशन डेवलपर आपकी लाइब्रेरी को अपने ऐप्लिकेशन में आसानी से शामिल कर सकें. साथ ही, असली उपयोगकर्ता को बेहतरीन अनुभव मिलता रहे. इसका मतलब है कि आपकी लाइब्रेरी, Android ऑप्टिमाइज़ेशन (R8) के साथ काम करनी चाहिए. इसके लिए, डेवलपर को कोई अतिरिक्त सेटअप करने की ज़रूरत नहीं होनी चाहिए. इसके अलावा, यह भी बताया जाना चाहिए कि लाइब्रेरी, Android पर इस्तेमाल करने के लिए सही नहीं है. यह ज़रूरी है कि Android पर इस्तेमाल की जाने वाली लाइब्रेरी, ऐप्लिकेशन के ज़रूरी ऑप्टिमाइज़ेशन को न रोकें. साथ ही, ऑप्टिमाइज़ेशन से जुड़ी अन्य ज़रूरी शर्तों का पालन करें.

यह दस्तावेज़, पब्लिश की गई लाइब्रेरी के डेवलपर के लिए है. हालांकि, यह किसी बड़े और मॉड्यूलर ऐप्लिकेशन में, इंटरनल लाइब्रेरी मॉड्यूल के डेवलपर के लिए भी मददगार हो सकता है.

अगर आप ऐप्लिकेशन डेवलपर हैं और आपको अपने Android ऐप्लिकेशन को ऑप्टिमाइज़ करने के बारे में जानना है, तो ऐप्लिकेशन ऑप्टिमाइज़ेशन की सुविधा चालू करना लेख पढ़ें. इस्तेमाल करने के लिए कौनसी लाइब्रेरी सही हैं, इस बारे में जानने के लिए, लाइब्रेरी को सोच-समझकर चुनें लेख पढ़ें.

डेटा को बनाए रखने के नियम के टाइप समझना

लाइब्रेरी में दो तरह के नियम बनाए जा सकते हैं:

• उपभोक्ता के डेटा को सुरक्षित रखने से जुड़े कीप नियमों में, ऐसे नियम शामिल होने चाहिए जो लाइब्रेरी में मौजूद हर चीज़ को सुरक्षित रखें. अगर कोई लाइब्रेरी अपने कोड या क्लाइंट ऐप्लिकेशन के तय किए गए कोड को कॉल करने के लिए, रिफ़्लेक्शन या जेएनआई का इस्तेमाल करती है, तो इन नियमों में यह बताना ज़रूरी है कि कौनसा कोड रखना है. लाइब्रेरी में, उपभोक्ता के डेटा को सुरक्षित रखने से जुड़े कीप नियम शामिल होने चाहिए. ये नियम, ऐप्लिकेशन के कीप नियमों के फ़ॉर्मैट का ही इस्तेमाल करते हैं. ये नियम, लाइब्रेरी आर्टफ़ैक्ट (AAR या JAR) में बंडल किए जाते हैं. साथ ही, लाइब्रेरी का इस्तेमाल करने पर, Android ऐप्लिकेशन को ऑप्टिमाइज़ करने के दौरान ये अपने-आप इस्तेमाल हो जाते हैं. इन नियमों को आपकी build.gradle.kts (या build.gradle) फ़ाइल में, consumerProguardFiles प्रॉपर्टी के साथ बताई गई फ़ाइल में सेव किया जाता है. ज़्यादा जानने के लिए, उपभोक्ता के लिए डेटा बनाए रखने के नियम लिखना लेख पढ़ें.
• लाइब्रेरी बिल्ड कीप नियम, लाइब्रेरी बनाते समय लागू होते हैं. इनकी ज़रूरत सिर्फ़ तब होती है, जब आपको बिल्ड के समय अपनी लाइब्रेरी को कुछ हद तक ऑप्टिमाइज़ करना हो. उन्हें लाइब्रेरी के सार्वजनिक एपीआई को हटाए जाने से रोकना होगा. ऐसा न करने पर, लाइब्रेरी डिस्ट्रिब्यूशन में सार्वजनिक एपीआई मौजूद नहीं होगा. इसका मतलब है कि ऐप्लिकेशन डेवलपर, लाइब्रेरी का इस्तेमाल नहीं कर पाएंगे. ये नियम, आपकी build.gradle.kts (या build.gradle) फ़ाइल में proguardFiles प्रॉपर्टी के साथ बताई गई फ़ाइल में सेव किए जाते हैं. ज़्यादा जानने के लिए, एएआर लाइब्रेरी बिल्ड को ऑप्टिमाइज़ करना लेख पढ़ें.

ऑप्टिमाइज़ेशन से जुड़ी ज़रूरी शर्तें और दिशा-निर्देश

लाइब्रेरी में मौजूद R8 कॉन्फ़िगरेशन का, इस्तेमाल किए जा रहे ऐप्लिकेशन के फ़ाइनल बाइनरी साइज़ और परफ़ॉर्मेंस पर ग्लोबल असर पड़ता है. कीप नियम के सबसे सही तरीकों के अलावा, लाइब्रेरी तैयार करने वाले डेवलपर को कुछ खास ज़रूरी शर्तों का पालन करना होगा. साथ ही, उन्हें अन्य दिशा-निर्देशों का भी ध्यान रखना होगा.

ऑप्टिमाइज़ेशन से जुड़ी ज़रूरी शर्तों का पालन करना

लाइब्रेरी में मौजूद गड़बड़ियों की वजह से, ऐप्लिकेशन का साइज़ बढ़ जाता है, मेमोरी बर्बाद होती है, ऐप्लिकेशन धीरे-धीरे शुरू होता है, और एएनआर (ऐप्लिकेशन काम नहीं कर रहा है) जैसी गड़बड़ियां होती हैं. लाइब्रेरी को इन ज़रूरी शर्तों का उल्लंघन करने से बचना चाहिए, ताकि ऐप्लिकेशन की क्वालिटी और उपयोगकर्ता अनुभव में काफ़ी कमी न आए.

• डेटा सुरक्षित रखने के लिए, बड़े पैमाने पर या पूरे पैकेज पर लागू होने वाले कीप नियम न बनाएं: आपकी लाइब्रेरी में, डेटा सुरक्षित रखने के लिए बड़े पैमाने पर लागू होने वाले ऐसे कीप नियम शामिल नहीं होने चाहिए जो आपकी लाइब्रेरी या किसी दूसरी लाइब्रेरी में मौजूद ज़्यादातर कोड को सुरक्षित रखते हों. ब्रॉड कीप रूल, कुछ समय के लिए क्रैश की समस्या को हल कर सकते हैं. हालांकि, इनसे आपकी लाइब्रेरी का इस्तेमाल करने वाले सभी ऐप्लिकेशन का साइज़ बढ़ जाता है.

  अपनी लाइब्रेरी या रेफ़रंस के तौर पर इस्तेमाल की गई अन्य लाइब्रेरी में मौजूद पैकेज के लिए, पैकेज-वाइड कीप रूल (जैसे, -keep class com.mylibrary.** {*; }) शामिल न करें. ऐसे नियम, आपकी लाइब्रेरी का इस्तेमाल करने वाले सभी ऐप्लिकेशन में इन पैकेज के ऑप्टिमाइज़ेशन को सीमित करते हैं.

  तीसरे पक्ष की उन डिपेंडेंसी के लिए, कीप रूल को बड़े पैमाने पर शामिल न करें जिनका इस्तेमाल आपकी लाइब्रेरी करती है. उदाहरण के लिए, -keep public class com.google.android.gms.** { *; }. बाहरी लाइब्रेरी में से कई लाइब्रेरी, पहले से ही अपने उपभोक्ता के लिए कीप रूल उपलब्ध कराती हैं. पूरे पैकेज के लिए नियम लागू करने पर, वे नियम बदल जाते हैं. साथ ही, R8 को पूरे ऐप्लिकेशन में, बिना रेफ़रंस वाले डिपेंडेंसी कोड को बनाए रखने के लिए मजबूर होना पड़ता है.

• गलत ग्लोबल नियम न बनाएं: -dontobfuscate या -allowaccessmodification जैसे ग्लोबल विकल्पों का इस्तेमाल कभी न करें.

• जब भी संभव हो, रिफ़्लेक्शन के बजाय कोड जनरेशन का इस्तेमाल करें: जब भी संभव हो, रिफ़्लेक्शन के बजाय कोड जनरेशन (codegen) का इस्तेमाल करें. प्रोग्रामिंग करते समय, छोटे-मोटे बदलाव वाले कोड से बचने के लिए, कोडजेन और रिफ़्लेक्शन, दोनों ही सामान्य तरीके हैं. हालांकि, कोडजेन, R8 जैसे ऐप्लिकेशन ऑप्टिमाइज़र के साथ ज़्यादा बेहतर तरीके से काम करता है.

  कोड जनरेशन की सुविधा की मदद से, बिल्ड प्रोसेस के दौरान कोड का विश्लेषण किया जाता है और उसमें बदलाव किया जाता है. कंपाइल के समय के बाद कोई बड़ा बदलाव नहीं होता है. इसलिए, ऑप्टिमाइज़र को पता होता है कि आखिर में किस कोड की ज़रूरत है और किसे सुरक्षित तरीके से हटाया जा सकता है.

  रिफ़्लेक्शन की मदद से, रनटाइम के दौरान कोड का विश्लेषण किया जाता है और उसमें बदलाव किया जाता है. ऐसा इसलिए, क्योंकि कोड के लागू होने तक उसे फ़ाइनल नहीं किया जाता. इसलिए, ऑप्टिमाइज़र को यह नहीं पता होता कि किस कोड को सुरक्षित तरीके से हटाया जा सकता है. इससे, रनटाइम के दौरान रिफ़्लेक्शन की मदद से डाइनैमिक तौर पर इस्तेमाल होने वाला कोड हट सकता है. इस वजह से, उपयोगकर्ताओं के लिए ऐप्लिकेशन क्रैश हो सकता है.

  कई आधुनिक लाइब्रेरी, रिफ़्लेक्शन के बजाय कोडजेन का इस्तेमाल करती हैं. KSP को एक सामान्य एंट्रीपॉइंट के तौर पर देखें. इसका इस्तेमाल Room, Hilt, और कई अन्य टूल करते हैं.

  ध्यान दें: कुछ मामलों में, रिफ़्लेक्शन का इस्तेमाल करना सही हो सकता है. ज़्यादा जानकारी के लिए, रिफ़्लेक्शन कब ठीक होता है लेख पढ़ें.

• R8 फ़ुल मोड के साथ काम करना: R8 फ़ुल मोड चालू होने पर, आपकी लाइब्रेरी क्रैश नहीं होनी चाहिए. R8 का इस्तेमाल करने के लिए, इसके फ़ुल मोड का इस्तेमाल करने का सुझाव दिया जाता है. यह Android Gradle प्लगिन 8.0 के बाद से डिफ़ॉल्ट रूप से सेट होता है. इसे 2023 में स्टेबल बनाया गया था. अगर R8 की वजह से आपकी लाइब्रेरी क्रैश हो जाती है, तो इसका समाधान यह है कि रिफ़्लेक्शन या जेएनआई एंट्री पॉइंट की पहचान करें और टारगेट किया गया नियम जोड़ें. पूरे पैकेज को न रखें. इन एंट्री पॉइंट पर एनोटेशन से टारगेट किए गए नियम जनरेट करने के लिए, Jetpack Keep का इस्तेमाल करें.

कुछ और सुझाव

ऑप्टिमाइज़ेशन की ज़रूरी शर्तों के अलावा, यहां कुछ और सुझाव दिए गए हैं.

• अपनी लाइब्रेरी के उपभोक्ता के डेटा को सुरक्षित रखने से जुड़े कीप नियमों की फ़ाइल में, -repackageclasses का इस्तेमाल न करें. उपभोक्ता के कीप नियम, आपकी लाइब्रेरी का इस्तेमाल करने वाले हर ऐप्लिकेशन के R8 कॉन्फ़िगरेशन में मर्ज हो जाते हैं. इसलिए, यह ग्लोबल विकल्प पूरे ऐप्लिकेशन पर लागू होता है और ऐप्लिकेशन डेवलपर की रीपैकेजिंग सेटिंग को बदल देता है. AGP 9.0 या इसके बाद के वर्शन से, डिफ़ॉल्ट रूप से लाइब्रेरी को पब्लिश नहीं किया जा सकता. ऐसा तब होता है, जब इसके उपभोक्ता के लिए बनाए गए नियमों में ग्लोबल विकल्प शामिल हों. ज़्यादा जानकारी के लिए, AGP 9.0 के रिलीज़ नोट देखें.

  अपनी लाइब्रेरी के बिल्ड को ऑप्टिमाइज़ करने के लिए, लाइब्रेरी की बिल्ड कीप रूल्स फ़ाइल में, -repackageclasses के साथ पैकेज का कोई इंटरनल नाम इस्तेमाल किया जा सकता है. जैसे, <your.library.package>.internal. इससे ऑप्टिमाइज़ नहीं किए गए ऐप्लिकेशन में आपकी लाइब्रेरी की परफ़ॉर्मेंस बेहतर हो सकती है. हालांकि, आम तौर पर इसकी ज़रूरत नहीं होती, क्योंकि ऐप्लिकेशन भी ऑप्टिमाइज़ किए जाने चाहिए.

• अपनी लाइब्रेरी के लिए ज़रूरी सभी एट्रिब्यूट को लाइब्रेरी की कीप रूल फ़ाइलों में शामिल करें. भले ही, वे एट्रिब्यूट proguard-android-optimize.txt में तय किए गए एट्रिब्यूट से ओवरलैप हो रहे हों.

• अगर आपको अपनी लाइब्रेरी डिस्ट्रिब्यूशन में इन एट्रिब्यूट की ज़रूरत है, तो उन्हें अपनी लाइब्रेरी की बिल्ड कीप रूल्स फ़ाइल में बनाए रखें. साथ ही, उन्हें अपनी लाइब्रेरी की उपभोक्ता कीप रूल्स फ़ाइल में न रखें:

  • AnnotationDefault
  • EnclosingMethod
  • Exceptions
  • InnerClasses
  • RuntimeInvisibleAnnotations
  • RuntimeInvisibleParameterAnnotations
  • RuntimeInvisibleTypeAnnotations
  • RuntimeVisibleAnnotations
  • RuntimeVisibleParameterAnnotations
  • RuntimeVisibleTypeAnnotations
  • Signature

• अगर रनटाइम के दौरान एनोटेशन का इस्तेमाल किया जाता है, तो लाइब्रेरी तैयार करने वाले डेवलपर को उपभोक्ता के लिए डेटा सुरक्षित रखने वाले कीप नियमों में, RuntimeVisibleAnnotations एट्रिब्यूट को शामिल करना चाहिए.

• लाइब्रेरी तैयार करने वाले डेवलपर को उपभोक्ता के लिए डेटा सुरक्षित रखने वाले कीप नियमों में, इन ग्लोबल विकल्पों का इस्तेमाल नहीं करना चाहिए. -repackageclasses की तरह ही, ये विकल्प आपकी लाइब्रेरी के कोड के बजाय, ऐप्लिकेशन के पूरे R8 बिल्ड को कॉन्फ़िगर करते हैं. इसलिए, इन्हें ऐप्लिकेशन डेवलपर के लिए छोड़ दें:

  • -include
  • -basedirectory
  • -injars
  • -outjars
  • -libraryjars
  • -repackageclasses
  • -flattenpackagehierarchy
  • -allowaccessmodification
  • -renamesourcefileattribute
  • -ignorewarnings
  • -addconfigurationdebugging
  • -printconfiguration
  • -printmapping
  • -printusage
  • -printseeds
  • -applymapping
  • -obfuscationdictionary
  • -classobfuscationdictionary
  • -packageobfuscationdictionary

रिफ़्लेक्शन कब ठीक होता है

अगर आपको रिफ़्लेक्शन का इस्तेमाल करना है, तो आपको सिर्फ़ इनमें से किसी एक में रिफ़्लेक्शन करना चाहिए:

• टारगेट किए गए खास टाइप (इंटरफ़ेस लागू करने वाले खास लोग या सबक्लास)
• किसी खास रनटाइम एनोटेशन का इस्तेमाल करने वाला कोड

इस तरह से रिफ़्लेक्शन का इस्तेमाल करने से, रनटाइम की लागत कम हो जाती है. साथ ही, उपभोक्ता के लिए टारगेट किए गए नियम लिखे जा सकते हैं.

रिफ़्लेक्शन के इस खास और टारगेट किए गए फ़ॉर्म का पैटर्न, Android फ़्रेमवर्क (उदाहरण के लिए, गतिविधियों, व्यू, और ड्रॉएबल को इनफ़्लेट करते समय) और AndroidX लाइब्रेरी (उदाहरण के लिए, WorkManager ListenableWorkers या RoomDatabases बनाते समय), दोनों में देखा जा सकता है. इसके उलट, Gson के ओपन एंडेड रिफ़्लेक्शन का इस्तेमाल, Android ऐप्लिकेशन में नहीं किया जा सकता.

सामान्य भ्रांतियां

कुछ आम गलतफ़हमियों की वजह से, हो सकता है कि आप R8 को गलत तरीके से कॉन्फ़िगर कर दें. इनमें ये शामिल हैं:

• R8 के ऑप्टिमाइज़ेशन के बारे में गलत जानकारी: आम तौर पर, लोगों को लगता है कि R8 के ऑप्टिमाइज़ेशन सिर्फ़ कोड को छिपाने तक सीमित हैं. हालांकि, ऐसा नहीं है. इनमें कोड को छोटा करना और लॉजिकल ऑप्टिमाइज़ेशन भी शामिल हैं. इसके लिए, मेथड इनलाइनिंग और क्लास मर्ज करने की तकनीकों का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, R8 ऑप्टिमाइज़ेशन की खास जानकारी देखें.

• ऑब्फ़स्केट की गई लाइब्रेरी के ऑप्टिमाइज़ेशन को बायपास करना: एक सामान्य गड़बड़ी यह है कि किसी लाइब्रेरी को ऑप्टिमाइज़ेशन से हटा दिया जाता है. ऐसा इसलिए होता है, क्योंकि लाइब्रेरी को एएआर (Android Archive) या जेएआर (Java Archive) में कंपाइल करते समय, ऑप्टिमाइज़ या ऑब्फ़स्केट किया गया था. लाइब्रेरी बनाने के दौरान, ऑप्टिमाइज़ेशन सीमित होते हैं. साथ ही, आपके ऐप्लिकेशन को लाइब्रेरी के ऑप्टिमाइज़ेशन को बंद नहीं करना चाहिए. इसके लिए, उसे कीप नियम में शामिल करना चाहिए. ज़्यादा जानकारी के लिए, एएआर लाइब्रेरी बिल्ड को ऑप्टिमाइज़ करना लेख पढ़ें.

• -keep विकल्प के बारे में गलत जानकारी -keep नियम, R8 को अपने किसी भी ऑप्टिमाइज़ेशन पास को चलाने से रोकता है. ज़्यादा जानकारी के लिए, सही कीप ऑप्शन चुनना लेख पढ़ें.

उपभोक्ता के लिए निजी डेटा के रखरखाव के नियम की क्वालिटी की पुष्टि करना

यह पुष्टि करने के लिए कि आपकी लाइब्रेरी किसी ऐप्लिकेशन में एम्बेड किए जाने पर, कोड ऑप्टिमाइज़ेशन को ज़्यादा नहीं रोकती है, लाइब्रेरी के सैंपल या इंटिग्रेशन टेस्ट ऐप्लिकेशन का इस्तेमाल करें. R8 को चालू करें और R8 Configuration Analyzer की मदद से, ऐप्लिकेशन के R8 कॉन्फ़िगरेशन की क्वालिटी की जांच करें.

अगर आपके कंज़्यूमर नियम, आपकी लाइब्रेरी के कोड के बड़े हिस्सों पर ऑप्टिमाइज़ेशन को सीमित करते हैं, तो इसका मतलब है कि आपके कंज़्यूमर नियमों में सुधार की ज़रूरत है. उपभोक्ता के नियमों को सीमित करें. साथ ही, R8 की सुविधा वाले ऐप्लिकेशन में, अपनी लाइब्रेरी के उन सभी पहलुओं की जांच करें जिन पर असर पड़ा है.

नियम की पैकेजिंग कॉन्फ़िगर करना

उपभोक्ता के लिए बनाए गए कीप नियमों को सही तरीके से लागू करने के लिए, आपको उन्हें अपनी लाइब्रेरी के फ़ॉर्मैट के हिसाब से सही तरीके से पैकेज करना होगा.

अगर अपनी लाइब्रेरी के रिफ़्लेक्शन और जेएनआई के इस्तेमाल का एलान करने के लिए, Jetpack Keep का इस्तेमाल किया जाता है, तो इसका Gradle प्लग इन, जनरेट किए गए नियमों को उपभोक्ता के लिए बनाए रखने के नियमों के तौर पर पैकेज कर सकता है.

एएआर लाइब्रेरी

किसी एएआर लाइब्रेरी के लिए उपभोक्ता नियम जोड़ने के लिए, Android लाइब्रेरी मॉड्यूल की बिल्ड स्क्रिप्ट में consumerProguardFiles विकल्प का इस्तेमाल करें. ज़्यादा जानकारी के लिए, लाइब्रेरी मॉड्यूल बनाने के बारे में हमारे दिशा-निर्देश देखें.

Kotlin

android {
    defaultConfig {
        consumerProguardFiles("consumer-proguard-rules.pro")
    }
    ...
}

Groovy

android {
    defaultConfig {
        consumerProguardFiles 'consumer-proguard-rules.pro'
    }
    ...
}

JAR लाइब्रेरी

JAR के तौर पर शिप की जाने वाली Kotlin या Java लाइब्रेरी के साथ नियमों को बंडल करने के लिए, अपनी नियमों वाली फ़ाइल को फ़ाइनल JAR की META-INF/proguard/ डायरेक्ट्री में डालें. इसके लिए, कोई भी फ़ाइल नाम इस्तेमाल करें. उदाहरण के लिए, अगर आपका कोड <libraryroot>/src/main/kotlin में है, तो उपभोक्ता के नियमों वाली फ़ाइल को <libraryroot>/src/main/resources/META-INF/proguard/consumer-proguard-rules.pro पर डालें. इसके बाद, नियमों को आपके आउटपुट JAR में सही जगह पर बंडल कर दिया जाएगा.

पुष्टि करें कि फ़ाइनल JAR बंडल के नियम सही हैं. इसके लिए, देखें कि नियम META-INF/proguard डायरेक्ट्री में हैं या नहीं.

AAR लाइब्रेरी बिल्ड को ऑप्टिमाइज़ करना (ऐडवांस)

ध्यान दें: Android डेवलपमेंट में एक आम गलतफ़हमी यह है कि एएआर (Android Archive) या जेएआर (Java Archive) को ऑप्टिमाइज़ करने से, ऐप्लिकेशन-लेवल बिल्ड के दौरान लाइब्रेरी पैकेज को बनाए रखकर ऑप्टिमाइज़ेशन को रोका जा सकता है. हालांकि, लाइब्रेरी लेवल पर किए गए ऑप्टिमाइज़ेशन की तुलना में, ऐप्लिकेशन लेवल पर किया गया ऑप्टिमाइज़ेशन ज़्यादा असरदार होता है. ऐप्लिकेशन बिल्ड के दौरान ही, जब किसी लाइब्रेरी को ऐप्लिकेशन के हिस्से के तौर पर शामिल किया जाता है, तब R8 को पता चलता है कि लाइब्रेरी के सभी तरीकों का इस्तेमाल कैसे किया जाता है और कौनसे पैरामीटर पास किए जाते हैं.

आम तौर पर, आपको लाइब्रेरी बिल्ड को सीधे तौर पर ऑप्टिमाइज़ करने की ज़रूरत नहीं होती. ऐसा इसलिए, क्योंकि लाइब्रेरी बिल्ड के समय ऑप्टिमाइज़ेशन की संभावनाएं बहुत कम होती हैं. लाइब्रेरी डेवलपर के तौर पर, आपको ऑप्टिमाइज़ेशन के कई चरणों के बारे में सोचना होगा. साथ ही, लाइब्रेरी को ऑप्टिमाइज़ करने से पहले, लाइब्रेरी और ऐप्लिकेशन के बिल्ड टाइम, दोनों पर उसके व्यवहार को ध्यान में रखना होगा.

अगर आपको अब भी बिल्ड के समय अपनी लाइब्रेरी को ऑप्टिमाइज़ करना है, तो Android Gradle प्लगिन का इस्तेमाल करें.

Kotlin

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
        configureEach {
            consumerProguardFiles("consumer-rules.pro")
        }
    }
}

Groovy

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles
                getDefaultProguardFile('proguard-android-optimize.txt'),
                'proguard-rules.pro'
        }
        configureEach {
            consumerProguardFiles "consumer-rules.pro"
        }
    }
}

ध्यान दें कि proguardFiles का व्यवहार, consumerProguardFiles से काफ़ी अलग है:

• proguardFiles का इस्तेमाल, बिल्ड के समय किया जाता है. अक्सर, इसका इस्तेमाल getDefaultProguardFile("proguard-android-optimize.txt") के साथ किया जाता है. इससे यह तय किया जाता है कि लाइब्रेरी बिल्ड के दौरान, आपकी लाइब्रेरी का कौनसा हिस्सा सेव रखा जाना चाहिए. कम से कम, यह आपका सार्वजनिक एपीआई है.
• इसके उलट, consumerProguardFiles को लाइब्रेरी में पैकेज किया जाता है, ताकि बाद में होने वाले ऑप्टिमाइज़ेशन पर असर डाला जा सके. ऐसा आपकी लाइब्रेरी का इस्तेमाल करने वाले ऐप्लिकेशन के बिल्ड के दौरान होता है.

उदाहरण के लिए, अगर आपकी लाइब्रेरी इंटरनल क्लास बनाने के लिए रिफ़्लेक्शन का इस्तेमाल करती है, तो आपको proguardFiles और consumerProguardFiles, दोनों में कीप रूल तय करने पड़ सकते हैं.

अगर अपनी लाइब्रेरी के बिल्ड में -repackageclasses का इस्तेमाल किया जाता है, तो क्लास को अपनी लाइब्रेरी के पैकेज के अंदर सब-पैकेज में फिर से पैकेज करें. उदाहरण के लिए, -repackageclasses 'internal' के बजाय -repackageclasses 'com.example.mylibrary.internal' का इस्तेमाल करें.

R8 के अलग-अलग वर्शन के लिए सहायता (ऐडवांस)

R8 के खास वर्शन को टारगेट करने के लिए, नियमों में बदलाव किया जा सकता है. इससे आपकी लाइब्रेरी, R8 के नए वर्शन का इस्तेमाल करने वाले प्रोजेक्ट में बेहतर तरीके से काम कर पाती है. साथ ही, मौजूदा नियम R8 के पुराने वर्शन वाले प्रोजेक्ट में इस्तेमाल किए जा सकते हैं.

टारगेट किए गए R8 नियमों की जानकारी देने के लिए, आपको उन्हें एएआर के classes.jar में मौजूद META-INF/com.android.tools डायरेक्ट्री में या जेएआर की META-INF/com.android.tools डायरेक्ट्री में शामिल करना होगा.

In an AAR library:
    proguard.txt (legacy location, the file name must be "proguard.txt")
    classes.jar
    └── META-INF
        └── com.android.tools (location of targeted R8 rules)
            ├── r8-from-<X>-upto-<Y>/<R8-rule-files>
            └── ... (more directories with the same name format)

In a JAR library:
    META-INF
    ├── proguard/<ProGuard-rule-files> (legacy location)
    └── com.android.tools (location of targeted R8 rules)
        ├── r8-from-<X>-upto-<Y>/<R8-rule-files>
        └── ... (more directories with the same name format)

META-INF/com.android.tools डायरेक्ट्री में, r8-from-<X>-upto-<Y> के फ़ॉर्मैट में नाम वाली कई सबडायरेक्ट्री हो सकती हैं. इससे यह पता चलता है कि नियम, R8 के किन वर्शन के लिए लिखे गए हैं. हर सबडायरेक्ट्री में, R8 नियमों वाली एक या उससे ज़्यादा फ़ाइलें हो सकती हैं. इन फ़ाइलों के नाम और एक्सटेंशन कुछ भी हो सकते हैं.

ध्यान दें कि -from-<X> और -upto-<Y> हिस्से ज़रूरी नहीं हैं. <Y> वर्शन एक्सक्लूज़िव है. साथ ही, वर्शन की रेंज आम तौर पर लगातार होती हैं, लेकिन ओवरलैप भी हो सकती हैं.

उदाहरण के लिए, r8, r8-upto-8.0.0, r8-from-8.0.0-upto-8.2.0, और r8-from-8.2.0 डायरेक्ट्री के नाम हैं. ये R8 के नियमों के सेट को दिखाते हैं. r8 डायरेक्ट्री में मौजूद नियमों का इस्तेमाल, R8 के किसी भी वर्शन के लिए किया जा सकता है. r8-from-8.0.0-upto-8.2.0 डायरेक्ट्री में मौजूद नियमों का इस्तेमाल, R8 के 8.0.0 से लेकर 8.2.0 तक के वर्शन कर सकते हैं. हालांकि, 8.2.0 वर्शन में इन नियमों का इस्तेमाल नहीं किया जा सकता.

Android Gradle प्लगिन, उस जानकारी का इस्तेमाल करके उन सभी नियमों को चुनता है जिनका इस्तेमाल R8 के मौजूदा वर्शन में किया जा सकता है. अगर कोई लाइब्रेरी, टारगेट किए गए R8 नियमों के बारे में नहीं बताती है, तो Android Gradle प्लग इन, लेगसी जगहों (एएआर के लिए proguard.txt या जेएआर के लिए META-INF/proguard/<ProGuard-rule-files>) से नियम चुनेगा.