مراحل الإنشاء والأداء

عند تحديث إطار في Compose، يمر بثلاث مراحل:

  • المقطوعة الموسيقية: تحدّد ميزة "إنشاء" المحتوى الذي يتم عرضه. تقوم بتشغيل دوال قابلة للإنشاء وبناء شجرة واجهة المستخدم.
  • التنسيق: يحدّد Compose حجم كل عنصر وموضعه في شجرة واجهة المستخدم.
  • رسم: يؤدي إنشاء النص إلى عرض عناصر واجهة المستخدم الفردية فعليًا.

يمكن لميزة "الكتابة" تخطّي أي من هذه المراحل بشكل ذكي إذا لم تكن ضرورية. على سبيل المثال، لنفترض أن عنصرًا رسوميًا واحدًا يبدّل بين أيقونتين بنفس الحجم. بما أن حجم هذا العنصر لا يتغير، ولا تتم إضافة أو إزالة أي عناصر من شجرة واجهة المستخدم، يمكن لـ Compose تخطي مرحلتي الإنشاء والتخطيط وإعادة رسم هذا العنصر الواحد.

مع ذلك، قد تصعّب أخطاء البرمجة على Compose المراحل التي يمكن تخطّيها بأمان، وفي هذه الحالة تعمل ميزة ComposeAllowed على المراحل الثلاث، ما قد يؤدي إلى إبطاء واجهة المستخدم. لذا، فإن العديد من أفضل ممارسات الأداء هي مساعدة Compose في تخطي المراحل التي لا يحتاج إلى القيام بها.

لمزيد من المعلومات، يمكنك الاطّلاع على دليل مراحل Jetpack Compose.

المبادئ العامة

هناك مبادئ واسعة يجب اتباعها لتحسين الأداء بشكل عام:

  • إن أمكن، انقل العمليات الحسابية من الدوال القابلة للإنشاء. قد تحتاج إلى إعادة تشغيل الدوال القابلة للإنشاء كلما تغيّرت واجهة المستخدم. تتم إعادة تنفيذ أي رمز تضعه في العنصر القابل للإنشاء، ومن المحتمل أن يتم ذلك لكل إطار من الرسوم المتحركة. حصر التعليمة البرمجية للإنشاء بما يحتاج إليه فقط لإنشاء واجهة المستخدم.
  • "تأجيل" قراءة الحالة لأطول فترة ممكنة عن طريق نقل قراءة الحالة إلى مرحلة فرعية قابلة للإنشاء أو مرحلة لاحقة، يمكنك تقليل إعادة الإنشاء أو تخطي مرحلة التركيب بالكامل. يمكنك إجراء ذلك عن طريق تمرير دوال lambda بدلاً من قيمة الدولة للحالة المتغيرة بشكل متكرر ومن خلال تفضيل المعدّلات المستندة إلى lambda عند تمرير الحالة المتغيرة بشكل متكرر. يمكنك الاطّلاع على مثال على هذه التقنية في قسم تأجيل القراءة لأطول وقت ممكن ضمن القسم اتّباع أفضل الممارسات.

مراجع إضافية