عندما يكون لديك عرض مصمَّم بشكل جيد يستجيب للإيماءات وينتقل بين الحالات، احرص على أن يعمل العرض بسرعة. لتجنُّب واجهة مستخدم بطيئة أو متقطّعة أثناء التشغيل، تأكَّد من تشغيل الرسوم المتحركة باستمرار بمعدّل 60 إطارًا في الثانية.
تسريع عملية العرض
لتسريع العرض، يمكنك إزالة الرموز غير الضرورية من الروتينات التي يتم استدعاؤها بشكل متكرر. ابدأ
بالإجراء
onDraw() الذي يمنحك أكبر عائد. على وجه الخصوص، يجب إلغاء عمليات التخصيص في onDraw()،
لأنّ عمليات التخصيص قد تؤدي إلى جمع البيانات غير الضرورية ما يتسبب في حدوث تقطّع. تخصيص الكائنات
أثناء عملية التهيئة أو بين الصور المتحركة لا تُجري عملية تخصيص أثناء تشغيل صورة متحركة.
بالإضافة إلى جعل onDraw() أكثر فعالية، احرص على عدم استدعائه إلا عند الضرورة. معظم المكالمات إلى onDraw() هي نتيجة مكالمة إلى invalidate()، لذا عليك إلغاء المكالمات غير الضرورية إلى invalidate().
هناك عملية أخرى مكلفة جدًا وهي اجتياز التصاميم. عندما يستدعي العرض requestLayout()، يتنقّل نظام واجهة مستخدم Android في هيكلية طرق العرض بالكامل لمعرفة حجم كل عرض. إذا عثرت على قياسات متضاربة، قد تتنقّل في التسلسل الهرمي عدة مرات. ينشئ مصممو واجهة المستخدم أحيانًا تسلسلات هرمية معقّدة من الكائنات المتداخلة ViewGroup. تتسبّب التسلسلات الهرمية للعرض المتعمّق في حدوث مشاكل في الأداء، لذا احرص على أن تكون التسلسلات الهرمية للعرض سطحية قدر الإمكان.
إذا كانت لديك واجهة مستخدم معقّدة، ننصحك بكتابة ViewGroup مخصّصة لتنفيذ تصميمها.
وعلى عكس طرق العرض المضمّنة، يمكن لطريقة العرض المخصّصة أن تضع افتراضات خاصة بالتطبيق بشأن حجم وشكل العناصر التابعة لها، وبالتالي تتجنّب الانتقال إلى العناصر التابعة لحساب القياسات.
على سبيل المثال، إذا كان لديك ViewGroup مخصّص لا يضبط حجمه تلقائيًا ليتناسب مع جميع طرق العرض الفرعية، يمكنك تجنُّب عبء قياس جميع طرق العرض الفرعية. ولا يمكن إجراء هذا التحسين إذا كنت تستخدم التنسيقات المضمّنة التي تلبي مجموعة كبيرة من حالات الاستخدام.