2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
SurfaceFlinger と WindowManager
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
SurfaceFlinger は、バッファを受け取り、合成して、ディスプレイに送ります。WindowManager は、バッファとウィンドウ メタデータを SurfaceFlinger に提供し、これを使用して SurfaceFlinger がサーフェスを合成してディスプレイに送ります。
SurfaceFlinger
SurfaceFlinger がバッファを受け取る方法は 2 つあります。BufferQueue と SurfaceControl を通じて受け取る方法、および ASurfaceControl を通じて受け取る方法です。
SurfaceFlinger がバッファを受け取る方法の一つは、BufferQueue と SurfaceControl を通す方法です。アプリは、フォアグラウンドになると WindowManager にバッファをリクエストします。次に WindowManager は SurfaceFlinger にレイヤをリクエストします。レイヤとは、BufferQueue を含んだサーフェスと、ディスプレイ フレームのようなレイヤ メタデータを含んだ SurfaceControl の組み合わせです。SurfaceFlinger は、レイヤを作成し、それを WindowManager に送ります。すると、WindowManager はサーフェスをアプリに送りますが、画面上でのアプリの外観を操作するために SurfaceControl を保持します。
Android 10 では、SurfaceFlinger がバッファを受け取るもう 1 つの方法として、ASurfaceControl が追加されています。ASurfaceControl は、サーフェスと SurfaceControl を 1 つのトランザクション パッケージに結合して SurfaceFlinger に送ります。ASurfaceControl は、アプリが ASurfaceTransaction を通じて更新するレイヤに関連付けられます。アプリはコールバックを通じて ASurfaceTransaction に関する情報を取得します。このコールバックは、ラッチ時間、取得時間などの情報を含む ASurfaceTransactionStats を渡します。
次の表は、ASurfaceControl とその関連コンポーネントの詳細です。
コンポーネント |
説明 |
ASurfaceControl |
SurfaceControl をラップし、ディスプレイ上のレイヤに対応する SurfaceControl をアプリが作成できるようにします。
ANativeWindow の子として、または別の ASurfaceControl の子として作成できます。 |
ASurfaceTransaction |
Transaction をラップして、クライアントがジオメトリなどのレイヤの記述プロパティを編集し、更新されたバッファを SurfaceFlinger に送信できるようにします。 |
ASurfaceTransactionStats |
ラッチ時間、取得時間、前のリリース フェンスなどの与えられたトランザクションに関する情報を、事前登録されたコールバックを通じてアプリに送信します。 |
アプリはいつでもバッファを送れますが、SurfaceFlinger はディスプレイのリフレッシュ(デバイスによって異なる)の合間でのみ復帰してバッファを受け取ります。それによってメモリの使用量が最小限に抑えられ、ディスプレイのリフレッシュの途中で発生する画面の乱れがなくなります。
ディスプレイは、リフレッシュの合間に、VSYNC 信号を SurfaceFlinger に送ります。VSYNC 信号は、ディスプレイが乱れを発生させることなくリフレッシュできることを示します。SurfaceFlinger は、VSYNC 信号を受信すると、新しいバッファを見つけるためにレイヤのリストを確認します。SurfaceFlinger が新しいバッファを検出した場合、そのバッファを取得します。検出しなかった場合、以前に取得したバッファを引き続き使用します。SurfaceFlinger は常に何かを表示する必要があるため、1 つのバッファを保持し続けます。レイヤにバッファが送られていない場合、そのレイヤは無視されます。
SurfaceFlinger は、表示されるレイヤのすべてのバッファを収集した後、Hardware Composer(HWC)に合成方法を尋ねます。HWC がレイヤ合成タイプをクライアント合成にマークすると、SurfaceFlinger がそれらのレイヤを合成します。次に SurfaceFlinger は出力バッファを HWC に渡します。
WindowManager
WindowManager は、View オブジェクトのコンテナである Window オブジェクトを制御します。Window オブジェクトの背後には常に Surface オブジェクトがあります。WindowManager は、ライフサイクル、入力イベントやフォーカス イベント、画面の向き、遷移、アニメーション、位置、変換、Z オーダーなどのウィンドウの特性を監視します。WindowManager はすべてのウィンドウ メタデータを SurfaceFlinger に送るため、SurfaceFlinger はそのデータを使用してディスプレイ上にサーフェスを合成できます。
事前回転
多くのハードウェア オーバーレイは回転に対応していません(対応していても負荷の大きい処理です)。これは、SurfaceFlinger に到達する前にバッファを変換すれば解決します。Android は、ANativeWindow
でクエリヒント(NATIVE_WINDOW_TRANSFORM_HINT
)をサポートしており、SurfaceFlinger によってバッファに適用される可能性が最も高い変換を提示できます。GL ドライバは、このヒントを使用して SurfaceFlinger に到達する前にバッファを事前変換し、バッファが到着したときに正しく変換されているようにします。
たとえば、ヒントが 90 度の回転である場合、行列を生成してバッファに適用して、ページからはみ出さないようにします。電力を節約するには、この事前回転を行ってください。詳しくは、system/core/include/system/window.h
で定義されている ANativeWindow
インターフェースをご覧ください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# SurfaceFlinger and WindowManager\n\nSurfaceFlinger accepts buffers, composes buffers, and sends buffers to the\ndisplay. `WindowManager` provides SurfaceFlinger with buffers and window\nmetadata, which SurfaceFlinger uses to composite surfaces to the display.\n\nSurfaceFlinger\n--------------\n\nSurfaceFlinger can accept buffers in two ways: through BufferQueue and\n`SurfaceControl`, or through `ASurfaceControl`.\n\nOne way SurfaceFlinger accepts buffers is through BufferQueue and\n`SurfaceControl`. When an app comes to the foreground, it requests buffers from\n[`WindowManager`](https://developer.android.com/reference/android/view/WindowManager.html). `WindowManager` then requests a layer from\nSurfaceFlinger. A layer is a combination of a [surface](/docs/core/graphics/arch-sh), which contains the BufferQueue, and\na [`SurfaceControl`](https://developer.android.com/reference/android/view/SurfaceControl) instance,\nwhich contains the layer metadata like the display frame.\nSurfaceFlinger creates the layer and sends it to `WindowManager`. `WindowManager`\nthen sends the surface to the app, but keeps the `SurfaceControl` instance to\nmanipulate the appearance of the app on the screen.\n\nAndroid 10 adds `ASurfaceControl`, which is another\nway that SurfaceFlinger can accept buffers. `ASurfaceControl` combines a surface\nand a `SurfaceControl` instance into one transaction package that is sent to\nSurfaceFlinger. `ASurfaceControl` is associated with a layer, which apps\nupdate through `ASurfaceTransaction` instances. Apps then get information about\n`ASurfaceTransaction` instances through callbacks that pass `ASurfaceTransactionStats`\ncontaining information, such as latch time, acquire times, and so on.\n\nThe following table includes more details about `ASurfaceControl` and its\nassociated components:\n\n| Component | Description |\n|----------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `ASurfaceControl` | Wraps `SurfaceControl` and enables an app to create `SurfaceControl` instances that correspond to layers on the display. Can be created as a child of `ANativeWindow` or as a child of another `ASurfaceControl` instance. |\n| `ASurfaceTransaction` | Wraps `Transaction` to enable the client to edit a layer's descriptive properties, such as geometry, and sends the updated buffers to SurfaceFlinger. |\n| `ASurfaceTransactionStats` | Sends information about transactions that have been presented, such as latch time, acquire times, and previous release fence, to an app through a preregistered callback. |\n\nThough apps can submit buffers at any time, SurfaceFlinger only wakes up to\naccept buffers between display refreshes, which can differ depending on the\ndevice. This minimizes memory usage and avoids visible tearing on the\nscreen, which can occur when updating the display mid-refresh.\n\nWhen the display is between refreshes, the display sends the VSync\nsignal to SurfaceFlinger. The VSync signal indicates that the display can be\nrefreshed without tearing. When SurfaceFlinger receives the VSync signal, SurfaceFlinger\nwalks through its list of layers looking for new buffers. If SurfaceFlinger finds a\nnew buffer, SurfaceFlinger acquires the buffer; if not, SurfaceFlinger continues\nto use the previously acquired buffer. SurfaceFlinger must always display something,\nso it hangs on to one buffer. If no buffers have ever been submitted on a\nlayer, the layer is ignored.\n\nAfter SurfaceFlinger has collected all buffers for visible layers, it asks\nthe Hardware Composer (HWC) how composition should be performed. If the HWC\nmarks layer composition type as client composition, SurfaceFlinger composites those\nlayers. Then, SurfaceFlinger passes the output buffer to the [HWC](/docs/core/graphics/implement-hwc).\n\nWindowManager\n-------------\n\n`WindowManager` controls [`Window`](https://developer.android.com/reference/android/view/Window) objects,\nwhich are containers for [`View`](https://developer.android.com/reference/android/view/View)\nobjects. `Window` objects are always backed by\n[`Surface`](https://developer.android.com/reference/android/view/Surface) objects.\n`WindowManager` oversees lifecycles, input and focus\nevents, screen orientation, transitions, animations, position, transforms,\nz-order, and many other aspects of a window. `WindowManager` sends all of the\nwindow metadata to SurfaceFlinger so SurfaceFlinger can use that data to\ncomposite surfaces on the display.\n\n### Pre-rotation\n\nMany hardware overlays don't support rotation (and even if they do, it costs\nprocessing power); the solution is to transform the buffer before it reaches\nSurfaceFlinger. Android supports a query hint\n(`NATIVE_WINDOW_TRANSFORM_HINT`) in `ANativeWindow` to\nrepresent the most likely transform to be applied to the buffer by\nSurfaceFlinger. GL drivers can use this hint to pre-transform the buffer\nbefore it reaches SurfaceFlinger so that when the buffer arrives, it's correctly\ntransformed.\n\nFor example, when receiving a hint to rotate 90 degrees, generate and apply a\nmatrix to the buffer to prevent it from running off the end of the page. To save\npower, do this pre-rotation. For details, see the `ANativeWindow`\ninterface defined in `system/core/include/system/window.h`."]]