تقليل استهلاك ذاكرة الرسومات

في حزمة الرسومات، توجد ذاكرة تخزين مؤقت لكل طبقة بين Composer HAL وSurfaceFlinger لتقليل النفقات العامة المرتبطة بواصفات الملفات المرسلة عبر IPC. قبل الإصدار 14 من نظام التشغيل Android 14، لم تتم إزالة ذاكرة التخزين المؤقت للمخزن المؤقت هذه نهائيًا عند قطع اتصال GraphicBufferProducer بأداة SurfaceFlinger GraphicBufferConsumer، مثلاً عند إلغاء ربط MediaCodec من SurfaceView. بدءًا من الإصدار 14 من نظام التشغيل Android، يمكنك محو ذاكرة التخزين المؤقت للمرءّع بشكلٍ قسري لمحاولة تقليل استهلاك ذاكرة الرسومات.

اختَر أحد الخيارَين التاليَين:

  • بالنسبة إلى الأجهزة التي تعمل بالإصدار 14 من نظام التشغيل Android والإصدارات الأحدث، يجب تنفيذ الإصدار 3.2 من واجهة برمجة التطبيقات Composer HAL API. يتم تفعيل هذا الخيار تلقائيًا ويوفر أكبر قدر من الذاكرة. يمكن للأجهزة التي يتم ترقيتها إلى الإصدار 14 والإصدارات الأحدث أيضًا استخدام هذا الخيار للاستفادة من مزايا الذاكرة الكاملة.
  • بالنسبة إلى الأجهزة التي يتم ترقيتها إلى Android 14 والتي لا تريد تنفيذ واجهة برمجة التطبيقات Composer HAL 3.2 API عليها، يمكنك تفعيل الخيار المتوافق مع الإصدارات القديمة. يحفظ هذا الخيار قدرًا من الذاكرة يقارب المساحة التي يحفظها الخيار السابق.

يوضّح القسمان التاليان كيفية تنفيذ كل خيار.

تنفيذ واجهة برمجة التطبيقات Composer HAL 3.2

للاستفادة من مزايا ذاكرة التخزين المؤقت للرسومات بالكامل، يجب:

  1. عدِّل عملية تنفيذ HAL في Composer إلى الإصدار 3.2.
  2. عالج العملية LayerCommand::bufferSlotsToClear من خلال إزالة إدخالات ملف التخزين المؤقت في الوسيط المشار إليها بأرقام الفتحات المتوفّرة في القائمة.

واجهات برمجة التطبيقات في Composer HAL 3.2 المرتبطة بذاكرة التخزين المؤقت للرسومات، بما في ذلك LayerCommand:bufferSlotsToClear، متوفّرة في LayerCommand.aidl-.

تفعيل خيار التوافق مع الإصدارات القديمة

ويستبدل خيار تقليل الذاكرة المتوافق مع الإصدارات القديمة المخزن المؤقت الحقيقي في خانة ذاكرة التخزين المؤقت بمخزن نائب 1×1، ما يؤدي إلى توفير الذاكرة لجميع الخانات التي تمت إزالتها نهائيًا، باستثناء منفذ المخزن المؤقت النشط الحالي. للاستفادة من مزايا توفير الذاكرة الجزئية، فعِّل الخيار المتوافق مع الإصدارات القديمة من خلال ضبط surface_flinger.clear_slots_with_set_layer_buffer sysprop على true. يمكن العثور على sysprop هذا في ملف property_contexts.

يتطلب إعداد هذا النظام الأساسي تنفيذ بروتوكول HAL للمؤلف لمعالجة أوامر setLayerBuffer المتعددة بشكل صحيح للطبقة نفسها في دورة حالية واحدة.

يؤدي تفعيل خيار التوافق مع الإصدارات القديمة إلى التأثيرات التالية:

  • بالنسبة إلى واجهات برمجة التطبيقات لHAL في واجهة برمجة التطبيقات (AIDL): تُرسِل SurfaceFlinger عدّة مثيلات من LayerCommand ل طبقة واحدة، وكلّ منها يتضمّن BufferCommand واحدًا. يحتوي كل BufferCommand على معرّف عنصر نائب ومقدار ذاكرة التخزين المؤقت 1×1 ورقم خانة ذاكرة التخزين المؤقت التي يجب تنظيفها.

  • بالنسبة إلى واجهات HIDL HAL: يُرسِل SurfaceFlinger عدة أوامر SELECT_DISPLAY SELECT_LAYER SET_BUFFER. تحتوي هذه الأوامر على معرّف ملف احتياطي نائب 1×1 ورقم خانة لخانة ملف التخزين المؤقت التي يجب محو بياناتها.

قد يؤدي خيار التوافق مع الإصدارات القديمة إلى تعطُّل HAL في Composer على بعض الأجهزة. قد تتمكّن من تعديل HAL في Composer لحلّ هذه المشكلة. يمكنك العثور على الرمز البرمجي الذي يتحكّم في هذا السلوك هنا:

اختبار استهلاك ذاكرة التخزين المؤقت في ذاكرة التخزين المؤقت للرسومات

لا يمكن للاختبارات التحقّق مما إذا كانت عمليات تنفيذ HAL تُفرِغ خانات ذاكرة التخزين المؤقت. ومع ذلك، يمكنك استخدام أدوات تصحيح الأخطاء لمراقبة استخدام ذاكرة التخزين المؤقت للرسومات. أثناء المراقبة، من المفترض أن تلاحظ انخفاضًا في عدد أخطاء "الذاكرة غير كافية" في السيناريوهات التي يتم فيها إيقاف وتشغيل فيديوهات متعددة مختلفة بشكل متتابع وسريعة على YouTube.

تتوفّر اختبارات VTS للتحقّق من أنّ تنفيذ HAL قادر وظيفيًا على تلقّي طلبات بيانات واجهة برمجة التطبيقات الجديدة (الإصدار 3.2 من HAL والإصدارات الأحدث) أو أوامر setLayerBuffer متعددة لتنفيذ التوافق مع الإصدارات القديمة. مع ذلك، لا ينبغي اعتبار هذا الاختبار كافيًا للوظائف المناسبة، لأنّ بعض الأجهزة تجتاز اختبارات VTS هذه، ولكنها لا تنجح أثناء حالات الاستخدام الفعلية.

بالنسبة إلى اختبارات VTS الجديدة، انتقِل إلى الروابط التالية: