सामान्य कीप रूल, कीप रूल के अन्य टाइप, और ग्लोबल विकल्पों के अलावा, ऑप्टिमाइज़ेशन से जुड़ी समस्याओं को हल करने के लिए कुछ नियमों का इस्तेमाल किया जा सकता है.
-checkdiscard
-checkdiscard नियम की मदद से, यह पता लगाया जा सकता है कि R8 ने उस क्लास या उसके सदस्य को हटाया है या नहीं जिसे आपको हटाना था. अगर बताई गई क्लास या मेंबर को नहीं हटाया जाता है, तो बिल्ड नहीं हो पाएगा.
-checkdiscard का सिंटैक्स इस तरह होता है:
-checkdiscard <class_specification>
यहां दिए गए उदाहरण में, अगर com.example.models.User क्लास से userId फ़ील्ड या setLabel() मेथड को बनाए रखा जाता है, तो बिल्ड पूरा नहीं होगा:
-checkdiscard class com.example.models.User{
private java.lang.String userId;
public void setLabel(java.lang.String);
}
अगर क्लास के तरीकों को अन्य क्लास में इनलाइन किया गया था, तो क्लास का कोड अब भी ऐप्लिकेशन में मौजूद हो सकता है. यह पक्का करने के लिए कि कोड पूरी तरह से हटा दिया गया है और सिर्फ़ इनलाइन नहीं किया गया है, इससे जुड़ा एक ऐसा नियम जोड़ें जो R8 को टारगेट क्लास पर ऑप्टिमाइज़ेशन करने से रोकता हो. इसके लिए, -checkdiscard को -keep,allowshrinking नियम के साथ मिलाएं. इससे क्लास मर्जिंग और इनलाइनिंग जैसे ऑप्टिमाइज़ेशन नहीं किए जा सकते. अगर -checkdiscard नियम लागू होता है, तो मैच की गई क्लास का कोई भी कॉन्टेंट, ऑप्टिमाइज़ किए गए ऐप्लिकेशन में नहीं होता है.
यहां दिए गए उदाहरण में, इस सुविधा के इस्तेमाल के बारे में बताया गया है:
# Either keep or remove the class, don't rename or otherwise optimize it
-keep,allowshrinking class com.example.foo { *; }
# Verify that the class and all of its fields and methods are removed.
-checkdiscard class com.example.foo
-whyareyoukeeping
-whyareyoukeeping नियम का इस्तेमाल करके, यह पता लगाएं कि R8 ने आपके ऐप्लिकेशन की बिल्ड में किसी क्लास, फ़ील्ड या तरीके को क्यों रखा है. किसी आइटम को कई वजहों से सेव करके रखा जा सकता है.
हालांकि, यह नियम सिर्फ़ उस वजह के बारे में बताता है जिसकी वजह से सेव किए गए आइटम से
कम से कम समय में आइटम को ऐक्सेस किया जा सकता है. अपने कोड से इस पाथ को हटाने पर, आपको आइटम अब भी दिख सकता है. हालांकि, इसकी वजह अलग होगी.
इसकी ये वजहें हो सकती हैं:
डेटा को सुरक्षित रखने से जुड़ा नियम: यह नियम, ऐप्लिकेशन, इस्तेमाल की गई लाइब्रेरी या AAPT (Android ऐप्लिकेशन पैकेजिंग टूल) से जनरेट किए गए नियमों से लिया जा सकता है.
रखे गए कोड या संसाधनों से ट्रांज़िटिव रेफ़रंस: अगर R8, कोड या एक्सएमएल (जैसे कि लेआउट) को बनाए रखता है, तो यह स्टैटिक तौर पर जिस भी चीज़ को रेफ़रंस करता है उसे बनाए रखा जाता है.
इसका सिंटैक्स यह है:
-whyareyoukeeping <class_specification>
उदाहरण के लिए:
-whyareyoukeeping class com.example.foo.MainActivity {
private void setLabel(...);
}
आउटपुट को कंसोल पर प्रिंट किया जाता है.
अगर आपके पास setLabel() को बनाए रखने का कोई नियम नहीं है, तो आउटपुट यह होगा:
com.example.foo.MainActivity
|- is referenced in keep rule:
| /app/build/intermediates/aapt_proguard_file/release/processReleaseResources/aapt_rules.txt:4:1
Nothing is keeping void com.example.foo.MainActivity.setLabel()
अगर आपके पास setLabel() को टारगेट करने वाला कीप रूल है, तो आउटपुट यहां दिए गए उदाहरण जैसा होगा:
com.example.foo.MainActivity
|- is referenced in keep rule:
| /app/proguard-rules.pro:23:1
void com.example.foo.MainActivity.setLabel()
|- is referenced in keep rule:
| /app/proguard-rules.pro:23:1