از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
آهنگساز سخت افزار HAL
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
Hardware Composer (HWC) HAL کارآمدترین راه را برای بافرهای ترکیبی با سخت افزار موجود تعیین می کند. به عنوان یک HAL، پیاده سازی آن برای دستگاه خاص است و معمولاً توسط سخت افزار OEM نمایشگر انجام می شود.
وقتی صفحات همپوشانی را در نظر می گیریم که بافرهای متعددی را در سخت افزار نمایشگر به جای GPU ترکیب می کنند، ارزش این رویکرد آسان است. به عنوان مثال، یک تلفن اندرویدی معمولی را در جهت عمودی در نظر بگیرید، با نوار وضعیت در بالا، نوار ناوبری در پایین، و محتوای برنامه در هر جای دیگر. محتویات هر لایه در بافرهای جداگانه قرار دارد. می توانید ترکیب را با استفاده از یکی از روش های زیر مدیریت کنید:
- رندر کردن محتوای برنامه در یک بافر اسکرچ، سپس رندر کردن نوار وضعیت روی آن، نوار ناوبری در بالای آن، و در نهایت ارسال بافر خراش به سخت افزار نمایشگر.
- انتقال هر سه بافر به سخت افزار نمایشگر و دستور خواندن داده ها از بافرهای مختلف برای قسمت های مختلف صفحه.
رویکرد دوم می تواند به طور قابل توجهی کارآمدتر باشد.
قابلیت های پردازنده نمایشگر به طور قابل توجهی متفاوت است. بیان تعداد لایه‌ها، اعم از اینکه لایه‌ها را می‌توان چرخاند یا ترکیب کرد، و محدودیت‌ها در موقعیت‌یابی و همپوشانی ممکن است از طریق API دشوار باشد. برای تطبیق این گزینه ها، HWC محاسبات زیر را انجام می دهد:
- SurfaceFlinger لیست کاملی از لایه‌ها را در اختیار HWC قرار می‌دهد و از او می‌پرسد: "چگونه می‌خواهید این کار را انجام دهید؟"
- HWC با علامت گذاری هر لایه به عنوان ترکیب دستگاه یا مشتری پاسخ می دهد.
- SurfaceFlinger از هر کلاینت مراقبت می‌کند، بافر خروجی را به HWC می‌دهد و به HWC اجازه می‌دهد بقیه را مدیریت کند.
از آنجایی که فروشندگان سخت افزار می توانند کدهای تصمیم گیری را سفارشی کنند، می توان بهترین عملکرد را از هر دستگاهی دریافت کرد.
هنگامی که هیچ چیز روی صفحه تغییر نمی کند، صفحات روکش ممکن است نسبت به ترکیب GL کارایی کمتری داشته باشند. این امر به ویژه زمانی صادق است که محتویات همپوشانی دارای پیکسل‌های شفاف باشند و لایه‌های همپوشانی با هم ترکیب شوند. در چنین مواردی، HWC می تواند ترکیب GLES را برای برخی یا همه لایه ها درخواست کند و بافر ترکیبی را حفظ کند. اگر SurfaceFlinger بخواهد مجموعه ای از بافرها را ترکیب کند، HWC می تواند بافر خراش ترکیب شده قبلی را نشان دهد. این می تواند عمر باتری یک دستگاه بیکار را بهبود بخشد.
دستگاه های اندرویدی معمولاً از چهار صفحه همپوشانی پشتیبانی می کنند. تلاش برای ترکیب لایه‌های بیشتری نسبت به پوشش‌ها باعث می‌شود سیستم از ترکیب GLES برای برخی از آنها استفاده کند، به این معنی که تعداد لایه‌های استفاده شده توسط یک برنامه می‌تواند تأثیر قابل‌اندازه‌گیری بر مصرف انرژی و عملکرد داشته باشد.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و 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,["# 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."]]
