स्‍मृति उपयोग अनुकूलित करें

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

मेमोरी को ऑप्टिमाइज़ करना ज़रूरी है, ताकि ऐप्लिकेशन को क्रैश होने से बचाया जा सके और सिस्टम और प्लैटफ़ॉर्म की परफ़ॉर्मेंस को बेहतर बनाया जा सके. हर ऐप्लिकेशन में, मेमोरी के इस्तेमाल को मॉनिटर और ऑप्टिमाइज़ किया जाना चाहिए. हालांकि, टीवी के लिए कॉन्टेंट ऐप्लिकेशन वाले डिवाइसों में कुछ खास समस्याएं होती हैं, जो हाथ में पकड़े जाने वाले डिवाइसों के लिए सामान्य Android ऐप्लिकेशन से अलग होती हैं.

ज़्यादा मेमोरी खर्च होने पर, ऐप्लिकेशन और सिस्टम के काम करने के तरीके में समस्याएं आ सकती हैं. इनमें ये शामिल हैं:

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

टीवी डिवाइसों पर मेमोरी से जुड़ी बातें

आम तौर पर, टीवी डिवाइसों में फ़ोन या टैबलेट की तुलना में काफ़ी कम मेमोरी होती है. उदाहरण के लिए, टीवी पर हमें 1 जीबी रैम और 1080 पिक्सल वीडियो रिज़ॉल्यूशन वाला कॉन्फ़िगरेशन दिख सकता है. साथ ही, ज़्यादातर टीवी ऐप्लिकेशन में मिलती-जुलती सुविधाएं होती हैं. इसलिए, इन्हें लागू करने का तरीका और आम तौर पर आने वाली समस्याएं भी एक जैसी होती हैं. इन दोनों स्थितियों में ऐसी समस्याएं आती हैं जो दूसरे डिवाइसों और ऐप्लिकेशन में नहीं आती हैं:

• मीडिया टीवी ऐप्लिकेशन में आम तौर पर, ग्रिड में व्यवस्थित इमेज व्यू और फ़ुलस्क्रीन बैकग्राउंड इमेज, दोनों शामिल होते हैं. इनमें कम समय में, ज़्यादा इमेज को मेमोरी में लोड करना ज़रूरी होता है
• टीवी ऐप्लिकेशन, मल्टीमीडिया स्ट्रीम चलाते हैं. इनमें वीडियो और ऑडियो चलाने के लिए, कुछ मेमोरी को ऐलोकेट करना ज़रूरी होता है. साथ ही, वीडियो को बिना किसी रुकावट के चलाने के लिए, ज़रूरत के मुताबिक मीडिया बफ़र की ज़रूरत होती है.
• मीडिया की अन्य सुविधाओं (वीडियो पर आगे-पीछे जाना, एपिसोड बदलना, ऑडियो ट्रैक बदलना वगैरह) को ठीक से लागू न करने पर, मेमोरी पर ज़्यादा दबाव पड़ सकता है.

टीवी डिवाइसों के बारे में जानकारी

इस गाइड में मुख्य रूप से, कम रैम वाले डिवाइसों के लिए, ऐप्लिकेशन के मेमोरी इस्तेमाल और मेमोरी टारगेट पर फ़ोकस किया गया है.

टीवी डिवाइसों पर, इन बातों का ध्यान रखें:

• डिवाइस की मेमोरी: डिवाइस में इंस्टॉल की गई रैंडम ऐक्सेस मेमोरी (रैम) की मात्रा.
• डिवाइस के यूज़र इंटरफ़ेस (यूआई) का रिज़ॉल्यूशन: यह वह रिज़ॉल्यूशन होता है जिसका इस्तेमाल डिवाइस, ओएस और ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) को रेंडर करने के लिए करता है. आम तौर पर, यह डिवाइस के वीडियो रिज़ॉल्यूशन से कम होता है.
• वीडियो रिज़ॉल्यूशन: यह वह ज़्यादा से ज़्यादा रिज़ॉल्यूशन होता है जिस पर डिवाइस वीडियो चला सकता है.

इससे अलग-अलग तरह के डिवाइसों की कैटगरी तय की जा सकती है. साथ ही, यह भी तय किया जा सकता है कि उन डिवाइसों को मेमोरी का इस्तेमाल कैसे करना चाहिए.

टीवी डिवाइसों की खास जानकारी

कम रैम वाले टीवी डिवाइस

ये डिवाइस मेमोरी की कमी की स्थिति में हैं और ActivityManager.isLowRAMDevice() को 'सही है' के तौर पर रिपोर्ट करेंगे. कम रैम वाले टीवी डिवाइसों पर चलने वाले ऐप्लिकेशन को, मेमोरी कंट्रोल करने के अन्य तरीके लागू करने होंगे.

हम इन सुविधाओं वाले डिवाइसों को इस कैटगरी में शामिल करते हैं:

• 1 जीबी डिवाइस: 1 जीबी रैम, 720 पिक्सल/एचडी (1280x720) यूज़र इंटरफ़ेस (यूआई) रिज़ॉल्यूशन, 1080 पिक्सल/फ़ुल एचडी (1920x1080) वीडियो रिज़ॉल्यूशन
• 1.5 जीबी डिवाइस: 1.5 जीबी रैम, 1080 पिक्सल/फ़ुल एचडी (1920x1080) यूज़र इंटरफ़ेस (यूआई) रिज़ॉल्यूशन, 2160 पिक्सल/अल्ट्रा एचडी/4K (3840x2160) वीडियो रिज़ॉल्यूशन
• अन्य स्थितियां, जिनमें OEM ने अतिरिक्त मेमोरी की समस्याओं की वजह से, ActivityManager.isLowRAMDevice() फ़्लैग तय किया है.

सामान्य टीवी डिवाइस

इन डिवाइसों में ज़्यादा मेमोरी का इस्तेमाल नहीं होता. हम इन डिवाइसों के लिए ये सुविधाएं मानते हैं:

• 1.5 जीबी से ज़्यादा रैम, 720 पिक्सल या 1080 पिक्सल का यूज़र इंटरफ़ेस (यूआई), और 1080 पिक्सल का वीडियो रिज़ॉल्यूशन
• 2 जीबी या उससे ज़्यादा रैम, 1080 पिक्सल का यूज़र इंटरफ़ेस (यूआई), और 1080 पिक्सल या 2160 पिक्सल का वीडियो रिज़ॉल्यूशन

इसका मतलब यह नहीं है कि ऐप्लिकेशन को इन डिवाइसों पर मेमोरी के इस्तेमाल की परवाह नहीं करनी चाहिए. ऐसा इसलिए, क्योंकि मेमोरी के गलत इस्तेमाल से अब भी उपलब्ध मेमोरी खत्म हो सकती है और ऐप्लिकेशन की परफ़ॉर्मेंस खराब हो सकती है.

कम रैम वाले टीवी डिवाइसों के लिए मेमोरी टारगेट

इन डिवाइसों पर मेमोरी मेज़र करते समय, हमारा सुझाव है कि आप Android Studio मेमोरी प्रोफ़ाइलर का इस्तेमाल करके, मेमोरी के हर सेक्शन को मॉनिटर करें. टीवी ऐप्लिकेशन को अपनी मेमोरी के इस्तेमाल की प्रोफ़ाइल बनानी चाहिए. साथ ही, अपनी कैटगरी को इस सेक्शन में बताए गए थ्रेशोल्ड से नीचे रखना चाहिए.

स्टोरेज की गिनती कैसे की जाती है सेक्शन में, आपको स्टोरेज के आंकड़ों के बारे में पूरी जानकारी मिलेगी. टीवी ऐप्लिकेशन के लिए थ्रेशोल्ड तय करने के लिए, हम मेमोरी की तीन कैटगरी पर फ़ोकस करेंगे:

• अनाम + स्वैप: यह Android Studio में, Java + नेटिव + स्टैक ऐलोकेशन मेमोरी से बना होता है.
• ग्राफ़िक्स: प्रोफ़ाइलर टूल पर सीधे तौर पर रिपोर्ट की जाती है. आम तौर पर, इसमें ग्राफ़िक्स टेक्सचर होते हैं.
• फ़ाइल: Android Studio में, "कोड" + "अन्य" कैटगरी के तौर पर रिपोर्ट की गई.

इन परिभाषाओं के आधार पर, यहां दी गई टेबल से पता चलता है कि हर तरह के मेमोरी ग्रुप को ज़्यादा से ज़्यादा कितनी वैल्यू का इस्तेमाल करना चाहिए:

कुल मेमोरी (Anon+Swap + Graphics + File) इनसे ज़्यादा नहीं होनी चाहिए:

• 1 जीबी रैम वाले डिवाइसों के लिए, कुल मेमोरी का इस्तेमाल (Anon+Swap + Graphics + File) 280 एमबी.

हमारा सुझाव है कि आप इनसे ज़्यादा न करें:

• Anon+Swap + Graphics पर 200 एमबी मेमोरी का इस्तेमाल.

फ़ाइल मेमोरी

फ़ाइल बैक अप की गई मेमोरी के लिए सामान्य दिशा-निर्देश के तौर पर, इन बातों का ध्यान रखें:

• आम तौर पर, फ़ाइल मेमोरी को ओएस मेमोरी मैनेजमेंट की मदद से अच्छी तरह से मैनेज किया जाता है.
• फ़िलहाल, हमें इसकी वजह से मेमोरी का दबाव बढ़ने की कोई बड़ी वजह नहीं मिली है.

हालांकि, आम तौर पर फ़ाइल मेमोरी का इस्तेमाल करते समय:

• अपने बिल्ड में इस्तेमाल न की गई लाइब्रेरी शामिल न करें. साथ ही, जब भी हो सके, लाइब्रेरी के पूरे सेट के बजाय छोटे सबसेट का इस्तेमाल करें.
• बड़ी फ़ाइलों को मेमोरी में खुला न रखें. साथ ही, काम पूरा होने के बाद उन्हें तुरंत बंद कर दें.
• Java और Kotlin क्लास के लिए, कंपाइल किए गए कोड का साइज़ कम करें. इसके लिए, अपने ऐप्लिकेशन को छोटा करें, उसे अस्पष्ट बनाएं, और ऑप्टिमाइज़ करें गाइड देखें.

टीवी के लिए खास सुझाव

इस सेक्शन में, टीवी डिवाइसों पर मेमोरी के इस्तेमाल को ऑप्टिमाइज़ करने के लिए खास सुझाव दिए गए हैं.

ग्राफ़िक्स मेमोरी

इमेज के सही फ़ॉर्मैट और रिज़ॉल्यूशन का इस्तेमाल करें.

• डिवाइस के यूज़र इंटरफ़ेस (यूआई) के रिज़ॉल्यूशन से ज़्यादा रिज़ॉल्यूशन वाली इमेज लोड न करें. उदाहरण के लिए, 720p यूज़र इंटरफ़ेस (यूआई) वाले डिवाइस पर, 1080p इमेज को 720p में छोटा किया जाना चाहिए.
• जब भी हो सके, हार्डवेयर पर काम करने वाले बिटमैप का इस्तेमाल करें.
  • Glide जैसी लाइब्रेरी में, Downsampler.ALLOW_HARDWARE_CONFIG वाली सुविधा चालू करें. यह सुविधा डिफ़ॉल्ट रूप से बंद रहती है. इसे चालू करने से, बिटमैप के डुप्लीकेट वर्शन से बचा जा सकता है. ऐसा न करने पर, ये वर्शन ग्राफ़िक मेमोरी और अनाम मेमोरी, दोनों में सेव हो जाते हैं.
• इंटरमीडिएट रेंडर और फिर से रेंडर करने से बचें
  • Android GPU Inspector की मदद से, इनकी पहचान की जा सकती है:
  • "टेक्स्चर" सेक्शन में, ऐसी इमेज देखें जो आखिरी रेंडर के लिए ज़रूरी हैं, न कि सिर्फ़ उनका हिस्सा हैं. आम तौर पर, इन्हें "इंटरमीडिएट रेंडर" कहा जाता है.
  • Android SDK ऐप्लिकेशन के लिए, अक्सर इन्हें हटाया जा सकता है. इसके लिए, लेआउट के लिए इंटरमीडिएट रेंडर को बंद करने के लिए, लेआउट फ़्लैग forceHasOverlappedRendering:false का इस्तेमाल करें.
  • ओवरलैप होने वाले रेंडर से जुड़ी समस्या को हल करने के लिए, ओवरलैप होने वाले रेंडर से बचना लेख पढ़ें.
• जब भी हो सके, प्लेसहोल्डर इमेज लोड करने से बचें. प्लेसहोल्डर टेक्सचर के लिए, @android:color/ या @color का इस्तेमाल करें.
• अगर कॉम्पोज़िशन को ऑफ़लाइन किया जा सकता है, तो डिवाइस पर एक से ज़्यादा इमेज को कॉम्पोज़ करने से बचें. डाउनलोड की गई इमेज से इमेज कंपज़िशन करने के बजाय, अलग से इमेज लोड करना
• बिटमैप को बेहतर तरीके से मैनेज करने के लिए, बिटमैप मैनेज करना गाइड पढ़ें.

Anon+Swap मेमोरी

Anon+Swap, Android Studio के मेमोरी प्रोफ़ाइलर में नेटिव + Java + स्टैक ऐलोकेशन से बना होता है. डिवाइस में स्टोरेज की कमी है या नहीं, यह देखने के लिए ActivityManager.isLowMemoryDevice() का इस्तेमाल करें. साथ ही, इन दिशा-निर्देशों का पालन करके इस स्थिति से निपटें.

• मीडिया:
  • डिवाइस के रैम और वीडियो चलाने के रिज़ॉल्यूशन के आधार पर, मीडिया बफ़र के लिए अलग-अलग साइज़ तय करें. इसमें वीडियो चलाने का एक मिनट का समय शामिल होना चाहिए:
    1. 1 जीबी / 1080 पिक्सल के लिए 40 से 60 एमबी
    2. 1.5 जीबी / 1080 पिक्सल के लिए 60 से 80 एमबी
    3. 1.5 जीबी / 2160 पिक्सल के लिए 80 से 100 एमबी
    4. 2 जीबी / 2160 पिक्सल के लिए 100 से 120 एमबी
  • किसी एपिसोड को बदलते समय, मीडिया मेमोरी के लिए उपलब्ध जगह, ताकि एनोनीम मेमोरी की कुल संख्या में बढ़ोतरी न हो.
  • जब आपका ऐप्लिकेशन बंद हो जाए, तो मीडिया रिसॉर्स को तुरंत रिलीज़ करें और बंद करें: ऑडियो और वीडियो रिसॉर्स को मैनेज करने के लिए, गतिविधि के लाइफ़साइकल कॉलबैक का इस्तेमाल करें. अगर आपका ऐप्लिकेशन ऑडियो ऐप्लिकेशन नहीं है, तो अपनी गतिविधियों पर onStop() होने पर, प्लेबैक रोकें. साथ ही, अपना पूरा काम सेव करें और अपने संसाधनों को रिलीज़ करने के लिए सेट करें. बाद में ज़रूरी होने वाले काम को शेड्यूल करने के लिए. जॉब और अलार्म सेक्शन देखें.
    • LiveData और LifecycleOwner जैसे लाइफ़साइकल की जानकारी वाले कॉम्पोनेंट का इस्तेमाल करके, गतिविधि के लाइफ़साइकल कॉल को मैनेज किया जा सकता है.
    • अपने काम को लाइफ़साइकल के हिसाब से बनाने के लिए, Kotlin कोरूटीन और Kotlin फ़्लो का भी इस्तेमाल किया जा सकता है.
  • वीडियो पर आगे-पीछे जाने के दौरान बफ़र की मेमोरी पर ध्यान दें: डेवलपर अक्सर उपयोगकर्ता के लिए वीडियो तैयार करते समय, आने वाले समय के लिए 15 से 60 सेकंड का अतिरिक्त कॉन्टेंट तय करते हैं. हालांकि, इससे मेमोरी का इस्तेमाल ज़्यादा होता है. आम तौर पर, जब तक उपयोगकर्ता वीडियो की नई जगह नहीं चुन लेता, तब तक वीडियो को 5 सेकंड से ज़्यादा के लिए बफ़र न करें. अगर आपको वीडियो में आगे या पीछे जाने के दौरान, ज़्यादा समय के लिए वीडियो को पहले से बफ़र करना है, तो पक्का करें कि:
    • वीडियो में आगे-पीछे जाने के लिए, पहले से बफ़र का इस्तेमाल करें और उसका फिर से इस्तेमाल करें.
    • बफ़र का साइज़ 15 से 25 एमबी से ज़्यादा नहीं होना चाहिए. यह साइज़, डिवाइस की मेमोरी पर निर्भर करता है.
• अलोकेशन:
  • ग्राफ़िक मेमोरी से जुड़े दिशा-निर्देशों का इस्तेमाल करके पक्का करें कि आपने अनाम मेमोरी में इमेज की डुप्लीकेट कॉपी न बनाई हो
    • आम तौर पर, इमेज सबसे ज़्यादा मेमोरी का इस्तेमाल करती हैं. इसलिए, इमेज का डुप्लीकेट बनाना, डिवाइस पर ज़्यादा दबाव डाल सकता है. यह खास तौर पर, इमेज ग्रिडव्यू के ज़्यादा नेविगेशन के दौरान ज़्यादा सही होता है.
  • स्क्रीन पर आगे बढ़ते समय, रेफ़रंस हटाकर ऐलोकेशन रिलीज़ करना: पक्का करें कि बिटमैप और ऑब्जेक्ट के कोई रेफ़रंस न छूटे.
• लाइब्रेरी:
  • नई लाइब्रेरी जोड़ने पर, लाइब्रेरी से प्रोफ़ाइल मेमोरी का ऐलोकेशन, क्योंकि ये अतिरिक्त लाइब्रेरी भी लोड कर सकती हैं. ये लाइब्रेरी भी ऐलोकेशन कर सकती हैं और बाइंडिंग बना सकती हैं.
• नेटवर्किंग:
  • ऐप्लिकेशन के शुरू होने के दौरान, नेटवर्क कॉल को ब्लॉक न करें. इससे ऐप्लिकेशन के शुरू होने में लगने वाला समय बढ़ जाता है. साथ ही, ऐप्लिकेशन के लॉन्च होने पर ज़्यादा मेमोरी खर्च होती है. ऐसा इसलिए होता है, क्योंकि ऐप्लिकेशन लोड होने पर मेमोरी की कमी होती है. सबसे पहले लोडिंग या स्प्लैश स्क्रीन दिखाएं और यूज़र इंटरफ़ेस (यूआई) के लागू होने के बाद, नेटवर्क अनुरोध करें.

बाइंडिंग

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

सामान्य बाइंडिंग और सबसे सही तरीके:

• Play Integrity API: इसका इस्तेमाल, डिवाइस के पूरी तरह सुरक्षित होने की जांच करने के लिए किया जाता है
  • मीडिया चलाने से पहले और लोडिंग स्क्रीन के बाद, डिवाइस इंटिग्रिटी की जांच करना
  • कॉन्टेंट चलाने से पहले, PlayIntegrity के रेफ़रंस रिलीज़ करें StandardIntegrityManager.
• Play Billing Library: इसका इस्तेमाल, Google Play का इस्तेमाल करके ली गई सदस्यताओं और खरीदारी को मैनेज करने के लिए किया जाता है
  • लोडिंग स्क्रीन के बाद लाइब्रेरी को शुरू करें और कोई भी मीडिया चलाने से पहले, बिलिंग से जुड़े सभी कामों को मैनेज करें.
  • लाइब्रेरी का इस्तेमाल करने के बाद और वीडियो या मीडिया चलाने से पहले, BillingClient.endConnection() का इस्तेमाल करें.
  • अगर बिलिंग से जुड़ा कोई काम फिर से करना है, तो BillingClient.isReady() और BillingClient.getConnectionState() का इस्तेमाल करके देखें कि सेवा बंद हुई है या नहीं. इसके बाद, काम पूरा करने के बाद BillingClient.endConnection() का इस्तेमाल फिर से करें.
• GMS FontsProvider
  • कम रैम वाले डिवाइसों पर, फ़ॉन्ट उपलब्ध कराने वाली सेवाओं के बजाय, स्टैंडअलोन फ़ॉन्ट का इस्तेमाल करें. ऐसा इसलिए, क्योंकि फ़ॉन्ट डाउनलोड करने में ज़्यादा समय लगता है और FontsProvider इसे करने के लिए सेवाओं को बांध देगा.
• Google Assistant लाइब्रेरी: कभी-कभी, खोज और ऐप्लिकेशन में खोजने के लिए इसका इस्तेमाल किया जाता है. अगर हो सके, तो इस लाइब्रेरी को बदलें.
  • लीनबैक ऐप्लिकेशन के लिए: Gboard के टेक्स्ट को बोली में बदलने की सुविधा या androidx.leanback लाइब्रेरी का इस्तेमाल करें.
    • खोज की सुविधा लागू करने के लिए, Search के दिशा-निर्देशों का पालन करें.
    • ध्यान दें: leanback की सुविधा का इस्तेमाल बंद कर दिया गया है. इसलिए, ऐप्लिकेशन को TV Compose पर माइग्रेट कर दिया जाना चाहिए.
  • Compose ऐप्लिकेशन के लिए:
    • वॉइस सर्च की सुविधा इस्तेमाल करने के लिए, Gboard पर टेक्स्ट को बोली में बदलने की सुविधा का इस्तेमाल करें.
  • अपने ऐप्लिकेशन में मीडिया कॉन्टेंट को खोजा जा सके, इसके लिए अगला वीडियो देखें सुविधा लागू करें.

फ़ोरग्राउंड सेवाएं

फ़ोरग्राउंड सेवाएं, सूचना से जुड़ी एक खास तरह की सेवा होती हैं. यह सूचना, फ़ोन और टैबलेट पर सूचना ट्रे में दिखती है. हालांकि, टीवी डिवाइसों पर सूचना ट्रे नहीं होती. भले ही, फ़ोरग्राउंड सेवाएं काम की हों, क्योंकि ऐप्लिकेशन के बैकग्राउंड में रहने के दौरान भी उन्हें चालू रखा जा सकता है, लेकिन टीवी ऐप्लिकेशन को इन दिशा-निर्देशों का पालन करना होगा:

Android TV और Google TV में, उपयोगकर्ता के ऐप्लिकेशन से बाहर निकलने के बाद, फ़ोरग्राउंड सेवाओं को सिर्फ़ तब चलने की अनुमति है, जब:

• ऑडियो ऐप्लिकेशन के लिए: ऑडियो ट्रैक को चलाने के लिए, उपयोगकर्ता के ऐप्लिकेशन से बाहर निकलने के बाद, फ़ोरग्राउंड सेवाओं को सिर्फ़ तब चलने की अनुमति है. ऑडियो प्लेबैक खत्म होने के बाद, सेवा तुरंत बंद कर दी जानी चाहिए.
• किसी भी दूसरे ऐप्लिकेशन के लिए: सभी फ़ोरग्राउंड सेवाएं बंद होनी चाहिए. ऐसा उपयोगकर्ता के आपके ऐप्लिकेशन से बाहर निकलने के बाद करना ज़रूरी है, क्योंकि उपयोगकर्ता को यह सूचना नहीं दी जाती कि ऐप्लिकेशन अब भी चल रहा है और संसाधनों का इस्तेमाल कर रहा है.
• बैकग्राउंड में चलने वाली प्रोसेस के लिए, WorkManager का इस्तेमाल करें. जैसे, सुझाव अपडेट करना या अगला देखें.

जॉब और अलार्म

WorkManager बैकग्राउंड में बार-बार होने वाले कामों को शेड्यूल करने के लिए, यह सबसे आधुनिक Android API है. SDK टूल के 23 या इसके बाद के वर्शन में उपलब्ध होने पर, WorkManager नए JobScheduler का इस्तेमाल करेगा. अगर SDK टूल का वर्शन 23 या इसके बाद का नहीं है, तो वह पुराने AlarmManager का इस्तेमाल करेगा. टीवी पर शेड्यूल की गई जॉब को बेहतर तरीके से चलाने के लिए, ये सुझाव अपनाएं:

• SDK 23 और उसके बाद के वर्शन पर, AlarmManager एपीआई का इस्तेमाल न करें. खास तौर पर, AlarmManager.set(), AlarmManager.setExact(), और इससे मिलते-जुलते तरीकों का इस्तेमाल न करें. ऐसा इसलिए, क्योंकि ये सिस्टम को यह तय करने की अनुमति नहीं देते कि जॉब कब चलाए जाएं. उदाहरण के लिए, जब डिवाइस इस्तेमाल में न हो.
• कम रैम वाले डिवाइसों पर, ज़रूरत न होने पर जॉब न चलाएं. अगर ज़रूरी हो, तो WorkManager WorkRequest का इस्तेमाल करें. हालांकि, ऐसा सिर्फ़ वीडियो चलाने के बाद सुझावों को अपडेट करने के लिए करें. साथ ही, ऐप्लिकेशन खुला होने पर ऐसा करें.

• सिस्टम को सही समय पर आपके जॉब चलाने की अनुमति देने के लिए, WorkManager Constraints को तय करें:

Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresStorageNotLow(true)
    .setRequiresDeviceIdle(true)
    .build()

Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresStorageNotLow(true)
    .setRequiresDeviceIdle(true)
    .build()

• अगर आपको नियमित तौर पर जॉब चलाने हैं, तो मेमोरी का इस्तेमाल कम रखें. उदाहरण के लिए, किसी दूसरे डिवाइस पर आपके ऐप्लिकेशन में कॉन्टेंट देखने की गतिविधि के आधार पर, अगला वीडियो देखें को अपडेट करने के लिए. इसके लिए, जॉब की मेमोरी खपत को 30 एमबी से कम रखें.

मेमोरी से जुड़ी सामान्य बातें

यहां दिए गए दिशा-निर्देशों से, Android ऐप्लिकेशन डेवलप करने के बारे में सामान्य जानकारी मिलती है:

• ऑब्जेक्ट के ऐलोकेशन को कम करें, ऑब्जेक्ट के फिर से इस्तेमाल को ऑप्टिमाइज़ करें, और इस्तेमाल न किए गए किसी भी ऑब्जेक्ट को तुरंत अनअलोकेट करें.
  • ऑब्जेक्ट, खास तौर पर बिटमैप के रेफ़रंस न रखें.
  • System.gc() और मेमोरी रिलीज़ करने के डायरेक्ट कॉल का इस्तेमाल करने से बचें, क्योंकि ये सिस्टम की मेमोरी मैनेज करने की प्रोसेस में रुकावट डालते हैं: उदाहरण के लिए, zRAM का इस्तेमाल करने वाले डिवाइसों में, gc() को फ़ोर्स कॉल करने पर, मेमोरी को कंप्रेस और डिकंप्रेस करने की वजह से, कुछ समय के लिए मेमोरी का इस्तेमाल बढ़ सकता है.
  • LazyList का इस्तेमाल करें. जैसे, Compose में कैटलॉग ब्राउज़र में दिखाया गया है या अब बंद किए गए Leanback यूज़र इंटरफ़ेस (यूआई) टूलकिट में RecyclerView का इस्तेमाल करें. इससे, सूची के एलिमेंट को फिर से बनाने के बजाय, व्यू का फिर से इस्तेमाल किया जा सकता है.
  • बाहरी कॉन्टेंट की सेवा देने वाली कंपनियों से पढ़े गए ऐसे एलिमेंट को कैश मेमोरी में सेव करें जिनमें बदलाव होने की संभावना कम हो. साथ ही, अपडेट करने के इंटरवल तय करें, ताकि अतिरिक्त बाहरी मेमोरी को ऐलोकेट करने से रोका जा सके.
• मेमोरी लीक की जांच करें.
  • सामान्य तौर पर, मेमोरी लीक के मामलों से सावधान रहें. जैसे, अनाम थ्रेड में रेफ़रंस, वीडियो बफ़र को फिर से असाइन करना, जो कभी रिलीज़ नहीं होता, और ऐसी ही अन्य स्थितियां.
  • मेमोरी लीक को डीबग करने के लिए, हीप डंप का इस्तेमाल करें.
• बेसलाइन प्रोफ़ाइलें जनरेट करें, ताकि कोल्ड स्टार्ट पर ऐप्लिकेशन को चलाते समय, ज़रूरत के हिसाब से कंपाइलेशन की संख्या कम हो.

सीधे तौर पर मेमोरी वापस पाने की सुविधा के बारे में जानकारी

जब कोई Android TV ऐप्लिकेशन मेमोरी का अनुरोध करता है और सिस्टम पर दबाव पड़ता है, तो Android के आधार पर काम करने वाले Linux kernel को डायरेक्ट मेमोरी रीक्लेम का इस्तेमाल करना पड़ सकता है.

इस प्रोसेस में, मेमोरी को ऐलोकेट करने वाली किसी भी थ्रेड को पूरी तरह से रोकना शामिल है, ताकि खाली मेमोरी पेजों का इंतज़ार किया जा सके. ऐसा तब होता है, जब बैकग्राउंड में मेमोरी खाली करने की सुविधा, पहले से ज़रूरत के मुताबिक मेमोरी का पूल बनाए रखने में कामयाब न हो.

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

टूल की खास जानकारी

• Android Studio के मेमोरी प्रोफ़ाइलर टूल का इस्तेमाल करके, देखें कि ऐप्लिकेशन के इस्तेमाल के दौरान कितनी मेमोरी खर्च हुई.
  • किसी खास ऑब्जेक्ट और बिटमैप के लिए, heapdump का इस्तेमाल करके, एलोकेशन की जांच करें.
  • Java या Kotlin के अलावा किसी अन्य कोड के लिए मेमोरी का इस्तेमाल होने की जांच करने के लिए, नेटिव मेमोरी प्रोफ़ाइलर का इस्तेमाल करें.
• ग्राफ़िक्स के लिए एलोकेशन की जांच करने के लिए, Android GPU Inspector का इस्तेमाल करें.