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 में 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 का इस्तेमाल करें. इससे, परफ़ॉर्मेंस और संसाधन की खपत के बीच बैलेंस बनाया जा सकता है.

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

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

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

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