एंड्रॉइड में जीसी कार्यक्रमों को कैसे सुनें

Question

क्या वैसे भी हम एंड्रॉइड में जीसी घटनाओं की निगरानी कर सकते हैं?

जावा में, मुझे विश्वास है कि हम घटनाओं को सुन सकते हैं http://www.fasterj.com/articles/gcnotifs.shtml लेकिन java.lang.management API एंड्रॉइड में उपलब्ध नहीं हैं।

Answer 1

आप यह श्रोता क्यों चाहते हैं। आप बस कि आपके ऐप में स्मृति से बाहर चल रहा है जानना चाहते हैं तो बस इस जाँच: के रूप में स्मृति तंग

हो जाता है को अपने ऐप्लिकेशन के जीवन चक्र के किसी भी चरण के दौरान

रिलीज स्मृति, onTrimMemory() कॉलबैक भी बताता है कि कुल डिवाइस मेमोरी कम हो रही है। आप आगे() onTrimMemory द्वारा दिया निम्नलिखित स्मृति स्तरों के आधार पर संसाधनों जारी करके जवाब देना चाहिए:

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

• TRIM_MEMORY_RUNNING_CRITICAL आपका ऐप अभी भी चल रहा है, लेकिन सिस्टम ने पहले ही एलआरयू कैश में अधिकांश प्रक्रियाओं को मार दिया है, इसलिए आपको अब सभी गैर-महत्वपूर्ण संसाधनों को छोड़ना चाहिए। यदि सिस्टम पर्याप्त मात्रा में रैम को पुनः प्राप्त नहीं कर सकता है, तो यह सभी एलआरयू कैश को साफ़ कर देगा और उन प्रक्रियाओं को मारना शुरू कर देगा जो सिस्टम जीवित रहने की पसंद करते हैं, जैसे चल रहे सेवा की मेजबानी करना। इसके अलावा, जब अपने अनुप्रयोग प्रक्रिया वर्तमान में कैश किया गया है, तो आप onTrimMemory से निम्न स्तर() में से एक प्राप्त हो सकता है:

• TRIM_MEMORY_BACKGROUND सिस्टम स्मृति कम हो रही है और अपने प्रक्रिया LRU सूची की शुरुआत के पास है। यद्यपि आपकी ऐप प्रक्रिया को मारने के उच्च जोखिम पर नहीं है, लेकिन सिस्टम एलआरयू कैश में पहले से ही प्रक्रियाओं को मार रहा है। आपको संसाधनों को पुनर्प्राप्त करना चाहिए जो पुनर्प्राप्त करना आसान है, इसलिए आपकी प्रक्रिया सूची में रहेगी और उपयोगकर्ता आपके ऐप पर वापस आने पर जल्दी से फिर से शुरू होगा।

• TRIM_MEMORY_MODERATE सिस्टम स्मृति पर कम चल रहा है और आपकी प्रक्रिया एलआरयू सूची के मध्य के पास है। अगर प्रणाली स्मृति के लिए और बाध्य हो जाती है, तो एक मौका है कि आपकी प्रक्रिया मारे जायेगी।
• TRIM_MEMORY_COMPLETE सिस्टम मेमोरी पर कम चल रहा है और सिस्टम अब स्मृति में पुनर्प्राप्त नहीं होने पर मारने वाले पहले व्यक्ति में से एक है। आपको अपनी ऐप स्थिति को फिर से शुरू करने के लिए महत्वपूर्ण नहीं है जो सब कुछ जारी करना चाहिए। क्योंकि onTrimMemory() कॉलबैक एपीआई स्तर 14 में जोड़ा गया था, इसलिए आप पुराने संस्करणों के लिए फॉलबैक के रूप में ऑनमोमरी() कॉलबैक का उपयोग कर सकते हैं, जो लगभग TRIM_MEMORY_COMPLETE ईवेंट के बराबर है।

यहाँ संदर्भ लिंक https://developer.android.com/training/articles/memory.html

Answer 2

ठीक है, यह दोनों Dalvik और कला के लिए अलग होगा ..

मूल रूप से आप एक ट्रेस फ़ाइल में जीसी घटनाओं को दर्ज करने के adb शेल निर्देश दे सकते हैं है ..

कला: https://source.android.com/devices/tech/dalvik/gc-debug.html

यह भी दोनों कला और Dalvik के लिए एक ही एडीबी आदेशों हो सकता है।

मेमोरी मॉनिटर टूल इसमें प्लग करता है जब यह एंड्रॉइड स्टूडियो में आपके लिए स्मृति के उस ग्राफिकल चार्ट को प्रदर्शित करता है।

प्रोगामैटिकली, शायद कठिन है .. इस बात पर ध्यान दें कि एफबी ने अपना प्रदर्शन टूलिंग कैसे किया क्योंकि मुझे विश्वास है कि वे मूल सी/सी ++ पक्ष से जीसी इवेंट की गणना कर रहे हैं और उन्हें अपने साइड प्रोफाइलिंग टूल कोड के लिए फ्लैटबफर में एकत्रित कर रहे हैं। पहुंचने के लिए ..