मीडिया प्लेबैक को बेहतर बनाना: 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 Playback के साथ इंटरैक्ट करने का विज़ुअल प्रज़ेंटेशन देखें.

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

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

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

preloadManagerBuilder.setBandwidthMeter(customBandwidthMeter)

यह पक्का करना कि ExoPlayer के LoadControl, TrackSelector, और Renderer कॉम्पोनेंट शेयर किए गए हों

• 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 के अन्य कॉम्पोनेंट के बारे में पढ़ें.

सबसे अहम नियम: सभी के लिए एक ही प्लेबैक लूपर का इस्तेमाल करना

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 का इस्तेमाल करके, स्मार्ट और टियर वाली प्रीलोडिंग की रणनीति बनाएं. इससे परफ़ॉर्मेंस और संसाधन के इस्तेमाल के बीच संतुलन बना रहता है.

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

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

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

अपडेट के लिए बने रहें और वीडियो को तेज़ स्पीड में चलाने की सुविधा का इस्तेमाल करें! 🚀