मीडिया प्लेबैक को बेहतर बनाना: 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)

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

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

• पहले से लोड करने की हमारी सफलता दर क्या है? (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, built-in setWindowSize() तरीका उपलब्ध नहीं कराता. स्लाइडिंग विंडो एक डिज़ाइन पैटर्न है. इसे लागू करने की ज़िम्मेदारी डेवलपर की होती है. इसके लिए, add() और remove() तरीकों का इस्तेमाल किया जाता है. आपके ऐप्लिकेशन के लॉजिक को, यूज़र इंटरफ़ेस (यूआई) इवेंट (जैसे, स्क्रोल या पेज में बदलाव) को इन एपीआई कॉल से कनेक्ट करना होगा. अगर आपको इसके लिए कोड रेफ़रंस चाहिए, तो हमारे पास सोशल मीडिया वाले सैंपल में स्लाइडिंग विंडो पैटर्न लागू किया गया है. इसमें PreloadManagerWrapper भी शामिल है, जो स्लाइडिंग विंडो की तरह काम करता है.

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

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

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

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

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

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

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

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

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

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

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

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

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