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

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 का इस्तेमाल करें.

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

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

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

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