SurfaceFlinger akzeptiert, komponiert und sendet Buffers an das Display. WindowManager stellt SurfaceFlinger Buffers und Fenstermetadaten zur Verfügung, mit denen SurfaceFlinger Oberflächen auf dem Display zusammensetzt.
SurfaceFlinger
SurfaceFlinger kann Buffers auf zwei Arten akzeptieren: über BufferQueue und SurfaceControl oder über ASurfaceControl.
Eine Möglichkeit, wie SurfaceFlinger Buffers akzeptiert, ist über BufferQueue und SurfaceControl. Wenn eine App in den Vordergrund rückt, fordert sie Buffers vom WindowManager an. WindowManager fordert dann eine Ebene von SurfaceFlinger an. Eine Ebene ist eine Kombination aus einer Surface, die die BufferQueue enthält, und einer SurfaceControl, die die Ebenenmetadaten wie den Displayframe enthält. SurfaceFlinger erstellt die Ebene und sendet sie an WindowManager. WindowManager sendet die Oberfläche dann an die App, behält aber die SurfaceControl bei, um das Erscheinungsbild der App auf dem Bildschirm zu manipulieren.
In Android 10 wird ASurfaceControl hinzugefügt, eine weitere Möglichkeit, wie SurfaceFlinger Buffers akzeptieren kann. ASurfaceControl kombiniert eine Oberfläche und eine SurfaceControl in einem Transaktionspaket, das an SurfaceFlinger gesendet wird. Eine ASurfaceControl ist mit einer Ebene verknüpft, die Apps über ASurfaceTransactions aktualisieren. Apps erhalten dann Informationen zu ASurfaceTransactions über Callbacks, die ASurfaceTransactionStats mit Informationen wie Lach-Zeit, Beschaffungszeit usw. übergeben.
Die folgende Tabelle enthält weitere Details zu ASurfaceControl und den zugehörigen Komponenten.
Komponente | Beschreibung |
---|---|
ASurfaceControl | Umschließt SurfaceControl und ermöglicht es einer App, SurfaceControls zu erstellen, die den Ebenen auf dem Display entsprechen. Kann als untergeordnetes Element von ANativeWindow oder als untergeordnetes Element eines anderen ASurfaceControl erstellt werden. |
ASurfaceTransaction | Fasst die Transaktion zusammen, damit der Client die beschreibenden Eigenschaften einer Ebene bearbeiten kann, z. B. die Geometrie, und sendet die aktualisierten Zwischenspeicher an SurfaceFlinger. |
ASurfaceTransactionStats | Sendet Informationen zu Transaktionen, die präsentiert wurden, z. B. Latch-Zeit, Akquisitionszeiten und vorherige Release-Grenzen, über einen vorab registrierten Rückruf an eine App. |
Obwohl Apps jederzeit Puffer senden können, wird SurfaceFlinger nur aktiviert, um Puffer zwischen Anzeigeaktualisierungen zu akzeptieren, die je nach Gerät variieren können. Dadurch wird die Arbeitsspeichernutzung minimiert und ein sichtbares Aufreißen auf dem Bildschirm verhindert, das auftreten kann, wenn das Display während der Aktualisierung aktualisiert wird.
Wenn sich das Display zwischen den Aktualisierungen befindet, sendet es das VSYNC-Signal an SurfaceFlinger. Das VSYNC-Signal gibt an, dass das Display ohne Tearing aktualisiert werden kann. Wenn SurfaceFlinger das VSYNC-Signal empfängt, sucht er in seiner Liste der Ebenen nach neuen Buffers. Wenn SurfaceFlinger einen neuen Puffer findet, holt es ihn ab. Andernfalls verwendet SurfaceFlinger weiterhin den zuvor abgerufenen Puffer. SurfaceFlinger muss immer etwas anzeigen, damit es an einem Zwischenspeicher hängt. Wenn noch keine Zwischenspeicher für eine Ebene gesendet wurden, wird die Ebene ignoriert.
Nachdem SurfaceFlinger alle Buffers für sichtbare Ebenen erfasst hat, fragt er den Hardware Composer (HWC), wie die Zusammensetzung erfolgen soll. Wenn der HWC den Ebenenzusammensetzungstyp als Clientzusammensetzung kennzeichnet, werden diese Ebenen von SurfaceFlinger zusammengesetzt. Anschließend gibt SurfaceFlinger den Ausgabepuffer an die HWC weiter.
WindowManager
WindowManager steuert Fenster-Objekte, die Container für Ansicht-Objekte sind. Fensterobjekte werden immer von Oberflächenobjekten unterstützt. Der WindowManager überwacht Lebenszyklen, Eingabe- und Fokusereignisse, Bildschirmausrichtung, Übergänge, Animationen, Position, Transformationen, Z-Reihenfolge und viele andere Aspekte eines Fensters. WindowManager sendet alle Fenstermetadaten an SurfaceFlinger, damit SurfaceFlinger diese Daten zum Zusammensetzen von Oberflächen auf dem Display verwenden kann.
Vor Rotation
Viele Hardware-Overlays unterstützen keine Drehung (und selbst wenn, kostet das Rechenleistung). Die Lösung besteht darin, den Puffer zu transformieren, bevor er SurfaceFlinger erreicht. Android unterstützt einen Abfragehinweis (NATIVE_WINDOW_TRANSFORM_HINT
) in ANativeWindow
, um die Transformation darzustellen, die von SurfaceFlinger am wahrscheinlichsten auf den Zwischenspeicher angewendet wird. GL-Treiber können diesen Hinweis verwenden, um den Puffer vor der Übertragung an SurfaceFlinger zu transformieren, damit er bei der Ankunft korrekt transformiert ist.
Wenn Sie beispielsweise einen Hinweis zur Drehung um 90 Grad erhalten, generieren und wenden Sie eine Matrix auf den Puffer an, damit er nicht über das Ende der Seite hinausragt. Führen Sie diese Schritte vor der Drehung aus, um Strom zu sparen. Weitere Informationen finden Sie in der ANativeWindow
-Benutzeroberfläche, die in system/core/include/system/window.h
definiert ist.