مقارنة مقاييس "الإنشاء" و"العرض"

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

حجم حزمة APK وأوقات الإنشاء

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

حجم حزمة APK

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

عند إضافة Compose إلى Sunflower لأول مرة، زاد حجم حزمة APK من 2,252 كيلوبايت إلى 3,034 كيلوبايت، أي بمقدار 782 كيلوبايت. تضمّن حِزمة APK التي تم إنشاؤها إصدار واجهة المستخدم مع مزيج من طرق العرض وCompose. من المتوقّع حدوث هذه الزيادة بسبب إضافة تبعيات إضافية إلى Sunflower.

في المقابل، عند نقل تطبيق Sunflower إلى تطبيق يعتمد على Compose فقط، انخفض حجم حزمة APK من 3,034 كيلوبايت إلى 2,966 كيلوبايت، أي انخفاض بمقدار 68 كيلوبايت. ويعود هذا الانخفاض إلى إزالة التبعيات غير المستخدَمة في View، مثل AppCompat وConstraintLayout.

مدّة التصميم

تؤدي إضافة Compose إلى زيادة مدّة التصميم لتطبيقك لأنّ برنامج التجميع في Compose يعالج العناصر القابلة للإنشاء في تطبيقك. تم الحصول على النتائج التالية باستخدام أداة gradle-profiler المستقلة، والتي تنفّذ عملية إصدار عدة مرات حتى يمكن الحصول على متوسط مدّة التصميم لإصدار مخصص لتصحيح الأخطاء في Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug

عند إضافة Compose إلى Sunflower لأول مرة، زاد متوسط مدّة التصميم من 299 ملي ثانية إلى 399 ملي ثانية، أي بمقدار 100 ملي ثانية. يرجع سبب هذه المدة إلى أنّ برنامج التجميع في Compose ينفّذ مهام إضافية لتحويل رمز Compose المحدّد في المشروع.

في المقابل، انخفض متوسط مدّة التصميم إلى 342 ملي ثانية، أي انخفاض بمقدار 57 ملي ثانية، عند اكتمال عملية نقل Sunflower إلى Compose. يمكن أن يُعزى هذا الانخفاض إلى عدة عوامل تقلّل بشكل جماعي من مدّة التصميم، مثل إزالة ربط البيانات ونقل التبعيات التي تستخدم kapt إلى KSP وتحديث العديد من التبعيات إلى أحدث إصداراتها.

ملخّص

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

يمكنك الاطّلاع على المزيد من دراسات الحالة في استخدام Compose for Teams.

الأداء أثناء التشغيل

يتناول هذا القسم مواضيع ذات صلة بأداء وقت التشغيل في Jetpack Compose للمساعدة في فهم مستوى أداء Jetpack Compose مقارنةً بنظام View، وكيفية قياسه.

إعادة التكوين الذكي

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

ملفات Baseline

ملفات Baseline Profiles هي طريقة ممتازة لتسريع تجارب المستخدمين الشائعة. يمكن أن يؤدي تضمين ملف Baseline Profile في تطبيقك إلى تحسين سرعة تنفيذ الرمز بنسبة% 30 تقريبًا من عملية التشغيل الأولى، وذلك من خلال تجنُّب خطوات التفسير والتجميع أثناء التنفيذ (JIT) لمسارات الرموز البرمجية المضمّنة.

تتضمّن مكتبة Jetpack Compose ملف Baseline Profile خاصًا بها، وستحصل تلقائيًا على عمليات التحسين هذه عند استخدام Compose في تطبيقك. ومع ذلك، لا تؤثر عمليات التحسين هذه إلا في مسارات الرموز البرمجية ضِمن مكتبة Compose، لذا ننصحك بإضافة ملف Baseline Profile إلى تطبيقك لتغطية مسارات الرموز البرمجية خارج Compose.

المقارنة مع نظام View

يوفّر Jetpack Compose العديد من التحسينات مقارنةً بنظام View. يتم توضيح هذه التحسينات في الأقسام التالية.

كل شيء يمتد إلى View

يتطلّب كل View يتم رسمه على الشاشة، مثل TextView أو Button أو ImageView، عمليات تخصيص للذاكرة وتتبُّعًا صريحًا للحالة وعمليات ردّ اتصال متنوعة لتلبية جميع حالات الاستخدام. بالإضافة إلى ذلك، يجب أن ينفّذ مالك View المخصّص منطقًا صريحًا لمنع إعادة الرسم عندما لا يكون ذلك ضروريًا، مثلاً لمعالجة البيانات المتكرّرة.

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

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

عمليات تمرير متعددة للتصميم

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

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

عرض أداء بدء التشغيل

يحتاج نظام العرض إلى توسيع تنسيقات XML عند عرض تنسيق معيّن للمرة الأولى. يتم حفظ هذه التكلفة في Jetpack Compose لأنّ التنسيقات مكتوبة بلغة Kotlin ويتم تجميعها مثل بقية تطبيقك.

Benchmark Compose

في Jetpack Compose 1.0، هناك اختلافات ملحوظة بين أداء التطبيق في الوضعين debug وrelease. بالنسبة إلى التوقيتات التمثيلية، عليك دائمًا استخدام الإصدار release بدلاً من الإصدار debug عند إنشاء ملف تعريف لتطبيقك.

للتحقّق من مستوى أداء رمز Jetpack Compose، يمكنك استخدام مكتبة Jetpack Macrobenchmark. لمعرفة كيفية استخدامها مع Jetpack Compose، راجِع مشروع MacrobenchmarkSample.

يستخدم فريق Jetpack Compose أيضًا Macrobenchmark لرصد أي تراجعات محتملة في الأداء. على سبيل المثال، يمكنك الاطّلاع على مقياس الأداء لعمود التحميل الكسول ولوحة البيانات الخاصة به لتتبُّع حالات التراجع.

إنشاء ملف شخصي للتثبيت

بما أنّ Jetpack Compose هي مكتبة غير مجمَّعة، لا تستفيد من Zygote التي تحمّل مسبقًا فئات وأدوات الرسم في واجهة المستخدم لنظام View. يستخدم الإصدار 1.0 من Jetpack Compose عملية تثبيت الملفات الشخصية لإنشاءات الإصدار. تتيح برامج تثبيت الملفات الشخصية للتطبيقات تحديد الرموز البرمجية المهمة التي سيتم تجميعها مسبقًا (AOT) في وقت التثبيت. تتضمّن Compose قواعد تثبيت ملفات تعريف الشحن التي تقلّل وقت بدء التشغيل وإيقاف مؤقت لعرض واجهة المستخدم في تطبيقات Compose.