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 इंस्टेंस को ऐक्सेस किया जा सकता है उसे साफ़ तौर पर तय किया जा सकता है. इसके लिए, प्लेयर बनाते समय Looper पास करें. जिस थ्रेड से प्लेयर को ऐक्सेस करना है उसके लूपर के बारे में 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 का इस्तेमाल करके, तेज़, स्थिर, और संसाधन-कुशल मीडिया फ़ीड बनाने के बारे में बेहतर जानकारी है.

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

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

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

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

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

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