گرافیک

فریم ورک اندروید انواع API های رندر گرافیکی را برای دو بعدی و سه بعدی ارائه می دهد که با پیاده سازی سازنده درایورهای گرافیکی تعامل دارند، بنابراین مهم است که درک خوبی از نحوه عملکرد آن API ها در سطح بالاتر داشته باشید. این صفحه لایه انتزاعی سخت افزاری گرافیکی (HAL) را معرفی می کند که این درایورها بر روی آن ساخته شده اند.

توسعه دهندگان برنامه تصاویر را به سه روش روی صفحه می کشند: با Canvas ، OpenGL ES ، یا Vulkan .

اجزای گرافیکی اندروید

مهم نیست که توسعه‌دهندگان API از چه رندری استفاده می‌کنند، همه چیز بر روی یک سطح رندر می‌شود. سطح نمایانگر سمت تولید کننده یک صف بافر است که اغلب توسط SurfaceFlinger مصرف می شود. هر پنجره ای که در پلتفرم اندروید ایجاد می شود توسط یک سطح پشتیبانی می شود. تمام سطوح قابل مشاهده ارائه شده توسط SurfaceFlinger بر روی صفحه نمایش ترکیب می شوند.

نمودار زیر نشان می دهد که چگونه اجزای کلیدی با هم کار می کنند:

شکل 1. سطوح چگونه رندر می شوند

اجزای اصلی در زیر توضیح داده شده است:

تولید کنندگان جریان تصویر

تولید کننده جریان تصویر می تواند هر چیزی باشد که بافرهای گرافیکی را برای مصرف تولید می کند. به عنوان مثال می توان به رمزگشاهای ویدئویی OpenGL ES، Canvas 2D و مدیاسرور اشاره کرد.

مصرف کنندگان جریان تصویر

رایج ترین مصرف کننده جریان تصویر SurfaceFlinger است، سرویس سیستمی که سطوح قابل مشاهده فعلی را مصرف می کند و با استفاده از اطلاعات ارائه شده توسط Window Manager آنها را روی نمایشگر ترکیب می کند. SurfaceFlinger تنها سرویسی است که می تواند محتوای نمایشگر را تغییر دهد. SurfaceFlinger از OpenGL و Hardware Composer برای ترکیب گروهی از سطوح استفاده می کند.

سایر برنامه‌های OpenGL ES نیز می‌توانند جریان تصویر را مصرف کنند، مانند برنامه دوربین که جریان تصویر پیش‌نمایش دوربین را مصرف می‌کند. برنامه های غیر GL نیز می توانند مصرف کننده باشند، برای مثال کلاس ImageReader.

آهنگساز سخت افزار

انتزاع سخت افزاری برای زیرسیستم نمایشگر. SurfaceFlinger می تواند کارهای ترکیبی خاصی را به Hardware Composer واگذار کند تا کار را از OpenGL و GPU بارگذاری کند. SurfaceFlinger فقط به عنوان یکی دیگر از سرویس گیرندگان OpenGL ES عمل می کند. بنابراین وقتی SurfaceFlinger به طور فعال یک یا دو بافر را به یک سوم ترکیب می کند، برای مثال از OpenGL ES استفاده می کند. این باعث می شود که ترکیب قدرت کمتری نسبت به GPU داشته باشد که تمام محاسبات را انجام دهد.

Hardware Composer HAL نیمه دیگر کار را انجام می دهد و نقطه مرکزی تمام رندرهای گرافیکی اندروید است. Hardware Composer باید از رویدادهایی پشتیبانی کند که یکی از آنها VSYNC است (یکی دیگر هات پلاگ برای پشتیبانی از plug-and-playHDMI است).

گرالوک

تخصیص دهنده حافظه گرافیکی (Gralloc) برای تخصیص حافظه درخواستی تولیدکنندگان تصویر مورد نیاز است. برای جزئیات، Gralloc HAL را ببینید.

گردش داده ها

نمودار زیر را برای تصویری از خط لوله گرافیکی اندروید ببینید:

شکل 2. جریان داده های گرافیکی از طریق اندروید

اشیاء سمت چپ رندرهایی هستند که بافرهای گرافیکی را تولید می کنند، مانند صفحه اصلی، نوار وضعیت و رابط کاربری سیستم. SurfaceFlinger آهنگساز و Hardware Composer آهنگساز است.

BufferQueue

BufferQueues چسب بین اجزای گرافیکی اندروید را فراهم می کند. اینها یک جفت صف هستند که چرخه ثابت بافرها را از تولید کننده به مصرف کننده واسطه می کنند. هنگامی که تولیدکنندگان بافرهای خود را تحویل می دهند، SurfaceFlinger مسئول ترکیب همه چیز بر روی صفحه نمایش است.

نمودار زیر را برای فرآیند ارتباط BufferQueue ببینید.

شکل 3. فرآیند ارتباط BufferQueue

BufferQueue حاوی منطقی است که تولیدکنندگان جریان تصویر و مصرف کنندگان جریان تصویر را به هم پیوند می دهد. برخی از نمونه‌های تولیدکنندگان تصویر، پیش‌نمایش‌های دوربین هستند که توسط بازی‌های دوربین HAL یا OpenGL ES تولید می‌شوند. برخی از نمونه‌های مصرف‌کنندگان تصویر عبارتند از SurfaceFlinger یا برنامه دیگری که یک جریان OpenGL ES را نمایش می‌دهد، مانند برنامه دوربین که منظره یاب دوربین را نمایش می‌دهد.

BufferQueue یک ساختار داده ای است که یک مخزن بافر را با یک صف ترکیب می کند و از Binder IPC برای عبور بافرها بین فرآیندها استفاده می کند. رابط تولید کننده، یا چیزی که به شخصی که می خواهد بافرهای گرافیکی تولید کند، ارسال می کنید، IGraphicBufferProducer (بخشی از SurfaceTexture ) است. BufferQueue اغلب برای رندر کردن به یک Surface و مصرف با یک مصرف کننده GL و سایر وظایف استفاده می شود.

BufferQueue می تواند در سه حالت مختلف کار کند:

حالت مشابه همزمان - BufferQueue به طور پیش‌فرض در حالتی شبیه به همگام عمل می‌کند، که در آن هر بافری که از سازنده وارد می‌شود به سمت مصرف‌کننده می‌رود. هیچ بافری در این حالت حذف نمی شود. و اگر تولیدکننده خیلی سریع باشد و بافرها را سریعتر از تخلیه آنها ایجاد کند، آن را مسدود کرده و منتظر بافرهای رایگان می ماند.

حالت غیر مسدود کننده - BufferQueue همچنین می تواند در حالت غیر مسدود کننده عمل کند که در آن به جای اینکه منتظر بافر در آن موارد باشد، خطا ایجاد می کند. در این حالت نیز هیچ بافری حذف نمی شود. این برای جلوگیری از بن‌بست‌های احتمالی در نرم‌افزار کاربردی که ممکن است وابستگی‌های پیچیده چارچوب گرافیکی را درک نکنند، مفید است.

حالت صرف‌نظر کردن - در نهایت، BufferQueue ممکن است به گونه‌ای پیکربندی شود که بافرهای قدیمی را به جای ایجاد خطا یا صبر کردن، کنار بگذارد. به عنوان مثال، در صورت انجام رندر GL به نمای بافت و ترسیم در سریع ترین زمان ممکن، بافرها باید حذف شوند.

برای انجام بیشتر این کار، SurfaceFlinger فقط به عنوان یکی دیگر از سرویس گیرندگان OpenGL ES عمل می کند. بنابراین وقتی SurfaceFlinger به طور فعال یک یا دو بافر را به یک سوم ترکیب می کند، برای مثال از OpenGL ES استفاده می کند.

Hardware Composer HAL نیمه دیگر کار را انجام می دهد. این HAL به عنوان نقطه مرکزی برای تمام رندرهای گرافیکی اندروید عمل می کند.