ग्राफ़िक्स मेमोरी का इस्तेमाल कम करना

ग्राफ़िक्स स्टैक में, हर लेयर के लिए बफ़र कैश, कंपोज़र HAL और SurfaceFlinger के बीच होता है. इससे आईपीसी पर फ़ाइल डिस्क्रिप्टर भेजने से जुड़ा ओवरहेड कम हो जाता है. Android 14 से पहले, जब कोई GraphicBufferProducer, SurfaceFlinger GraphicBufferConsumer से डिसकनेक्ट होता था, तब इस बफ़र कैश को मिटाया नहीं जाता था. जैसे, जब कोई MediaCodec, SurfaceView से डिसकनेक्ट होता था. Android 14 से, इस बफ़र कैश को पूरी तरह से मिटाया जा सकता है, ताकि ग्राफ़िक्स मेमोरी का इस्तेमाल कम किया जा सके.

इनमें से कोई एक विकल्प चुनें:

  • Android 14 और इसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों के लिए, आपको Composer HAL API के नए वर्शन 3.2 को लागू करना होगा. यह विकल्प डिफ़ॉल्ट रूप से चालू होता है और इससे सबसे ज़्यादा मेमोरी सेव होती है. iOS 14 और इसके बाद के वर्शन पर अपग्रेड किए गए डिवाइसों पर भी इस विकल्प का इस्तेमाल किया जा सकता है, ताकि मेमोरी का पूरा फ़ायदा मिल सके.
  • Android 14 पर अपग्रेड किए जा रहे उन डिवाइसों के लिए, जिनमें Composer HAL 3.2 API लागू नहीं करना है, पुराने सिस्टम के साथ काम करने वाले विकल्प को चालू किया जा सकता है. इस विकल्प से, पिछले विकल्प के बराबर मेमोरी सेव होती है.

यहां दिए गए दो सेक्शन में, हर विकल्प को लागू करने का तरीका बताया गया है.

Composer HAL 3.2 API लागू करना

ग्राफ़िक्स बफ़र मेमोरी के सभी फ़ायदे पाने के लिए, आपको यह करना होगा:

  1. Composer HAL को 3.2 वर्शन में अपडेट करें.
  2. सूची में दिए गए स्लॉट नंबर के हिसाब से, बफ़र कैश की उन एंट्री को मिटाकर LayerCommand::bufferSlotsToClear प्रोसेस करें.

ग्राफ़िक बफ़र मेमोरी से जुड़े Composer HAL 3.2 API, 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 कमांड पाने में सक्षम है. हालांकि, इसे सही तरीके से काम करने की जांच के लिए काफ़ी नहीं माना जाना चाहिए, क्योंकि कुछ डिवाइस इन वीटीएस टेस्ट को पास कर लेते हैं, लेकिन असल दुनिया में इस्तेमाल के दौरान फ़ेल हो जाते हैं.

नए वीटीएस टेस्ट के लिए, इन लिंक पर जाएं: