اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
SurfaceFlinger وWindowManager
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يقبل SurfaceFlinger وحدات التخزين المؤقت وينشئها ويرسلها إلى الشاشة. WindowManager يقدّم SurfaceFlinger وحدات تخزين مؤقت وبيانات وصفية للنوافذ، ويستخدمها SurfaceFlinger لدمج مساحات العرض على الشاشة.
SurfaceFlinger
يمكن أن يقبل SurfaceFlinger وحدات التخزين المؤقت بطريقتَين: من خلال BufferQueue و
SurfaceControl أو من خلال ASurfaceControl.
تتمثل إحدى طرق قبول SurfaceFlinger للوسائط المخزّنة في BufferQueue و
SurfaceControl. عندما يظهر تطبيق في المقدّمة، يطلب من
WindowManager وحدات تخزين مؤقت. يطلب WindowManager بعد ذلك طبقة من
SurfaceFlinger. الطبقة هي عبارة عن تركيبة من سطح يحتوي على BufferQueue وSurfaceControl،
التي تحتوي على البيانات الوصفية للطبقة، مثل إطار العرض.
ينشئ SurfaceFlinger الطبقة ويرسلها إلى WindowManager. WindowManager
يُرسِل بعد ذلك السطح إلى التطبيق، ولكن يحافظ على مثيل SurfaceControl ل
التلاعب بمظهر التطبيق على الشاشة.
يضيف نظام Android 10 ASurfaceControl، وهي طريقة أخرى
يمكن من خلالها لـ SurfaceFlinger قبول وحدات التخزين المؤقت. يدمج ASurfaceControl سطحًا
ومثيل SurfaceControl في حزمة معاملة واحدة يتم إرسالها إلى
SurfaceFlinger. يكون ASurfaceControl مرتبطًا بطبقة، وتعدّل التطبيقاتASurfaceTransaction من خلال نُسخ ASurfaceTransaction. تحصل التطبيقات بعد ذلك على معلومات عن مثيلات
ASurfaceTransaction من خلال عمليات الاستدعاء التي تُرسل ASurfaceTransactionStats
التي تحتوي على معلومات، مثل وقت الربط وأوقات الاكتساب وما إلى ذلك.
يتضمن الجدول التالي مزيدًا من التفاصيل حول ASurfaceControl و
مكوناته المرتبطة:
| المكوّن |
الوصف |
ASurfaceControl |
يُغلِّف SurfaceControl ويسمح للتطبيق بإنشاء مثيلات SurfaceControl
تتوافق مع الطبقات على الشاشة.
يمكن إنشاؤه كعنصر تابع
ANativeWindow أو كعنصر تابع لمثيل ASurfaceControl آخر. |
ASurfaceTransaction |
لفّ Transaction لإتاحة تعديل العميل للخصائص الوصفية
للطبقة، مثل الأشكال الهندسية، وإرسال المخازن المؤقتة المعدَّلة إلى
SurfaceFlinger |
ASurfaceTransactionStats
| تُرسِل هذه العملية معلومات عن المعاملات التي تم عرضها، مثل
وقت الانتظار ووقت اكتساب الإصدار السابق ووقت الانتظار السابق للإصدار، إلى تطبيق من خلال callback
مسجَّل مسبقًا. |
على الرغم من أنّ التطبيقات يمكنها إرسال ذاكرات التخزين المؤقت في أي وقت، لا يتم تفعيل SurfaceFlinger إلا لقبول ذاكرات التخزين المؤقت بين عمليات إعادة تحميل الشاشة، والتي يمكن أن تختلف حسب
الجهاز. ويؤدي ذلك إلى تقليل استخدام الذاكرة وتجنُّب حدوث تمزّق مرئي على
الشاشة، والذي يمكن أن يحدث عند تعديل الشاشة أثناء عملية إعادة التحميل.
عندما تكون الشاشة بين عمليات إعادة التحميل، تُرسِل الشاشة إشارة VSync
إلى SurfaceFlinger. تشير إشارة VSync إلى أنّه يمكن إعادة رسوم الشاشة
بدون تمزيق. عندما يتلقّى SurfaceFlinger إشارة VSync، يبحث SurfaceFlinger
في قائمة الطبقات بحثًا عن وحدات تخزين مؤقتة جديدة. إذا عثر SurfaceFlinger على ملف تدخُّل
جديد، يحصل عليه. وإذا لم يعثر على ملف تدخُّل جديد، يواصل SurfaceFlinger استخدام
ملف التدخُّل الذي حصل عليه سابقًا. يجب أن يعرض SurfaceFlinger دائمًا محتوى معيّنًا،
لذلك يتم تثبيته على مخزن مؤقت واحد. إذا لم يتم إرسال أيّ ذاكرة تخزين مؤقت على أحد
الطبقات، يتم تجاهل الطبقة.
بعد أن يجمع SurfaceFlinger جميع وحدات التخزين المؤقت للطبقات المرئية، يسأل
أداة Hardware Composer (HWC) عن كيفية تنفيذ عملية الدمج. إذا وضعت واجهة HWC
علامة على نوع تركيبة الطبقة على أنّه تركيبة العميل، يُجمِّع SurfaceFlinger تلك
الطبقات. بعد ذلك، يُرسِل SurfaceFlinger وحدة تخزين مؤقت للإخراج إلى HWC.
WindowManager
تتحكّم WindowManager في عناصر Window،
وهي حاويات لعناصر View. يتم دائمًا الاحتفاظ بنسخة احتياطية من عناصر Window باستخدام عناصر
Surface.
WindowManager تتولى الإشراف على دورات الحياة وأحداث الإدخال والتركيز
واتجاه الشاشة والانتقالات والصور المتحركة والموضع والتحولات
وترتيب z والعديد من الجوانب الأخرى للنافذة. تُرسِل WindowManager جميع
البيانات الوصفية للنوافذ إلى SurfaceFlinger حتى يتمكّن من استخدام هذه البيانات ل
تجميع مساحات العرض على الشاشة.
الدوران المُسبَق
لا تتيح العديد من عمليات التراكب على الأجهزة إمكانية التدوير (وحتى إذا كانت تتيح ذلك، فإنّها تستهلك
طاقة المعالجة)، لذا فإنّ الحلّ هو تحويل المخزن المؤقت قبل وصوله إلى
SurfaceFlinger. يتيح Android تلميح طلب بحث
(NATIVE_WINDOW_TRANSFORM_HINT) في ANativeWindow لتمثيل عملية التحويل الأكثر احتمالًا ليتم تطبيقها على المخزن المؤقت من قِبل
SurfaceFlinger. يمكن لبرامج تشغيل GL استخدام هذه التلميحة لتحويل المخزن المؤقت مسبقًا
قبل وصوله إلى SurfaceFlinger، وذلك لكي يتم تحويله بشكلٍ صحيح عند وصوله.
على سبيل المثال، عند تلقّي تلميح للدوران 90 درجة، يمكنك إنشاء matroid وتطبيقه على المخزن المؤقت لمنع تجاوزه نهاية الصفحة. لتوفير
الطاقة، عليك إجراء هذا الدوران المُسبَق. لمعرفة التفاصيل، يُرجى الاطّلاع على ANativeWindow
واجهة system/core/include/system/window.h.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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`."]]
