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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इन डिवाइसों पर, मेमोरी से जुड़ी ऐसी कोई समस्या नहीं आती. हम इन डिवाइसों को इन सुविधाओं के साथ मानते हैं:

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

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

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

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

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

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

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

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

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

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

• (Anon+Swap + Graphics) पर 200 एमबी मेमोरी का इस्तेमाल किया गया है.

फ़ाइल मेमोरी

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

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

हालांकि, फ़ाइल की मेमोरी से जुड़ी सामान्य समस्याओं को हल करने के लिए:

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

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

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

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

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

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

Anon+स्वैप मेमोरी

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

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

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

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

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

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

जॉब और अलार्म

WorkManager बैकग्राउंड में बार-बार होने वाले कामों को शेड्यूल करने के लिए, सबसे नया Android API है. 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() को फ़ोर्स करने पर, मेमोरी के कंप्रेस और डीकंप्रेस होने की वजह से, मेमोरी का इस्तेमाल कुछ समय के लिए बढ़ सकता है.
  • Compose में कैटलॉग ब्राउज़र में दिखाए गए LazyList या अब इस्तेमाल नहीं किए जा रहे Leanback यूज़र इंटरफ़ेस (यूआई) टूलकिट में RecyclerView का इस्तेमाल करें. इससे व्यू का फिर से इस्तेमाल किया जा सकेगा और सूची के एलिमेंट को फिर से नहीं बनाना पड़ेगा.
  • बाहरी कॉन्टेंट उपलब्ध कराने वाली कंपनियों से पढ़े गए उन एलिमेंट को स्थानीय तौर पर कैश मेमोरी में सेव करें जिनमें बदलाव होने की संभावना कम होती है. साथ ही, अपडेट करने के ऐसे इंटरवल तय करें जिनसे अतिरिक्त बाहरी मेमोरी को असाइन करने से रोका जा सके.
• मेमोरी लीक की संभावित समस्याओं की जांच करें.
  • ध्यान दें कि मेमोरी लीक के सामान्य मामलों में, गुमनाम थ्रेड में रेफ़रंस, वीडियो बफ़र का फिर से बंटवारा, और अन्य ऐसी ही स्थितियां शामिल हैं.
  • मेमोरी लीक को डीबग करने के लिए, हीप डंप का इस्तेमाल करें.
• बेसलाइन प्रोफ़ाइलें जनरेट करें, ताकि कोल्ड स्टार्ट पर ऐप्लिकेशन को चलाने के लिए, कम से कम जस्ट-इन-टाइम कंपाइलेशन की ज़रूरत पड़े.

डायरेक्ट मेमोरी रीक्लेम के बारे में जानकारी

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

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

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

टूल के बारे में खास जानकारी

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