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

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

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

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

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

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

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

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

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

مراجع إضافية