2018: एंड्रॉइड इस मूल को जीवनचक्र के घटकों के माध्यम से समर्थन करता है।
मार्च 2018 अपडेट : अब एक बेहतर समाधान है। ProcessLifecycleOwner देखें । आपको नए आर्किटेक्चर घटकों का उपयोग करने की आवश्यकता होगी 1.1.0 (इस समय नवीनतम) लेकिन यह विशेष रूप से ऐसा करने के लिए डिज़ाइन किया गया है।
इस उत्तर में एक सरल नमूना प्रदान किया गया है लेकिन मैंने इसके बारे में एक नमूना ऐप और एक ब्लॉग पोस्ट लिखा है।
जब से मैंने 2014 में इसे वापस लिखा, तब से अलग-अलग समाधान सामने आए। कुछ ने काम किया, कुछ ने काम करने के लिए सोचा था, लेकिन खामियां थीं (मेरी सहित!) और हम, एक समुदाय के रूप में (एंड्रॉइड) ने परिणामों के साथ रहना सीखा और विशेष मामलों के लिए वर्कअराउंड लिखा।
कोड का एक भी स्निपेट कभी नहीं मानें कि आप जिस समाधान की तलाश कर रहे हैं, यह संभावना नहीं है; बेहतर अभी तक, यह समझने की कोशिश करें कि यह क्या करता है और यह क्यों करता है।
MemoryBossवर्ग वास्तव में कभी के रूप में यहाँ लिखा मेरे द्वारा इस्तेमाल किया गया था, यह सिर्फ छद्म कोड है कि काम का क्या हुआ का एक टुकड़ा था।
जब तक आपके पास नए आर्किटेक्चर घटकों का उपयोग न करने का वैध कारण है (और कुछ हैं, खासकर यदि आप सुपर पुरानी एपिस को लक्षित करते हैं), तो आगे बढ़ें और उनका उपयोग करें। वे सही से बहुत दूर हैं, लेकिन न तो थे ComponentCallbacks2।
अद्यतन / सूचना (नवंबर 2015) : लोग दो टिप्पणियां कर रहे हैं, पहला यह है कि >=इसके बजाय इसका उपयोग किया जाना चाहिए ==क्योंकि प्रलेखन में कहा गया है कि आपको सटीक मानों की जांच नहीं करनी चाहिए । यह अधिकांश मामलों के लिए ठीक है, लेकिन ध्यान रखें कि यदि आप केवल ऐप के बैकग्राउंड में जाने पर कुछ करने की परवाह करते हैं , तो आपको == का उपयोग करना होगा और इसे दूसरे समाधान के साथ भी संयोजित करना होगा (जैसे कि एक्टिविटी लाइफसाइकल कॉलबैक), या आप आपका इच्छित प्रभाव नहीं मिल सकता है। उदाहरण (और यह मेरे साथ हुआ) यह है कि यदि आप लॉक करना चाहते हैंपासवर्ड स्क्रीन के साथ आपका ऐप जब यह पृष्ठभूमि पर जाता है (जैसे 1Password अगर आप इससे परिचित हैं), तो आप गलती से अपने ऐप को लॉक कर सकते हैं यदि आप मेमोरी पर कम चलाते हैं और अचानक परीक्षण कर रहे हैं >= TRIM_MEMORY, क्योंकि एंड्रॉइड एक LOW MEMORYकॉल को ट्रिगर करेगा और वह है तुम्हारी तुलना में अधिक है। इसलिए सावधान रहें कि आप कैसे / क्या परीक्षण करते हैं।
इसके अतिरिक्त, कुछ लोगों ने पूछा है कि जब आप वापस आते हैं, तो कैसे पता लगाया जाए।
सबसे आसान तरीका जिसके बारे में मैं नीचे बता सकता हूं, लेकिन चूंकि कुछ लोग इससे अपरिचित हैं, इसलिए मैं यहां कुछ छद्म कोड जोड़ रहा हूं। आप YourApplicationऔर MemoryBossवर्गों को मानकर , अपने में class BaseActivity extends Activity(आपको एक बनाने की आवश्यकता होगी यदि आपके पास एक नहीं है)।
@Override
protected void onStart() {
super.onStart();
if (mApplication.wasInBackground()) {
// HERE YOU CALL THE CODE YOU WANT TO HAPPEN ONLY ONCE WHEN YOUR APP WAS RESUMED FROM BACKGROUND
mApplication.setWasInBackground(false);
}
}
मैं सलाह देता हूं कि क्योंकि संवाद एक गतिविधि को रोक सकता है इसलिए मैं शर्त लगाता हूं कि आप नहीं चाहते कि आपका ऐप "यह पृष्ठभूमि में चला गया" यदि आप सभी ने एक पूर्ण स्क्रीन संवाद प्रदर्शित किया था, लेकिन आपका लाभ भिन्न हो सकता है।
और बस यही। अगर ब्लॉक में कोड होगा केवल एक बार निष्पादित किया , भले ही आप किसी अन्य गतिविधि के लिए जाना, नया एक (जो भी extends BaseActivity) रिपोर्ट करेंगे wasInBackgroundहै false, तो यह कोड निष्पादित नहीं होगा जब तक onMemoryTrimmedकहा जाता है और झंडा फिर से सही पर सेट है ।
उम्मीद है की वो मदद करदे।
अद्यतन / नोट (अप्रैल 2015) : इससे पहले कि आप सभी इस कोड पर कॉपी और पेस्ट करें, ध्यान दें कि मुझे कुछ ऐसे उदाहरण मिले हैं जहां यह 100% विश्वसनीय नहीं हो सकता है और सर्वोत्तम परिणाम प्राप्त करने के लिए अन्य तरीकों के साथ जोड़ा जाना चाहिए । उल्लेखनीय रूप से, दो ज्ञात उदाहरण हैं जहां onTrimMemoryकॉल बैक को निष्पादित करने की गारंटी नहीं है:
यदि आपका फ़ोन स्क्रीन पर दिखाई देता है, जबकि आपका ऐप दिखाई देता है (जैसे कि nn मिनट के बाद आपका डिवाइस लॉक हो जाता है), इस कॉलबैक को (या हमेशा नहीं) कहा जाता है क्योंकि लॉकस्क्रीन अभी शीर्ष पर है, लेकिन आपका ऐप अभी भी "चल रहा है" यद्यपि कवर किया हुआ है।
यदि आपका डिवाइस मेमोरी (और मेमोरी स्ट्रेस के तहत) पर अपेक्षाकृत कम है, तो ऑपरेटिंग सिस्टम इस कॉल को अनदेखा करता है और सीधे अधिक महत्वपूर्ण स्तरों पर जाता है।
अब, आपके लिए यह जानना कितना ज़रूरी है कि आपका ऐप कब बैकग्राउंड में चला गया है, आपको गतिविधि जीवनचक्र और व्हाट्सएप पर नज़र रखने के साथ इस समाधान का विस्तार करने की आवश्यकता हो सकती है या नहीं।
बस उपरोक्त को ध्यान में रखें और एक अच्छी क्यूए टीम है;)
अद्यतन का अंत
यह देर हो सकती है लेकिन आइसक्रीम सैंडविच (एपीआई 14) और इसके बाद के संस्करण में एक विश्वसनीय विधि है ।
यह बताता है कि जब आपके ऐप में UI दिखाई नहीं देता है, तो कॉलबैक शुरू हो जाता है। कॉलबैक, जिसे आप एक कस्टम वर्ग में लागू कर सकते हैं, को ComponentCallbacks2 (हाँ, दो के साथ) कहा जाता है । यह कॉलबैक केवल एपीआई स्तर 14 (आइसक्रीम सैंडविच) और इसके बाद के संस्करण में उपलब्ध है।
आपको मूल रूप से विधि के लिए एक कॉल मिलता है:
public abstract void onTrimMemory (int level)
स्तर 20 या अधिक विशेष रूप से है
public static final int TRIM_MEMORY_UI_HIDDEN
मैं यह परीक्षण कर रहा हूं और यह हमेशा काम करता है, क्योंकि स्तर 20 सिर्फ एक "सुझाव" है जिसे आप कुछ संसाधनों को जारी करना चाहते हैं क्योंकि आपका ऐप अब दिखाई नहीं देता है।
आधिकारिक डॉक्स को उद्धृत करने के लिए:
OnTrimMemory (int) के लिए स्तर: प्रक्रिया उपयोगकर्ता इंटरफ़ेस दिखा रही थी, और अब ऐसा नहीं कर रही है। यूआई के साथ बड़े आवंटन को इस बिंदु पर जारी किया जाना चाहिए ताकि स्मृति को बेहतर तरीके से प्रबंधित किया जा सके।
बेशक, आप यह लागू वास्तव में यह क्या कहते हैं (स्मृति साफ है कि कुछ समय में उपयोग नहीं किया जा करने के लिए करना चाहिए, कुछ संग्रह है कि अप्रयुक्त बैठे, आदि संभावनाएं अनंत हैं (अन्य संभावित लिए सरकारी दस्तावेज़ देख सकेंगे स्पष्ट अधिक महत्वपूर्ण स्तर)।
लेकिन, दिलचस्प बात यह है कि ओएस आपको बता रहा है: अरे, आपका ऐप पृष्ठभूमि पर चला गया!
वही है जो आप पहली बार में जानना चाहते थे।
जब आप वापस आ गए तो आप कैसे निर्धारित करते हैं?
खैर यह आसान है, मुझे यकीन है कि आपके पास एक "बेसएक्टिविटी" है, ताकि आप अपने onResume () का उपयोग इस तथ्य को चिह्नित करने के लिए कर सकें कि आप वापस आ गए हैं। क्योंकि केवल समय आप कह रहे हैं कि आप वापस नहीं हैं जब आप वास्तव में उपरोक्त onTrimMemoryविधि के लिए कॉल प्राप्त करते हैं ।
यह काम करता हैं। आपको झूठी सकारात्मकता नहीं मिलती। यदि कोई गतिविधि फिर से शुरू हो रही है, तो आप 100% बार वापस आ जाते हैं। यदि उपयोगकर्ता फिर से पीछे जाता है, तो आपको एक और onTrimMemory()कॉल मिलती है ।
आपको अपनी गतिविधियाँ (या बेहतर अभी तक, एक कस्टम वर्ग) का पता लगाने की आवश्यकता है।
यह गारंटी देने का सबसे आसान तरीका है कि आप इसे हमेशा प्राप्त करें, इस तरह से एक साधारण वर्ग बनाना है:
public class MemoryBoss implements ComponentCallbacks2 {
@Override
public void onConfigurationChanged(final Configuration newConfig) {
}
@Override
public void onLowMemory() {
}
@Override
public void onTrimMemory(final int level) {
if (level == ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
// We're in the Background
}
// you might as well implement some memory cleanup here and be a nice Android dev.
}
}
इसका उपयोग करने के लिए, आपके एप्लिकेशन कार्यान्वयन में ( आपके पास एक, राइट? ), कुछ इस तरह से करें:
MemoryBoss mMemoryBoss;
@Override
public void onCreate() {
super.onCreate();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
mMemoryBoss = new MemoryBoss();
registerComponentCallbacks(mMemoryBoss);
}
}
आप एक बनाते हैं, तो Interfaceआप एक जोड़ सकते हैं elseकि करने के लिए ifऔर लागू ComponentCallbacks(बिना 2) एपीआई 14. नीचे कुछ भी में प्रयोग किया जाता कॉलबैक केवल यही onLowMemory()तरीका है और कहा जाता है नहीं प्राप्त करता है जब आप पृष्ठभूमि में जाते , लेकिन आप इसे ट्रिम स्मृति का उपयोग करना चाहिए ।
अब अपना ऐप लॉन्च करें और घर दबाएं। आपकी onTrimMemory(final int level)विधि को बुलाया जाना चाहिए (संकेत: लॉगिंग जोड़ें)।
अंतिम चरण कॉलबैक से अपंजीकृत करना है। संभवत: सबसे अच्छी जगह onTerminate()आपके ऐप की विधि है, लेकिन , यह तरीका असली डिवाइस पर नहीं मिलता है:
/**
* This method is for use in emulated process environments. It will
* never be called on a production Android device, where processes are
* removed by simply killing them; no user code (including this callback)
* is executed when doing so.
*/
इसलिए जब तक आपके पास वास्तव में ऐसी स्थिति नहीं है जहां आप अब पंजीकृत नहीं होना चाहते हैं, तो आप सुरक्षा को अनदेखा कर सकते हैं, क्योंकि आपकी प्रक्रिया वैसे भी ओएस स्तर पर मर रही है।
यदि आप किसी बिंदु पर अपंजीकृत करने का निर्णय लेते हैं (यदि आप, उदाहरण के लिए, अपने ऐप को साफ करने और मरने के लिए शटडाउन तंत्र प्रदान करें), तो आप कर सकते हैं:
unregisterComponentCallbacks(mMemoryBoss);
और बस।
