Verbrauch des Grafikspeichers reduzieren

Im Grafikstack befindet sich zwischen Composer HAL und SurfaceFlinger ein Zwischenspeicher-Cache pro Schicht, um den Aufwand beim Senden von Dateideskriptoren über IPC zu reduzieren. Vor Android 14 wurde dieser Puffercache nicht geleert, wenn eine GraphicBufferProducer-Instanz die Verbindung zu einem SurfaceFlinger GraphicBufferConsumer trennte, z. B. wenn ein MediaCodec von einer SurfaceView getrennt wurde. Ab Android 14 können Sie diesen Puffercache erzwungen leeren, um die Grafikspeichernutzung zu reduzieren.

Wählen Sie eine der folgenden Optionen aus:

  • Für Geräte, die mit Android 14 oder höher auf den Markt kommen, müssen Sie die neue Composer HAL API-Version 3.2 implementieren. Diese Option ist standardmäßig aktiviert und spart am meisten Speicherplatz. Bei Geräten, die auf 14 und höher upgraden, kann diese Option ebenfalls verwendet werden, um vollen Arbeitsspeicher zu nutzen.
  • Für Geräte, die auf Android 14 umgestellt werden und für die Sie die Composer HAL 3.2 API nicht implementieren möchten, können Sie die rückwärtskompatible Option aktivieren. Mit dieser Option wird fast so viel Speicherplatz gespart wie mit der vorherigen Option.

In den folgenden beiden Abschnitten wird erläutert, wie die einzelnen Optionen implementiert werden.

Composer HAL 3.2 API implementieren

Damit Sie den vollen Nutzen des Grafik-Framebuffer-Speichers nutzen können, müssen folgende Voraussetzungen erfüllt sein:

  1. Aktualisieren Sie Ihre Composer HAL-Implementierung auf Version 3.2.
  2. Bearbeiten Sie LayerCommand::bufferSlotsToClear, indem Sie die Buffer-Cache-Einträge löschen, die durch die in der Liste angegebenen Steckplatznummern gekennzeichnet sind.

Die Composer HAL 3.2 APIs, die sich auf den Grafikbufferspeicher beziehen, einschließlich LayerCommand:bufferSlotsToClear, finden Sie unter LayerCommand.aidl-.

Option „Abwärtskompatibel“ aktivieren

Bei der rückwärtskompatiblen Speicherreduzierungsoption wird ein echter Puffer im Cache-Speicherplatz durch einen Platzhalter-Puffer mit einer Größe von 1 × 1 ersetzt. Dadurch wird Speicherplatz für alle gelöschten Speicherplätze freigegeben, mit Ausnahme des aktuell aktiven Pufferspeicherplatzes. Wenn Sie teilweise von den Vorteilen der Arbeitsspeichereinsparung profitieren möchten, aktivieren Sie die abwärtskompatible Option. Setzen Sie dazu surface_flinger.clear_slots_with_set_layer_buffer-Sysprop auf true. Dieses Sysprop befindet sich in der Datei property_contexts.

Wenn Sie diesen Sysprop festlegen, muss Ihre Composer HAL-Implementierung mehrere setLayerBuffer-Befehle für dieselbe Schicht in einem einzigen vorhandenen Zyklus korrekt verarbeiten.

Das Aktivieren der abwärtskompatiblen Option hat folgende Auswirkungen:

  • Für AIDL HALs: SurfaceFlinger sendet mehrere LayerCommand-Instanzen für eine einzelne Ebene mit jeweils einer einzelnen BufferCommand. Jede BufferCommand enthält einen 1 × 1-Platzhalter-Puffer-Handle und eine Steckplatznummer für den Cache-Puffer-Steckplatz, der gelöscht werden muss.

  • Für HIDL HALs: SurfaceFlinger sendet mehrere SELECT_DISPLAY-, SELECT_LAYER- und SET_BUFFER-Befehle. Diese Befehle enthalten einen 1x1-Platzhalter-Zwischenspeicher-Handle und eine Slotnummer für den Cache-Zwischenspeicherslot, der dauerhaft gelöscht werden muss.

Die rückwärtskompatible Option kann dazu führen, dass die HAL von Composer auf einigen Geräten abstürzt. Möglicherweise können Sie Ihre Composer HAL ändern, um dieses Problem zu beheben. Der Code, der dieses Verhalten steuert, befindet sich hier:

Arbeitsspeicherverbrauch des Grafik-Buffer-Caches testen

Mit Tests kann nicht überprüft werden, ob die Cache-Slots von HAL-Implementierungen geleert werden. Sie können jedoch die Debugging-Tools verwenden, um die Nutzung der Grafikzwischenspeicherung zu überwachen. Bei der Überwachung sollten Sie feststellen, dass es in Szenarien, in denen mehrere verschiedene Videos auf YouTube in schneller Folge angehalten und gestartet werden, weniger Fehlermeldungen wegen fehlendem Arbeitsspeicher gibt.

Es sind VTS-Tests verfügbar, mit denen geprüft wird, ob die HAL-Implementierung funktionell in der Lage ist, die neuen API-Aufrufe (HAL-Version 3.2 oder höher) oder mehrere setLayerBuffer-Befehle für die abwärtskompatible Implementierung zu empfangen. Dies sollte jedoch nicht als ausreichendes Testen der ordnungsgemäßen Funktionalität betrachtet werden, da einige Geräte diese VTS-Tests bestehen, in realen Anwendungsfällen aber fehlschlagen.

Für neue VTS-Tests rufen Sie die folgenden Links auf: