लार्जहाइप को सच करने के क्या फायदे हैं?

Question

मेरे पास लगभग 50 वर्गों के साथ एक ऐप है जिसे मैं सेट android:largeHeap="true"कर रहा हूं , जैसा कि नीचे देखा जा सकता है। क्या यह अच्छा अभ्यास है?

<application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="Mall"
        android:largeHeap="true"
        android:logo="@drawable/logo_for_up"
        android:screenOrientation="portrait"
        android:theme="@style/AppTheme" >
</application>

इसका उपयोग करने के लिए कृपया फायदे और नुकसान का सुझाव दें।

मुझे स्मृति के मुद्दे मिल रहे हैं इसलिए मैं यह सवाल पूछ रहा हूं।

Comments

अगर आपको अपने ऐप के लिए बड़ी मेमोरी की आवश्यकता है जैसे गेम्स 3

— डीमॉडल

50 कक्षाएं कई नहीं हैं।

— क्रिस हेस

developer.android.com/training/articles/memory.html

— जानुप्रसाद

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

— अदिति ११

वर्गों की संख्या महत्वपूर्ण नहीं है। आम तौर पर बहुत सारी मेमोरी लेने पर बिटमैप होता है। " मेमोरी में स्केल्ड डाउन संस्करण लोड करें " देखें ।

— टूलमेकर

Answer 1

यहां पार्टी के लिए बहुत देर हो चुकी है, लेकिन मैं अपने 0.02 $ रास्ते की पेशकश करूंगा।
यह android:largeHeap="true" यहाँ उपयोग करने के लिए एक अच्छा विचार नहीं है जो Google से निकालने वाला है जो इसे समझाता है,

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

यहाँ प्रलेखन का पूरा लिंक है https://developer.android.com/training/articles/memory.html है

अपडेट करें

साथ काम करने के बाद excrutiatingly out of memory errors मैं कहना चाहूंगा कि मुद्दे से बचने के लिए इसे प्रकट करना एक पाप नहीं है, @Milad बिंदुओं की तरह यह भी एप के सामान्य कामकाज को प्रभावित नहीं करता है

अद्यतन २

यहां कुछ उपाय बताए गए हैं साथout of memory errors

1) इन कॉलबैक कि एंड्रॉयड देता है का उपयोग करें onLowMemory, onTrimMemory(int) और (पिकासो, ग्लाइड, फ्रेस्को ....) आप उनके बारे में अधिक पढ़ सकते हैं की तरह छवि के कैश को साफ़ यहाँ और यहाँ
2) सेक अपनी फ़ाइलें (चित्र, पीडीएफ)
3) के बारे में पढ़ा बिटमैप को अधिक कुशलता से कैसे संभालना है
4) उत्पादन को बढ़ाने से पहले नियमित रूप से लिंट का उपयोग करें ताकि यह सुनिश्चित हो सके कि कोड चिकना है और भारी नहीं है

Comments

आप क्यों कहते हैं "यह ऐप के सामान्य कामकाज को प्रभावित नहीं करता है"? यह उत्तर कुछ परिणामों पर चर्चा करता है। अन्य जगहों पर, मैंने कुछ ऐप्स पर लार्जएचईपी जीसी के लिए और भी बदतर समय मापा है।

— टूलमेकर

Answer 2

मुझे लगता है कि यह एक बहुत प्रभावी प्रश्न है, और मुझे इस विकल्प का उपयोग करने के फायदे और नुकसान के बारे में कुछ विवरण जोड़ना चाहिए।

क्या आपको मिला :

• जाहिर है, आप बड़े ढेर हो जाते हैं, जिसका मतलब है कि जोखिम कम होना OutOfMemoryError।

आप क्या खो देते हैं:

• आप कुछ फ़्रेम खो सकते हैं, जो दृश्यमान अड़चन पैदा कर सकता है । बड़े ढेर कचरा संग्रहण में अधिक समय लेते हैं। क्योंकि कचरा संग्रहकर्ता को मूल रूप से वस्तुओं के आपके पूरे लाइव सेट का पता लगाना होता है। आमतौर पर, कचरा संग्रहण ठहराव का समय लगभग 5ms है, और आप सोच सकते हैं कि कुछ मिलीसेकंड कोई बड़ी बात नहीं है। लेकिन हर मिलीसेकंड गिनती। एंड्रॉइड डिवाइस को हर 16 एमएस में अपनी स्क्रीन को अपडेट करना पड़ता है और जीसी समय आपके फ़्रेम प्रसंस्करण समय को 16 मिलीसेकंड बाधा से अधिक धक्का दे सकता है, जिससे एक दृश्य अड़चन हो सकती है।

• साथ ही ऐप्स स्विच करना धीमा हो जाएगा । एंड्रॉइड सिस्टम LRU कैश में प्रक्रियाओं को कम से कम हाल ही में उपयोग की गई प्रक्रिया के साथ मार सकता है, लेकिन यह भी कुछ विचार दे रहा है कि कौन सी प्रक्रियाएं सबसे अधिक स्मृति गहन हैं। इसलिए यदि आप बड़े हीप का उपयोग करते हैं, तो आपकी प्रक्रिया पृष्ठभूमि होने पर मारे जाने की अधिक संभावना होगी, जिसका अर्थ है कि जब उपयोगकर्ता अन्य ऐप्स से आपका स्विच करना चाहते हैं, तो इसमें अधिक समय लग सकता है। इसके अलावा, अन्य पृष्ठभूमि वाली प्रक्रियाओं को आपकी प्रक्रिया के अग्रभूमि होने पर बाहर किए जाने की संभावना होगी, क्योंकि आपके ऐप में बड़ी मेमोरी की आवश्यकता होती है। इसका मतलब है कि आपके ऐप से अन्य ऐप में स्विच करने में भी अधिक समय लगता है।

निष्कर्ष:

largeHeapजितना हो सके विकल्प का उपयोग करने से बचें । यह आपको मुश्किल-से-नोटिस प्रदर्शन ड्रॉप और खराब उपयोगकर्ता अनुभव का अनुभव हो सकता है।

Answer 3

मेरे पास लगभग 50 वर्गों के साथ एक ऐप है

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

आप पिकासो , यूआईएल या ग्लाइड जैसे इमेज लोडिंग लाइब्रेरी का भी उपयोग कर सकते हैं । इन सभी में मेमोरी और / या डिस्क पर इमेज कैशिंग की सुविधा है।

Comments

छवि लोडिंग के लिए मैं आमतौर पर

— पिकासो

ग्लाइड बेहतर है और थोड़ा और अधिक अनुकूलित है तो पिकासो

— डेमियन प्राका

@DamienPraca मुझे नहीं लगता, कम से कम यदि आप पिकासो में टैग्स (सेटटैग (), पॉज़टैग (), रिज्यूमटैग ()) का सही उपयोग करते हैं।

— रुसलान फिरोजोव

Answer 4

वास्तव में एंड्रॉइड: लार्जहीप आपके आवंटित मेमोरी को ऐप में बढ़ाने का साधन है।

इस ध्वज का उपयोग करने की आवश्यकता की कोई स्पष्ट परिभाषा नहीं है। यदि आपको अधिक मेमोरी की आवश्यकता है - एंड्रॉइड आपको इसे बढ़ाने के लिए एक उपकरण प्रदान करता है। लेकिन उपयोग की आवश्यकता, आप खुद को परिभाषित करते हैं।

Comments

हाँ इस लिंक को देखें एक स्पष्ट परिभाषा है। डेवलपर

— ।android.com

@war_Hero - शायद उस लेख ने अपनी सामग्री बदल दी है? इसमें लार्जएप का कोई जिक्र नहीं है।

— टूलमेकरसेव

Answer 5

यदि आपको बड़ी मात्रा में मेमोरी का उपयोग करना चाहिए (और बनाए रखना चाहिए ), तो हां, आप कर सकते हैं और उपयोग करना चाहिए android:largeHeap="true"। लेकिन अगर आप इसका उपयोग करते हैं, तो आपको अपने ऐप को मेमोरी से फ्लश करने के लिए तैयार रहना चाहिए जब भी अन्य ऐप अग्रभूमि में हों।

"तैयार रहें," मेरा मतलब है कि आपको उस संभावना के लिए डिज़ाइन करना चाहिए, ताकि आपकी onStop()औरonResume() तरीकों को यथासंभव कुशलता से लिखा जाए, यह सुनिश्चित करते हुए कि सभी प्रासंगिक स्थिति को बचाया जाता है और इस तरह से बहाल किया जाता है जो उपयोगकर्ता के लिए एक सहज उपस्थिति प्रस्तुत करता है।

वहाँ तीन तरीकों कि इस पैरामीटर से संबंधित हैं: maxMemory(),getMemoryClass() , और getLargeMemoryClass()।

अधिकांश उपकरणों के लिए, maxMemory() एक समान मूल्य का प्रतिनिधित्व करेगाgetMemoryClass() डिफ़ॉल्ट रूप , हालांकि बाद के मेगाबाइट में व्यक्त किया गया है, जबकि पूर्व बाइट्स में व्यक्त किया गया है।

जब आप largeHeapपैरामीटर का उपयोग करते हैं,maxMemory() तो डिवाइस-विशिष्ट उच्च स्तर तक बढ़ा दिया getMemoryClass()जाएगा , जबकि यह समान रहेगा।

getMemoryClass()आपके ढेर के आकार को बाधित नहीं करता है, लेकिन यह आपको बताता है कि यदि आप अपने ऐप को उस विशेष डिवाइस की सीमा के भीतर आराम से और मज़बूती से काम करना चाहते हैं जिस पर आप चल रहे हैं, तो आपको कितनी मात्रा में उपयोग करना चाहिए ।

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

आपका ऐप वास्तव में यह पता लगा सकता है कि किसी विशेष डिवाइस पर largeHeapपैरामीटर का उपयोग करके पैरामीटर को मेमोरी के माध्यम से कितना मेमोरी उपलब्ध कराया जाएगाgetLargeMemoryClass() । लौटाया गया मान मेगाबाइट में है।

इस पहले की पोस्ट में की चर्चा शामिल है largeHeap पैरामीटर , साथ ही कई विशिष्ट एंड्रॉइड डिवाइसों पर इसके उपयोग के बिना और उसके उपयोग के बिना ढेर की कितनी मात्रा में उपलब्ध कराया गया है, इसके कई उदाहरण हैं:

Android में एप्लिकेशन हीप आकार का पता लगाएं

मैंने इस पैरामीटर के साथ अपना कोई भी ऐप सही पर सेट नहीं किया है। हालाँकि, ऑप्टिमाइज़-संबंधित मापदंडों के सेट को संकलित करने के लिए मेरे एक ऐप में कुछ मेमोरी-इंटेंसिव कोड है, जो केवल विकास के दौरान चलता है। मैं largeHeapइस कोड को चलाते समय मेमोरी त्रुटियों से बचने के लिए, केवल विकास के दौरान पैरामीटर जोड़ता हूं । लेकिन मैं एप्लिकेशन को लागू करने से पहले पैरामीटर (और कोड) को हटा देता हूं।

Comments

"सभी सावधानी बरतें और ऑल-यू-टू-ईट बुफे के माध्यम से अपना रास्ता छोड़ें" ua

— जोशुआ पिंटर

Answer 6

क्या आपके आवेदन की प्रक्रियाएं एक बड़े Dalvik ढेर के साथ बनाई जानी चाहिए। यह आवेदन के लिए बनाई गई सभी प्रक्रियाओं पर लागू होता है। यह केवल एक प्रक्रिया में लोड किए गए पहले आवेदन पर लागू होता है; यदि आप एक साझा उपयोगकर्ता आईडी का उपयोग कर रहे हैं, तो कई अनुप्रयोगों को एक प्रक्रिया का उपयोग करने की अनुमति देने के लिए, वे सभी को लगातार इस विकल्प का उपयोग करना होगा या उनके अप्रत्याशित परिणाम होंगे।

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