नियम के अन्य टाइप

R8, आपको ऐसे नियम जोड़ने की सुविधा देता है जिनसे आपके ऐप्लिकेशन के ऑप्टिमाइज़ेशन पर असर पड़ता है. हालांकि, इसमें कीप नियमों को शामिल नहीं किया जाता. इन नियमों को उसी proguard-rules.pro फ़ाइल में जोड़ें जिसमें कीप के नियम सेव किए जाते हैं.

इन नियमों को इन कैटगरी में बांटा गया है:

अनुमान
- -assumevalues
- -assumenosideeffects
अन्य ऑप्टिमाइज़ेशन
- -convertchecknotnull
- -maximumremovedandroidloglevel

अनुमान

इन नियमों से R8 को पता चलता है कि रनटाइम के दौरान, वह किसी खास कोड के बारे में कुछ अनुमान लगा सकता है.

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

`-assumevalues`

-assumevalues नियम, R8 को बताता है कि किसी फ़ील्ड की वैल्यू या किसी तरीके की रिटर्न वैल्यू, रनटाइम के दौरान हमेशा कोई खास कॉन्स्टेंट होती है या तय की गई रेंज में आती है. -assumevalues का इस्तेमाल फ़्लैग वैल्यू जैसी चीज़ों के लिए किया जाता है. बिल्ड टाइम में, रनटाइम के दौरान इनकी वैल्यू तय होती है.

R8 का स्टैंडर्ड स्टैटिक विश्लेषण, सदस्यों की रनटाइम वैल्यू का पता नहीं लगा सकता. -assumevalues की मदद से, R8 को यह बताया जाता है कि कोड को ऑप्टिमाइज़ करते समय, बताई गई वैल्यू या रेंज को मान लिया जाए. इससे R8 को बेहतर तरीके से ऑप्टिमाइज़ेशन करने में मदद मिलती है.

-assumevalues का सिंटैक्स, member_specification को बनाए रखने के सिंटैक्स जैसा ही होता है. हालांकि, इसमें return clause भी शामिल होता है. यह इस तरह होता है:

<member_specification> return <value> | <range>

<value> और <range> आर्ग्युमेंट के लिए, यहां दी गई वैल्यू और टाइप इस्तेमाल किए जा सकते हैं:

खास वैल्यू: true, false, null, @NonNull
प्रिमिटिव वैल्यू: int
स्ट्रिंग कॉन्स्टेंट
स्टैटिक फ़ील्ड रेफ़रंस (इसमें enum फ़ील्ड भी शामिल हैं)

किसी रेंज को तय करने के लिए, min..max फ़ॉर्मैट का इस्तेमाल करें. उदाहरण के लिए, यहां दिए गए स्निपेट से पता चलता है कि वैरिएबल CUSTOM_VAL, 26 से 2147483647 तक की वैल्यू स्वीकार करता है:

-assumevalues public class com.example.Foo {
    public static int CUSTOM_VAL return 26..2147483647;
}

इस नियम का इस्तेमाल इन स्थितियों में किया जा सकता है:

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

यहां दिए गए उदाहरण में, एक ऐसी क्लास दिखाई गई है जिसमें R8, ऐप्लिकेशन के ऑप्टिमाइज़ किए गए वर्शन से डीबग टूल हटाता है:

package com.example;

public class MyConfig {
    // This field is initialized to false but is overwritten by a resource
    // value or other mechanism in the final build process. R8's static analysis
    // might see the initial 'false' but the runtime value is known to be
    // 'true'.
    public static final boolean IS_OPTIMIZED_VERSION = false;
}

// In another class:
public void initFeatures() {
    if (MyConfig.IS_OPTIMIZED_VERSION) {
        System.out.println("Starting optimized features...");
        android.util.Log.d(TAG, "Starting optimized features...");
        initOptimizedService();
    } else {
        android.util.Log.d(TAG, "Starting debug/logging features...");
        initDebugTools();
    }
}

यहां दिए गए नियम से पता चलता है कि R8 को यह कैसे बताया जाए कि वैरिएबल IS_OPTIMIZED_VERSION को हमेशा true पर सेट किया जाना चाहिए.

-assumevalues class com.example.MyConfig {
    public static final boolean IS_OPTIMIZED_VERSION return true;
}

`-assumenosideeffects`

-assumenosideeffects नियम, R8 को बताता है कि वह यह मान सकता है कि बताए गए सदस्यों पर कोई खराब असर नहीं पड़ता. R8, ऐसे तरीकों के कॉल को पूरी तरह से हटा सकता है जिनकी कोई रिटर्न वैल्यू नहीं होती या जो एक तय वैल्यू देते हैं.

-assumenosideeffects का सिंटैक्स, member_specification को बनाए रखने के सिंटैक्स से मिलता-जुलता है.

यहां दिए गए सैंपल में बताया गया है कि R8 को यह कैसे बताया जाए कि DebugLogger क्लास में log नाम वाले सभी public static तरीकों का कोई साइड इफ़ेक्ट नहीं होना चाहिए. इससे R8 को इन तरीकों के कॉल हटाने की अनुमति मिलती है.

-assumenosideeffects class com.example.DebugLogger {
    public static void log(...);
}

अन्य ऑप्टिमाइज़ेशन

ये कुछ और बेहतर ऑप्टिमाइज़ेशन हैं, जो डिफ़ॉल्ट रूप से चालू नहीं होते. इन्हें चालू करने पर, R8 को डिफ़ॉल्ट ऑप्टिमाइज़ेशन के साथ-साथ, निर्देश के मुताबिक कोड को ऑप्टिमाइज़ करने की अनुमति मिलती है.

`-convertchecknotnull`

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

अगर कोई -convertchecknotnull नियम किसी दिए गए तरीके से मेल खाता है, तो उस तरीके के हर कॉल को पहले आर्ग्युमेंट पर getClass() के कॉल से बदल दिया जाता है. getClass() को कॉल करने से, शून्य की जांच करने की सुविधा मिलती है. साथ ही, R8 को शून्य की जांच करने वाले ओरिजनल फ़ंक्शन के किसी भी अतिरिक्त आर्ग्युमेंट को हटाने की अनुमति मिलती है. जैसे, स्ट्रिंग के लिए मेमोरी का महंगा असाइनमेंट.

-convertchecknotnull का सिंटैक्स इस तरह होता है:

-convertchecknotnull <class_specification> {
   <member_specification>;
}

उदाहरण के लिए, अगर आपके पास Preconditions क्लास है और उसमें checkNotNull तरीका इस तरह है:

class Preconditions {
    fun <T> checkNotNull(value: T?): T {
        if (value == null) {
            throw NullPointerException()
        } else {
            return value
        }
    }
}

इस नियम का इस्तेमाल करें:

-convertchecknotnull class com.example.package.Preconditions {
  void checkNotNull(java.lang.Object);
}

यह नियम, checkNotNull() को किए गए सभी कॉल को पहले आर्ग्युमेंट में दिए गए getClass को किए गए कॉल में बदल देता है. इस उदाहरण में, checkNotNull(bar) को bar.getClass() से बदल दिया गया है. अगर bar null होता, तो bar.getClass() NullPointerException दिखाता. इससे, शून्य की जांच करने का वही असर मिलता, लेकिन ज़्यादा असरदार तरीके से.

`-maximumremovedandroidloglevel`

इस तरह के नियम से, Android के लॉगिंग स्टेटमेंट (जैसे कि Log.w(...) और Log.isLoggable(...)) को किसी लॉग लेवल पर या उससे नीचे हटा दिया जाता है.

maximumremovedandroidloglevel का सिंटैक्स इस तरह होता है:

-maximumremovedandroidloglevel <log_level> [<class_specification>]

अगर आपने class_specification का इस्तेमाल नहीं किया है, तो R8 पूरे ऐप्लिकेशन से लॉग हटाने की सुविधा लागू करता है.

लॉग लेवल ये हैं:

लॉग लेबल	लॉग लेवल
ज़्यादा जानकारी देने वाला	2
डीबग करें	3
जानकारी	4
चेतावनी	5
गड़बड़ी	6
ASSERT	7

उदाहरण के लिए, अगर आपके पास यह कोड है:

class Foo {
  private static final String TAG = "Foo";
  void logSomething() {
    if (Log.isLoggable(TAG, WARNING)) {
      Log.e(TAG, "Won't be logged");
    }
    Log.w(TAG, "Won't be logged");
    Log.e(TAG, "Will be logged");
  }
}

इस नियम के साथ:

# A level of 5 corresponds to a log level of WARNING.
-maximumremovedandroidloglevel 5 class Foo { void logSomething(); }

ऑप्टिमाइज़ किया गया कोड यहां दिया गया है:

class Foo {
  private static final String TAG = "Foo";
  void logSomething() {
    Log.e(TAG, "Will be logged");
  }
}

अगर एक ही तरीके के लिए, ज़्यादा से ज़्यादा लॉग लेवल दिए जाते हैं, तो R8 सबसे कम लेवल का इस्तेमाल करता है. उदाहरण के लिए, यहां दिए गए नियमों के हिसाब से:

-maximumremovedandroidloglevel 7 class ** { void foo(); }
-maximumremovedandroidloglevel 4 class ** { void foo(); }

इसलिए, foo() के लिए हटाए गए लॉग लेवल की ज़्यादा से ज़्यादा वैल्यू 4 है.