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)

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

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

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

preloadManagerBuilder.setTrackSelectorFactory(customTrackSelectorFactory)

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

preloadManagerBuilder.setRenderersFactory(customRenderersFactory)

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

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

प्लेयर बनाते समय, Looper पास करके, यह साफ़ तौर पर बताया जा सकता है कि ExoPlayer इंस्टेंस को किस थ्रेड पर ऐक्सेस किया जा सकता है. Player.getApplicationLooper का इस्तेमाल करके, उस थ्रेड के Looper के बारे में क्वेरी की जा सकती है जिससे प्लेयर को ऐक्सेस करना है. प्लेयर और 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 में, Default कॉम्पोनेंट का इस्तेमाल किया जाता है. जैसे, DefaultLoadControlवगैरह, तो आपको उन्हें DefaultPreloadManager के साथ साफ़ तौर पर शेयर करने की ज़रूरत नहीं है. अगर डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ डिफ़ॉल्ट तरीके से लागू करने की सुविधा का इस्तेमाल किया जाता है, तो DefaultPreloadManager.Builder के buildExoPlayer के ज़रिए ExoPlayer इंस्टेंस बनाने पर, ये कॉम्पोनेंट एक-दूसरे से अपने-आप रेफ़रंस हो जाते हैं. हालांकि, अगर कस्टम कॉम्पोनेंट या कस्टम कॉन्फ़िगरेशन का इस्तेमाल किया जाता है, तो आपको ऊपर दिए गए एपीआई के ज़रिए, DefaultPreloadManager को इनके बारे में साफ़ तौर पर बताना चाहिए.

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

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

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

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

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

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

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

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

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

नतीजा और अगले चरण

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

आइए, खास बातों पर एक नज़र डालते हैं:

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

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

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

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

अप-टू-डेट रहें और वीडियो प्लेबैक को तेज़ बनाएं! 🚀