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

في حِزمة الرسومات، يتم وضع ذاكرة تخزين مؤقت لكل طبقة بين Composer HAL و SurfaceFlinger لتقليل الوقت المستغرَق في إرسال أوصاف الملفات عبر واجهة برمجة التطبيقات (IPC). قبل 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.

يتطلب ضبط هذا sysprop أن يعالج تنفيذ HAL في Composer بشكل صحيح أوامر 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 الجديدة، انتقِل إلى الروابط التالية: