المفاهيم والتنفيذ في Jetpack Compose
بدءًا من الإصدار 3.0 من نظام التشغيل Android (المستوى 11 من واجهة برمجة التطبيقات)، يتيح مسار عرض الرسومات الثنائية الأبعاد في Android تسريع الأجهزة، ما يعني أنّ جميع عمليات الرسم التي يتم تنفيذها على لوحة عرض View تستخدم وحدة معالجة الرسومات.
بسبب زيادة الموارد المطلوبة لتفعيل ميزة "تسريع الأداء باستخدام الأجهزة"، سيستهلك تطبيقك المزيد من ذاكرة الوصول العشوائي.
يتم تفعيل تسريع الأجهزة تلقائيًا إذا كان مستوى واجهة برمجة التطبيقات المستهدَف
>=14، ولكن يمكن أيضًا تفعيله بشكل صريح. إذا كان تطبيقك يستخدم طرق العرض العادية وDrawable فقط، لن يؤدي تفعيلها على مستوى العالم إلى حدوث أي تأثيرات سلبية في الرسم. ومع ذلك، بما أنّ تسريع الأجهزة غير متاح لجميع عمليات الرسم الثنائي الأبعاد، قد يؤثر تفعيله في بعض طرق العرض المخصّصة أو طلبات الرسم. تظهر المشاكل عادةً على شكل عناصر غير مرئية أو استثناءات أو وحدات بكسل معروضة بشكل خاطئ. ولحلّ هذه المشكلة، يتيح لك نظام التشغيل Android إمكانية تفعيل ميزة تسريع الأجهزة أو إيقافها على مستويات متعددة. اطّلِع على التحكّم في ميزة "تسريع الأجهزة".
إذا كان تطبيقك ينفّذ عمليات رسم مخصّصة، اختبِر تطبيقك على أجهزة فعلية مع تفعيل ميزة تسريع الأجهزة للعثور على أي مشاكل. يوضّح قسم إتاحة عمليات الرسم المشاكل المعروفة المتعلقة بتسريع الأجهزة وكيفية حلّها.
يمكنك أيضًا الاطّلاع على OpenGL مع واجهات برمجة التطبيقات الخاصة بإطار العمل وRenderscript.
التحكّم في ميزة "تسريع الأجهزة"
يمكنك التحكّم في تسريع الأجهزة على المستويات التالية:
- التطبيق
- النشاط
- نافذة
- عرض
مستوى التطبيق
في ملف بيان Android، أضِف السمة التالية إلى العلامة <application> لتفعيل تسريع الأجهزة للتطبيق بأكمله:
<application android:hardwareAccelerated="true" ...>
مستوى النشاط
إذا كان تطبيقك لا يعمل بشكل صحيح عند تفعيل ميزة "تسريع الأجهزة" على مستوى العالم، يمكنك التحكّم فيها للأنشطة الفردية أيضًا. لتفعيل ميزة تسريع الأجهزة أو إيقافها على مستوى النشاط، يمكنك استخدام السمة android:hardwareAccelerated للعنصر <activity>. يُفعّل المثال التالي تسريع الأجهزة للتطبيق بأكمله، ولكنّه يوقفه لأحد الأنشطة:
<application android:hardwareAccelerated="true">
<activity ... />
<activity android:hardwareAccelerated="false" />
</application>
مستوى النافذة
إذا كنت بحاجة إلى تحكّم أكثر دقة، يمكنك تفعيل تسريع الأجهزة لنافذة معيّنة باستخدام الرمز التالي:
Kotlin
window.setFlags( WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED )
Java
getWindow().setFlags( WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
مستوى العرض
يمكنك إيقاف تسريع الأجهزة لعرض فردي في وقت التشغيل باستخدام الرمز التالي:
Kotlin
myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null)
Java
myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
تحديد ما إذا كان العرض يتم تسريعه باستخدام الأجهزة
من المفيد أحيانًا أن يعرف التطبيق ما إذا كان يتم تسريعه حاليًا باستخدام الأجهزة، خاصةً بالنسبة إلى عناصر مثل طرق العرض المخصّصة. ويكون ذلك مفيدًا بشكل خاص إذا كان تطبيقك ينفّذ الكثير من عمليات الرسم المخصّص ولم تكن جميع العمليات متوافقة بشكل صحيح مع مسار العرض الجديد.
هناك طريقتان مختلفتان للتحقّق ممّا إذا كان التطبيق يستخدم تسريع الأجهزة:
تعرض
View.isHardwareAcceleratedالقيمةtrueإذا كانViewمرتبطًا بنافذة تستخدم ميزة تسريع الأجهزة.تعرِض
Canvas.isHardwareAcceleratedالقيمةtrueإذا كانCanvasيستخدم ميزة تسريع الأجهزة.
إذا كان عليك إجراء هذا التحقّق في رمز الرسم، استخدِم
Canvas.isHardwareAccelerated بدلاً من
View.isHardwareAccelerated كلما أمكن ذلك. عند ربط طريقة عرض بنافذة تتضمّن تسريعًا للأجهزة، يمكن مواصلة رسمها باستخدام لوحة رسم لا تتضمّن تسريعًا للأجهزة. يحدث ذلك، على سبيل المثال، عند رسم عرض في صورة نقطية لأغراض التخزين المؤقت.
نماذج الرسم في Android
عند تفعيل ميزة "تسريع الأجهزة"، يستخدم إطار عمل Android نموذج رسم جديدًا يستفيد من قوائم العرض لعرض تطبيقك على الشاشة. لفهم قوائم العرض بشكل كامل وكيفية تأثيرها في تطبيقك، من المفيد معرفة الطريقة التي يرسم بها نظام التشغيل Android طرق العرض بدون تسريع الأجهزة أيضًا. توضّح الأقسام التالية نماذج الرسم المستندة إلى البرامج ونماذج الرسم التي تستخدم تسريع الأجهزة.
نموذج الرسم المستند إلى البرامج
في نموذج رسم البرامج، يتم رسم طرق العرض باتّباع الخطوتَين التاليتَين:
- إلغاء صلاحية التسلسل الهرمي
- رسم التسلسل الهرمي
عندما يحتاج تطبيق إلى تعديل جزء من واجهة المستخدم، يستدعي الدالة
invalidate() (أو إحدى صيغها) على أي عرض تم تغيير
محتواه. يتم نشر رسائل الإبطال على مستوى تسلسل عرض العناصر بالكامل لحساب مناطق الشاشة التي يجب إعادة رسمها (المنطقة غير الصالحة). بعد ذلك، يرسم نظام التشغيل Android أي عرض في التسلسل الهرمي يتقاطع مع المنطقة المعدّلة. مع ذلك، هناك عيبان في نموذج الرسم هذا:
أولاً، يتطلّب هذا النموذج تنفيذ الكثير من الرموز في كل عملية رسم. على سبيل المثال، إذا كان تطبيقك يستدعي
invalidateعلى زر وكان هذا الزر يقع فوق طريقة عرض أخرى، يعيد نظام Android رسم طريقة العرض حتى إذا لم تتغير.المشكلة الثانية هي أنّ نموذج الرسم يمكنه إخفاء الأخطاء في تطبيقك. بما أنّ نظام التشغيل Android يعيد رسم طرق العرض عندما تتقاطع مع المنطقة المتغيرة، قد تتم إعادة رسم طريقة العرض التي غيّرت محتواها حتى إذا لم يتم استدعاء
invalidateعليها. وعند حدوث ذلك، ستعتمد على إبطال صحة عرض آخر للحصول على السلوك المناسب. ويمكن أن يتغيّر هذا السلوك في كل مرة تعدّل فيها تطبيقك. لهذا السبب، عليك دائمًا استدعاءinvalidateفي طرق العرض المخصّصة كلما عدّلت البيانات أو الحالة التي تؤثر في رمز الرسم الخاص بطريقة العرض.
نموذج الرسم المسرَّع للأجهزة
سيظل نظام التشغيل Android يستخدم invalidate وdraw لطلب
تعديلات على الشاشة وعرض طرق العرض، ولكنّه سيتعامل مع عملية الرسم الفعلية بشكل مختلف.
بدلاً من تنفيذ أوامر الرسم على الفور، يسجّل نظام Android هذه الأوامر في قوائم العرض التي تحتوي على ناتج رمز الرسم الخاص بتسلسل عرض العناصر. من التحسينات الأخرى أنّ نظام التشغيل Android يحتاج فقط إلى تسجيل قوائم العرض وتعديلها للعناصر التي تم وضع علامة عليها بأنّها غير صالحة من خلال طلب invalidate. يمكن إعادة رسم طرق العرض التي لم يتم إبطالها
من خلال إعادة إصدار قائمة العرض المسجّلة سابقًا. يتضمّن نموذج الرسم الجديد ثلاث مراحل:
إلغاء صلاحية التسلسل الهرمي
تسجيل قوائم العرض وتعديلها
رسم قوائم العرض
باستخدام هذا النموذج، لا يمكنك الاعتماد على عرض يتقاطع مع المنطقة المعدّلة لتنفيذ طريقة draw. لضمان تسجيل نظام التشغيل Android لقائمة عرض خاصة بأحد عناصر العرض، عليك استدعاء invalidate. ويؤدي عدم إجراء ذلك إلى ظهور طريقة العرض نفسها حتى بعد تغييرها.
يؤدي استخدام قوائم العرض أيضًا إلى تحسين أداء الرسوم المتحركة لأنّ ضبط خصائص معيّنة، مثل الشفافية أو التدوير، لا يتطلّب إبطال العرض المستهدَف (يتم ذلك تلقائيًا). ينطبق هذا التحسين أيضًا على طرق العرض التي تتضمّن قوائم عرض (أي طريقة عرض عندما يكون تطبيقك يستخدم تسريعًا على مستوى الأجهزة). على سبيل المثال، لنفترض أنّ هناك LinearLayout يتضمّن ListView فوق Button. تبدو قائمة العرض الخاصة بـ
LinearLayout على النحو التالي:
DrawDisplayList(ListView)DrawDisplayList(Button)
لنفترض الآن أنّك تريد تغيير مستوى عتامة ListView. بعد استدعاء setAlpha(0.5f) على ListView، أصبحت قائمة العرض تتضمّن ما يلي:
SaveLayerAlpha(0.5)DrawDisplayList(ListView)RestoreDrawDisplayList(Button)
لم يتم تنفيذ رمز الرسم المعقّد الخاص بـ ListView. بدلاً من ذلك، عدّل النظام قائمة العرض الخاصة بالرمز LinearLayout الأبسط بكثير.
في تطبيق لم يتم تفعيل ميزة تسريع الأجهزة فيه، يتم تنفيذ رمز الرسم الخاص بكل من القائمة والعنصر الرئيسي مرة أخرى.
إتاحة عمليات الرسم
عندما يتم تسريع الأجهزة، يتيح مسار عرض الرسومات ثنائية الأبعاد عمليات الرسم Canvas الأكثر استخدامًا، بالإضافة إلى العديد من العمليات الأقل استخدامًا. تتوفّر جميع عمليات الرسم المستخدَمة لعرض التطبيقات التي تأتي مع Android، والأدوات والتنسيقات التلقائية، والمؤثرات البصرية المتقدّمة الشائعة، مثل الانعكاسات والملمس المبلّط.
يوضّح الجدول التالي مستوى التوافق مع العمليات المختلفة على مستوى إصدارات واجهة برمجة التطبيقات:
| أول مستوى لواجهة برمجة التطبيقات متوافق | ||||
| Canvas | ||||
| drawBitmapMesh() (مصفوفة الألوان) | 18 | |||
| drawPicture() | 23 | |||
| drawPosText() | 16 | |||
| drawTextOnPath() | 16 | |||
| drawVertices() | 29 | |||
| setDrawFilter() | 16 | |||
| clipPath() | 18 | |||
| clipRegion() | 18 | |||
| clipRect(Region.Op.XOR) | 18 | |||
| clipRect(Region.Op.Difference) | 18 | |||
| clipRect(Region.Op.ReverseDifference) | 18 | |||
| clipRect() مع التدوير/المنظور | 18 | |||
| طلاء | ||||
| setAntiAlias() (للنص) | 18 | |||
| setAntiAlias() (للخطوط) | 16 | |||
| setFilterBitmap() | 17 | |||
| setLinearText() | ✗ | |||
| setMaskFilter() | ✗ | |||
| setPathEffect() (للخطوط) | 28 | |||
| setShadowLayer() (باستثناء النص) | 28 | |||
| setStrokeCap() (للخطوط) | 18 | |||
| setStrokeCap() (للنقاط) | 19 | |||
| setSubpixelText() | 28 | |||
| Xfermode | ||||
| PorterDuff.Mode.DARKEN (إطار التخزين المؤقت) | 28 | |||
| PorterDuff.Mode.LIGHTEN (إطار التخزين المؤقت) | 28 | |||
| PorterDuff.Mode.OVERLAY (إطار المخزن المؤقت) | 28 | |||
| Shader | ||||
| ComposeShader داخل ComposeShader | 28 | |||
| تظليلات من النوع نفسه داخل ComposeShader | 28 | |||
| المصفوفة المحلية في ComposeShader | 18 | |||
تحجيم لوحة العرض
تم إنشاء مسار عرض ثنائي الأبعاد مسرّع للأجهزة أولاً لتوفير إمكانية الرسم بدون تغيير الحجم، مع العلم أنّ بعض عمليات الرسم تؤدي إلى انخفاض كبير في الجودة عند استخدام قيم أعلى لتغيير الحجم. يتم تنفيذ هذه العمليات كصور يتم رسمها بمقياس 1.0، ويتم تحويلها بواسطة وحدة معالجة الرسومات. بدءًا من المستوى 28 لواجهة برمجة التطبيقات، يمكن تغيير حجم جميع عمليات الرسم بدون أي مشاكل.
يوضِّح الجدول التالي الحالات التي تم فيها تغيير التنفيذ للتعامل بشكل صحيح مع المقاييس الكبيرة:
| عملية الرسم التي سيتم تغيير حجمها | أول مستوى لواجهة برمجة التطبيقات متوافق |
| drawText() | 18 |
| drawPosText() | 28 |
| drawTextOnPath() | 28 |
| الأشكال البسيطة | 17 |
| الأشكال المعقّدة | 28 |
| drawPath() | 28 |
| طبقة الظل | 28 |
إذا كان تطبيقك يتأثر بأي من هذه الميزات أو القيود غير المتوفّرة، يمكنك إيقاف ميزة تسريع الأداء باستخدام الأجهزة للجزء المتأثر فقط من تطبيقك عن طريق استدعاء setLayerType(View.LAYER_TYPE_SOFTWARE, null).
بهذه الطريقة، سيظلّ بإمكانك الاستفادة من ميزة "تسريع الأجهزة" في كل مكان آخر.
راجِع مقالة التحكّم في تسريع الأجهزة لمزيد من المعلومات حول كيفية تفعيل ميزة تسريع الأجهزة وإيقافها على مستويات مختلفة في تطبيقك.
عرض الطبقات
في جميع إصدارات Android، كانت طرق العرض قادرة على العرض في المخازن المؤقتة خارج الشاشة، إما باستخدام ذاكرة التخزين المؤقت للرسم الخاصة بطريقة العرض، أو باستخدام Canvas.saveLayer. تتعدّد استخدامات المخازن المؤقتة أو الطبقات خارج الشاشة. يمكنك استخدامها لتحسين الأداء عند تحريك طرق عرض معقّدة أو لتطبيق تأثيرات التركيب. على سبيل المثال، يمكنك تنفيذ تأثيرات التلاشي باستخدام
Canvas.saveLayer لعرض إحدى طرق العرض مؤقتًا في طبقة ثم إعادة تركيبها على الشاشة باستخدام عامل التعتيم.
بدءًا من الإصدار 3.0 من نظام التشغيل Android (المستوى 11 من واجهة برمجة التطبيقات)، يمكنك التحكّم بشكل أكبر في كيفية استخدام الطبقات وموعد استخدامها من خلال طريقة View.setLayerType. تتلقّى واجهة برمجة التطبيقات هذه مَعلمتَين: نوع الطبقة التي تريد استخدامها وعنصر Paint اختياري يوضّح كيفية دمج الطبقة. يمكنك استخدام المَعلمة
Paint لتطبيق فلاتر الألوان أو أوضاع المزج الخاصة أو
الشفافية على إحدى الطبقات. يمكن أن يستخدم العرض أحد أنواع الطبقات الثلاثة التالية:
LAYER_TYPE_NONE: يتم عرض طريقة العرض بشكل طبيعي ولا يتم الاحتفاظ بنسخة احتياطية منها في ذاكرة مؤقتة خارج الشاشة. وهذا هو الإعداد التلقائي.LAYER_TYPE_HARDWARE: يتم عرض طريقة العرض في الجهاز على شكل نسيج إذا كان التطبيق يستخدم تسريع الأجهزة. إذا لم يكن التطبيق يستفيد من تسريع الأجهزة، سيتصرف نوع الطبقة هذا بالطريقة نفسها التي يتصرف بهاLAYER_TYPE_SOFTWARE.
LAYER_TYPE_SOFTWARE: يتم عرض طريقة العرض في برنامج على شكل صورة نقطية.
يعتمد نوع الطبقة التي تستخدمها على هدفك:
الأداء: استخدِم نوع طبقة أجهزة لعرض طريقة عرض في نسيج أجهزة. بعد عرض طريقة العرض في طبقة، لا يلزم تنفيذ رمز الرسم الخاص بها إلا عندما تستدعي طريقة العرض
invalidate. يمكن بعد ذلك تطبيق بعض الحركات، مثل حركات ألفا، مباشرةً على الطبقة، ما يتيح لوحدة معالجة الرسومات تنفيذها بكفاءة عالية.التأثيرات المرئية: استخدِم نوع طبقة للأجهزة أو البرامج و
Paintلتطبيق معالجات مرئية خاصة على طريقة العرض. على سبيل المثال، يمكنك رسم عرض باللونَين الأبيض والأسود باستخدامColorMatrixColorFilter.التوافق: استخدِم نوع طبقة برمجية لفرض عرض إحدى طرق العرض باستخدام البرنامج. إذا كانت هناك مشكلة في عرض إحدى طرق العرض التي يتم تسريعها باستخدام الأجهزة (على سبيل المثال، إذا كان يتم تسريع تطبيقك بالكامل باستخدام الأجهزة)، فإنّ هذه الطريقة سهلة لتجنُّب القيود المفروضة على مسار عرض الأجهزة.
عرض الطبقات والصور المتحركة
يمكن أن توفّر طبقات الأجهزة رسومات متحركة أسرع وأكثر سلاسة عندما يكون تطبيقك يستخدم ميزة تسريع الأجهزة. لا يمكن دائمًا تشغيل صورة متحركة بمعدل 60 إطارًا في الثانية عند تحريك عروض معقّدة تنفّذ الكثير من عمليات الرسم. ويمكن التخفيف من ذلك باستخدام طبقات الأجهزة لعرض طريقة العرض
في نسيج الأجهزة. ويمكن بعد ذلك استخدام نسيج الأجهزة لتنشيط طريقة العرض، ما يلغي الحاجة إلى إعادة رسم طريقة العرض باستمرار عند تنشيطها. لا تتم إعادة رسم العرض إلا إذا غيّرت خصائصه،
ما يؤدي إلى استدعاء invalidate، أو إذا استدعيت invalidate يدويًا. إذا كنت تعرض صورة متحركة في تطبيقك ولم تحصل على النتائج السلسة التي تريدها، ننصحك بتفعيل طبقات الأجهزة في طرق العرض المتحركة.
عندما تكون طريقة العرض مستندة إلى طبقة أجهزة، يتم التعامل مع بعض خصائصها من خلال طريقة تركيب الطبقة على الشاشة. سيكون ضبط هذه الخصائص فعّالاً لأنّها لا تتطلّب إبطال صحة العرض وإعادة رسمه. في ما يلي قائمة بالخصائص التي تؤثر في طريقة تركيب الطبقة. سيؤدي استدعاء أداة تحديد القيمة لأي من هذه الخصائص إلى إبطال صحة البيانات على النحو الأمثل وعدم إعادة رسم العرض المستهدف:
alpha: لتغيير درجة تعتيم الطبقة
xوyوtranslationXوtranslationY: لتغيير موضع الطبقة
scaleX،scaleY: لتغيير حجم الطبقةrotationوrotationXوrotationY: لتغيير اتجاه الطبقة في المساحة الثلاثية الأبعاد
pivotX،pivotY: لتغيير مصدر عمليات التحويل في الطبقة
هذه السمات هي الأسماء المستخدَمة عند تحريك عرض باستخدام
ObjectAnimator. إذا أردت الوصول إلى هذه السمات، استدعِ دالة الضبط أو الاسترجاع المناسبة. على سبيل المثال، لتعديل السمة alpha، استخدِم الأمر
setAlpha. يوضّح مقتطف الرمز التالي الطريقة الأكثر فعالية لتدوير عرض ثلاثي الأبعاد حول المحور Y:
Kotlin
view.setLayerType(View.LAYER_TYPE_HARDWARE, null) ObjectAnimator.ofFloat(view, "rotationY", 180f).start()
Java
view.setLayerType(View.LAYER_TYPE_HARDWARE, null); ObjectAnimator.ofFloat(view, "rotationY", 180).start();
بما أنّ الطبقات المسرَّعة على الجهاز تستهلك ذاكرة الفيديو، ننصحك بشدة بتفعيلها فقط خلال مدة الصورة المتحركة ثم إيقافها بعد انتهاء الصورة المتحركة. يمكنك تحقيق ذلك باستخدام أدوات معالجة أحداث الحركة:
Kotlin
view.setLayerType(View.LAYER_TYPE_HARDWARE, null) ObjectAnimator.ofFloat(view, "rotationY", 180f).apply { addListener(object : AnimatorListenerAdapter() { override fun onAnimationEnd(animation: Animator) { view.setLayerType(View.LAYER_TYPE_NONE, null) } }) start() }
Java
view.setLayerType(View.LAYER_TYPE_HARDWARE, null); ObjectAnimator animator = ObjectAnimator.ofFloat(view, "rotationY", 180); animator.addListener(new AnimatorListenerAdapter() { @Override public void onAnimationEnd(Animator animation) { view.setLayerType(View.LAYER_TYPE_NONE, null); } }); animator.start();
لمزيد من المعلومات حول تحريك العناصر، راجِع مقالة تحريك العناصر.
نصائح
يمكن أن يؤدي التبديل إلى الرسومات الثنائية الأبعاد المتسارعة بواسطة الأجهزة إلى زيادة الأداء على الفور، ولكن يجب أن تصمّم تطبيقك لاستخدام وحدة معالجة الرسومات بفعالية من خلال اتّباع هذه الاقتراحات:
- تقليل عدد طرق العرض في تطبيقك
- كلّما زاد عدد المشاهدات التي يجب أن يرسمها النظام، زادت بطء سرعته. وينطبق ذلك أيضًا على مسار عرض البرامج. يُعدّ تقليل عدد طرق العرض من أسهل الطرق لتحسين واجهة المستخدم.
- تجنُّب العرض الزائد
- لا ترسم الكثير من الطبقات فوق بعضها البعض. إزالة أي طرق عرض محجوبة تمامًا بطرق عرض أخرى غير شفافة فوقها إذا كنت بحاجة إلى رسم عدة طبقات مدمجة فوق بعضها البعض، ننصحك بدمجها في طبقة واحدة. من القواعد الأساسية الجيدة التي يجب اتّباعها مع الأجهزة الحالية عدم رسم أكثر من 2.5 مرة عدد وحدات البكسل على الشاشة لكل إطار (يتم احتساب وحدات البكسل الشفافة في صورة نقطية).
- عدم إنشاء عناصر العرض في طرق الرسم
- من الأخطاء الشائعة إنشاء
PaintأوPathجديد في كل مرة يتم فيها استدعاء طريقة عرض. ويؤدي ذلك إلى إجبار أداة جمع البيانات غير المرغوب فيها على العمل بشكل متكرر، كما يؤدي إلى تجاوز عمليات التخزين المؤقت والتحسين في مسار الأجهزة. - عدم تعديل الأشكال بشكل متكرّر
- يتم عرض الأشكال والمسارات والدوائر المعقّدة، على سبيل المثال، باستخدام أقنعة النسيج. في كل مرة تنشئ فيها مسارًا أو تعدّله، تنشئ سلسلة معالجة الأجهزة قناعًا جديدًا، وهو ما قد يكون مكلفًا.
- عدم تعديل الصور النقطية بشكل متكرّر
- في كل مرة تغيّر فيها محتوى صورة نقطية، يتم تحميلها مرة أخرى كنسيج لوحدة معالجة الرسومات في المرة التالية التي ترسمها فيها.
- استخدام الإصدار الأولي بحذر
- عندما تجعل طريقة العرض شفافة باستخدام
setAlphaأوAlphaAnimationأوObjectAnimator، يتم عرضها في مخزن مؤقت خارج الشاشة، ما يؤدي إلى مضاعفة معدل التعبئة المطلوب. عند تطبيق قيمة ألفا على طرق عرض كبيرة جدًا، ننصحك بضبط نوع الطبقة علىLAYER_TYPE_HARDWARE.