मीडिया प्लेबैक को बेहतर बनाना: Media3 के PreloadManager के बारे में ज़्यादा जानकारी पाएं - दूसरा भाग

Media3 की मदद से मीडिया प्रीलोडिंग के बारे में जानकारी देने वाली हमारी तीन पार्ट की सीरीज़ के दूसरे पार्ट में आपका स्वागत है. इस सीरीज़ को इसलिए डिज़ाइन किया गया है, ताकि आपको अपने Android ऐप्लिकेशन में, कम इंतज़ार के समय में मीडिया का बेहतर अनुभव देने वाले ऐप्लिकेशन बनाने की प्रोसेस के बारे में जानकारी मिल सके.

• पहले भाग: Media3 की मदद से प्रीलोडिंग की सुविधा के बारे में जानकारी में, बुनियादी बातों के बारे में बताया गया है. हमने सामान्य प्लेलिस्ट के लिए PreloadConfiguration और डाइनैमिक यूज़र इंटरफ़ेस (यूआई) के लिए ज़्यादा बेहतर DefaultPreloadManager के बीच के अंतर के बारे में जानकारी दी है. आपने एपीआई के लाइफ़साइकल को लागू करने का तरीका सीखा. जैसे: add() का इस्तेमाल करके मीडिया जोड़ना, getMediaSource() का इस्तेमाल करके तैयार किया गया MediaSource वापस पाना, setCurrentPlayingIndex() और invalidate() का इस्तेमाल करके प्राथमिकताओं को मैनेज करना, और remove() और release() का इस्तेमाल करके संसाधनों को रिलीज़ करना.
• दूसरा पार्ट (यह पोस्ट): इस ब्लॉग में, हम DefaultPreloadManager की बेहतर सुविधाओं के बारे में जानेंगे. हम आपको PreloadManagerListener की मदद से अहम जानकारी पाने, ExoPlayer के साथ मुख्य कॉम्पोनेंट शेयर करने जैसे प्रोडक्शन के लिए तैयार सबसे सही तरीके लागू करने, और मेमोरी को असरदार तरीके से मैनेज करने के लिए स्लाइडिंग विंडो पैटर्न में महारत हासिल करने का तरीका बताएंगे.
• तीसरा पार्ट: इस सीरीज़ के आखिरी पार्ट में, PreloadManager को डिस्क की कैश मेमोरी के साथ इंटिग्रेट करने के बारे में बताया जाएगा. इससे आपको रिसॉर्स मैनेजमेंट की मदद से डेटा खर्च को कम करने और लोगों को बेहतर अनुभव देने में मदद मिलेगी.

अगर आपको Media3 में प्रीलोडिंग की सुविधा के बारे में ज़्यादा जानकारी नहीं है, तो हमारा सुझाव है कि आगे बढ़ने से पहले पहला भाग पढ़ें. अगर आपको बुनियादी बातों से आगे बढ़ना है, तो आइए जानें कि मीडिया प्लेबैक को लागू करने के तरीके को कैसे बेहतर बनाया जा सकता है.

लिसनिंग इन: PreloadManagerListener की मदद से आंकड़े फ़ेच करना

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

PreloadManagerListener दो ज़रूरी कॉलबैक उपलब्ध कराता है. इनसे, प्रीलोड करने की प्रोसेस और स्थिति के बारे में अहम जानकारी मिलती है.

• onCompleted(MediaItem mediaItem): यह कॉलबैक, प्रीलोड करने के अनुरोध के पूरा होने पर शुरू होता है. इसे TargetPreloadStatusControl के हिसाब से तय किया जाता है.
• onError(PreloadException error): यह कॉलबैक, डीबग करने और मॉनिटर करने के लिए काम का हो सकता है. यह तब ट्रिगर होता है, जब प्रीलोड नहीं हो पाता. साथ ही, यह उससे जुड़ा अपवाद उपलब्ध कराता है.

यहां दिए गए उदाहरण कोड में दिखाए गए तरीके से, एक ही तरीके के कॉल के साथ लिसनर को रजिस्टर किया जा सकता है:

val preloadManagerListener = object : PreloadManagerListener {
    override fun onCompleted(mediaItem: MediaItem) {
        // Log success for analytics. 
        Log.d("PreloadAnalytics", "Preload completed for $mediaItem")
    }

    override fun onError( preloadError: PreloadException) {
        // Log the specific error for debugging and monitoring.
        Log.e("PreloadAnalytics", "Preload error ", preloadError)
    }
}

preloadManager.addListener(preloadManagerListener)

लिसनर से अहम जानकारी निकालना 

इन लिसनर कॉलबैक को आपकी ऐनलिटिक्स पाइपलाइन से जोड़ा जा सकता है. इन इवेंट को अपने Analytics इंजन पर फ़ॉरवर्ड करके, इन अहम सवालों के जवाब पाए जा सकते हैं:

• हमारा प्रीलोड सक्सेस रेट क्या है? (onCompleted इवेंट और प्रीलोड की कुल कोशिशों का अनुपात)
• किन सीडीएन या वीडियो फ़ॉर्मैट में गड़बड़ी की दर सबसे ज़्यादा है? (onError से अपवादों को पार्स करके)
• प्रीलोडिंग में गड़बड़ी की दर क्या है? (onError इवेंट और प्रीलोड करने की कुल कोशिशों का अनुपात)

इस डेटा से आपको पहले से लोड करने की रणनीति के बारे में संख्या के हिसाब से फ़ीडबैक मिल सकता है. इससे आपको A/B टेस्टिंग करने और डेटा के आधार पर उपयोगकर्ता अनुभव को बेहतर बनाने में मदद मिलती है. इस डेटा से, आपको प्रीलोड की अवधि को बेहतर बनाने में मदद मिल सकती है. साथ ही, यह तय किया जा सकता है कि कितने वीडियो प्रीलोड करने हैं और कितना बफ़र साइज़ तय करना है.

डीबग करने के अलावा: यूज़र इंटरफ़ेस (यूआई) को बेहतर तरीके से फ़ॉलबैक करने के लिए onError का इस्तेमाल करना

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

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

बडी सिस्टम: ExoPlayer के साथ कॉम्पोनेंट शेयर करना क्यों ज़रूरी है?

DefaultPreloadManager और ExoPlayer को एक साथ काम करने के लिए डिज़ाइन किया गया है. स्थिरता और बेहतर परफ़ॉर्मेंस के लिए, उन्हें कई मुख्य कॉम्पोनेंट शेयर करने होंगे. अगर वे अलग-अलग और बिना तालमेल वाले कॉम्पोनेंट के साथ काम करते हैं, तो इससे थ्रेड की सुरक्षा और प्लेयर पर पहले से लोड किए गए ट्रैक की उपयोगिता पर असर पड़ सकता है. ऐसा इसलिए, क्योंकि हमें यह पक्का करना होगा कि पहले से लोड किए गए ट्रैक, सही प्लेयर पर चलाए जाएं. अलग-अलग कॉम्पोनेंट, नेटवर्क बैंडविड्थ और मेमोरी जैसे सीमित संसाधनों के लिए भी कॉम्पिटिशन कर सकते हैं. इससे परफ़ॉर्मेंस में गिरावट आ सकती है. लाइफ़साइकल का एक अहम हिस्सा, सही तरीके से डिस्पोज़ल को मैनेज करना है. डिस्पोज़ल का सुझाया गया क्रम यह है कि सबसे पहले PreloadManager को रिलीज़ किया जाए. इसके बाद, ExoPlayer को रिलीज़ किया जाए.

DefaultPreloadManager.Builder को इस शेयरिंग को आसान बनाने के लिए डिज़ाइन किया गया है. इसमें आपके PreloadManager और लिंक किए गए प्लेयर इंस्टेंस, दोनों को इंस्टैंशिएट करने के लिए एपीआई मौजूद हैं. आइए, देखते हैं कि BandwidthMeter, LoadControl, TrackSelector, Looper जैसे कॉम्पोनेंट को शेयर क्यों करना चाहिए. ExoPlayer प्लेबैक के साथ ये कॉम्पोनेंट कैसे इंटरैक्ट करते हैं, इसकी विज़ुअल जानकारी देखें.

शेयर किए गए BandwidthMeter की वजह से, बैंडविड्थ से जुड़ी समस्याओं को रोकना

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

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

preloadManagerBuilder.setBandwidthMeter(customBandwidthMeter)

ExoPlayer के शेयर किए गए LoadControl, TrackSelector, और रेंडरर कॉम्पोनेंट के साथ एक जैसा अनुभव देना

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

ध्यान दें: Media3 (1.8) के नए वर्शन में LoadControl को शेयर करने की सुविधा उपलब्ध है. इससे यह पक्का किया जा सकता है कि इसके Allocator को PreloadManager और प्लेयर के साथ सही तरीके से शेयर किया जा सके. LoadControl का इस्तेमाल करके, प्रीलोडिंग को असरदार तरीके से कंट्रोल करने की सुविधा, Media3 1.9 के आने वाले वर्शन में उपलब्ध होगी.

preloadManagerBuilder.setLoadControl(customLoadControl)

• TrackSelector: यह कॉम्पोनेंट, लोड और चलाए जाने वाले ट्रैक चुनने के लिए ज़िम्मेदार होता है. जैसे, किसी खास रिज़ॉल्यूशन का वीडियो, किसी खास भाषा का ऑडियो. शेयर करने से यह पक्का होता है कि प्रीलोडिंग के दौरान चुने गए ट्रैक वही हैं जिनका इस्तेमाल प्लेयर करेगा. इससे ऐसे फ़िज़ूलखर्ची वाले हालात से बचा जा सकता है जहां 480 पिक्सल वाला वीडियो ट्रैक पहले से लोड हो जाता है. हालांकि, प्लेयर उसे तुरंत खारिज कर देता है और वीडियो चलाने पर 720 पिक्सल वाला ट्रैक फ़ेच करता है.< br /> प्रीलोड मैनेजर को, प्लेयर के साथ TrackSelector का एक ही इंस्टेंस शेयर नहीं करना चाहिए. इसके बजाय, उन्हें TrackSelector के अलग-अलग इंस्टेंस का इस्तेमाल करना चाहिए, लेकिन उन्हें एक ही तरह से लागू करना चाहिए. इसलिए, हमने DefaultPreloadManager.Builder में TrackSelector के बजाय TrackSelectorFactory सेट किया है.

preloadManagerBuilder.setTrackSelectorFactory(customTrackSelectorFactory)

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

preloadManagerBuilder.setRenderersFactory(customRenderersFactory)

ExoPlayer के अन्य कॉम्पोनेंट के बारे में पढ़ें.

सबसे अहम नियम: सभी के लिए एक सामान्य Playback Looper

ExoPlayer इंस्टेंस को जिस थ्रेड पर ऐक्सेस किया जा सकता है उसे साफ़ तौर पर तय किया जा सकता है. इसके लिए, प्लेयर बनाते समय एक लूपर पास करें. जिस थ्रेड से प्लेयर को ऐक्सेस करना है उसके लूपर के बारे में Player.getApplicationLooper का इस्तेमाल करके क्वेरी की जा सकती है. प्लेयर और PreloadManager के बीच शेयर किए गए Looper को बनाए रखने से, यह पक्का किया जाता है कि शेयर किए गए इन मीडिया ऑब्जेक्ट पर की जाने वाली सभी कार्रवाइयां, एक थ्रेड की मैसेज कतार में क्रम से की जाती हैं. इससे, एक साथ कई अनुरोध मिलने पर होने वाली गड़बड़ियों को कम किया जा सकता है.

PreloadManager और प्लेयर के बीच, लोड किए जाने वाले या पहले से लोड किए जाने वाले मीडिया सोर्स के साथ सभी इंटरैक्शन, एक ही प्लेबैक थ्रेड पर होने चाहिए. थ्रेड की सुरक्षा के लिए, Looper को शेयर करना ज़रूरी है. इसलिए, हमें PreloadManager और प्लेयर के बीच PlaybackLooper को शेयर करना होगा.

PreloadManager, बैकग्राउंड में स्टेटफ़ुल MediaSource ऑब्जेक्ट तैयार करता है. जब आपका यूज़र इंटरफ़ेस (यूआई) कोड, player.setMediaSource(mediaSource) को कॉल करता है, तो इस जटिल और स्टेटफ़ुल ऑब्जेक्ट को पहले से लोड किए जा रहे MediaSource से प्लेयर को ट्रांसफ़र किया जाता है. इस मामले में, पूरा PreloadMediaSource, मैनेजर से प्लेयर में चला जाता है. ये सभी इंटरैक्शन और हैंडऑफ़, एक ही PlaybackLooper पर होने चाहिए.

अगर PreloadManager और ExoPlayer अलग-अलग थ्रेड पर काम कर रहे थे, तो रेस कंडीशन हो सकती है. ऐसा हो सकता है कि PreloadManager का थ्रेड, MediaSource की इंटरनल स्थिति में बदलाव कर रहा हो. जैसे, बफ़र में नया डेटा लिख रहा हो. ठीक उसी समय, प्लेयर का थ्रेड उससे डेटा पढ़ने की कोशिश कर रहा हो. इसकी वजह से, उम्मीद के मुताबिक नतीजे नहीं मिलते. साथ ही, IllegalStateException की गड़बड़ी होती है जिसे डीबग करना मुश्किल होता है.

preloadManagerBuilder.setPreloadLooper(playbackLooper)

आइए, देखते हैं कि सेटअप के दौरान, ExoPlayer और DefaultPreloadManager के बीच ऊपर दिए गए सभी कॉम्पोनेंट को कैसे शेयर किया जा सकता है.

val preloadManagerBuilder =
DefaultPreloadManager.Builder(context, targetPreloadStatusControl)

// Optional - Share components between ExoPlayer and DefaultPreloadManager
preloadManagerBuilder
     .setBandwidthMeter(customBandwidthMeter)
     .setLoadControl(customLoadControl)
     .setMediaSourceFactory(customMediaSourceFactory)
     .setTrackSelectorFactory(customTrackSelectorFactory)
     .setRenderersFactory(customRenderersFactory)
     .setPreloadLooper(playbackLooper)

val preloadManager = val preloadManagerBuilder.build()

अहम जानकारी: अगर ExoPlayer में डिफ़ॉल्ट कॉम्पोनेंट इस्तेमाल किए जाते हैं, जैसे कि DefaultLoadControl वगैरह, तो आपको उन्हें DefaultPreloadManager के साथ अलग से शेयर करने की ज़रूरत नहीं है. DefaultPreloadManager.Builder के buildExoPlayer का इस्तेमाल करके ExoPlayer इंस्टेंस बनाने पर, ये कॉम्पोनेंट एक-दूसरे से अपने-आप जुड़ जाते हैं. ऐसा तब होता है, जब डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ डिफ़ॉल्ट सेटिंग का इस्तेमाल किया जाता है. हालांकि, अगर कस्टम कॉम्पोनेंट या कस्टम कॉन्फ़िगरेशन का इस्तेमाल किया जाता है, तो आपको ऊपर दिए गए एपीआई के ज़रिए, DefaultPreloadManager को उनके बारे में साफ़ तौर पर सूचना देनी चाहिए.

प्रोडक्शन के लिए तैयार प्रीलोडिंग: स्लाइडिंग विंडो पैटर्न

डाइनैमिक फ़ीड में, उपयोगकर्ता को स्क्रोल करने पर बहुत सारा कॉन्टेंट दिख सकता है. अगर DefaultPreloadManager में लगातार वीडियो जोड़े जाते हैं और उन्हें हटाने की कोई रणनीति नहीं बनाई जाती है, तो आपको OutOfMemoryError का सामना करना पड़ेगा. पहले से लोड किया गया हर MediaSource, SampleQueue को होल्ड करता है. यह मेमोरी बफ़र को असाइन करता है. इनके इकट्ठा होने से, ऐप्लिकेशन का हीप स्पेस खत्म हो सकता है. इसका समाधान एक एल्गोरिदम है, जिसके बारे में शायद आपको पहले से पता हो. इसे स्लाइडिंग विंडो कहा जाता है. स्लाइडिंग विंडो पैटर्न, मेमोरी में आइटम का एक छोटा और मैनेज किया जा सकने वाला सेट बनाए रखता है. ये आइटम, फ़ीड में उपयोगकर्ता की मौजूदा जगह के हिसाब से होते हैं. जब उपयोगकर्ता स्क्रोल करता है, तो मैनेज किए जा रहे आइटम की यह "विंडो" उनके साथ स्लाइड होती है. इससे, दिखने वाले नए आइटम जुड़ते हैं और जो आइटम अब दूर हैं वे हट जाते हैं.

स्लाइडिंग विंडो पैटर्न लागू करना

यह समझना ज़रूरी है कि PreloadManager, setWindowSize() का इन-बिल्ट तरीका उपलब्ध नहीं कराता है. स्लाइडिंग विंडो, एक डिज़ाइन पैटर्न है. इसे लागू करने की ज़िम्मेदारी आपकी है. इसके लिए, आपको add() और remove() जैसे बुनियादी तरीकों का इस्तेमाल करना होगा. आपके ऐप्लिकेशन लॉजिक को यूआई इवेंट, जैसे कि स्क्रोल या पेज बदलने को इन एपीआई कॉल से कनेक्ट करना होगा. अगर आपको इसके लिए कोड रेफ़रंस चाहिए, तो हमने socialite सैंपल में स्लाइडिंग विंडो पैटर्न लागू किया है. इसमें PreloadManagerWrapper भी शामिल है, जो स्लाइडिंग विंडो की नकल करता है.

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

TargetPreloadStatusControl की मदद से, कैटगरी के हिसाब से पहले से लोड करने की रणनीति को बेहतर बनाना

अब जब हमने यह तय कर लिया है कि क्या प्रीलोड करना है (हमारी विंडो में मौजूद आइटम), तो हम हर आइटम के लिए प्रीलोड करने की संख्या के लिए एक तय रणनीति लागू कर सकते हैं. हमने पहले भाग में TargetPreloadStatusControl सेटअप की मदद से, इस बारीकी को हासिल करने का तरीका पहले ही देख लिया है.

याद रखें कि +/- 1 पोज़िशन पर मौजूद आइटम के चलने की संभावना, +/- 4 पोज़िशन पर मौजूद आइटम के चलने की संभावना से ज़्यादा होती है. उपयोगकर्ता के अगले आइटम देखने की संभावना के हिसाब से, उसे ज़्यादा संसाधन (नेटवर्क, सीपीयू, मेमोरी) दिए जा सकते हैं. इससे नज़दीकी के आधार पर "पहले से लोड करने" की रणनीति बनती है. यह रणनीति, तुरंत वीडियो चलाने और संसाधनों के बेहतर इस्तेमाल के बीच संतुलन बनाने के लिए ज़रूरी है.

प्रीलोड करने की अवधि तय करने की रणनीति तय करने के लिए, PreloadManagerListener के ज़रिए Analytics के डेटा का इस्तेमाल किया जा सकता है. इसके बारे में पिछले सेक्शन में बताया गया है.

निष्कर्ष और अगले चरण

अब आपके पास Media3 के DefaultPreloadManager का इस्तेमाल करके, तेज़, स्टेबल, और कम संसाधनों का इस्तेमाल करने वाले मीडिया फ़ीड बनाने की बेहतर जानकारी है.

आइए, हम इस बारे में कुछ ज़रूरी बातें दोहरा लेते हैं:

• Analytics से अहम जानकारी इकट्ठा करने और गड़बड़ी को ठीक करने के लिए, PreloadManagerListener का इस्तेमाल करें.
• मैनेजर और प्लेयर, दोनों के इंस्टेंस बनाने के लिए, हमेशा एक ही DefaultPreloadManager.Builder का इस्तेमाल करें. इससे यह पक्का किया जा सकेगा कि ज़रूरी कॉम्पोनेंट शेयर किए जाएं.
• स्लाइडिंग विंडो पैटर्न लागू करें. इसके लिए, add() और remove() कॉल को मैनेज करें, ताकि OutOfMemoryError से बचा जा सके.
• TargetPreloadStatusControl का इस्तेमाल करके, स्मार्ट और टियर वाली प्रीलोडिंग रणनीति बनाएं. इससे परफ़ॉर्मेंस और संसाधनों के इस्तेमाल को संतुलित किया जा सकता है.

तीसरे भाग में क्या है: पहले से लोड किए गए मीडिया के साथ कैश मेमोरी में सेव करना

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

क्या आपको कोई सुझाव/राय देनी है या शिकायत करनी है? हमें आपके जवाब का इंतज़ार रहेगा.

हमारे साथ बने रहें और वीडियो चलाने की स्पीड को तेज़ करें! 🚀