Client-Framebuffer-Verwaltung

Ab Android 13 werden neue Framebuffer, die während der Client-Zusammensetzung verwendet werden, immer dann zugewiesen, wenn sich die Bildschirmauflösung ändert. Diese Zuweisung wird von SurfaceFlinger im nächsten invalidate-Zyklus nach einer Auflösungsänderung durchgeführt.

Framebuffer-Verwaltung bei Auflösungswechseln

Änderungen der Auflösung können in einem der folgenden beiden Szenarien auftreten:

  • Ein Hotplug-Ereignis, das vom Hardware Composer (HWC) initiiert wird und auftritt, wenn von einem externen Display zu einem anderen externen Display mit einer anderen Standardauflösung gewechselt wird.

    Bei einem Hotplug-Ereignis werden die Handles für die alten Framebuffer freigegeben, wenn die alten Displaydaten freigegeben werden.

  • Ein von SurfaceFlinger initiierter Displaymoduswechsel, der auftritt, wenn der Nutzer die Auflösung über die Nutzereinstellungen ändert oder eine App die Auflösung über preferredDisplayModeId ändert.

    Beim Wechsel des Anzeigemodus werden die Handles für vorhandene Client-Framebuffer von SurfaceFlinger freigegeben, bevor setActiveConfig oder setActiveConfigWithConstraints aufgerufen wird.

Um schwerwiegende Probleme wie die Speicherfragmentierung auf Geräten zu vermeiden, die nicht genügend Speicher für die alten und neuen Framebuffer reservieren, ist es wichtig, dass HWC die alten Framebuffer nicht mehr verwendet und alle Handles für diese Framebuffer freigibt, wie in den folgenden Fällen gezeigt:

Durch das Freigeben der Handles kann der Framebuffer-Speicher vollständig freigegeben werden, bevor neue Framebuffer zugewiesen werden, was SurfaceFlinger während des nächsten invalidate-Zyklus ausführt.

Empfehlungen für die Framebuffer-Verwaltung

Wenn HWC Handles für alte Framebuffer nicht rechtzeitig freigibt, erfolgt die neue Framebuffer-Zuweisung vor der alten Framebuffer-Freigabe. Dies kann zu schwerwiegenden Problemen führen, wenn die neue Zuweisung aufgrund von Fragmentierung oder anderen Problemen fehlschlägt. Noch schlimmer ist es, wenn HWC diese Handles überhaupt nicht freigibt, da dann ein Speicherleck auftreten kann.

Um schwerwiegende Zuweisungsfehler zu vermeiden, sollten Sie die folgenden Empfehlungen beachten:

  • Wenn HWC die alten Client-Framebuffer weiterhin verwenden muss, bis die neuen Client-Framebuffer bereitgestellt werden, ist es wichtig, genügend Arbeitsspeicher für die alten und neuen Framebuffer zu reservieren und möglicherweise Defragmentierungsalgorithmen für den Framebuffer-Arbeitsspeicher auszuführen.

  • Weisen Sie den Framebuffern einen dedizierten Arbeitsspeicherpool zu, der vom restlichen Grafikpuffer-Arbeitsspeicher getrennt ist. Das ist wichtig, da zwischen der Freigabe und der Neuzuweisung der Framebuffer ein Drittanbieterprozess versuchen kann, Grafikspeicher zuzuweisen. Wenn derselbe Grafikspeicherpool vom Framebuffer verwendet wird und der Grafikspeicher voll ist, kann der Drittanbieterprozess den Grafikspeicher belegen, der zuvor von einem Framebuffer zugewiesen wurde. Dadurch bleibt nicht genügend Speicher für die Neuzuweisung des Framebuffers oder der Speicherplatz wird möglicherweise fragmentiert.

Framebuffer-Verwaltung testen

OEMs wird empfohlen, das korrekte Client-Framebuffer-Speichermanagement bei Auflösungswechseln für ihr Gerät zu testen. Das Vorgehen wird im Folgenden beschrieben:

  • Bei Hotplug-Ereignissen müssen Sie einfach zwei verschiedene Displays mit unterschiedlichen Auflösungen trennen und wieder anschließen.

  • Verwenden Sie für Moduswechsel den ModeSwitchingTestActivity CTS-Verifier-Test, um einen Moduswechsel zum Testen des Framebuffer-Speicherverhaltens zu initiieren. Mit diesem Test lassen sich Probleme visuell erkennen, die sich programmatisch nur schwer ermitteln lassen.