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

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

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

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

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

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

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

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

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

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

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

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

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

डिवाइस का स्टोरेज डिवाइस का वीडियो रिज़ॉल्यूशन डिवाइस के यूज़र इंटरफ़ेस (यूआई) का रिज़ॉल्यूशन isLowRAMDevice()
1 जीबी 1080 पिक्सल 720 पिक्सल हां
1.5 जीबी 2160 पिक्सल 1080 पिक्सल हां
≥1.5 जीबी 1080 पिक्सल 720 पिक्सल या 1080 पिक्सल नहीं*
≥2 जीबी 2160 पिक्सल 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 के मेमोरी प्रोफ़ाइलर का इस्तेमाल करके, मेमोरी के हर सेक्शन पर नज़र रखें. टीवी ऐप्लिकेशन को मेमोरी के इस्तेमाल की अपनी प्रोफ़ाइल बनानी चाहिए. साथ ही, उन्हें इस सेक्शन में तय की गई थ्रेशोल्ड वैल्यू के हिसाब से अपनी कैटगरी तय करनी चाहिए.

मेमोरी प्रोफ़ाइलर

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

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

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

मेमोरी टाइप मकसद इस्तेमाल के टारगेट (1 जीबी)
बिना सोर्स फ़ाइल वाली मेमोरी + स्वैप मेमोरी (Java + नेटिव + स्टैक) इसका इस्तेमाल, मेमोरी का ज़्यादा इस्तेमाल करने वाले टास्क के लिए किया जाता है. जैसे, वैरिएबल, मीडिया बफ़र, और मेमोरी का बंटवारा. < 160 MB
ग्राफ़िक इस मेमोरी का इस्तेमाल, जीपीयू, टेक्सचर, और डिसप्ले से जुड़े बफ़र के लिए करता है 30 से 40 एमबी
फ़ाइल इसका इस्तेमाल, मेमोरी में मौजूद कोड पेजों और फ़ाइलों के लिए किया जाता है. 60 से 80 एमबी

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

  • 1 जीबी रैम वाले डिवाइसों के लिए, मेमोरी का कुल इस्तेमाल 280 एमबी (बिना सोर्स फ़ाइल वाली आरएसएस मेमोरी + स्वैप मेमोरी + ग्राफ़िक्स + फ़ाइल) होना चाहिए.

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

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

Kotlin

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

Java

Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresStorageNotLow(true)
    .setRequiresDeviceIdle(true)
    .build()
  • अगर आपको नियमित तौर पर टास्क चलाने हैं (उदाहरण के लिए, किसी दूसरे डिवाइस पर आपके ऐप्लिकेशन में कॉन्टेंट देखने से जुड़ी उपयोगकर्ता की गतिविधि के आधार पर, अगला वीडियो अपडेट करना), तो मेमोरी का इस्तेमाल कम करें. इसके लिए, टास्क की मेमोरी का इस्तेमाल 30 एमबी से कम रखें.

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

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

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

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

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

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

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

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

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