![رمز Android Graphics HAL](https://source.android.com/static/docs/core/graphics/images/ape-fwk-hal-graphics.png?authuser=6&hl=ar)
يوفر إطار عمل Android مجموعة متنوعة من واجهات برمجة التطبيقات لعرض الرسومات ثنائية وثلاثية الأبعاد التي تتفاعل مع تطبيقات الشركة المصنعة لبرامج تشغيل الرسومات، لذلك من المهم أن يكون لديك فهم جيد لكيفية عمل واجهات برمجة التطبيقات هذه على مستوى أعلى. تقدم هذه الصفحة طبقة تجريد أجهزة الرسومات (HAL) التي تم بناء برامج التشغيل عليها. قبل الاستمرار في هذا القسم، تعرف على المصطلحات التالية:
Canvas
(عنصر واجهة برمجة التطبيقات)Surface
. يحتوي Canvas
على أساليب لرسم الكمبيوتر القياسي للصور النقطية والخطوط والدوائر والمستطيلات والنص وما إلى ذلك، وهو مرتبط بصورة نقطية أو سطحية. اللوحة القماشية هي أبسط وأسهل طريقة لرسم كائنات ثنائية الأبعاد على الشاشة. الفئة الأساسية هي Canvas
.android.graphics.drawable
. لمزيد من المعلومات حول الرسوميات والموارد الأخرى، راجع الموارد .android.opengl
و javax.microedition.khronos.opengles
وظيفة OpenGL ES.Surface
(عنصر واجهة برمجة التطبيقات)Surface
. استخدم فئة SurfaceView
بدلاً من فئة Surface
مباشرة.SurfaceView
(عنصر واجهة برمجة التطبيقات)View
يقوم بتغليف كائن Surface
للرسم، ويكشف عن طرق لتحديد حجمه وتنسيقه ديناميكيًا. يوفر العرض السطحي طريقة للرسم بشكل مستقل عن سلسلة واجهة المستخدم للعمليات كثيفة الاستخدام للموارد، مثل الألعاب أو معاينات الكاميرا، ولكنه يستخدم ذاكرة إضافية نتيجة لذلك. يدعم العرض السطحي كلاً من رسومات اللوحة القماشية ورسومات OpenGL ES. الفئة الأساسية لكائن SurfaceView
هي SurfaceView
.R.style
ومقدمة بـ Theme_
.View
(عنصر واجهة برمجة التطبيقات)View
هي الفئة الأساسية لمعظم مكونات التخطيط الخاصة بالنشاط أو شاشة الحوار، مثل مربعات النص والنوافذ. يتلقى كائن View
استدعاءات من الكائن الأصلي (راجع ViewGroup
) لرسم نفسه، ويُعلم الكائن الأصلي الخاص به بحجمه المفضل وموقعه، والذي قد لا يحترمه الكائن الأصلي. لمزيد من المعلومات، راجع View
.ViewGroup
(عنصر واجهة برمجة التطبيقات)widget
، ولكنها تعمل على توسيع فئة ViewGroup
.android.widget
.Window
(عنصر واجهة برمجة التطبيقات)Window
Abstract التي تحدد عناصر النافذة العامة، مثل الشكل والمظهر ونص شريط العنوان وموقع القوائم ومحتواها. تستخدم مربعات الحوار والأنشطة تطبيقًا لفئة Window
لعرض كائن Window
. لا تحتاج إلى تنفيذ فئة Window
أو استخدام windows في تطبيقك.يرسم مطورو التطبيقات الصور على الشاشة بثلاث طرق: باستخدام Canvas أو OpenGL ES أو Vulkan .
مكونات رسومات أندرويد
بغض النظر عن ما يستخدمه مطورو واجهة برمجة التطبيقات (API)، يتم عرض كل شيء على السطح. يمثل السطح جانب المنتج من قائمة انتظار المخزن المؤقت التي غالبًا ما يتم استهلاكها بواسطة SurfaceFlinger. كل نافذة يتم إنشاؤها على نظام Android الأساسي مدعومة بسطح. يتم تركيب كافة الأسطح المرئية المقدمة على الشاشة بواسطة SurfaceFlinger.
يوضح الرسم البياني التالي كيفية عمل المكونات الرئيسية معًا:
![مكونات تقديم الصورة](https://source.android.com/static/docs/core/graphics/images/ape-fwk-graphics.png?authuser=6&hl=ar)
الشكل 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. وهذا يجعل عملية التركيب أقل طاقة من قيام وحدة معالجة الرسومات بإجراء جميع العمليات الحسابية.
يقوم Hardware Composer HAL بتنفيذ النصف الآخر من العمل وهو النقطة المركزية لجميع عمليات عرض رسومات Android. يجب أن يدعم "مكونات الأجهزة" الأحداث، أحدها هو VSYNC (وآخر هو hotplug لدعم التوصيل والتشغيل HDMI).
جرالوك
يلزم تخصيص ذاكرة الرسومات (Gralloc) لتخصيص الذاكرة المطلوبة من قبل منتجي الصور. لمزيد من التفاصيل، راجع جرالوك هال .
تدفق البيانات
راجع الرسم البياني التالي للحصول على وصف لمسار رسومات Android:
![تدفق البيانات الرسومية](https://source.android.com/static/docs/core/graphics/images/graphics-pipeline.png?authuser=6&hl=ar)
الشكل 2. تدفق البيانات الرسومية عبر Android
الكائنات الموجودة على اليسار هي أجهزة عرض تنتج مخازن مؤقتة للرسومات، مثل الشاشة الرئيسية وشريط الحالة وواجهة مستخدم النظام. SurfaceFlinger هو الملحن وملحن الأجهزة هو الملحن.
BufferQueue
توفر BufferQueues الرابط بين مكونات رسومات Android. هذان زوجان من قوائم الانتظار التي تتوسط الدورة الثابتة للمخازن المؤقتة من المنتج إلى المستهلك. بمجرد قيام المنتجين بتسليم المخازن المؤقتة الخاصة بهم، يصبح SurfaceFlinger مسؤولاً عن تركيب كل شيء على الشاشة.
راجع الرسم البياني التالي لعملية الاتصال BufferQueue.
![عملية الاتصال BufferQueue](https://source.android.com/static/docs/core/graphics/images/bufferqueue.png?authuser=6&hl=ar)
الشكل 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.
يقوم مؤلف الأجهزة HAL بإجراء النصف الآخر من العمل. يعمل HAL هذا كنقطة مركزية لجميع عمليات عرض رسومات Android.