يوفر إطار عمل Android مجموعة متنوعة من واجهات برمجة التطبيقات لعرض الرسومات ثنائية وثلاثية الأبعاد التي تتفاعل مع تطبيقات الشركة المصنعة لبرامج تشغيل الرسومات، لذلك من المهم أن يكون لديك فهم جيد لكيفية عمل واجهات برمجة التطبيقات هذه على مستوى أعلى. تقدم هذه الصفحة طبقة تجريد أجهزة الرسومات (HAL) التي تم بناء برامج التشغيل هذه عليها.
يقوم مطورو التطبيقات برسم الصور على الشاشة بثلاث طرق: باستخدام Canvas أو OpenGL ES أو Vulkan .
مكونات رسومات أندرويد
بغض النظر عن ما يستخدمه مطورو واجهة برمجة التطبيقات (API)، يتم عرض كل شيء على السطح . يمثل السطح جانب المنتج من قائمة انتظار المخزن المؤقت التي غالبًا ما يتم استهلاكها بواسطة SurfaceFlinger. كل نافذة يتم إنشاؤها على نظام Android الأساسي مدعومة بسطح. يتم تركيب كافة الأسطح المرئية المقدمة على الشاشة بواسطة 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. وهذا يجعل عملية التركيب أقل طاقة من قيام وحدة معالجة الرسومات بإجراء جميع العمليات الحسابية.
يقوم Hardware Composer HAL بتنفيذ النصف الآخر من العمل وهو النقطة المركزية لجميع عمليات عرض رسومات Android. يجب أن يدعم "مكونات الأجهزة" الأحداث، أحدها هو VSYNC (وآخر هو hotplug لدعم التوصيل والتشغيل HDMI).
جرالوك
يلزم تخصيص ذاكرة الرسومات (Gralloc) لتخصيص الذاكرة المطلوبة من قبل منتجي الصور. لمزيد من التفاصيل، راجع جرالوك هال .
تدفق البيانات
راجع الرسم البياني التالي للحصول على وصف لمسار رسومات Android:
الشكل 2. تدفق البيانات الرسومية عبر Android
الكائنات الموجودة على اليسار هي أجهزة عرض تنتج مخازن مؤقتة للرسومات، مثل الشاشة الرئيسية وشريط الحالة وواجهة مستخدم النظام. SurfaceFlinger هو الملحن وملحن الأجهزة هو الملحن.
BufferQueue
توفر BufferQueues الرابط بين مكونات رسومات Android. هذان زوجان من قوائم الانتظار التي تتوسط الدورة الثابتة للمخازن المؤقتة من المنتج إلى المستهلك. بمجرد قيام المنتجين بتسليم المخازن المؤقتة الخاصة بهم، يصبح 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.
يقوم مؤلف الأجهزة HAL بإجراء النصف الآخر من العمل. يعمل HAL هذا كنقطة مركزية لجميع عمليات عرض رسومات Android.