मेमोरी मुद्दों से बाहर एंड्रॉइड ऐप - सब कुछ करने की कोशिश की और अभी भी नुकसान में है

Question

मैंने 4 पूरे दिन बिताए, मैं जिस ऐप को विकसित कर रहा हूं, उसमें मेमोरी लीक का पता लगाने के लिए मैं सब कुछ करने की कोशिश कर रहा हूं, लेकिन कुछ समय पहले चीजों को समझना बंद हो गया।

मैं जो एप्लिकेशन विकसित कर रहा हूं वह सामाजिक प्रकृति का है, इसलिए प्रोफ़ाइल गतिविधियों (पी) और डेटा के साथ गतिविधियों की सूची सोचें - उदाहरण के लिए बैज (बी)। आप प्रोफाइल से बिल्ला सूची से अन्य प्रोफाइल, अन्य सूचियों, आदि के लिए आशा कर सकते हैं।

तो इस P1 -> B1 -> P2 -> B2 -> P3 -> B3, इत्यादि जैसे प्रवाह की कल्पना करें। संगति के लिए, मैं एक ही उपयोगकर्ता की प्रोफाइल और बैज लोड कर रहा हूं, इसलिए प्रत्येक P पेज एक जैसा है और ऐसा ही है। प्रत्येक बी पेज।

समस्या का सामान्य सार यह है: बिट के लिए नेविगेट करने के बाद, प्रत्येक पृष्ठ के आकार के आधार पर, मुझे यादृच्छिक स्थानों - बिटमैप्स, स्ट्रिंग्स, आदि में एक आउट-ऑफ-मेमोरी अपवाद मिलता है - यह सुसंगत प्रतीत नहीं होता है।

सब कुछ करने के लिए कल्पना करने के बाद कि मैं स्मृति से बाहर क्यों भाग रहा हूं, मैं कुछ भी नहीं लेकर आया हूं। मुझे समझ में नहीं आता है कि एंड्रॉइड पी 1, बी 1, आदि को क्यों नहीं मार रहा है अगर यह लोडिंग पर मेमोरी से बाहर निकलता है और इसके बजाय क्रैश होता है। मैं उम्मीद करूंगा कि यदि मैं कभी भी onCreate () और onRestoreInstanceState () के माध्यम से वापस आ जाऊं, तो ये पहले की गतिविधियां मर जाएंगी और पुनर्जीवित हो जाएंगी।

इसे अकेले ही करें - भले ही मैं P1 -> B1 -> पीछे -> B1 -> पीछे -> B1 करता हूं, फिर भी मुझे एक दुर्घटना मिलती है। यह स्मृति रिसाव के कुछ प्रकार को इंगित करता है, फिर भी hprof डंप करने और MAT और JProfiler का उपयोग करने के बाद भी, मैं इसे इंगित नहीं कर सकता।

मैंने वेब से छवियों को लोड करना अक्षम कर दिया है (और इसके लिए बनाने और परीक्षण को उचित बनाने के लिए लोड किए गए परीक्षण डेटा में वृद्धि की है) और यह सुनिश्चित किया है कि छवि कैश सॉफ्टरियर्स का उपयोग करती है। एंड्रॉइड वास्तव में इसके पास मौजूद कुछ SoftReferences को मुक्त करने की कोशिश करता है, लेकिन इससे पहले कि यह स्मृति से बाहर निकल जाए।

बैज पेज वेब से डेटा प्राप्त करते हैं, इसे एक आधार एडेप्टर से EntityData की एक सरणी में लोड करते हैं और इसे एक ListView को खिलाते हैं (मैं वास्तव में कॉमन्सवेयर के उत्कृष्ट मर्ज एडेप्टर का उपयोग कर रहा हूं , लेकिन इस बैज गतिविधि में, वास्तव में 1 एडेप्टर वैसे भी है, लेकिन मैं इस तथ्य का या तो रास्ता बताना चाहता था)।

मैं कोड के माध्यम से चला गया हूं और ऐसा कुछ भी नहीं पा रहा था जो लीक हो। मैंने अपना सबकुछ साफ़ कर दिया और मुझे और यहां तक ​​कि सिस्टम। Gc () को छोड़ दिया और दाएं लेकिन फिर भी ऐप क्रैश हो गया।

मुझे अभी तक समझ में नहीं आया कि निष्क्रिय गतिविधियाँ जो स्टैक पर क्यों हैं, फिर से नहीं मिलती हैं, और मुझे वास्तव में यह पता लगाना अच्छा लगेगा।

इस बिंदु पर, मैं किसी भी संकेत, सलाह, समाधान की तलाश कर रहा हूं ... कुछ भी जो मदद कर सकता है।

धन्यवाद।

Comments

इसलिए, यदि मैंने पिछले 20 सेकंड में 15 गतिविधियां खोली हैं (उपयोगकर्ता बहुत तेजी से गुजर रहा है), तो क्या यह समस्या हो सकती है? प्रदर्शित होने के बाद गतिविधि को साफ़ करने के लिए मुझे किस कोड को जोड़ना चाहिए? मुझे एक outOfMemoryत्रुटि मिलती है । धन्यवाद!

— रुचिर बैरोनिया

Answer 1

मुझे अभी तक समझ में नहीं आया है कि स्टैक पर मौजूद निष्क्रिय गतिविधियाँ क्यों नहीं होती हैं, और मुझे यह पता लगाना बहुत अच्छा लगता है।

यह नहीं है कि चीजें कैसे काम करती हैं। गतिविधि के जीवन चक्र को प्रभावित करने वाला एकमात्र मेमोरी प्रबंधन सभी प्रक्रियाओं में वैश्विक मेमोरी है, जैसा कि एंड्रॉइड तय करता है कि यह मेमोरी पर कम चल रहा है और इसलिए कुछ वापस पाने के लिए पृष्ठभूमि प्रक्रियाओं को मारने की आवश्यकता है।

यदि आपका एप्लिकेशन अधिक से अधिक गतिविधियों को शुरू करने के लिए अग्रभूमि में बैठा है, तो यह पृष्ठभूमि में कभी नहीं जा रहा है, इसलिए यह हमेशा अपनी स्थानीय प्रक्रिया मेमोरी सीमा को हिट करेगा क्योंकि सिस्टम कभी भी अपनी प्रक्रिया को मारने के करीब आता है। (और जब यह अपनी प्रक्रिया को मारता है, तो यह सभी गतिविधियों की मेजबानी करने वाली प्रक्रिया को मार देगा , जो कि वर्तमान में अग्रभूमि में है, सहित)

तो यह मुझे लगता है जैसे आपकी मूल समस्या यह है: आप बहुत सारी गतिविधियों को एक ही समय में चलने दे रहे हैं, और / या उन गतिविधियों में से प्रत्येक बहुत अधिक संसाधनों को पकड़े हुए है।

आपको बस अपने नेविगेशन को फिर से डिज़ाइन करने की आवश्यकता है ताकि संभावित भारी-वजन वाली गतिविधियों की एक मनमानी संख्या पर भरोसा न किया जा सके। जब तक आप onStop () में एक गंभीर मात्रा में सामान नहीं करते हैं (जैसे कि कॉलिंग कॉन्टेंट व्यू () गतिविधि के दृश्य पदानुक्रम को साफ करने के लिए और जो कुछ भी इसे पकड़ सकता है) के स्पष्ट चर, तो आप बस मेमोरी से बाहर निकलने वाले हैं।

आप नई फ्रैगमेंट एपीआई का उपयोग करके उन गतिविधियों के इस मनमाने ढेर को बदलने के लिए विचार कर सकते हैं जो एक ऐसी गतिविधि के साथ हैं जो आपकी स्मृति को और अधिक मजबूती से प्रबंधित करती है। उदाहरण के लिए यदि आप टुकड़ों के बैक स्टैक सुविधाओं का उपयोग करते हैं, जब एक टुकड़ा बैक स्टैक पर चला जाता है और अब दिखाई नहीं देता है, तो इसके ऑनरस्ट्रो व्यू () विधि को इसके दृश्य पदानुक्रम को पूरी तरह से हटाने के लिए कहा जाता है, इसके पदचिह्न को बहुत कम करता है।

अब, जहां तक ​​आप प्रवाह में दुर्घटनाग्रस्त हो रहे हैं जहां आप वापस दबाते हैं, एक गतिविधि पर जाएं, वापस दबाएं, दूसरी गतिविधि पर जाएं, आदि और कभी भी एक गहरी स्टैक न करें, फिर हां आपके पास बस एक रिसाव है। इस ब्लॉग पोस्ट में लीक को कैसे ख़त्म करना है इसका वर्णन किया गया है: http://android-developers.blogspot.com/2011/03/memory-analysis-for-android.html

Comments

ओपी के बचाव में, यह वही नहीं है जो प्रलेखन का सुझाव देता है। डेवलपर को उद्धृत करते हुए .android.com/guide/topics/fundamentals/… "(जब कोई गतिविधि रोक दी जाती है), तो यह अब उपयोगकर्ता को दिखाई नहीं देता है और यह सिस्टम द्वारा मारा जा सकता है जब मेमोरी कहीं और की आवश्यकता होती है।" "यदि किसी गतिविधि को रोका या रोका गया है, तो सिस्टम इसे मेमोरी से ड्रॉप कर सकता है ... इसे समाप्त करने के लिए कहकर (इसकी फिनिश () विधि)" "(onDestroy () कहा जाता है) क्योंकि सिस्टम अस्थायी रूप से इस आवृत्ति को नष्ट कर रहा है अंतरिक्ष को बचाने के लिए गतिविधि। "

— कॉमन्सवेयर

उसी पृष्ठ पर, "हालाँकि, जब स्मृति को पुनर्प्राप्त करने के लिए सिस्टम एक गतिविधि को नष्ट कर देता है"। आप जो संकेत कर रहे हैं वह यह है कि एंड्रॉइड कभी भी मेमोरी को पुनः प्राप्त करने के लिए गतिविधियों को नष्ट नहीं करता है, लेकिन केवल ऐसा करने के लिए प्रक्रिया को समाप्त कर देगा। यदि ऐसा है, तो इस पृष्ठ को एक गंभीर पुनर्लेखन की आवश्यकता है, क्योंकि यह बार-बार सुझाव देता है कि एंड्रॉइड मेमोरी को पुनः प्राप्त करने के लिए एक गतिविधि को नष्ट कर देगा । यह भी ध्यान दें कि कई उद्धृत मार्ग Activityजावाडॉक्स में भी मौजूद हैं ।

— कॉमन्सवेअर

मुझे लगा कि मैंने इसे यहां रखा है, लेकिन मैंने इसके लिए प्रलेखन अद्यतन करने के लिए एक अनुरोध पोस्ट किया: code.google.com/p/android/issues/detail?id=21552

— जस्टिन ब्रेइटफेलर

यह 2013 है और डॉक्स केवल झूठे बिंदु को अधिक स्पष्ट रूप से प्रस्तुत करने के लिए आए हैं: developer.android.com/training/basics/activity-lifecycle/… , "एक बार जब आपकी गतिविधि बंद हो जाती है, तो सिस्टम उस आवृत्ति को नष्ट कर सकता है यदि उसे पुनर्प्राप्त करने की आवश्यकता हो। सिस्टम मेमोरी। EXTREME मामलों में, सिस्टम आपकी ऐप प्रक्रिया को आसानी से मार सकता है "

— काए

अच्छा, बकवास। मैंने निश्चित रूप से हमेशा (डॉक्स के कारण) सोचा था कि सिस्टम आपकी प्रक्रिया में रुकी हुई गतिविधियों को प्रबंधित करेगा और आवश्यकतानुसार उन्हें क्रमबद्ध और डिस्क्रिअलाइज़ (नष्ट और निर्मित) करेगा।

— dcow

Answer 2

कुछ सुझाव:

1. सुनिश्चित करें कि आप रिसाव गतिविधि संदर्भ नहीं हैं।

2. सुनिश्चित करें कि आप बिटमैप पर संदर्भ नहीं रख रहे हैं। गतिविधि # onStop में अपने सभी ImageView की सफाई करें, कुछ इस तरह:

   Drawable d = imageView.getDrawable();  
   if (d != null) d.setCallback(null);  
   imageView.setImageDrawable(null);  
   imageView.setBackgroundDrawable(null);
   

3. यदि आपको उनकी आवश्यकता नहीं है, तो रीसायकल बिटमैप्स को रीसायकल करें।

4. यदि आप मेमोरी कैश का उपयोग करते हैं, तो मेमोरी-ल्रू की तरह, सुनिश्चित करें कि यह बहुत मेमोरी का उपयोग नहीं कर रहा है।

5. न केवल छवियां स्मृति का एक बहुत कुछ लेती हैं, सुनिश्चित करें कि आप स्मृति में बहुत अधिक अन्य डेटा नहीं रखते हैं। यह आसानी से हो सकता है यदि आपके ऐप में अनंत सूचियाँ हैं। DataBase में डेटा कैश करने का प्रयास करें।

6. एंड्रॉइड 4.2 पर, हार्डवेयर त्वरण के साथ एक बग (स्टैकओवरफ़्लो # 13754876) है , इसलिए यदि आप hardwareAccelerated=trueअपने मैनिफ़ेस्ट में उपयोग करते हैं तो यह मेमोरी को लीक कर देगा। GLES20DisplayList- संदर्भ को पकड़े रखें, भले ही आपने चरण (2) किया हो और कोई भी इस बिटमैप को संदर्भित नहीं कर रहा है। यहाँ आपको आवश्यकता है:

   a) 16/17 के लिए हार्डवेयर त्वरण अक्षम करें;
   या
   b) बिटमैप को पकड़े हुए देखें

7. Android 3+ के लिए आप android:largeHeap="true"अपने में उपयोग करने का प्रयास कर सकते हैं AndroidManifest। लेकिन यह आपकी मेमोरी समस्याओं को हल नहीं करेगा, बस उन्हें स्थगित करें।

8. यदि आपको जरूरत है, जैसे, अनंत नेविगेशन, तो Fragments - आपकी पसंद होनी चाहिए। तो आपके पास 1 गतिविधि होगी, जो सिर्फ टुकड़ों के बीच बदल जाएगी। इस तरह आप कुछ मेमोरी मुद्दों को भी हल करेंगे, जैसे नंबर 4।

9. अपनी मेमोरी लीक का कारण जानने के लिए मेमोरी एनालाइज़र का उपयोग करें।
   यहाँ Google I / O 2011 से बहुत अच्छा वीडियो है : एंड्रॉइड ऐप्स के लिए मेमोरी प्रबंधन
   यदि आप बिटमैप के साथ काम कर रहे हैं तो इसे अवश्य पढ़ें: बिटमैप को कुशलतापूर्वक प्रदर्शित करना

Comments

इसलिए, यदि मैंने पिछले 20 सेकंड में 15 गतिविधियां खोली हैं (उपयोगकर्ता बहुत तेजी से गुजर रहा है), क्या यह समस्या हो सकती है? प्रदर्शित होने के बाद गतिविधि को साफ करने के लिए मुझे किस कोड को जोड़ना चाहिए? मुझे एक outOfMemoryत्रुटि मिलती है । धन्यवाद!

— रुचिर बैरोनिया

Answer 3

बिटमैप्स अक्सर एंड्रॉइड पर मेमोरी त्रुटियों के लिए अपराधी होते हैं, इसलिए यह दोहरी जांच के लिए एक अच्छा क्षेत्र होगा।

Comments

इसलिए, यदि मैंने पिछले 20 सेकंड में 15 गतिविधियां खोली हैं (उपयोगकर्ता बहुत तेजी से गुजर रहा है), क्या यह समस्या हो सकती है? प्रदर्शित होने के बाद गतिविधि को साफ करने के लिए मुझे किस कोड को जोड़ना चाहिए? मुझे एक outOfMemoryत्रुटि मिलती है । धन्यवाद!

— रुचिर बैरोनिया

Answer 4

क्या आप प्रत्येक गतिविधि के लिए कुछ संदर्भ रख रहे हैं? AFAIK यह एक कारण है जो एंड्रॉइड को स्टैक से गतिविधियों को हटाने से रखता है।

हम अन्य उपकरणों पर भी इस त्रुटि को पुन: उत्पन्न करने में सक्षम हैं? मैंने ROM और / या हार्डवेयर निर्माता के आधार पर कुछ Android उपकरणों के कुछ अजीब व्यवहार का अनुभव किया है।

Comments

मैं इसे एक Droid पर चलाने में सक्षम था CM7 अधिकतम 16MB पर सेट के साथ चल रहा है, जो समान मूल्य है जो मैं एमुलेटर पर परीक्षण कर रहा हूं।

— आर्टेम रसाकोवस्की

आप किसी पर हो सकते हैं। जब दूसरी गतिविधि शुरू होती है, तो क्या 1 व्यक्ति ऑन-प्रॉप- ऑनऑनटॉप या सिर्फ ऑनपॉज करेगा? क्योंकि मैं ******* जीवनचक्र कॉल पर सभी प्रिंट कर रहा हूं, और मैं onPause -> onCreate, onStop के बिना देख रहा हूं। और क्रैश डंप में से एक ने वास्तव में onPause = true या onStop = false जैसा कुछ कहा था जैसे कि वह 3 गतिविधियों को मार रहा था।

— आर्टेम रसाकोवस्की

OnStop को तब बुलाया जाना चाहिए जब गतिविधि स्क्रीन को छोड़ देती है, लेकिन ऐसा नहीं हो सकता है कि यह सिस्टम द्वारा जल्दी प्राप्त किया जाता है।

— dten

यह पुनः प्राप्त नहीं होता है क्योंकि मुझे onCreate और onRestoreInstanceState दिखाई नहीं देता है अगर मैं वापस क्लिक करता हूं।

— आर्टेम रसाकोवस्की

जीवन चक्र के अनुसार जिन्हें कभी भी नहीं बुलाया जा सकता है, मेरे उत्तर की जांच करें जो कि आधिकारिक डेवलपर ब्लॉग के लिए एक लिंक है, यह संभावना से अधिक है जिस तरह से आप अपने बिटमैप को पास कर रहे हैं

— dten

Answer 5

मुझे लगता है कि समस्या शायद कई कारकों का एक संयोजन है जो उत्तर में यहां दिए गए हैं जो आपको समस्याएं दे रहे हैं। जैसे @Tim ने कहा, गतिविधि में एक (स्थिर) संदर्भ या उस गतिविधि में एक तत्व GC को गतिविधि को छोड़ने का कारण बन सकता है। यहाँ इस पहलू पर चर्चा करने वाला लेख है। मुझे लगता है कि संभावित मुद्दा गतिविधि को "दृश्यमान प्रक्रिया" स्थिति या उच्चतर में रखने से आता है, जो बहुत अधिक गारंटी देता है कि गतिविधि और इससे जुड़े संसाधन कभी भी पुनः प्राप्त नहीं होंगे।

मैं एक सेवा के साथ कुछ समय पहले विपरीत समस्या से गुजरा था, इसलिए मुझे इस विचार से गुजरना पड़ा: प्रक्रिया प्राथमिकता सूची में आपकी गतिविधि को उच्च रखने के लिए कुछ है ताकि यह प्रणाली GC के अधीन न हो, जैसे कि एक संदर्भ (@ टिम) या एक पाश (@ अलवारो)। लूप को एक अंतहीन या लंबे समय तक चलने वाली वस्तु होने की आवश्यकता नहीं है, बस कुछ ऐसा है जो एक पुनरावर्ती विधि या कैस्केड लूप (या उन पंक्तियों के साथ कुछ) जैसे बहुत कुछ चलाता है।

संपादित करें: जैसा कि मैं यह समझता हूं, एंड्रॉइड द्वारा ऑनपॉज़ और ऑनटॉप को स्वचालित रूप से आवश्यकतानुसार कहा जाता है। मुख्य रूप से आपके पास करने के लिए तरीके हैं ताकि आप इस बात का ध्यान रख सकें कि होस्टिंग प्रक्रिया को रोकने से पहले आपको क्या ज़रूरत है (बचत चर, मैन्युअल रूप से राज्य को बचाने, आदि); लेकिन ध्यान दें कि यह स्पष्ट रूप से कहा गया है कि onStop (onDestroy के साथ) हर मामले में नहीं कहा जा सकता है। इसके अतिरिक्त, यदि होस्टिंग प्रक्रिया एक गतिविधि, सेवा, आदि की मेजबानी कर रही है, जिसमें "फोरग्राउंड" या "दृश्यमान" स्थिति है, तो ओएस प्रक्रिया / थ्रेड को रोकने पर भी नहीं देख सकता है। उदाहरण के लिए: एक गतिविधि और एक सेवा दोनों को एक ही प्रक्रिया में लिया जाता है और सेवा वापस आ जाती START_STICKYहैonStartCommand()प्रक्रिया स्वचालित रूप से कम से कम एक दृश्य स्थिति लेती है। यह यहां की कुंजी हो सकती है, गतिविधि के लिए एक नई खरीद की घोषणा करने का प्रयास करें और देखें कि क्या कुछ भी बदलता है। इस गतिविधि को घोषणापत्र में अपनी गतिविधि की घोषणा के रूप में जोड़ने की कोशिश करें: android:process=":proc2"और यदि आपकी गतिविधि किसी अन्य चीज के साथ प्रक्रिया साझा करती है, तो फिर से परीक्षण चलाएं। सोचा यहाँ कि अगर आप अपने गतिविधि साफ और कर रहे हैं है सुंदर लगता है कि समस्या अपने गतिविधि नहीं है तो कुछ और ही समस्या और उस के लिए शिकारी के लिए अपने समय है।

इसके अलावा, मुझे याद नहीं है कि मैंने इसे कहाँ देखा था (यदि मैंने इसे एंड्रॉइड डॉक्स में भी देखा था), लेकिन मुझे याद है कि एक PendingIntentसंदर्भित के बारे में कुछ गतिविधि के कारण इस तरह से व्यवहार करने के लिए गतिविधि हो सकती है।

onStartCommand()गैर-हत्या के मोर्चे पर कुछ अंतर्दृष्टि के साथ पृष्ठ के लिए एक लिंक यहां दिया गया है ।

Comments

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

— आर्टेम रसाकोवस्की

Answer 6

केवल एक चीज जो मैं वास्तव में सोच सकता हूं, यदि आपके पास एक स्थिर चर है जो संदर्भ को प्रत्यक्ष या अप्रत्यक्ष रूप से संदर्भित करता है। यहां तक ​​कि आवेदन के हिस्से के संदर्भ में इतना कुछ। मुझे यकीन है कि आपने पहले ही इसकी कोशिश कर ली है, लेकिन मैं इसे सिर्फ मामले में सुझाऊंगा, बस कोशिश करें कि अपने सभी स्थिर चर onDestroy () में यह सुनिश्चित करने के लिए कि कचरा कलेक्टर को मिल जाए।

Answer 7

स्मृति रिसाव का सबसे बड़ा स्रोत मैंने पाया है कि कुछ वैश्विक, उच्च स्तर या लंबे समय तक संदर्भ के संदर्भ में था। यदि आप "संदर्भ" को एक चर में कहीं भी संग्रहीत कर रहे हैं, तो आप अप्रत्याशित मेमोरी लीक का सामना कर सकते हैं।

Comments

हाँ, मैंने इसे कई बार सुना और पढ़ा है, लेकिन मुझे इसे कम करने में परेशानी हुई है। अगर केवल मैं ही समझ सकता हूं कि उन लोगों का पता कैसे लगाया जाए।

— अर्टेम रसाकोवस्की

मेरे मामले में यह किसी भी चर में कक्षा स्तर पर अनुवादित किया गया था जो कि संदर्भ के बराबर सेट किया गया था (जैसे Class1.variable = getContext ();)। सामान्य तौर पर, "getContext" के लिए एक ताजा कॉल के साथ मेरे ऐप में "संदर्भ" के हर उपयोग की जगह या इसी तरह मेरी पुरानी मेमोरी समस्याओं को हल किया। लेकिन मेरा अस्थिर और अनिश्चित था, आपके मामले में पूर्वानुमान जैसा नहीं था, इसलिए संभवतः कुछ अलग हो।

— D2TheC

Answer 8

जो भी एक संदर्भ की जरूरत है getApplicationContext () पास करने की कोशिश करें। आपके पास एक वैश्विक चर हो सकता है जो आपकी गतिविधियों के संदर्भ में है और उन्हें एकत्र होने से रोक रहा है।

Answer 9

उन चीजों में से एक, जिन्होंने वास्तव में मेरे मामले में मेमोरी इश्यू की मदद की, मेरे बिटमैप्स के लिए सच करने के लिए दुर्गम स्थापित करना समाप्त कर दिया। देखें कि मैं कभी बिटमैपफैक्टरी के दुर्गम विकल्प का उपयोग क्यों नहीं करूंगा? और अधिक जानकारी के लिए उत्तर की चर्चा।

डायने हैकॉर्न का उत्तर और हमारी बाद की चर्चा (धन्यवाद भी, कॉमन्सवेयर) ने कुछ चीजों को स्पष्ट करने में मदद की, जिनके बारे में मुझे भ्रम था, इसलिए इसके लिए धन्यवाद।

Comments

मुझे पता है कि यह एक पुराना विषय है लेकिन मुझे लगता है कि इस खोज को कई खोजों पर लगता है। मैं एक महान ट्यूटोरियल को लिंक करना चाहता हूं जो मैंने बहुत कुछ सीखा है जिससे आप यहां मिल सकते हैं: developer.android.com/training/displaying-bitmaps/index.html

— कोडवर्ड

Answer 10

मुझे आपके साथ एक ही समस्या का सामना करना पड़ा। मैं एक त्वरित मैसेजिंग ऐप पर काम कर रहा था, उसी संपर्क के लिए, चैटएक्टिविटी में एक प्रोफाइलएक्टिविटी शुरू करना संभव है, और इसके विपरीत। मैं बस एक और गतिविधि शुरू करने के इरादे में एक स्ट्रिंग अतिरिक्त जोड़ता हूं, यह वर्ग प्रकार की स्टार्टर गतिविधि, और उपयोगकर्ता आईडी की जानकारी लेता है। उदाहरण के लिए, ProfileActivity एक ChatActivity शुरू करती है, फिर ChatActivity.onCreate में, मैं इनवॉकर क्लास प्रकार 'ProfileActivity' और यूजर आईडी को चिह्नित करता हूं, अगर यह एक गतिविधि शुरू करने जा रहा है, तो मैं जांच करूंगा कि यह उपयोगकर्ता के लिए 'ProfileActivity' है या नहीं। । यदि ऐसा है, तो बस 'फिनिश' () को कॉल करें और एक नया बनाने के बजाय पूर्व प्रोफाइल एक्टिविटी पर वापस जाएं। मेमोरी लीक होना दूसरी बात है।