अपने ऐप्लिकेशन की मेमोरी मैनेज करना

इस पेज पर बताया गया है कि अपने ऐप्लिकेशन में मेमोरी के इस्तेमाल को कैसे कम किया जा सकता है. इसके बारे में जानकारी के लिए Android ऑपरेटिंग सिस्टम, मेमोरी को कैसे मैनेज करता है, देखें मेमोरी मैनेजमेंट की खास जानकारी.

रैंडम ऐक्सेस मेमोरी (रैम) किसी भी सॉफ़्टवेयर डेवलपमेंट एनवायरमेंट के लिए एक अहम संसाधन है और यह मोबाइल ऑपरेटिंग सिस्टम के लिए और भी ज़्यादा फ़ायदेमंद है, जहां अक्सर फ़िज़िकल मेमोरी सीमित होती है. हालांकि, Android रनटाइम (ART) और Delvik वर्चुअल मशीन, दोनों का रूटीन गड़बड़ है इकट्ठा नहीं करते हैं, तो इसका मतलब यह नहीं है कि आप इस बात को अनदेखा कर सकते हैं कि आपका ऐप्लिकेशन कब और कहां मेमोरी असाइन करता है और उसे रिलीज़ करता है. आपको अब भी मेमोरी लीक होने से बचना होगा—आम तौर पर, यह ऑब्जेक्ट को दबाकर रखने की वजह से होता है के रेफ़रंस हैं—और किसी भी लिंक को यहां Reference ऑब्जेक्ट हैं लाइफ़साइकल कॉलबैक के हिसाब से तय किया गया सही समय.

उपलब्ध मेमोरी और मेमोरी के इस्तेमाल को मॉनिटर करना

ऐप्लिकेशन में मेमोरी के इस्तेमाल से जुड़ी समस्याओं को ठीक करने से पहले, आपको उनका पता लगाना होगा. Android Studio में मौजूद मेमोरी प्रोफ़ाइलर की मदद से, मेमोरी से जुड़ी समस्याओं का पता लगाया जा सकता है और उनका विश्लेषण किया जा सकता है. इसके लिए, ये तरीके अपनाएं:

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

इवेंट के जवाब में मेमोरी रिलीज़ करना

ज़रूरी टास्क के लिए रैम खाली करने के लिए, Android आपके ऐप्लिकेशन से रैम वापस ले सकता है या ज़रूरत पड़ने पर आपके ऐप्लिकेशन को पूरी तरह से बंद कर सकता है. इस बारे में रैम मैनेजमेंट की खास जानकारी में बताया गया है. सिस्टम मेमोरी को संतुलित रखने और सिस्टम को आपके ऐप्लिकेशन की प्रोसेस को रोकने से बचाने के लिए, अपनी Activity क्लास में ComponentCallbacks2 इंटरफ़ेस लागू किया जा सकता है. दिया गया onTrimMemory() अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है कॉलबैक मैथड आपके ऐप्लिकेशन को ऐसे लाइफ़साइकल या मेमोरी से जुड़े इवेंट की सूचना देता है जो को अपनी मर्ज़ी से मेमोरी के इस्तेमाल को कम करने का मौका मिल सकता है. मेमोरी खाली करने से, कम मेमोरी वाले ऐप्लिकेशन को बंद करने की सुविधा से आपके ऐप्लिकेशन के बंद होने की संभावना कम हो सकती है.

मेमोरी से जुड़े अलग-अलग इवेंट के जवाब देने के लिए, onTrimMemory() कॉलबैक लागू किया जा सकता है. इसका उदाहरण यहां दिया गया है:

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    // Other activity code.

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

import android.content.ComponentCallbacks2;
// Other import statements.

public class MainActivity extends AppCompatActivity
    implements ComponentCallbacks2 {

    // Other activity code.

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    public void onTrimMemory(int level) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

देखें कि आपको कितनी मेमोरी चाहिए

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

मेमोरी खत्म होने से बचने के लिए, सिस्टम से क्वेरी करके यह पता लगाया जा सकता है कि मौजूदा डिवाइस पर कितना हेप स्टोरेज उपलब्ध है. इस आंकड़े के लिए सिस्टम से क्वेरी करने के लिए, getMemoryInfo() को कॉल करें. इससे ActivityManager.MemoryInfo अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है वह ऑब्जेक्ट जो डिवाइस की मौजूदा मेमोरी की स्थिति के बारे में जानकारी देता हो. इसमें, उपलब्ध स्टोरेज की स्थिति भी शामिल है मेमोरी, कुल मेमोरी, और मेमोरी का थ्रेशोल्ड—मेमोरी का वह लेवल जिससे सिस्टम शुरू होता है प्रक्रियाओं को रोक देता है. ActivityManager.MemoryInfo ऑब्जेक्ट भी दिखाता है lowMemory, यह एक सिंपल बूलियन है, जिससे आपको पता चलता है कि डिवाइस की मेमोरी कम है या नहीं.

यहां दिए गए कोड स्निपेट में, अपने ऐप्लिकेशन में getMemoryInfo() तरीके का इस्तेमाल करने का तरीका बताया गया है.

fun doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check whether the device is in a low memory state.
    if (!getAvailableMemory().lowMemory) {
        // Do memory intensive work.
    }
}

// Get a MemoryInfo object for the device's current memory status.
private fun getAvailableMemory(): ActivityManager.MemoryInfo {
    val activityManager = getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
    return ActivityManager.MemoryInfo().also { memoryInfo ->
        activityManager.getMemoryInfo(memoryInfo)
    }
}

public void doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check whether the device is in a low memory state.
    ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();

    if (!memoryInfo.lowMemory) {
        // Do memory intensive work.
    }
}

// Get a MemoryInfo object for the device's current memory status.
private ActivityManager.MemoryInfo getAvailableMemory() {
    ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
    ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
    activityManager.getMemoryInfo(memoryInfo);
    return memoryInfo;
}

ज़्यादा मेमोरी-इफ़िशिएंट कोड कंस्ट्रक्ट का इस्तेमाल करना

Android की कुछ सुविधाएं, Java क्लास, और कोड कंस्ट्रक्ट, अन्य सुविधाओं की तुलना में ज़्यादा मेमोरी का इस्तेमाल करते हैं. अपने कोड में ज़्यादा असरदार विकल्प चुनकर, यह तय किया जा सकता है कि आपका ऐप्लिकेशन कितनी मेमोरी का इस्तेमाल करे.

सेवाओं का कम इस्तेमाल करना

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

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

आम तौर पर, हमेशा चालू रहने वाली सेवाओं का इस्तेमाल करने से बचें. ऐसा इसलिए, क्योंकि ये सेवाएं डिवाइस की उपलब्ध स्मृति पर लगातार दबाव डालती रहती हैं. इसके बजाय, हमारा सुझाव है कि आप लागू करने के किसी दूसरे तरीके का इस्तेमाल करें, जैसे कि WorkManager. बैकग्राउंड प्रोसेस को शेड्यूल करने के लिए, WorkManager का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, लगातार काम करने की सुविधा देखें.

ऑप्टिमाइज़ किए गए डेटा कंटेनर का इस्तेमाल करना

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

Android फ़्रेमवर्क में, ऑप्टिमाइज़ किए गए कई डेटा कंटेनर शामिल हैं. इनमें ये शामिल हैं SparseArray, SparseBooleanArray, और LongSparseArray. उदाहरण के लिए, SparseArray क्लास ज़्यादा असरदार होती हैं, क्योंकि इनकी मदद से, सिस्टम को अपने-आप बॉक्स में बने हुए पासकोड और कभी-कभी वैल्यू को मैन्युअल तरीके से बॉक्स में डालने की ज़रूरत नहीं पड़ती. इससे हर एंट्री के लिए एक या दो और ऑब्जेक्ट बन जाते हैं.

अगर ज़रूरी हो, तो बेहतर डेटा स्ट्रक्चर के लिए, हमेशा रॉ कलेक्शन का इस्तेमाल किया जा सकता है.

कोड के एब्स्ट्रैक्शन से सावधान रहें

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

सीरियलाइज़ किए गए डेटा के लिए, लाइट प्रोटोबस का इस्तेमाल करना

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

ज़्यादा जानकारी के लिए, protobuf के readme देखें.

मेमोरी चर्न (मेमोरी का तेज़ी से कम होना) से बचना

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

आम तौर पर, मेमोरी चर्न आउट की वजह से, कचरा इकट्ठा करने की कई घटनाएं हो सकती हैं. तय सीमा में मेमोरी चर्न आउट से यह पता चलता है कि किसी डेटा में समय की जानकारी देते हैं.

उदाहरण के लिए, for लूप में कई अस्थायी ऑब्जेक्ट असाइन किए जा सकते हैं. या नया Paint बनाया जा सकता है या Bitmap ऑब्जेक्ट के अंदर onDraw() किसी व्यू का फ़ंक्शन. दोनों ही मामलों में, ऐप्लिकेशन तेज़ी से बहुत ज़्यादा ऑब्जेक्ट बनाता है. ये, नई जनरेशन में मौजूद सभी मेमोरी को तुरंत खर्च कर सकते हैं. इससे, ग़ैर-ज़रूरी डेटा हटाने की प्रोसेस शुरू हो जाती है.

मेमोरी प्रोफ़ाइलर का इस्तेमाल करके, अपने कोड में उन जगहों का पता लगाएं जहां मेमोरी का इस्तेमाल ज़्यादा हो रहा है. इसके बाद, उन्हें ठीक करें.

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

यह भी आकलन किया जा सकता है कि ऑब्जेक्ट पूल से इस्तेमाल के उदाहरण को फ़ायदा हो रहा है या नहीं. इसके बजाय, किसी ऑब्जेक्ट पूल के साथ किसी ऑब्जेक्ट को फ़र्श पर लाकर, ज़रूरत न होने पर उसे पूल में छोड़ दें. अगली बार जब उस तरह के किसी ऑब्जेक्ट इंस्टेंस की ज़रूरत पड़े, तो उसे पूल से हासिल किया जा सकता है असाइन करने के बजाय.

परफ़ॉर्मेंस का पूरी तरह से आकलन करके यह तय करें कि किसी खास स्थिति में ऑब्जेक्ट पूल सही है या नहीं. कुछ मामलों में, ऑब्जेक्ट पूल की वजह से परफ़ॉर्मेंस खराब हो सकती है. हालांकि पूल से बचने के लिए भी कहा जाता है आवंटन के बाद ही, अन्य ओवरहेड लगा दिए जाते हैं. उदाहरण के लिए, पूल के रखरखाव में आम तौर पर सिंक करना, जिसका ओवरहेड न के बराबर होता है. साथ ही, पूल किए गए ऑब्जेक्ट इंस्टेंस को रिलीज़ के दौरान मेमोरी लीक होने से बचाते हैं. इसके बाद, उपयोगकर्ता हासिल करने के दौरान इसे शुरू करने के लिए, शून्य के अलावा कोई अन्य वैल्यू दी जा सकती है ओवरहेड.

पूल में ज़रूरत से ज़्यादा ऑब्जेक्ट को दबाकर रखने से भी कचरे का बोझ कम होता है संग्रह. ऑब्जेक्ट पूल, गै़रबेज कलेक्शन के अनुरोधों की संख्या को कम करते हैं. हालांकि, इनसे हर अनुरोध के लिए ज़रूरी काम की संख्या बढ़ जाती है, क्योंकि यह काम, ऐक्टिव (पहुंचने लायक) बाइट की संख्या के हिसाब से होता है.

ज़्यादा मेमोरी लेने वाले रिसॉर्स और लाइब्रेरी हटाना

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

APK का कुल साइज़ कम करें

अपने ऐप्लिकेशन के कुल साइज़ को कम करके, उसके स्टोरेज के इस्तेमाल को काफ़ी हद तक कम किया जा सकता है. बिटमैप का साइज़, संसाधन, ऐनिमेशन फ़्रेम, और तीसरे पक्ष की लाइब्रेरी, तीन सबसे सही तरीक़े यहाँ दिए गए हैं. Android Studio और Android SDK टूल की मदद से, कई टूल मिलते हैं. इनकी मदद से, एआर की मदद से और बाहरी डिपेंडेंसी के हिसाब से अपने संसाधन और अन्य संसाधन हासिल करें. ये टूल, कोड को छोटा करने के आधुनिक तरीकों के साथ काम करते हैं. जैसे, R8 कंपाइलेशन.

अपने ऐप्लिकेशन के कुल साइज़ को कम करने के बारे में ज़्यादा जानने के लिए, अपने ऐप्लिकेशन का साइज़ कम करना लेख पढ़ें.

डिपेंडेंसी इंजेक्शन के लिए Hilt या Dagger 2 का इस्तेमाल करें

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

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

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

बाहरी लाइब्रेरी का इस्तेमाल करते समय सावधानी बरतें

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

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

ProGuard, सही फ़्लैग की मदद से एपीआई और संसाधनों को हटाने में मदद कर सकता है. हालांकि, यह लाइब्रेरी की बड़ी इंटरनल डिपेंडेंसी को नहीं हटा सकता. इन लाइब्रेरी में आपको जो सुविधाएं चाहिए उनके लिए, हो सकता है कि आपको कम लेवल की डिपेंडेंसी की ज़रूरत पड़े. इससे खास तौर पर तब समस्या आ सकती है, जब Activity सब-क्लास का इस्तेमाल करें लाइब्रेरी—जिसमें कई डिपेंडेंसी हो सकती हैं—जब लाइब्रेरी प्रतिबिंब का इस्तेमाल करती हैं, सामान्य है और इसे काम करने के लिए ProGuard को मैन्युअल रूप से ट्विस्ट करने की आवश्यकता होती है.

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