تحسين عرض مخصّص
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
عندما يكون لديك عرض مُصمَّم جيدًا يستجيب للإيماءات والانتقالات بين الحالات،
تأكد من أن العرض يعمل بسرعة. لتجنب واجهة المستخدم التي تبدو بطيئة أو تتعثر أثناء التشغيل، احرص على تشغيل الرسوم المتحركة باستمرار بمعدل 60 إطارًا في الثانية.
تسريع عملية العرض
لتسريع العرض، يمكنك إزالة الرموز غير الضرورية من سلاسل الإجراءات التي يتم طلبها بشكل متكرّر. ابدأ
بـ
onDraw()،
التي تمنحك أكبر مبلغ مردود. وعلى وجه التحديد، أزِل التوزيعات في onDraw()،
لأن التخصيصات قد تؤدي إلى تجميع البيانات غير الضرورية التي تؤدي إلى حدوث خلل في الأداء. خصص الكائنات أثناء التهيئة
أو بين الرسوم المتحركة. لا تقوم أبدًا بإجراء تخصيص أثناء تشغيل
الرسوم المتحركة.
بالإضافة إلى تقليل حجم onDraw()، ننصحك بعدم تكرار استخدام هذه السمة
قدر الإمكان. إنّ معظم المكالمات الواردة إلى onDraw() هي نتيجة لمتصل إلى
invalidate()، لذا ننصحك بإزالة
المكالمات غير الضرورية إلى invalidate().
عملية أخرى مكلفة للغاية هي اجتياز التخطيطات. عند استدعاء إحدى المشاهدات
requestLayout()، يتجاوز نظام واجهة المستخدم في Android
التسلسل الهرمي لطريقة العرض بالكامل لمعرفة الحجم اللازم لكل طريقة عرض. وإذا عثر على قياسات متضاربة، فقد يجتاز التسلسل الهرمي عدة مرات. ينشئ مصممو واجهة المستخدم
أحيانًا تسلسلات هرمية عميقة لكائنات ViewGroup المدمجة. تتسبب هذه التسلسلات الهرمية لطريقة العرض العميقة في حدوث مشاكل في الأداء، لذا اجعل التسلسلات الهرمية لطريقة العرض ضحلة قدر الإمكان.
إذا كانت لديك واجهة مستخدم معقّدة، ننصحك بكتابة عنصر ViewGroup مخصّص لتنفيذ تنسيقه.
على عكس طرق العرض المضمنة، يمكن لطريقة العرض المخصصة أن تضع افتراضات خاصة بالتطبيق حول حجم عناصرها الثانوية وشكلها وبالتالي تجنب تجاوز عناصرها الثانوية لحساب القياسات.
على سبيل المثال، إذا كانت لديك طريقة عرض مخصّصة "ViwGroup" لا تضبط حجمها ليلائم
جميع طرق العرض الفرعية، ستتجنّب النفقات العامة لقياس جميع المشاهدات الفرعية. وهذا التحسين غير ممكن إذا كنت تستخدم التخطيطات المضمنة التي تلبي مجموعة واسعة من حالات الاستخدام.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Optimize a custom view\n\nWhen you have a well-designed view that responds to gestures and transitions between states, make\nsure the view runs fast. To avoid a UI that feels sluggish or stutters during playback, make sure\nanimations consistently run at 60 frames per second.\n\nSpeed up your view\n------------------\n\nTo speed up your view, eliminate unnecessary code from routines that are called frequently. Start\nwith\n[onDraw()](/reference/android/view/View#onDraw(android.graphics.Canvas)),\nwhich gives you the biggest payback. In particular, eliminate allocations in `onDraw()`,\nbecause allocations might lead to a garbage collection that causes a stutter. Allocate objects\nduring initialization or between animations. Never make an allocation while an animation is\nrunning.\n\nIn addition to making `onDraw()` leaner, make sure it's called as infrequently as\npossible. Most calls to `onDraw()` are the result of a call to\n[invalidate()](/reference/android/view/View#invalidate()), so eliminate\nunnecessary calls to `invalidate()`.\n\nAnother very expensive operation is traversing layouts. When a view calls\n[requestLayout()](/reference/android/view/View#requestLayout()), the\nAndroid UI system traverses the entire view hierarchy to find how big each view needs to be. If it\nfinds conflicting measurements, it might traverse the hierarchy multiple times. UI designers\nsometimes create deep hierarchies of nested\n[ViewGroup](/reference/android/view/ViewGroup) objects. These deep view\nhierarchies cause performance problems, so make your view hierarchies as shallow as possible.\n\nIf you have a complex UI, consider writing a custom `ViewGroup` to perform its layout.\nUnlike the built-in views, your custom view can make application-specific assumptions about the size\nand shape of its children and therefore avoid traversing its children to calculate measurements.\n\nFor example, if you have a custom `ViwGroup` that doesn't adjust its own size to fit\nall its child views, you avoid the overhead of measuring all the child views. This optimization\nisn't possible if you use the built-in layouts that cater to a wide range of use-cases."]]
