ग्राफ़िक मेमोरी की खपत कम करें

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

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