اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
Hardware Composer HAL
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يحدِّد "واجهة برمجة التطبيقات لبرنامج Hardware Composer (HWC)" الطريقة الأكثر فعالية لتركيب المخزن المؤقت باستخدام الأجهزة المتاحة. وبما أنّه HAL، فإنّ تنفيذه
يعتمد على الجهاز، وعادةً ما ينفّذه المصنّع الأصلي لأجهزة العرض.
من السهل التعرّف على قيمة هذا النهج عند التفكير في مستويات التراكب التي تُنشئ وحدات تخزين مؤقت متعددة في
معدات العرض بدلاً من وحدة معالجة الرسومات. على سبيل المثال، لنفترض أنّه هاتف Android عادي في الوضع العمودي، مع شريط الحالة في الأعلى، وشريط التنقل في أسفل الشاشة، ومحتوى التطبيق في كل مكان آخر. يتم تخزين محتوى كل طبقة
في ذاكرة تخزين مؤقت منفصلة. يمكنك معالجة التركيب باستخدام إحدى الطريقتين التاليتَين:
- عرض محتوى التطبيق في ذاكرة تخزين مؤقتة، ثم عرض شريط الحالة فوقه، ثم شريط التنقّل فوقه، وأخيراً تمرير ذاكرة التخزين المؤقت إلى جهاز العرض
- تمرير جميع المخزنَين المؤقتَين الثلاثة إلى جهاز العرض وإرشاده لقراءة البيانات
من مخزنَين مؤقتَين مختلفَين لأجزاء مختلفة من الشاشة
يمكن أن يكون النهج الأخير أكثر فعالية بشكل كبير.
تختلف إمكانات معالجات العرض بشكل كبير. قد يكون من الصعب تحديد عدد الصور التي تظهر على سطح الصورة،
وما إذا كان يمكن تدوير الطبقات أو مزجها، والقيود المفروضة على مواضعها
والتداخل بينها من خلال واجهة برمجة التطبيقات. لاستيعاب هذه الخيارات، تُجري "وحدة التحكّم في الحرارة"
العمليات الحسابية التالية:
- يقدّم SurfaceFlinger لـ HWC قائمة كاملة بالطبقات ويسأل، "كيف
تريد التعامل مع هذا؟"
- يستجيب HWC عن طريق وضع علامة على كل طبقة على أنّها تركيبة جهاز أو عميل.
- يهتم SurfaceFlinger بأي عملاء، ويمرّر وحدة تخزين مؤقت للإخراج
إلى HWC، ويترك HWC يتولى بقية المهام.
بما أنّ مورّدي الأجهزة يمكنهم تخصيص رمز اتخاذ القرار، من الممكن
تحقيق أفضل أداء من كل جهاز.
قد تكون المستويات المتراكبة أقل فعالية من تركيب GL عندما لا يتغيّر أي شيء على الشاشة. وينطبق ذلك بشكل خاص عندما يكون محتوى التراكب يحتوي على بكسل متعالِم ويتم دمج الطبقات المتداخلة. في هذه الحالات،
يمكن أن تطلب وحدة HWC إنشاء رسومات باستخدام GLES لبعض الطبقات أو جميعها مع الاحتفاظ
بالمخازن المؤقتة التي تم دمجها. إذا طلب SurfaceFlinger دمج
المجموعة نفسها من وحدات التخزين المؤقت، يمكن أن يعرض HWC ملف التخزين المؤقت
الاحتياطي الذي تم دمجه سابقًا. ويمكن أن يؤدي ذلك إلى تحسين عمر بطارية الجهاز في وضع السكون.
تتوافق أجهزة Android عادةً مع أربع مساحات عرض للتراكبات.
تؤدي محاولة دمج عدد طبقات أكبر من الطبقات التي تظهر على سطح الشاشة إلى استخدام النظام لدمج GLES
لبعض منها، ما يعني أنّ عدد الطبقات التي يستخدمها التطبيق يمكن أن يؤدي
إلى تأثير قابل للقياس في استهلاك الطاقة والأداء.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# Hardware Composer HAL\n\nThe Hardware Composer (HWC) HAL determines the most efficient\nway to composite buffers with the available hardware. As a HAL, its\nimplementation is device-specific and usually done by the display hardware OEM.\n\nThe value of this approach is easy to recognize when you consider *overlay\nplanes*, which composite multiple buffers in\nthe display hardware rather than the GPU. For example, consider a typical\nAndroid phone in portrait orientation, with the status bar on top, navigation\nbar at the bottom, and app content everywhere else. The contents for each layer\nare in separate buffers. You can handle composition using either of the\nfollowing methods:\n\n- Rendering the app content into a scratch buffer, then rendering the status bar over it, the navigation bar on top of that, and finally passing the scratch buffer to the display hardware.\n- Passing all three buffers to the display hardware and instructing it to read data from different buffers for different parts of the screen.\n\nThe latter approach can be significantly more efficient.\n\nDisplay processor capabilities vary significantly. The number of overlays,\nwhether layers can be rotated or blended, and restrictions on positioning and\noverlap can be difficult to express through an API. To accommodate these options, the HWC performs\nfollowing calculations:\n\n1. SurfaceFlinger provides HWC with a full list of layers and asks, \"How do you want to handle this?\"\n2. HWC responds by marking each layer as device or client composition.\n3. SurfaceFlinger takes care of any client, passing the output buffer to HWC, and lets HWC handle the rest.\n\nBecause hardware vendors can custom tailor decision-making code, it's possible\nto get the best performance out of every device.\n\nOverlay planes may be less efficient than GL composition when nothing on the\nscreen is changing. This is particularly true when overlay contents have\ntransparent pixels and overlapping layers are blended. In such cases,\nthe HWC can request GLES composition for some or all layers and retain\nthe composited buffer. If SurfaceFlinger asks to composite the same\nset of buffers, the HWC can show the previously composited scratch\nbuffer. This can improve the battery life of an idle device.\n\nAndroid devices typically support four overlay planes.\nAttempting to composite more layers than overlays causes the system to use GLES\ncomposition for some of them, meaning the number of layers used by an app can\nhave a measurable impact on power consumption and performance."]]
