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

ग्राफ़िक्स स्टैक में, हर लेयर के लिए बफ़र कैश, Composer HAL और SurfaceFlinger के बीच होता है. इससे, आईपीसी के ज़रिए फ़ाइल डिस्क्रिप्टर भेजने से जुड़े ओवरहेड को कम किया जाता है. Android 14 से पहले, जब कोई GraphicBufferProducer, SurfaceFlingerGraphicBufferConsumer से डिसकनेक्ट होता था, तब इस बफ़र कैश मेमोरी को मिटाया नहीं जाता था. जैसे, जब कोई 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 को लागू करना

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

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

ग्राफ़िक बफ़र मेमोरी से जुड़े Composer HAL 3.2 एपीआई, LayerCommand:bufferSlotsToClear के साथ-साथ LayerCommand.aidl- में मौजूद हैं.

पुराने वर्शन के साथ काम करने वाला विकल्प चालू करना

पुराने वर्शन के साथ काम करने वाले, मेमोरी कम करने के विकल्प की मदद से, कैश स्लॉट में मौजूद असली बफ़र को 1x1 प्लेसहोल्डर बफ़र से बदल दिया जाता है. इससे, मौजूदा ऐक्टिव बफ़र स्लॉट को छोड़कर, सभी खाली किए गए स्लॉट के लिए मेमोरी बचती है. कुछ हद तक मेमोरी बचाने के फ़ायदे पाने के लिए, surface_flinger.clear_slots_with_set_layer_buffer sysprop को true पर सेट करके, पुराने सिस्टम के साथ काम करने की सुविधा चालू करें. यह sysprop, property_contexts फ़ाइल में मिलता है.

इस sysprop को सेट करने के लिए, आपके Composer HAL को एक ही लेयर के लिए, एक ही मौजूदा साइकल में कई setLayerBuffer कमांड को सही तरीके से मैनेज करना होगा.

पुराने वर्शन के साथ काम करने वाले विकल्प को चालू करने पर, इन पर असर पड़ता है:

  • एआईडीएल एचएएल के लिए: SurfaceFlinger, एक लेयर के लिए कई LayerCommand इंस्टेंस भेजता है. हर इंस्टेंस में एक BufferCommand होता है. हर BufferCommand में 1x1 वाला प्लेसहोल्डर बफ़र हैंडल और कैश मेमोरी बफ़र स्लॉट का स्लॉट नंबर होता है. इस स्लॉट को खाली करना होता है.

  • HIDL HAL के लिए: SurfaceFlinger एक से ज़्यादा SELECT_DISPLAY, SELECT_LAYER, SET_BUFFER निर्देश भेजता है. इन निर्देशों में, 1x1 प्लेसहोल्डर बफ़र हैंडल और कैश बफ़र स्लॉट के लिए स्लॉट नंबर होता है. इस स्लॉट को खाली करना होता है.

पुराने वर्शन के साथ काम करने वाले विकल्प की वजह से, कुछ डिवाइसों पर Composer HAL क्रैश हो सकता है. इस समस्या को हल करने के लिए, अपने Composer HAL में बदलाव किया जा सकता है. इस व्यवहार को कंट्रोल करने वाला कोड यहां मिलता है:

ग्राफ़िक्स बफ़र कैश मेमोरी के इस्तेमाल की जांच करना

टेस्ट से यह पुष्टि नहीं की जा सकती कि एचएएल लागू करने से कैश स्लॉट खाली हो गए हैं या नहीं. हालांकि, ग्राफ़िक बफ़र के इस्तेमाल को मॉनिटर करने के लिए, डीबगिंग टूल का इस्तेमाल किया जा सकता है. मॉनिटर करने पर, आपको पता चलेगा कि YouTube पर एक के बाद एक कई वीडियो रोकने और फिर शुरू करने पर, 'स्टोरेज की कमी' वाली गड़बड़ियां कम होती हैं.

VTS टेस्ट उपलब्ध हैं, जिनसे यह पुष्टि की जा सकती है कि एचएएल लागू करने की सुविधा, एपीआई के नए कॉल (एचएएल वर्शन 3.2+) या कई setLayerBuffer निर्देशों को पाने के लिए काम करती है. ऐसा इसलिए, ताकि एचएएल को पुराने वर्शन के साथ काम करने वाले डिवाइसों पर भी इस्तेमाल किया जा सके. हालांकि, इसे सही तरीके से काम करने के लिए ज़रूरी जांच नहीं माना जाना चाहिए, क्योंकि कुछ डिवाइस इन वीटीएस टेस्ट में पास हो जाते हैं, लेकिन असल में इस्तेमाल के उदाहरणों के दौरान फ़ेल हो जाते हैं.

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