از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
SurfaceFlinger و WindowManager
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
SurfaceFlinger بافرها را میپذیرد، بافرها را مینویسد و بافرها را به صفحه نمایش میفرستد. WindowManager
بافرها و ابرداده های پنجره را به SurfaceFlinger می دهد که SurfaceFlinger از آنها برای ترکیب سطوح روی نمایشگر استفاده می کند.
سرفیس فلینگر
SurfaceFlinger می تواند به دو طریق بافرها را بپذیرد: از طریق BufferQueue و SurfaceControl
یا از طریق ASurfaceControl
.
یکی از راه هایی که SurfaceFlinger بافرها را می پذیرد از طریق BufferQueue و SurfaceControl
است. هنگامی که یک برنامه در پیش زمینه قرار می گیرد، از WindowManager
درخواست بافر می کند. سپس WindowManager
یک لایه از SurfaceFlinger درخواست می کند. یک لایه ترکیبی از یک سطح است که حاوی BufferQueue و یک نمونه SurfaceControl
است که حاوی ابرداده لایه مانند قاب نمایش است. SurfaceFlinger لایه را ایجاد می کند و آن را به WindowManager
ارسال می کند. سپس WindowManager
سطح را به برنامه می فرستد، اما نمونه SurfaceControl
برای دستکاری ظاهر برنامه روی صفحه نگه می دارد.
اندروید 10 ASurfaceControl
اضافه می کند، که راه دیگری است که SurfaceFlinger می تواند بافرها را بپذیرد. ASurfaceControl
یک سطح و یک نمونه SurfaceControl
را در یک بسته تراکنش ترکیب می کند که به SurfaceFlinger ارسال می شود. ASurfaceControl
با لایه ای مرتبط است که برنامه ها از طریق نمونه های ASurfaceTransaction
به روز می شوند. سپس برنامهها اطلاعات مربوط به نمونههای ASurfaceTransaction
را از طریق تماسهایی دریافت میکنند که ASurfaceTransactionStats
حاوی اطلاعاتی مانند زمان قفل، زمانهای دریافت و غیره را ارسال میکنند.
جدول زیر شامل جزئیات بیشتر در مورد ASurfaceControl
و اجزای مرتبط با آن است:
جزء | توضیحات |
---|
ASurfaceControl | SurfaceControl را می پیچد و یک برنامه را قادر می سازد تا نمونه هایی از SurfaceControl ایجاد کند که مطابق با لایه های نمایشگر هستند.
می تواند به عنوان فرزند ANativeWindow یا فرزند نمونه دیگری از ASurfaceControl ایجاد شود. |
ASurfaceTransaction | Transaction Wraps می کند تا مشتری را قادر سازد تا ویژگی های توصیفی یک لایه را ویرایش کند، مانند هندسه، و بافرهای به روز شده را به SurfaceFlinger ارسال می کند. |
ASurfaceTransactionStats اطلاعات مربوط به تراکنشهای ارائهشده، مانند زمان اتصال، زمانهای کسب، و حصار انتشار قبلی را از طریق یک تماس از قبل ثبتشده به برنامه ارسال میکند. |
اگرچه برنامهها میتوانند در هر زمانی بافر ارسال کنند، SurfaceFlinger فقط برای پذیرش بافرها بین بازخوانیهای نمایشگر بیدار میشود، که بسته به دستگاه میتواند متفاوت باشد. این کار مصرف حافظه را به حداقل میرساند و از پاره شدن قابل مشاهده روی صفحه جلوگیری میکند، که ممکن است هنگام بهروزرسانی صفحه نمایش در اواسط بازخوانی رخ دهد.
هنگامی که نمایشگر بین رفرش است، نمایشگر سیگنال VSync را به SurfaceFlinger ارسال می کند. سیگنال VSync نشان می دهد که صفحه نمایش را می توان بدون پاره شدن تازه کرد. هنگامی که SurfaceFlinger سیگنال VSync را دریافت می کند، SurfaceFlinger در لیست لایه های خود به دنبال بافرهای جدید می رود. اگر SurfaceFlinger یک بافر جدید پیدا کند، SurfaceFlinger بافر را بدست می آورد. در غیر این صورت، SurfaceFlinger به استفاده از بافری که قبلا به دست آورده بود، ادامه می دهد. SurfaceFlinger همیشه باید چیزی را نمایش دهد، بنابراین به یک بافر آویزان می شود. اگر هیچ بافری روی یک لایه ارسال نشده باشد، لایه نادیده گرفته می شود.
پس از اینکه SurfaceFlinger تمام بافرهای لایه های قابل مشاهده را جمع آوری کرد، از Hardware Composer (HWC) می پرسد که ترکیب بندی چگونه باید انجام شود. اگر HWC نوع ترکیب لایه را به عنوان ترکیب مشتری علامت گذاری کند، SurfaceFlinger آن لایه ها را ترکیب می کند. سپس SurfaceFlinger بافر خروجی را به HWC ارسال می کند.
WindowManager
WindowManager
اشیاء Window
را کنترل می کند که محفظه هایی برای View
اشیاء هستند. اشیاء Window
همیشه توسط آبجکت های Surface
پشتیبانی می شوند. WindowManager
بر چرخههای عمر، رویدادهای ورودی و تمرکز، جهتگیری صفحه، انتقالها، انیمیشنها، موقعیت، تبدیلها، ترتیب z و بسیاری از جنبههای دیگر یک پنجره نظارت میکند. WindowManager
تمام ابرداده های پنجره را به SurfaceFlinger می فرستد تا SurfaceFlinger بتواند از آن داده ها برای ترکیب سطوح روی نمایشگر استفاده کند.
پیش چرخش
بسیاری از پوششهای سختافزاری از چرخش پشتیبانی نمیکنند (و حتی اگر این کار را انجام دهند، قدرت پردازش هزینه دارد). راه حل این است که بافر را قبل از رسیدن به SurfaceFlinger تبدیل کنید. Android از یک اشاره پرس و جو ( NATIVE_WINDOW_TRANSFORM_HINT
) در ANativeWindow
پشتیبانی می کند تا محتمل ترین تبدیلی را که توسط SurfaceFlinger به بافر اعمال می شود، نشان دهد. درایورهای GL میتوانند از این راهنمایی برای پیشتغییر بافر قبل از رسیدن به SurfaceFlinger استفاده کنند تا وقتی بافر رسید، به درستی تبدیل شود.
به عنوان مثال، هنگام دریافت راهنمایی برای چرخش 90 درجه، یک ماتریس ایجاد و روی بافر اعمال کنید تا از پایان صفحه جلوگیری شود. برای صرفه جویی در مصرف برق، این پیش چرخش را انجام دهید. برای جزئیات، به رابط ANativeWindow
تعریف شده در system/core/include/system/window.h
مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],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`."]]