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

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

कीप के नियमों में अच्छे पैटर्न

डेटा को सुरक्षित रखने के लिए बनाए गए नियमों में सटीक जानकारी होनी चाहिए:

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

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

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

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

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

  उदाहरण के लिए, androidx.annotation जैसी लाइब्रेरी इस पैटर्न का इस्तेमाल करती हैं:

  // In your source code
  @Keep
  class MyDataClass { /* ... */ }
  
  // In your R8 rules
  -keep @androidx.annotation.DisplayComponent class * {*;}
  

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

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

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

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

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

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

ऐसा करने से बचें

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

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

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