Overdraw في التطبيقات المحمولة: ما هو، الأسباب والتحسين

ما هو Overdraw في الرسوميات المحمولة؟

Overdraw هو حالة يتم فيها إعادة رسم نفس البكسل على الشاشة عدة مرات داخل إطار عرض واحد. في السيناريو المثالي، يجب كتابة كل بكسل مرة واحدة بالضبط، ولكن في الواجهات الحقيقية بسبب المشاهدات المتداخلة والصور الخلفية والطبقات الشفافة، تقوم GPU بكتابات متكررة.

كل إعادة رسم إضافية تزيد من وقت عرض الإطار. عند معدل 60 إطارًا في الثانية القياسي، يتوفر لكل إطار حوالي 16.6 مللي ثانية. إذا تسبب overdraw في تجاوز هذا الحد، ينخفض معدل الإطارات إلى 30 إطارًا في الثانية أو أقل، مما يضعف سلاسة الواجهة بشكل ملحوظ.

وفقًا لأنماط أداء Android من Google، فإن التطبيق الذي يحتوي على عامل overdraw 3x ينفق ثلاثة أضعاف الوقت على تظليل الأجزاء مقارنة بالتطبيق الذي يحتوي على overdraw 1x. على أجهزة GPU منخفضة الأداء، يؤدي هذا إلى تأخيرات ملحوظة أثناء التمرير والرسوم المتحركة.

بالنسبة لمطوري التطبيقات المحمولة، فإن فهم overdraw أمر بالغ الأهمية: هذا العامل هو الأكثر تسببًا في التمرير المتقطع وانخفاض معدلات الإطارات في الشاشات البسيطة ظاهريًا التي تحتوي على عدد كبير من العناصر المتداخلة.

كيف يؤثر Overdraw على أداء GPU

يتكون خط أنابيب GPU من عدة مراحل: تظليل الرؤوس، التنقيط وتظليل الأجزاء. تظليل الأجزاء هو الجزء الأكثر تكلفة، حيث يتم تنفيذه لكل بكسل من كل بدائية. مع overdraw 2x، يعالج تظليل الأجزاء ضعف عدد البكسلات، مما يزيد وقت الإطار مباشرة.

تحتوي وحدات GPU المحمولة الحديثة مثل Qualcomm Adreno و Apple GPU على آليات اختبار Early-Z وإزالة الأسطح المخفية التي تعوض جزئيًا عن overdraw. ومع ذلك، تعمل هذه التحسينات فقط في ظل ظروف معينة، ولا ينبغي الاعتماد فقط على تسريع الأجهزة.

على سبيل المثال، عند عرض عناصر شبه شفافة، فإن Early-Z للأجهزة غير فعال، ويتم معالجة كل بكسل بالكامل — يمكن أن يصل overdraw في مثل هذه السيناريوهات إلى 5x أو أكثر.

الأسباب الرئيسية لإعادة الرسم المفرطة

الخلفيات متعددة الطبقات هي أحد الأسباب الرئيسية لـ overdraw في التطبيقات المحمولة. عندما تقوم Activity أو ViewController بتعيين لون خلفية، يمكن لكل View متداخلة إضافة خلفيتها الخاصة، ويتم إعادة رسم البكسل في كل مستوى من التسلسل الهرمي.

أظهرت دراسة هندسة Uber أن إزالة الخلفيات الزائدة في تطبيق Android الخاص بهم قللت overdraw بنسبة 32% ووقت عرض الشاشة بنسبة 25%. يوجد وضع مماثل في iOS: تعيين opaque = true للمشاهدات غير الشفافة يلغي مزج ألفا ويمنع كتابات البكسلات المتعددة.

• التراكبات الشفافة — العناصر ذات قناة ألفا فوق العناصر الأخرى تسبب دائمًا overdraw.
• ClipChildren=false — تعطيل قص العناصر الفرعية يؤدي إلى عرض المناطق غير المرئية.
• استخدام ShapeDrawable بدلاً من الألوان البسيطة يزيد الحمل على تظليل الأجزاء.
• التداخل المفرط — كل مستوى في تسلسل View الهرمي يضيف طبقة إعادة رسم محتملة.

على منصة iOS، يحدث overdraw غالبًا بسبب استخدام UIStackView الشفافة و CALayer مع shouldRasterize و UIBlurEffect المتداخلة. توصي Apple بالتحقق من overdraw من خلال أداة Core Animation في XCode — فهي تظهر مناطق إعادة الرسم كتراكب أحمر.

كيفية تشخيص Overdraw: الأدوات والطرق

Debug GPU Overdraw هي أداة مدمجة في Android تلون الشاشة بألوان مختلفة حسب عامل overdraw. الأرجواني يعني 1x، الأزرق — 2x، الأخضر — 3x، الوردي — 4x، الأحمر — 5x أو أكثر. يجب أن تكون الشاشة المثالية أرجوانية في الغالب.

في iOS، يتم إجراء تشخيص مماثل بواسطة أداة Core Animation في XCode Instruments. تقوم بتصور مناطق إعادة الرسم وتظهر العدد الدقيق لكتابات البكسلات في وضع Color Blended Layers. الطبقات الخضراء غير شفافة (مثالية)، والطبقات الحمراء تحتوي على شفافية وتسبب overdraw.

• Profile GPU Rendering في Android يظهر رسمًا بيانيًا لوقت العرض. تشير الأعمدة الخضراء الطويلة إلى مشاكل overdraw.
• Renderscript هي أداة أكثر تقدمًا لتحليل خط أنابيب العرض على أجهزة Android 10+.
• Metal Debugger في XCode يسمح بتحليل كل تمريرة عرض ورؤية العدد الدقيق لاستدعاءات تظليل الأجزاء.

بعد التشخيص، من المهم قياس FPS قبل وبعد التحسين. فرق 10–15 إطارًا في الثانية عند إصلاح overdraw هو نتيجة طبيعية لشاشة معقدة تحتوي على قوائم ورسوم متحركة.

تقنيات تحسين Overdraw في التطبيقات المحمولة

إزالة الخلفيات الزائدة هي الطريقة الأبسط والأكثر فعالية. في Android، يكفي تعيين android:windowBackground فقط للنشاط أو السمة، وليس لكل View. في iOS، يؤدي opaque = true لجميع UIView غير الشفافة إلى تقليل overdraw إلى الصفر تقريبًا لتلك العناصر.

وفقًا لمؤتمر Google I/O 2019، سمح تحسين overdraw في Google Maps بتقليل وقت عرض الإطار بنسبة 40% من خلال دمج الطبقات واستخدام ClipRect للحد من منطقة الرسم. لمطوري Android، توصي Google بالممارسات التالية:

• ClipRect — يحد من منطقة رسم Canvas. إذا لم يكن هناك شيء خارج المنطقة المرئية، فإن GPU لا تهدر الموارد.
• ViewStub — للعناصر نادرة الاستخدام أو غير المرئية عند التحميل الأولي. يتم عرض المكون فقط عند استدعاء inflate.
• merge و include — يقللان من عمق التسلسل الهرمي لـ View، مما يقلل عدد تمريرات العرض.
• المخازن المؤقتة المسطحة — استبدال التخطيطات المتداخلة بـ ConstraintLayout أو RelativeLayout واحد.

في iOS، يتم تحقيق التحسين من خلال تكوين CALayer: تعيين masksToBounds = true يقص المحتوى خارج حدود الطبقة، و shouldRasterize يتيح التخزين المؤقت للصورة النقطية للطبقات الثابتة.

أمثلة كود: إزالة Overdraw في Android و iOS

دعونا نلقي نظرة على أمثلة عملية في Kotlin و Swift توضح سيناريوهات نموذجية لإزالة overdraw. المثال الأول يظهر التحسين من خلال ClipRect في Android:

class OptimizedView@JvmOverloads constructor(
    context: Context, attrs: AttributeSet? = null
) : View(context, attrs) {

    override fun onDraw(canvas: Canvas) {
        canvas.clipRect(
            paddingLeft.toFloat(), paddingTop.toFloat(),
            width - paddingRight.toFloat(), height - paddingBottom.toFloat()
        )
        // Draw content only within clipped area
        super.onDraw(canvas)
    }
}

المثال الثاني في Swift يظهر تعطيل الشفافية لطبقة إذا كان العنصر لا يجب أن يكون شبه شفاف:

class OpaqueLabel: UILabel {
    override var isOpaque: Bool {
        get { true }
        set { }
    }

    override func draw(_ rect: CGRect) {
        backgroundColor?.setFill()
        UIRectFill(rect)
        super.draw(rect)
    }
}

المثال الثالث يوضح استخدام ViewStub للتحميل المؤجل للخريطة في Android. ViewStub لا يتم عرضه حتى يصبح مرئيًا، مما يلغي overdraw في مرحلة تهيئة الشاشة:

<!-- layout/activity_main.xml -->
<ViewStub
    android:id="@+id/map_stub"
    android:layout_width="match_parent"
    android:layout_height="200dp"
    android:inflatedId="@+id/map_container"
    android:layout="@layout/map_fragment" />

// Inflate on demand
ViewStub stub = findViewById(R.id.map_stub)
stub?.inflate()