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

در این مقاله hardware abstraction layer (HAL) به معنای لایۀ انتزاعی سخت افزاری گرافیکی معرفی خواهد شد که این درایور ها روی آن ساخته شده اند.

برنامه نویسان اپلیکیشن به سه روش تصاویر رو روی صفحه نمایش ترسیم می کنن : Canvas ،OpenGL ES  یا Vulkan

اکنون به بررسی گرافیک در اندروید می پردازیم

اجزای گرافیکی اندروید(بررسی گرافیک در اندروید)

در ادامۀ بررسی گرافیک در اندروید لازمه که بدونی اصلا مهم نیست که یک برنامه نویس از چه API رندرینگی استفاده می کنه؛ همه چیز بر روی یک Surface رندر می شه.

Surface نمایانگر سَمتِ تولید کنندۀ صف Buffer هست که اغلب توسط SurfaceFlinger مصرف می شه. هر پنجره (Window) ای که در پلتفرم اندروید ایجاد می شه توسط یک Surface پشتیبانی می شه.

همۀ Surface های قابل مشاهدۀ رندر شده توسط SurfaceFlinger بر روی صفحه نمایش ترکیب می شن.

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

اجزای اصلی در زیر شرح داده شده :

Image Stream Producers : تولید کنندۀ جریان تصویر می تونه هر چیزی باشه که بافر های گرافیکی رو برای مصرف تولید می کنه. به عنوان مثال می شه به OpenGL ES و Canvas 2D و mediaserver  و video decoders اشاره کرد.

Image stream consumers : رایج ترین مصرف کنندۀ جریان تصویر SurfaceFlinger هست، سرویس سیستمی که surface های قابل مشاهدۀ فعلی رو مصرف می کنه و با استفاده از اطلاعات ارائه شده از سوی WindowManager آنها رو روی نمایشگر ترکیب می کنه. SurfaceFlinger تنها سرویسیه که می تونه محتوای نمایشگر رو تغییر بده. SurfaceFlinger از OpenGL و Hardware Composer برای ترکیب گروهی از Surface ها استفاده می کنه.

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

Hardware Composer

در ادامۀ بحث گرافیک در اندروید می پردازیم به Hardware Composer. در بحث گرافیک در اندروید Hardware Composer یک انتزاع سخت افزاری (Hardware Abstraction) برای subservice اِ نمایشگر است.

SurfaceFlinger می تونه کارهای ترکیبی خاصی رو به Hardware Composer واگذار کنه تا کار از OpenGL و GPU تخلیه بشه.

این باعث می شه که ترکیب قدرت کمتری نسبت به GPU داشته باشه که تمام محاسبات رو انجام می ده.

Hardware Composer HAL نیمه دیگر کار رو انجام می ده و نقطه مرکزی تمام رندر های گرافیک در اندروید می باشه. Hardware Composer باید از رویداد هایی پشتیبانی کنه که یکی از آنها VSYNC هست.

جایگاه Gralloc در گرافیک در اندروید

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

Data Flow

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

شئ های سمت چپ بافرهایی هستند که بافرهایی گرافیکی رو تولید می کنن، مانند صفحۀ اصلی، نوار وضعیت و رابط کاربری سیستم. surfaceFlinger درواقع Compositor و HardwreComposer هم  Composer هست.

BufferQueue

آیا می خواهی به تمام معماری های برنامه نویسی اندروید و مسلط بشی و کلی چیزهایی از اندروید که هنوز بلد نیستی رو یاد بگیری؟ به این بخش از آکادمی نوری سر بزن!

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

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

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

برخی از نمونه های مصرف کنندگان تصویر عبارتند از SurfaceFlinger یا برنامۀ دیگر که یک جریان OpenGL ES را نمایش می ده، مانند برنامۀ دوربین که منظره یاب دوربین رو نمایش می ده.

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

BufferQueue اغلب برای رندر کردن به یک Surface و مصرف کردن با یک GL Consumer و سایر وظیفه ها استفاده می شه.

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

حالت Synchronous مانند، در بحث گرافیک در اندروید BufferQueue به صورت پیشفرض Synchronous مانند، کُنش می ورزد، که در آن هر بافر که از سازنده وارد می شه به سمت مصرف کننده می ره.

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

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

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

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

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

سپاسگزاریم که در بحث گرافیک در اندروید همراه ما بودید.