सबसे सही तरीकों का पालन करना

कीप रूल का इस्तेमाल करते समय, यह ज़रूरी है कि आप सही मात्रा में खास जानकारी दें. इससे यह पक्का किया जा सकेगा कि आपको फ़ायदे मिलें और आपके ऐप्लिकेशन का व्यवहार बना रहे. कीप रूल में अच्छे पैटर्न के साथ-साथ, किन चीज़ों से बचना चाहिए, यह जानने के लिए यहां दिए गए सेक्शन देखें.

कीप रूल में अच्छे पैटर्न

अच्छी तरह से तय किए गए कीप रूल, ज़्यादा से ज़्यादा खास जानकारी देते हैं. साथ ही, ये इन पैटर्न के मुताबिक होते हैं:

• क्लास स्पेसिफ़िकेशन के लिए, हमेशा कोई खास क्लास, बेस क्लास या एनोटेट की गई क्लास तय करें. हालांकि, ऐसा तब करें, जब यह मुमकिन हो. इसके लिए, यहां दिए गए उदाहरण देखें:

  -keepclassmembers class com.example.MyClass {
    void someSpecificMethod();
  }
  

  -keepclassmembers ** extends com.example.MyBaseClass {
    void someSpecificMethod();
  }
  

  -keepclassmembers @com.example.MyAnnotation class ** {
    void someSpecificMethod();
  }
  

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

  उदाहरण के लिए, यहां दिए गए स्निपेट से पता चलता है कि MyClass के साथ-साथ, @com.example.DisplayComponent से एनोटेट की गई अन्य क्लास को कैसे सुरक्षित रखा जा सकता है:

  // In the source code
  @com.example.DisplayComponent
  class MyClass { /* ... */ }
  
  // In the keep rules
  -keep @com.example.DisplayComponent class * {*;}
  

  हमारा सुझाव है कि एनोटेशन के ऐसे नाम रखें जिनसे यह पता चले कि कोड के किन हिस्सों को सुरक्षित रखा गया है. उदाहरण के लिए, ऐसे ऐप्लिकेशन के लिए @DisplayComponent का इस्तेमाल करें जिसमें डिसप्ले कॉम्पोनेंट के कुछ हिस्सों को सुरक्षित रखना ज़रूरी है.

• जब भी मुमकिन हो, मेंबर स्पेसिफ़िकेशन को तय किया जाना चाहिए. साथ ही, इसमें क्लास के सिर्फ़ उन हिस्सों का रेफ़रंस होना चाहिए जिन्हें ऐप्लिकेशन के काम करने के लिए सुरक्षित रखना ज़रूरी है. हमारा सुझाव है कि किसी पूरी क्लास पर कोई नियम लागू न करें. इसके लिए, सदस्य के स्कोप को { *; } के तौर पर तय न करें. हालांकि, ऐसा तब करें, जब इसकी सख्त ज़रूरत हो.

  -keepclassmembers com.example.MyClass {
    void someSpecificMethod();
    void @com.example.MyAnnotation *;
  }
  

• repackageclasses ग्लोबल विकल्प का इस्तेमाल करने पर, पैकेज का नाम तय न करें. हालांकि, यह ज़रूरी नहीं है. इससे DEX फ़ाइलें छोटी होती हैं, क्योंकि रीपैकेज की गई क्लास के नामों में पैकेज का प्रीफ़िक्स शामिल नहीं होता.

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

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

• जहां तक हो सके, नल की जांच को ऑप्टिमाइज़ करने के लिए -assumenosideeffects या -convertchecknotnull का इस्तेमाल करें. ऐसा इसलिए, क्योंकि इससे आपके ऐप्लिकेशन के DEX का साइज़ काफ़ी कम हो सकता है. ज़्यादा जानकारी के लिए, नियमों के अन्य टाइप देखें.

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

-keepclassmembers class com.example.pkg.** { *; }

इनसे बचें

कीप रूल के सिंटैक्स में कई विकल्प होते हैं. हालांकि, हम आपको मेज़र की जा सकने वाली और लंबे समय तक चलने वाली परफ़ॉर्मेंस के फ़ायदों के लिए, इनका इस्तेमाल न करने का सुझाव देते हैं:

• लंबे समय तक, पूरे पैकेज के लिए कीप रूल का इस्तेमाल न करें. जैसे, -keep class com.example.pkg.** { *; }. R8 को कॉन्फ़िगर करते समय आने वाली समस्याओं से बचने के लिए, इनका इस्तेमाल कुछ समय के लिए किया जा सकता है. ज़्यादा जानकारी के लिए, ऑप्टिमाइज़ेशन के स्कोप को सीमित करना लेख देखें. आम तौर पर, वाइल्डकार्ड का इस्तेमाल करते समय सावधानी बरतें. पक्का करें कि आपने सिर्फ़ उस कोड को सुरक्षित रखा है जिसकी आपको ज़रूरत है.
• जब भी मुमकिन हो, ऐसी लाइब्रेरी से बचें जिनमें कीप रूल को कॉपी और पेस्ट करने का सुझाव दिया जाता है. खास तौर पर, पूरे पैकेज के लिए कीप रूल का इस्तेमाल करते समय. Android पर अच्छी परफ़ॉर्मेंस देने के लिए डिज़ाइन की गई लाइब्रेरी को, जहां तक हो सके, रिफ़्लेक्शन से बचना चाहिए. साथ ही, ज़रूरत पड़ने पर उपभोक्ता के डेटा को सुरक्षित रखने से जुड़े कीप रूल को एम्बेड करना चाहिए.
• कीप रूल में, इनवर्ज़न ऑपरेटर ! का इस्तेमाल करने से बचें. ऐसा इसलिए, क्योंकि इससे आपके ऐप्लिकेशन की करीब हर क्लास पर अनजाने में कोई नियम लागू हो सकता है.

अगर इन नियमों का पालन नहीं किया जा सकता, तो हो सकता है कि आपके ऐप्लिकेशन में, ओपन-एंडेड रिफ़्लेक्शन का ज़्यादा इस्तेमाल किया जा रहा हो. ऐसे में, आपको या तो रिफ़्लेक्शन से बचना चाहिए या रिफ़्लेक्शन का इस्तेमाल करने वाली लाइब्रेरी से बचना चाहिए. इसके लिए, Gson का केस स्टडी देखें.