इस पेज पर बताया गया है कि अपने ऐप्लिकेशन में मेमोरी के इस्तेमाल को कैसे कम किया जा सकता है. इसके बारे में जानकारी के लिए Android ऑपरेटिंग सिस्टम, मेमोरी को कैसे मैनेज करता है, देखें मेमोरी मैनेजमेंट की खास जानकारी.
रैंडम ऐक्सेस मेमोरी (रैम) किसी भी सॉफ़्टवेयर डेवलपमेंट एनवायरमेंट के लिए एक अहम संसाधन है और
यह मोबाइल ऑपरेटिंग सिस्टम के लिए और भी ज़्यादा फ़ायदेमंद है, जहां अक्सर फ़िज़िकल मेमोरी सीमित होती है.
हालांकि, Android रनटाइम (ART) और Delvik वर्चुअल मशीन, दोनों का रूटीन गड़बड़ है
इकट्ठा नहीं करते हैं, तो इसका मतलब यह नहीं है कि आप इस बात को अनदेखा कर सकते हैं कि आपका ऐप्लिकेशन कब और कहां मेमोरी असाइन करता है और उसे रिलीज़ करता है.
आपको अब भी मेमोरी लीक होने से बचना होगा—आम तौर पर, यह ऑब्जेक्ट को दबाकर रखने की वजह से होता है
रेफ़रंस के लिए, स्टैटिक मेंबर वैरिएबल का इस्तेमाल करें—और अपने
यहां Reference ऑब्जेक्ट हैं
लाइफ़साइकल कॉलबैक के हिसाब से तय किया गया सही समय.
उपलब्ध मेमोरी और मेमोरी के इस्तेमाल को मॉनिटर करना
ऐप्लिकेशन की मेमोरी के इस्तेमाल से जुड़ी समस्याओं को ठीक करने से पहले, आपको उनकी जांच करनी होगी. कॉन्टेंट बनाने Android Studio में मौजूद मेमोरी प्रोफ़ाइलर की मदद से, और निम्न तरीकों से मेमोरी समस्याओं का निदान करें:
- देखें कि समय के साथ आपका ऐप्लिकेशन किस तरह से मेमोरी बांटता है. मेमोरी प्रोफ़ाइलर एक रीयलटाइम ग्राफ़ दिखाता है, जिसमें यह दिखाया जाता है कि आपका ऐप्लिकेशन कितनी मेमोरी का इस्तेमाल कर रहा है, तय किए गए Java ऑब्जेक्ट की संख्या, और कचरा इकट्ठा करने का समय होता है.
- अपने ऐप्लिकेशन के दौरान, कचरा इकट्ठा करने वाले इवेंट शुरू करें और Java हीप का स्नैपशॉट लें दौड़ता है.
- अपने ऐप्लिकेशन के लिए असाइन की गई मेमोरी को रिकॉर्ड करें, असाइन किए गए सभी ऑब्जेक्ट की जांच करें, और इनके लिए स्टैक ट्रेस देखें हर ऐलोकेशन के विकल्प को चुनें और Android Studio एडिटर में उनसे जुड़े कोड पर जाएं.
इवेंट के जवाब में, 'यादें' रिलीज़ करना
मेमोरी खाली करने के लिए, Android आपके ऐप्लिकेशन से मेमोरी पर फिर से दावा कर सकता है या आपके ऐप्लिकेशन को पूरी तरह से बंद कर सकता है
के बारे में ज़्यादा जानें, जैसा कि
मेमोरी मैनेजमेंट की खास जानकारी. ज़्यादा मदद पाने के लिए
सिस्टम की मेमोरी संतुलित रखने और सिस्टम को आपके ऐप्लिकेशन की प्रोसेस रोकने की ज़रूरत से बचने के लिए,
यह
ComponentCallbacks2 अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
इंटरफ़ेस आपके Activity की क्लास में दिखेगा.
दिया गया
onTrimMemory() अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
कॉलबैक मैथड से आपका ऐप्लिकेशन, मेमोरी से जुड़े इवेंट सुन सकता है. ऐसा तब होगा, जब आपका ऐप्लिकेशन
बैकग्राउंड या फ़ोरग्राउंड का इस्तेमाल किया जा सकता है. इसके बाद, यह ऐप्लिकेशन के लाइफ़साइकल के रिस्पॉन्स में ऑब्जेक्ट को रिलीज़ करता है या
जो सिस्टम इवेंट से पता चलता है कि सिस्टम को मेमोरी पर फिर से दावा करने की ज़रूरत है.
onTrimMemory() कॉलबैक लागू किया जा सकता है, ताकि मेमोरी से जुड़ी अलग-अलग तरह की जानकारी का जवाब दिया जा सके
इवेंट, जैसा कि इस उदाहरण में दिखाया गया है:
Kotlin
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) { // Determine which lifecycle or system event is raised. when (level) { ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN -> { /* Release any UI objects that currently hold memory. The user interface moves to the background. */ } ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE, ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW, ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL -> { /* Release any memory your app doesn't need to run. The device is running low on memory while the app is running. The event raised indicates the severity of the memory-related event. If the event is TRIM_MEMORY_RUNNING_CRITICAL, then the system begins stopping background processes. */ } ComponentCallbacks2.TRIM_MEMORY_BACKGROUND, ComponentCallbacks2.TRIM_MEMORY_MODERATE, ComponentCallbacks2.TRIM_MEMORY_COMPLETE -> { /* Release as much memory as the process can. The app is on the LRU list and the system is running low on memory. The event raised indicates where the app sits within the LRU list. If the event is TRIM_MEMORY_COMPLETE, the process is one of the first to be terminated. */ } else -> { /* Release any non-critical data structures. The app receives an unrecognized memory level value from the system. Treat this as a generic low-memory message. */ } } } }
Java
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) { // Determine which lifecycle or system event is raised. switch (level) { case ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN: /* Release any UI objects that currently hold memory. The user interface moves to the background. */ break; case ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE: case ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW: case ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL: /* Release any memory your app doesn't need to run. The device is running low on memory while the app is running. The event raised indicates the severity of the memory-related event. If the event is TRIM_MEMORY_RUNNING_CRITICAL, then the system begins stopping background processes. */ break; case ComponentCallbacks2.TRIM_MEMORY_BACKGROUND: case ComponentCallbacks2.TRIM_MEMORY_MODERATE: case ComponentCallbacks2.TRIM_MEMORY_COMPLETE: /* Release as much memory as the process can. The app is on the LRU list and the system is running low on memory. The event raised indicates where the app sits within the LRU list. If the event is TRIM_MEMORY_COMPLETE, the process is one of the first to be terminated. */ break; default: /* Release any non-critical data structures. The app receives an unrecognized memory level value from the system. Treat this as a generic low-memory message. */ break; } } }
यह देखना कि आपको कितनी मेमोरी की ज़रूरत है
कई प्रोसेस को चलाने की अनुमति देने के लिए, Android हर प्रोसेस के लिए असाइन किए गए हीप साइज़ की एक तय सीमा सेट करता है
है. हीप के साइज़ की सटीक सीमा, अलग-अलग डिवाइसों पर अलग-अलग होती है. यह इस बात पर निर्भर करता है कि डिवाइस में कितनी रैम है
कुल मिलाकर. अगर आपका ऐप्लिकेशन, हीप की क्षमता तक पहुंच जाता है और ज़्यादा मेमोरी असाइन करने की कोशिश करता है, तो सिस्टम
OutOfMemoryError.
मेमोरी खत्म होने से बचने के लिए, सिस्टम से क्वेरी करके पता लगाया जा सकता है कि हीप स्पेस कितना है
मौजूदा डिवाइस पर उपलब्ध है. आप
getMemoryInfo().
इससे
ActivityManager.MemoryInfo अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
वह ऑब्जेक्ट जो डिवाइस की मौजूदा मेमोरी की स्थिति के बारे में जानकारी देता हो. इसमें, उपलब्ध स्टोरेज की स्थिति भी शामिल है
मेमोरी, कुल मेमोरी, और मेमोरी का थ्रेशोल्ड—मेमोरी का वह लेवल जिससे सिस्टम शुरू होता है
प्रक्रियाओं को रोक देता है. ActivityManager.MemoryInfo ऑब्जेक्ट भी दिखाता है
lowMemory,
यह एक सिंपल बूलियन है, जिससे आपको पता चलता है कि डिवाइस की मेमोरी कम है या नहीं.
कोड स्निपेट के इस उदाहरण में, getMemoryInfo() तरीके को इस्तेमाल करने का तरीका बताया गया है
आपका ऐप्लिकेशन.
Kotlin
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) } }
Java
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. Reader Revenue Manager को सेट अप करने के बारे में
बैकग्राउंड में होने वाली प्रोसेस को शेड्यूल करने के लिए, WorkManager का इस्तेमाल करने का तरीका जानने के लिए, यहां देखें
लगातार काम.
ऑप्टिमाइज़ किए गए डेटा कंटेनर का इस्तेमाल करें
प्रोग्रामिंग भाषा से मिलने वाली कुछ क्लास को मोबाइल पर इस्तेमाल करने के लिए ऑप्टिमाइज़ नहीं किया गया है
डिवाइस. उदाहरण के लिए, जेनरिक
HashMap लागू करने की प्रक्रिया में मेमोरी हो सकती है
में इस्तेमाल नहीं कर सकते, क्योंकि इसे हर मैपिंग के लिए एक अलग एंट्री ऑब्जेक्ट की ज़रूरत होती है.
Android फ़्रेमवर्क में, ऑप्टिमाइज़ किए गए कई डेटा कंटेनर शामिल हैं. इनमें ये शामिल हैं
SparseArray,
SparseBooleanArray,
और LongSparseArray.
उदाहरण के लिए, SparseArray क्लास ज़्यादा काम करती हैं, क्योंकि वे सिस्टम की
यह करने की ज़रूरत है
ऑटोबॉक्स
कुंजी और कभी-कभी वैल्यू होती है, जो हर एंट्री के लिए एक या दो ऑब्जेक्ट बनाती है.
अगर ज़रूरी हो, तो बेहतर डेटा स्ट्रक्चर के लिए, हमेशा रॉ कलेक्शन का इस्तेमाल किया जा सकता है.
कोड ऐब्स्ट्रैक्ट से सावधान रहें
डेवलपर अक्सर एक अच्छे प्रोग्रामिंग अभ्यास के रूप में ऐब्स्ट्रैक्ट का इस्तेमाल करते हैं, क्योंकि वे कोड को बेहतर बनाने में मदद कर सकते हैं आसान और सुरक्षित तरीके से काम करता है. हालांकि, ऐब्स्ट्रैक्ट इमेज बहुत महंगी होती हैं, क्योंकि उन्हें आम तौर पर, ज़्यादा कोड की ज़रूरत होती है, जिसे एक्ज़ीक्यूट करना पड़ता है. साथ ही, मैप करने में ज़्यादा समय और रैम की ज़रूरत होती है मेमोरी में कोड डाल सकते हैं. अगर आपके ऐब्स्ट्रैक्ट नतीजे ज़्यादा फ़ायदेमंद नहीं हैं, तो उन्हें इस्तेमाल न करें.
क्रम से लगाए गए डेटा के लिए, लाइट प्रोटोबफ़ का इस्तेमाल करें
प्रोटोकॉल बफ़र (प्रोटोबफ़), एक लैंग्वेज न्यूट्रल, प्लैटफ़ॉर्म न्यूट्रल, एक्सटेंसिबल सिस्टम है. इसे डिज़ाइन किया गया है स्ट्रक्चर्ड डेटा को क्रम से लगाने के लिए Google. यह एक्सएमएल की तरह ही काम करता है, लेकिन यह छोटा, तेज़, और आसान है. अगर आपने तो डेटा के लिए प्रोटोबफ़ का इस्तेमाल करें. क्लाइंट-साइड कोड में हमेशा लाइट प्रोटोबफ़ का इस्तेमाल करें. सामान्य प्रोटोबफ़ बहुत ज़्यादा वर्बोस कोड जनरेट करते हैं, जिससे आपके ऐप्लिकेशन में कई समस्याएं हो सकती हैं, जैसे रैम का ज़्यादा इस्तेमाल, APK का साइज़ काफ़ी बढ़ गया है, और एक्ज़ीक्यूट होने की रफ़्तार धीमी है.
ज़्यादा जानकारी के लिए, देखें प्रोटोबफ़ रीडमी.
मेमोरी चर्न करने से बचना
कचरा इकट्ठा करने से जुड़े इवेंट से, आपके ऐप्लिकेशन की परफ़ॉर्मेंस पर कोई असर नहीं पड़ता. हालांकि, कचरा इकट्ठा करने के लिए कम समय में होने वाली गतिविधियों की वजह से, बैटरी तेज़ी से खर्च हो सकती है. साथ ही, थोड़ी-बहुत बैटरी खर्च हो सकती है गार्बेज कलेक्टर और ऐप्लिकेशन थ्रेड. सिस्टम, कचरा इकट्ठा करने में जितना ज़्यादा समय लगाता है, बैटरी उतनी ही तेज़ी से काम करती है नाले.
आम तौर पर, मेमोरी चर्न आउट की वजह से, कचरा इकट्ठा करने की कई घटनाएं हो सकती हैं. तय सीमा में मेमोरी चर्न आउट से यह पता चलता है कि किसी खास इवेंट में, कुछ समय के लिए मौजूद कितने ऑब्जेक्ट मौजूद हैं समय की जानकारी देते हैं.
उदाहरण के लिए, for लूप में कुछ समय के लिए काम करने वाले कई ऑब्जेक्ट असाइन किए जा सकते हैं. या
नया Paint बनाया जा सकता है या
Bitmap ऑब्जेक्ट के अंदर
onDraw()
एक व्यू का फ़ंक्शन. दोनों ही मामलों में, ऐप्लिकेशन तेज़ आवाज़ में तेज़ी से बहुत सारे ऑब्जेक्ट बनाता है. ये
युवा पीढ़ी की उपलब्ध मेमोरी को तुरंत इस्तेमाल कर सकता है, जिससे कचरा इकट्ठा होता है
होने वाला इवेंट.
किसी फ़ोल्डर में जगहें ढूंढने के लिए, मेमोरी प्रोफ़ाइलर का इस्तेमाल करना आपका कोड जहां मेमोरी चर्न आउट हो रही है, उसके बाद ही आप उन्हें ठीक कर सकें.
अपने कोड में समस्या वाले हिस्सों की पहचान करने के बाद, तय करें कि अहम हिस्सों की जानकारी देना ज़रूरी है. चीज़ों को अंदरूनी लूप से बाहर निकालने या उन्हें किसी दूसरी चीज़ में ले जाने के बारे में सोचें फ़ैक्ट्री पर आधारित ऐलोकेशन स्ट्रक्चर.
यह भी आकलन किया जा सकता है कि ऑब्जेक्ट पूल से इस्तेमाल के उदाहरण को फ़ायदा हो रहा है या नहीं. इसके बजाय, किसी ऑब्जेक्ट पूल के साथ किसी ऑब्जेक्ट को फ़र्श पर लाकर, ज़रूरत न होने पर उसे पूल में छोड़ दें. अगली बार जब उस तरह के किसी ऑब्जेक्ट इंस्टेंस की ज़रूरत पड़े, तो उसे पूल से हासिल किया जा सकता है असाइन करने के बजाय.
परफ़ॉर्मेंस का अच्छी तरह से आकलन करें, ताकि यह तय किया जा सके कि किसी स्थिति में ऑब्जेक्ट पूल सही है या नहीं. कुछ मामलों में ऑब्जेक्ट पूल की वजह से, परफ़ॉर्मेंस खराब हो सकती है. भले ही पूल में न जाना हो आवंटन के बाद ही, अन्य ओवरहेड लगा दिए जाते हैं. उदाहरण के लिए, पूल के रखरखाव में आम तौर पर सिंक करना, जिसका ओवरहेड न के बराबर होता है. साथ ही, पूल किए गए ऑब्जेक्ट इंस्टेंस को रिलीज़ के दौरान मेमोरी लीक होने से बचाते हैं. इसके बाद, उपयोगकर्ता हासिल करने के दौरान इसे शुरू करने के लिए, शून्य के अलावा कोई अन्य वैल्यू दी जा सकती है है.
पूल में ज़रूरत से ज़्यादा ऑब्जेक्ट को दबाकर रखने से भी कचरे का बोझ कम होता है संग्रह. हालांकि, ऑब्जेक्ट पूल कूड़ा इकट्ठा करने के अनुरोधों की संख्या को कम कर देते हैं, लेकिन ये हर बात के लिए काम की ज़रूरत को बढ़ाना, क्योंकि यह लाइव (पहुंच-योग्य) बाइट.
मेमोरी से ज़्यादा इस्तेमाल किए जाने वाले संसाधन और लाइब्रेरी हटाएं
आपके कोड में मौजूद कुछ संसाधन और लाइब्रेरी, आपकी जानकारी के बिना मेमोरी का इस्तेमाल कर सकती हैं. कॉन्टेंट बनाने इसमें तीसरे पक्ष की लाइब्रेरी या एम्बेड किए गए संसाधन शामिल हैं. इससे आपके ऐप्लिकेशन के कुल साइज़ पर मेमोरी का इस्तेमाल करती है. ग़ैर-ज़रूरी, आपके कोड से ग़ैर-ज़रूरी या फूले हुए कॉम्पोनेंट या रिसॉर्स और लाइब्रेरी को हटाना होगा.
APK का कुल साइज़ कम करें
अपने ऐप्लिकेशन के कुल साइज़ को कम करके, उसके स्टोरेज के इस्तेमाल को काफ़ी हद तक कम किया जा सकता है. बिटमैप का साइज़, संसाधन, ऐनिमेशन फ़्रेम, और तीसरे पक्ष की लाइब्रेरी, तीन सबसे सही तरीक़े यहाँ दिए गए हैं. Android Studio और Android SDK टूल की मदद से, कई टूल मिलते हैं. इनकी मदद से, एआर की मदद से और बाहरी डिपेंडेंसी के हिसाब से अपने संसाधन और अन्य संसाधन हासिल करें. ये टूल, कोड का साइज़ छोटा करने वाले आधुनिक तरीकों का इस्तेमाल करते हैं. जैसे, R8 कंपाइलेशन.
अपने ऐप्लिकेशन के कुल साइज़ को कम करने के बारे में ज़्यादा जानकारी के लिए, यहां देखें अपने ऐप्लिकेशन का साइज़ कम करें.
डिपेंडेंसी इंजेक्शन के लिए Hilt या Dagger 2 का इस्तेमाल करें
डिपेंडेंसी इंजेक्शन फ़्रेमवर्क आपके लिखे जाने वाले कोड को आसान बना सकते हैं. साथ ही, कोड के हिसाब से ढल जाने की सुविधा देते हैं एक ऐसा एनवायरमेंट है जो टेस्ट करने और कॉन्फ़िगरेशन में किए जाने वाले अन्य बदलावों के लिए काम आता है.
अगर आपको अपने ऐप्लिकेशन में डिपेंडेंसी इंजेक्शन फ़्रेमवर्क का इस्तेमाल करना है, तो हिलाएं या डैगर. Hilt एक डिपेंडेंसी इंजेक्शन है डैगर के ऊपर चलता है. डैगर आपके ऐप्लिकेशन की इमेज को स्कैन करने के लिए, रिफ़्लेक्शन का इस्तेमाल नहीं करता कोड. Android ऐप्लिकेशन में, डैगर के स्टैटिक कंपाइल टाइम को लागू करने की सुविधा का इस्तेमाल बिना किसी ज़रूरत के किया जा सकता है रनटाइम की लागत या मेमोरी के इस्तेमाल की जानकारी होती है.
रिफ़्लेक्शन का इस्तेमाल करने वाले अन्य डिपेंडेंसी इंजेक्शन फ़्रेमवर्क, आपकी वेबसाइट या ऐप्लिकेशन को स्कैन करके टिप्पणियों के लिए कोड. इस प्रोसेस में बहुत ज़्यादा सीपीयू साइकल और रैम की ज़रूरत पड़ सकती है. ऐप्लिकेशन के लॉन्च होने के समय, साफ़ तौर पर दिखने वाला अंतर.
बाहरी लाइब्रेरी का इस्तेमाल करते समय सावधानी बरतें
अक्सर बाहरी लाइब्रेरी कोड, मोबाइल एनवायरमेंट के लिए नहीं लिखे जाते हैं. इसलिए, हो सकता है कि ये कोड काम न करें मोबाइल क्लाइंट पर काम कर रहे हैं. जब किसी बाहरी लाइब्रेरी का इस्तेमाल किया जाता है, तो हो सकता है कि आपको उसे ऑप्टिमाइज़ करना पड़े मोबाइल डिवाइस के लिए लाइब्रेरी. इस काम के लिए पहले से ही योजना बना लें और लाइब्रेरी का विश्लेषण का इस्तेमाल करने से पहले कोड का साइज़ और रैम फ़ुटप्रिंट.
यहां तक कि मोबाइल के लिए ऑप्टिमाइज़ की गई कुछ लाइब्रेरी भी, अलग-अलग तरीकों से लागू करने की वजह से समस्याएं पैदा कर सकती हैं. इसके लिए उदाहरण के लिए, एक लाइब्रेरी लाइट प्रोटोबफ़ का इस्तेमाल कर सकती है, जबकि दूसरी माइक्रो प्रोटोबफ़ का इस्तेमाल कर सकती है, जिससे दो नतीजे मिलते हैं आपके ऐप्लिकेशन में अलग-अलग प्रोटोबफ़ लागू करना चाहिए. ऐसा अलग-अलग तरीकों से हो सकता है लॉगिंग, विश्लेषण, इमेज लोडिंग फ़्रेमवर्क, कैश मेमोरी वगैरह.
हालांकि, ProGuard, एपीआई और संसाधनों को हटाने में मदद कर सकता है
सही फ़्लैग करते हैं, तो यह लाइब्रेरी की बड़ी इंटरनल डिपेंडेंसी को नहीं हटा सकता. वे सुविधाएं जो आपको चाहिए
इन लाइब्रेरी के लिए, निचले लेवल की डिपेंडेंसी की ज़रूरत हो सकती है. इससे खास तौर पर तब समस्या आ सकती है, जब
Activity सब-क्लास का इस्तेमाल करें
लाइब्रेरी—जिसमें कई डिपेंडेंसी हो सकती हैं—जब लाइब्रेरी प्रतिबिंब का इस्तेमाल करती हैं,
आम है और इसे काम करने के लिए ProGuard को मैन्युअल रूप से ट्विस्ट करने की आवश्यकता होती है.
दर्जनों सुविधाओं में से सिर्फ़ एक या दो सुविधाओं के लिए, शेयर की गई लाइब्रेरी का इस्तेमाल करने से बचें. बड़े साइज़ की कोड और ओवरहेड की वह मात्रा जिसे आप इस्तेमाल नहीं करते हैं. किसी लाइब्रेरी का इस्तेमाल करते समय, जो आपकी ज़रूरत के मुताबिक पूरी तरह से काम करता हो. अगर ऐसा नहीं है, तो हो सकता है कि खुद लागू करना.