ग्राफ़िक्स स्टैक में, हर लेयर के लिए बफ़र कैश, कंपोज़र HAL और SurfaceFlinger के बीच होता है. इससे आईपीसी पर फ़ाइल डिस्क्रिप्टर भेजने से जुड़ा ओवरहेड कम होता है. Android 14 से पहले, जब GraphicBufferProducer, SurfaceFlinger के GraphicBufferConsumer से डिसकनेक्ट हो जाता था, तब सिस्टम इस बफ़र कैश को नहीं मिटाता था. उदाहरण के लिए, जब MediaCodec, SurfaceView से डिसकनेक्ट हो जाता था. Android 14 से, इस बफ़र कैश को पूरी तरह से मिटाया जा सकता है, ताकि ग्राफ़िक्स मेमोरी का इस्तेमाल कम किया जा सके.
इनमें से कोई एक विकल्प चुनें:
- Android 14 और इसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों के लिए, आपको Composer HAL API के नए वर्शन 3.2 को लागू करना होगा. यह विकल्प डिफ़ॉल्ट रूप से चालू होता है और इससे ज़्यादा से ज़्यादा मेमोरी सेव होती है. Android 14 और इसके बाद के वर्शन पर अपग्रेड किए गए डिवाइसों पर भी इस विकल्प का इस्तेमाल किया जा सकता है. इससे उन्हें मेमोरी के सभी फ़ायदे मिलेंगे.
- Android 14 पर अपग्रेड किए जा रहे उन डिवाइसों के लिए, जिनमें आपको Composer HAL 3.2 API लागू नहीं करना है, पुराने सिस्टम के साथ काम करने वाले विकल्प को चालू किया जा सकता है. इस विकल्प से, पिछले विकल्प के बराबर मेमोरी सेव होती है.
यहां दिए गए दो सेक्शन में, हर विकल्प को लागू करने का तरीका बताया गया है.
Composer HAL 3.2 API लागू करना
ग्राफ़िक्स बफ़र मेमोरी के सभी फ़ायदे पाने के लिए, आपको यह करना होगा:
- Composer HAL को 3.2 वर्शन में अपडेट करें.
- सूची में दिए गए स्लॉट नंबर के हिसाब से, बफ़र कैश की उन एंट्री को मिटाकर
LayerCommand::bufferSlotsToClearप्रोसेस करें.
ग्राफ़िक बफ़र मेमोरी से जुड़े Composer HAL 3.2 एपीआई, LayerCommand.aidl फ़ाइल में मौजूद हैं. इनमें LayerCommand::bufferSlotsToClear भी शामिल है.
पुराने सिस्टम के साथ काम करने वाला विकल्प चालू करना
मेमोरी को कम करने वाला बैकवर्ड-कंपैटिबल विकल्प, कैश मेमोरी के स्लॉट में मौजूद असली बफ़र को 1x1 प्लेसहोल्डर बफ़र से बदल देता है. इससे, हटाए गए सभी स्लॉट के लिए मेमोरी सेव होती है. हालांकि, इससे मौजूदा ऐक्टिव बफ़र स्लॉट के लिए मेमोरी सेव नहीं होती. मेमोरी बचाने की सुविधा का कुछ फ़ायदा पाने के लिए, पुराने सिस्टम के साथ काम करने वाले विकल्प को चालू करें. इसके लिए, surface_flinger.clear_slots_with_set_layer_buffer sysprop को true पर सेट करें. यह sysprop, property_contexts फ़ाइल में मौजूद है.
इस sysprop को सेट करने के लिए, आपके Composer HAL को यह पक्का करना होगा कि वह एक ही लेयर के लिए, एक ही प्रेजेंट साइकल में कई setLayerBuffer कमांड को सही तरीके से हैंडल कर रहा हो.
पुराने सिस्टम के साथ काम करने वाले विकल्प को चालू करने से ये असर देखने को मिलते हैं:
AIDL HAL के लिए: SurfaceFlinger, एक लेयर के लिए कई
LayerCommandइंस्टेंस भेजता है. हर इंस्टेंस में एकBufferCommandहोता है. हरBufferCommandमें, 1x1 प्लेसहोल्डर बफ़र हैंडल और कैश मेमोरी बफ़र स्लॉट के लिए एक स्लॉट नंबर होता है. इस स्लॉट को मिटाना ज़रूरी होता है.एचआईडीएल एचएएल के लिए: SurfaceFlinger, कई
SELECT_DISPLAY,SELECT_LAYER,SET_BUFFERकमांड भेजता है. इन कमांड में, 1x1 प्लेसहोल्डर बफ़र हैंडल और कैश मेमोरी बफ़र स्लॉट के लिए एक स्लॉट नंबर होता है. इस स्लॉट को हटाने की ज़रूरत होती है.
पुराने सिस्टम के साथ काम करने वाले विकल्प की वजह से, कुछ डिवाइसों पर कंपोज़र HAL क्रैश हो सकता है. इस समस्या को हल करने के लिए, Composer HAL में बदलाव किया जा सकता है. इस व्यवहार को कंट्रोल करने वाला कोड यहां दिया गया है:
ग्राफ़िक्स बफ़र कैश मेमोरी के इस्तेमाल की जांच करना
टेस्ट से यह पुष्टि नहीं की जा सकती कि HAL लागू करने से, कैश मेमोरी के स्लॉट मिट जाते हैं या नहीं. हालांकि, ग्राफ़िक बफ़र के इस्तेमाल को मॉनिटर करने के लिए, डीबग करने वाले टूल का इस्तेमाल किया जा सकता है. मॉनिटर करने के दौरान, आपको ऐसे मामलों में मेमोरी से जुड़ी कम गड़बड़ियां दिख सकती हैं जहां YouTube पर कई अलग-अलग वीडियो को तेज़ी से रोका और शुरू किया जाता है.
वीटीएस टेस्ट उपलब्ध हैं. इनसे यह पुष्टि की जाती है कि HAL लागू करने की सुविधा, नए एपीआई कॉल (HAL वर्शन 3.2+) या पीछे की ओर काम करने वाले HAL को लागू करने के लिए कई setLayerBuffer कमांड पाने में सक्षम है. हालांकि, इसे सही तरीके से काम करने की जांच के लिए काफ़ी नहीं माना जाना चाहिए. ऐसा इसलिए, क्योंकि कुछ डिवाइस इन वीटीएस टेस्ट को पास कर लेते हैं, लेकिन असल दुनिया में इस्तेमाल के उदाहरणों के दौरान फ़ेल हो जाते हैं.
नए वीटीएस टेस्ट के लिए, यहां दिए गए लिंक देखें: