أفضل الممارسات لتحسين التطبيقات

تساعد أفضل الممارسات التالية في تحسين أداء تطبيقك بدون التأثير على جودته.

استخدام الملفات الشخصية للمرجع

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

استخدام ملف بدء التشغيل

يشبه ملف بدء التشغيل الملف الشخصي للمرجع، ولكن يتم تشغيله في وقت التجميع لتحسين تنسيق DEX من أجل بدء تشغيل التطبيق بشكل أسرع.

استخدام مكتبة App Startup

تتيح لك مكتبة App Startup تحديد أدوات تهيئة المكوّنات التي تشارك مقدّم محتوى واحدًا، بدلاً من تحديد مقدّمي محتوى منفصلين لكل مكوّن تحتاج إلى تهيئته. يمكن أن يؤدي ذلك إلى تحسين وقت بدء تشغيل التطبيق بشكل كبير.

تحميل المكتبات بشكل مؤجل أو إيقاف عملية التهيئة التلقائية

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

استخدام الحالة في العناصر القابلة للإنشاء

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

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

var shouldLoad by remember {mutableStateOf(false)}

if (shouldLoad) {
   MyComposable()
}

حمِّل العناصر القابلة للإنشاء داخل الكتلة الشرطية عن طريق تعديل shouldLoad:

LaunchedEffect(Unit) {
   shouldLoad = true
}

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

تحسين شاشة البداية

تُعدّ شاشات البداية جزءًا رئيسيًا من عملية بدء تشغيل التطبيق، ويمكن أن يساعد استخدام شاشة بداية مصمّمة جيدًا في تحسين تجربة بدء تشغيل التطبيق بشكل عام. يتضمّن الإصدار Android 12 (مستوى واجهة برمجة التطبيقات 31) والإصدارات الأحدث شاشة بداية مصمّمة لتحسين الأداء. لمزيد من المعلومات، يُرجى الاطّلاع على شاشة البداية.

استخدام أنواع الصور القابلة لتغيير الحجم

ننصحك باستخدام الرسومات المتجهة للصور. إذا لم يكن ذلك ممكنًا، استخدِم صور WebP. تنسيق WebP هو تنسيق للصور يوفّر ضغطًا عاليًا بدون فقدان البيانات ومع معلومات مفقودة للصور على الويب. يمكنك تحويل صور BMP أو JPG أو PNG أو GIF الثابتة الحالية إلى تنسيق WebP باستخدام Android Studio. لمزيد من المعلومات، يُرجى الاطّلاع على قسم إنشاء صور WebP.

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

استخدام واجهات برمجة التطبيقات للأداء

تتوفّر واجهة برمجة التطبيقات للأداء لتشغيل الوسائط على الإصدار Android 12 (المستوى 31 لواجهة برمجة التطبيقات) والإصدارات الأحدث. يمكنك استخدام واجهة برمجة التطبيقات هذه لفهم إمكانات الجهاز وتنفيذ العمليات وفقًا لذلك.

تحديد أولويات عمليات تتبُّع بدء التشغيل على البارد

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