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

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

डेटा बनाए रखने के नियमों में अच्छे पैटर्न

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

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

  -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 इन आइटम को बनाए नहीं रख पाएगा.

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

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

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

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

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

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