فریم ورک اندروید انواع API های رندر گرافیکی را برای دو بعدی و سه بعدی ارائه می دهد که با پیاده سازی سازنده درایورهای گرافیکی تعامل دارند، بنابراین مهم است که درک خوبی از نحوه عملکرد آن API ها در سطح بالاتر داشته باشید. این صفحه لایه انتزاعی سخت افزاری گرافیکی (HAL) را معرفی می کند که آن درایورها بر روی آن ساخته شده اند. قبل از ادامه این بخش، با اصطلاحات زیر آشنا شوید:
Canvas
(عنصر API)Surface
انجام می دهد. Canvas
دارای روش هایی برای ترسیم رایانه ای استاندارد از بیت مپ ها، خطوط، دایره ها، مستطیل ها، متن و غیره است و به یک بیت مپ یا سطح محدود می شود. بوم ساده ترین و ساده ترین راه برای کشیدن اشیاء دو بعدی روی صفحه است. کلاس پایه Canvas
است.android.graphics.drawable
کامپایل میشوند. برای اطلاعات بیشتر در مورد قرعه کشی ها و سایر منابع، به منابع مراجعه کنید.android.opengl
و javax.microedition.khronos.opengles
عملکرد OpenGL ES را نشان میدهند.Surface
(عنصر API)Surface
ارائه می دهد. از کلاس SurfaceView
به جای کلاس Surface
به طور مستقیم استفاده کنید.SurfaceView
(عنصر API)View
است که یک شی Surface
را برای طراحی میپیچد و روشهایی را برای تعیین اندازه و قالب آن به صورت پویا در معرض نمایش میگذارد. نمای سطحی راهی برای ترسیم مستقل از رشته رابط کاربری برای عملیاتهایی که منابع فشرده دارند، مانند بازیها یا پیشنمایش دوربین، ارائه میکند، اما در نتیجه از حافظه اضافی استفاده میکند. نمای سطحی از گرافیک بوم و OpenGL ES پشتیبانی می کند. کلاس پایه برای یک شی SurfaceView
SurfaceView
است.R.style
فهرست شده و با Theme_
مقدمه شده است.View
(عنصر API)View
کلاس پایه برای اکثر اجزای طرح بندی یک فعالیت یا صفحه محاوره ای، مانند جعبه های متن و پنجره ها است. یک شی View
از شی والد خود (به ViewGroup
مراجعه کنید) فراخوانی دریافت می کند تا خود را ترسیم کند، و شی والد خود را در مورد اندازه و مکان ترجیحی خود، که ممکن است توسط والد محترم شمرده نشود، مطلع می کند. برای اطلاعات بیشتر، View
ببینید.ViewGroup
(عنصر API)widget
قرار دارند، اما کلاس ViewGroup
را گسترش دهید.android.widget
قرار دارند.Window
(عنصر API)Window
است که عناصر یک پنجره عمومی، مانند ظاهر و احساس، متن نوار عنوان، و مکان و محتوای منوها را مشخص میکند. دیالوگها و فعالیتها از پیادهسازی کلاس Window
برای رندر کردن یک شی Window
استفاده میکنند. شما نیازی به پیاده سازی کلاس Window
یا استفاده از ویندوز در برنامه خود ندارید.توسعه دهندگان برنامه تصاویر را به سه روش روی صفحه می کشند: با Canvas ، OpenGL ES ، یا Vulkan .
اجزای گرافیکی اندروید
مهم نیست که توسعه دهندگان API از چه رندرینگی استفاده می کنند، همه چیز بر روی یک سطح رندر می شود. سطح نمایانگر سمت تولید کننده یک صف بافر است که اغلب توسط SurfaceFlinger مصرف می شود. هر پنجره ای که در پلتفرم اندروید ایجاد می شود توسط یک سطح پشتیبانی می شود. تمام سطوح قابل مشاهده ارائه شده توسط SurfaceFlinger بر روی صفحه نمایش ترکیب می شوند.
نمودار زیر نشان می دهد که چگونه اجزای کلیدی با هم کار می کنند:
اجزای اصلی در زیر توضیح داده شده است:
تولیدکنندگان جریان تصویر
تولید کننده جریان تصویر می تواند هر چیزی باشد که بافرهای گرافیکی را برای مصرف تولید می کند. به عنوان مثال می توان به رمزگشاهای ویدئویی 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 را ببینید.
گردش داده ها
نمودار زیر را برای تصویری از خط لوله گرافیکی اندروید ببینید:
اشیاء سمت چپ رندرهایی هستند که بافرهای گرافیکی را تولید می کنند، مانند صفحه اصلی، نوار وضعیت و رابط کاربری سیستم. SurfaceFlinger آهنگساز و Hardware Composer آهنگساز است.
BufferQueue
BufferQueues چسب بین اجزای گرافیکی اندروید را فراهم می کند. اینها یک جفت صف هستند که چرخه ثابت بافرها را از تولید کننده به مصرف کننده واسطه می کنند. هنگامی که تولیدکنندگان بافرهای خود را تحویل می دهند، SurfaceFlinger مسئول ترکیب همه چیز بر روی صفحه نمایش است.
نمودار زیر را برای فرآیند ارتباط 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 به عنوان نقطه مرکزی برای تمام رندرهای گرافیکی اندروید عمل می کند.