اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
الطبقات والشاشات
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
الطبقات والشاشات هما عنصران أساسيان يمثّلان عمل التركيب
والتفاعلات مع أجهزة العرض.
الطبقات
الطبقة هي أهم وحدة في التركيب. الطبقة هي
مزيج من سطح ومثيل
SurfaceControl.
تحتوي كل طبقة على مجموعة من السمات التي تحدّد كيفية تفاعلها مع الطبقات الأخرى. يتم وصف سمات المحاولة التالية في الجدول التالي:
| الخاصية |
الوصف |
| الكلمات الرئيسية المتعلّقة بالموضع |
يحدِّد مكان ظهور الطبقة على الشاشة. يتضمّن معلومات
مثل مواضع حواف الطبقة وترتيبها حسب المحور Z
بالنسبة إلى الطبقات الأخرى (سواء كان يجب أن تكون أمام
الطبقات الأخرى أو خلفها). |
| المحتوى |
تحدّد كيفية عرض المحتوى المعروض على الطبقة ضمن
الحدود التي تحدّدها السمات الموضعية. تشمل هذه المعلومات
الاقتصاص (لتوسيع جزء من المحتوى لملء حدود الطبقة)
والتحويل (لعرض محتوى مُدار أو مقلوب). |
| مقطوعة موسيقية |
يحدِّد كيفية دمج الطبقة مع الطبقات الأخرى. يتضمّن
معلومات مثل وضع المزج وقيمة شفافية على مستوى الطبقة لدمج
الشفافية. |
| تحسين |
يوفّر معلومات ليست ضرورية تمامًا لدمج
الطبقة بشكل صحيح، ولكن يمكن لجهاز "أداة تركيب الأجهزة" (HWC)
استخدامها لتحسين كيفية تنفيذ عملية الدمج. يتضمّن معلومات، مثل
المنطقة المرئية من الطبقة والجزء الذي تم
تعديله من الطبقة منذ اللقطة السابقة. |
الشاشات
الشاشة هي وحدة أخرى مهمة للتركيب. يمكن أن يحتوي النظام على عدة شاشات ويمكن إضافة شاشات أو إزالتها أثناء عمليات النظام العادية. تتم إضافة الشاشات أو إزالتها بناءً على طلب من فريق HWC أو بناءً على طلب من إطار العمل.
يطلب جهاز HWC إضافة شاشات أو إزالتها عند توصيل شاشة
خارجية أو فصلها عن الجهاز، ما يُعرف باسم
hotplugging. يطلب العملاء شاشات افتراضية يتم عرض محتواها
في ذاكرة تخزين مؤقت خارج الشاشة بدلاً من عرضها على شاشة فعلية.
الشاشات الافتراضية
يتيح SurfaceFlinger
استخدام شاشة داخلية (مدمجة في الهاتف أو الجهاز اللوحي) وشاشات خارجية
(مثل تلفزيون متصل من خلال منفذ HDMI) وشاشة افتراضية واحدة أو أكثر
تتيح إمكانية عرض محتوى مجمّع داخل النظام. يمكن استخدام الشاشات الافتراضية
لتسجيل الشاشة أو إرسال الشاشة عبر شبكة. يتم كتابة الإطارات التي يتم إنشاؤها
لشاشة افتراضية في BufferQueue.
قد تشترك الشاشات الافتراضية في المجموعة نفسها من الطبقات التي تستخدمها الشاشة الرئيسية
(حزمة الطبقات) أو قد تستخدم مجموعة خاصة بها. لا يتوفّر معيار VSync للشاشة الافتراضية،
لذلك يؤدي معيار VSync للشاشة الداخلية إلى بدء عملية الدمج لجميع
الشاشات.
في عمليات تنفيذ HWC المتوافقة معهما، يمكن دمج الشاشة
الافتراضية باستخدام OpenGL ES (GLES) أو HWC أو كليهما.
في عمليات التنفيذ غير المتوافقة، يتم دائمًا دمج الشاشات الافتراضية باستخدام
GLES.
دراسة حالة: screenrecord
يسمح الأمر screenrecord للمستخدم بتسجيل كل ما يظهر على الشاشة كملف MP4 على القرص. لتنفيذ ذلك، يتلقّى النظام لقطات مجمّعة من
SurfaceFlinger ويكتبها في برنامج ترميز الفيديو، ثم يكتب بيانات
الفيديو المشفّرة في ملف. تتم إدارة برامج ترميز الفيديو من خلال عملية منفصلة
(mediaserver)، لذا يجب نقل وحدات تخزين الرسومات الكبيرة في
النظام. لزيادة مستوى الصعوبة، يُرجى تسجيل فيديو بمعدّل 60 لقطة في الثانية وبدرجة دقة كاملة. إنّ مفتاح تحقيق ذلك بكفاءة هو BufferQueue.
تسمح فئة MediaCodec للتطبيق بتقديم البيانات كوحدات بايت أولية في وحدات التخزين المؤقت،
أو من خلال سطح. عندما يطلب screenrecord الوصول إلى ملف ترميز
فيديو، تنشئ عملية mediaserver صفًا للانتظار، وتربط
نفسها بجهة المستهلك، ثم تعيد توجيه جهة المنتج إلى
screenrecord كسطح.
بعد ذلك، تطلب الأداة screenrecord من SurfaceFlinger إنشاء سطح شاشة
افتراضي يحاكي الشاشة الرئيسية (أي أنّه يتضمّن كل المستويات
نفسها)، وتوجّهه لإرسال الإخراج إلى السطح الذي جاء من عملية
mediaserver. في هذه الحالة، يكون SurfaceFlinger هو مُنشئ
المخازن المؤقتة بدلاً من المستخدِم.
بعد اكتمال الإعداد، يتم تنشيط screenrecord عند
ظهور البيانات المشفَّرة. أثناء رسم التطبيقات، يتم نقل ذاكرات التخزين المؤقت إلى SurfaceFlinger،
التي تجمعها في ذاكرة تخزين مؤقت واحدة يتم إرسالها مباشرةً إلى mediaserver لتشفير الفيديو. لا تتم معالجة اللقطات الكاملة أبدًا في عملية screenrecord. داخليًا، تمتلك عملية
mediaserver طريقة خاصة بها لنقل المخزن المؤقت الذي
ينقل البيانات أيضًا من خلال المعرّف، ما يقلل من الوقت المستغرَق.
دراسة حالة: محاكاة الشاشات الثانوية
يمكن أن يطلب WindowManager من SurfaceFlinger إنشاء طبقة مرئية يعمل فيها
SurfaceFlinger كمستهلك BufferQueue. من الممكن أيضًا أن تطلب من
SurfaceFlinger إنشاء شاشة افتراضية، ويكون SurfaceFlinger هو
مُنشئ BufferQueue.
في حال ربط شاشة افتراضية بطبقة مرئية، يتم إنشاء حلقة مغلقة
تظهر فيها الشاشة المجمّعة في نافذة. أصبحت هذه النافذة الآن جزءًا من المخرجات
المركّبة، لذا عند إعادة التحميل التالية، تعرِض الصورة المركّبة داخل النافذة
محتوى النافذة أيضًا. للاطّلاع على هذه الميزة، فعِّل خيارات المطوّرين في الإعدادات، ثم اختَر محاكاة الشاشات الثانوية، وفعِّل نافذة. للاطّلاع على
العروض الثانوية أثناء التشغيل، استخدِم screenrecord لتسجيل عملية
تفعيل الشاشة ثم إعادة تشغيلها إطارًا تلو الآخر.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# Layers and displays are two primitives that represent composition work\nand interactions with the display hardware.\n\nLayers\n------\n\nA *layer* is the most important unit of composition. A layer is a\ncombination of a [surface](/docs/core/graphics/arch-sh) and an instance of\n[`SurfaceControl`](https://developer.android.com/reference/android/view/SurfaceControl).\nEach layer has a set of properties that define how it interacts with other layers. Layer\nproperties are described in the following table:\n\n| Property | Description |\n|--------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Positional | Defines where the layer appears on its display. Includes information such as the positions of a layer's edges and its *Z order* relative to other layers (whether it should be in front of or behind other layers). |\n| Content | Defines how content displayed on the layer should be presented within the bounds defined by the positional properties. Includes information such as crop (to expand a portion of the content to fill the bounds of the layer) and transform (to show rotated or flipped content). |\n| Composition | Defines how the layer should be composited with other layers. Includes information such as blending mode and a layer-wide alpha value for [alpha compositing](https://en.wikipedia.org/wiki/Alpha_compositing#Alpha_blending). |\n| Optimization | Provides information not strictly necessary to correctly composite the layer, but that can be used by the Hardware Composer (HWC) device to optimize how it performs composition. Includes information such as the visible region of the layer and which portion of the layer has been updated since the previous frame. |\n\nDisplays\n--------\n\nA *display* is another important unit of composition. A system can\nhave multiple displays and\ndisplays can be added or removed during normal system operations. Displays are\nadded or removed at the request of the HWC or at the request of the framework.\nThe HWC device requests displays be added or removed when an external\ndisplay is connected or disconnected from the device, which is called\n*hotplugging* . Clients request *virtual displays*, whose contents\nare rendered into an off-screen buffer instead of to a physical display.\n\n### Virtual displays\n\n[SurfaceFlinger](/docs/core/graphics/arch-sf-hwc#surfaceflinger)\nsupports an internal display (built into the phone or tablet), external displays\n(such as a television connected through HDMI), and one or more virtual displays\nthat make composited output available within the system. Virtual displays can\nbe used to record the screen or send the screen over a network. Frames generated\nfor a virtual display are written to a BufferQueue.\n\nVirtual displays may share the same set of layers as the main display\n(the layer stack) or have their own set. There's no VSync for a virtual display,\nso the VSync for the internal display triggers composition for all\ndisplays.\n\nOn HWC implementations that support them, virtual\ndisplays can be composited with OpenGL ES (GLES), HWC, or both GLES and HWC.\nOn nonsupporting implementations, virtual displays are always composited using\nGLES.\n\nCase study: screenrecord\n------------------------\n\nThe [`screenrecord` command](https://android.googlesource.com/platform/frameworks/av/+/android16-release/cmds/screenrecord/) allows the user to\nrecord everything that appears on the screen as an MP4 file on\ndisk. To implement this, the system receives composited frames from\nSurfaceFlinger, writes them to the video encoder, and then writes the encoded\nvideo data to a file. The video codecs are managed by a separate process\n(`mediaserver`), so large graphics buffers have to move around the\nsystem. To make it more challenging, the goal is to record 60 fps video at\nfull resolution. The key to making this work efficiently is BufferQueue.\n\nThe `MediaCodec` class allows an app to provide data as raw bytes in buffers,\nor through a surface. When `screenrecord` requests access to a video\nencoder, the `mediaserver` process creates a BufferQueue, connects\nitself to the consumer side, then passes the producer side back to\n`screenrecord` as a surface.\n\nThe `screenrecord` utility then asks SurfaceFlinger to create a\nvirtual display that mirrors the main display (that is, it has all of the same\nlayers), and directs it to send output to the surface that came from the\n`mediaserver` process. In this case, SurfaceFlinger is the producer\nof buffers rather than the consumer.\n\nAfter the configuration is complete, `screenrecord` triggers when\nthe encoded data appears. As apps draw, their buffers travel to SurfaceFlinger,\nwhich composites them into a single buffer that's sent directly to the video\nencoder in the `mediaserver` process. The full frames are never\nseen by the `screenrecord` process. Internally, the\n`mediaserver` process has its own way of moving buffers around that\nalso passes data by handle, minimizing overhead.\n\nCase study: simulate secondary displays\n---------------------------------------\n\nThe WindowManager can ask SurfaceFlinger to create a visible layer for which\nSurfaceFlinger acts as the BufferQueue consumer. It's also possible to ask\nSurfaceFlinger to create a virtual display, for which SurfaceFlinger acts as\nthe BufferQueue producer.\n\nIf you connect a virtual display to a visible layer, a closed loop is created\nwhere the composited screen appears in a window. That window is now part of the\ncomposited output, so on the next refresh the composited image inside the window\nshows the window contents as well. To see this in action, enable\n[Developer options](https://developer.android.com/studio/debug/dev-options) in **Settings** , select\n**Simulate secondary displays** , and enable a window. To see\nsecondary displays in action, use `screenrecord` to capture the act\nof enabling the display then play it back frame by frame."]]
