اعتبارات أعمق بشأن الأداء

استرخِ ودعنا نقدّم لك المزيد من المعلومات الأساسية حول الأداء.

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

التحسين الموجّه بالملف الشخصي

تُعدّ ملفات Baseline Profiles وملفات Startup Profiles أساسية لتحسين أداء بدء التشغيل وأداء وقت التشغيل لتطبيقات Android. وهي جزء من مجموعة تحسينات الأداء المعروفة باسم "التحسين المستند إلى الملف الشخصي".

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

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

‫Trello وملفات Baseline Profile

تواصلنا مع مهندسين في تطبيق Trello لمعرفة تأثير "الملفات الشخصية للمرجع" في أداء التطبيق. بعد تطبيق "ملفات تعريف خط الأساس" على رحلة المستخدم الرئيسية، لاحظ فريق Trello انخفاضًا كبيرًا بنسبة % 25 في وقت بدء تشغيل التطبيق.

تمكّنت Trello من تحسين وقت بدء تشغيل تطبيقها بنسبة % 25 من خلال استخدام "ملفات تعريف المرجع".

ملفات Baseline Profile في Meta

نشر المهندسون في Meta مؤخرًا مقالة حول كيفية تسريع تطبيقات Android باستخدام "الملفات الشخصية للمرجع".

في تطبيقات Meta، لاحظت الفِرق تحسّنًا في مختلف المقاييس المهمة بنسبة تصل إلى % 40 بعد تطبيق "ملفات Baseline Profile".

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

بدء استخدام "ملفات Baseline"

لإنشاء ملف تعريف أساسي أو ملف تعريف بدء التشغيل، عليك كتابة اختبار Macrobenchmark يفعّل التطبيق. أثناء الاختبار، يتم جمع بيانات ملف التعريف التي سيتم استخدامها أثناء تجميع التطبيق. تتم كتابة الاختبارات باستخدام UiAutomator API الجديد، وسنتناول هذا الموضوع غدًا.

إنّ كتابة مقياس أداء مثل هذا أمر بسيط، ويمكنك الاطّلاع على النموذج الكامل على GitHub.

@Test

fun profileGenerator() {

    rule.collect(

        packageName = TARGET_PACKAGE,

        maxIterations = 15,

        stableIterations = 3,

        includeInStartupProfile = true

    ) {

        uiAutomator {

            startApp(TARGET_PACKAGE)

        }

    }


}

الاعتبارات

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

بدء استخدام ميزة "التحسين المستند إلى الملف الشخصي"

للتعرّف على طريقة عمل "ملفات تعريف الأداء الأساسي"، شاهِد هذا الفيديو من "قمة مطوّري تطبيقات Android":

يمكنك أيضًا مشاهدة حلقة Android Build Time حول ميزة "التحسين المستند إلى الملف الشخصي" للحصول على نظرة متعمّقة أخرى: 

يتوفّر أيضًا دليل شامل حول ملفات Baseline Profiles وملفات Startup Profiles يمكنك الاطّلاع عليه.

تحسينات على أداء Jetpack Compose

لقد أثمرت جهود فريق الهندسة في تحسين أداء إطار عمل واجهة المستخدم لنظام Android. فمنذ الإصدار 1.9 من Jetpack Compose، انخفضت نسبة إيقاف مؤقت لعرض واجهة المستخدم أثناء التمرير إلى % 0.2 خلال اختبار داخلي معياري للتمرير الطويل. 

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

نافذة ذاكرة التخزين المؤقت القابلة للتخصيص

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

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

val dpCacheWindow = LazyLayoutCacheWindow(ahead = 150.dp, behind = 100.dp)

val state = rememberLazyListState(cacheWindow = dpCacheWindow)

LazyColumn(state = state) {

    // column contents

}

تركيبة قابلة للإيقاف المؤقت

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

المزيد من تحسينات أداء Compose

في الإصدارَين 1.9 و1.10 من Compose، أجرى الفريق أيضًا العديد من التحسينات التي لا تبدو واضحة بعض الشيء.

تم تحسين العديد من واجهات برمجة التطبيقات التي تستخدم إجراءات فرعية في الخلفية. على سبيل المثال، عند استخدام Draggable وClickable، من المفترض أن يلاحظ المطوّرون سرعة أكبر في أوقات الاستجابة وتحسّنًا في عدد عمليات التخصيص.

أدّت التحسينات في تتبُّع مستطيل التنسيق إلى تحسين أداء أدوات التعديل، مثل onVisibilityChanged() وonLayoutRectChanged(). يؤدي ذلك إلى تسريع مرحلة التنسيق، حتى في حال عدم استخدام واجهات برمجة التطبيقات هذه بشكلٍ صريح.

من التحسينات الأخرى على الأداء استخدام القيم المخزّنة مؤقتًا عند مراقبة المواضع من خلال onPlaced().

جلب النص مسبقًا في الخلفية

بدءًا من الإصدار 1.9، تتيح Compose إمكانية الجلب المسبق للنص في سلسلة تعليمات في الخلفية. يتيح لك ذلك تسخين الذاكرات المؤقتة مسبقًا لتسريع تخطيط النص، وهو أمر مهم لأداء عرض التطبيق. أثناء التخطيط، يجب تمرير النص إلى إطار عمل Android حيث تتم تعبئة ذاكرة تخزين مؤقت للكلمات. يتم تشغيل هذا الإجراء تلقائيًا على سلسلة Ui. يمكن أن يؤدي نقل عملية الجلب المسبق وتعبئة ذاكرة التخزين المؤقت للكلمات إلى سلسلة فرعية في الخلفية إلى تسريع عملية التنسيق، خاصةً للنصوص الأطول. لإجراء عملية الجلب المُسبَق في سلسلة تعليمات في الخلفية، يمكنك ضبط منفِّذ مخصّص إلى أي دالة مركّبة تستخدم BasicText في الخلفية من خلال ضبط LocalBackgroundTextMeasurementExecutor إلى CompositionLocalProvider على النحو التالي.

val defaultTextMeasurementExecutor = Executors.newSingleThreadExecutor()

CompositionLocalProvider(

    LocalBackgroundTextMeasurementExecutor provides DefaultTextMeasurementExecutor

) {

    BasicText("Some text that should be measured on a background thread!")


}

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

اعتبارات أداء العمل في الخلفية

العمل في الخلفية هو جزء أساسي من العديد من التطبيقات. قد تستخدم مكتبات مثل WorkManager أو JobScheduler لتنفيذ مهام مثل:

• تحميل أحداث تحليلية بشكل دوري
• مزامنة البيانات بين خدمة خلفية وقاعدة بيانات
• معالجة الوسائط (أي تغيير حجم الصور أو ضغطها)

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

ومع ذلك، لا يُعدّ WorkManager حلاً واحدًا يناسب الجميع. يوفّر نظام التشغيل Android أيضًا عددًا من واجهات برمجة التطبيقات المحسَّنة لاستهلاك الطاقة والمصمَّمة خصيصًا مع أخذ بعض رحلات المستخدمين الأساسية الشائعة في الاعتبار.  

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

أدوات تصحيح الأخطاء المحلية للعمل في الخلفية: السيناريوهات الشائعة

لتصحيح أخطاء "العمل في الخلفية" وفهم سبب تأخُّر إحدى المهام أو تعذُّر تنفيذها، عليك معرفة كيفية جدولة النظام لمهامك. 

للمساعدة في ذلك، تتضمّن WorkManager العديد من الأدوات ذات الصلة التي تساعدك في تصحيح الأخطاء محليًا وتحسين الأداء (تعمل بعض هذه الأدوات أيضًا مع JobScheduler). في ما يلي بعض السيناريوهات الشائعة التي قد تواجهها عند استخدام WorkManager، وشرح للأدوات التي يمكنك استخدامها لتصحيح الأخطاء فيها.

تصحيح الأخطاء المتعلقة بعدم تنفيذ العمل المجدوَل

قد يتأخر تنفيذ العمل المجدوَل أو لا يتم تنفيذه على الإطلاق بسبب عدد من العوامل، بما في ذلك عدم استيفاء القيود المحدّدة أو فرض قيود من قِبل النظام. 

الخطوة الأولى في التحقيق في سبب عدم تنفيذ العمل المجدوَل هي التأكّد من أنّه تمّت جدولة العمل بنجاح.  بعد تأكيد حالة الجدولة، حدِّد ما إذا كانت هناك أي قيود أو شروط مسبقة لم يتم استيفاؤها تمنع تنفيذ العمل.

تتوفّر عدة أدوات لتصحيح الأخطاء في هذا السيناريو.

أداة فحص المهام في الخلفية

"أداة فحص المهام في الخلفية" هي أداة فعّالة مدمجة مباشرةً في "استوديو Android". ويوفّر تمثيلاً مرئيًا لجميع مهام WorkManager والحالات المرتبطة بها (قيد التشغيل، في قائمة الانتظار، تعذّر التنفيذ، تم التنفيذ بنجاح). 

لتحديد سبب عدم تنفيذ العمل المجدوَل باستخدام "أداة فحص المهام في الخلفية"، راجِع حالات Work المُدرَجة. تشير الحالة "في قائمة الانتظار" إلى أنّه تمّت جدولة مهمتك، ولكنّها لا تزال في انتظار التنفيذ.

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

عرض قائمة "أداة فحص المهام في الخلفية"

عرض "أداة فحص المهام في الخلفية" في رسم بياني

adb shell dumpsys jobscheduler

يعرض هذا الأمر قائمة بجميع مهام JobScheduler النشطة (التي تتضمّن WorkManager Workers) إلى جانب القيود المحدّدة والقيود التي يفرضها النظام. تعرض هذه الدالة أيضًا سجلّ الوظائف. 

استخدِم هذا الخيار إذا كنت تريد طريقة مختلفة لعرض العمل المُجدوَل والقيود المرتبطة به. بالنسبة إلى إصدارات WorkManager الأقدم من WorkManager 2.10.0، ستعرض adb shell dumpsys jobscheduler قائمة بـ Workers بهذا الاسم:

[package name]/androidx.work.impl.background.systemjob.SystemJobService

إذا كان تطبيقك يتضمّن العديد من المنفّذين، سيسمح لك التحديث إلى الإصدار 2.10.0 من WorkManager بالاطّلاع على أسماء المنفّذين والتمييز بينها بسهولة:

#WorkerName#@[package name]/androidx.work.impl.background.systemjob.SystemJobService

المزايا: يفيد هذا الأمر في معرفة ما إذا كانت هناك أي قيود مفروضة من النظام، وهي القيود التي لا يمكنك تحديدها باستخدام "أداة فحص المهام في الخلفية". على سبيل المثال، سيؤدي ذلك إلى عرض حزمة التطبيق الاحتياطية، ما قد يؤثر في الفترة الزمنية التي يتم فيها إكمال العمل المُجدوَل.

تفعيل ميزة تسجيل معلومات تصحيح الأخطاء

يمكنك تفعيل التسجيل المخصّص للاطّلاع على سجلّات WorkManager المطوَّلة التي سيتم إرفاق WM— بها. 

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

WorkInfo.StopReason

إذا لاحظت أداءً غير متوقّع لعامل معيّن، يمكنك مراقبة سبب إيقاف المنفِّذ في محاولة التشغيل السابقة آليًا باستخدام WorkInfo.getStopReason. 

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

المزايا: يمكنك استخدام WorkInfo.StopReason لجمع بيانات ميدانية حول أداء العاملين لديك.

تصحيح الأخطاء في مدة قفل التنشيط الطويلة التي تم رصدها في "مؤشرات Android الحيوية" والتي تم تحديد مصدرها على أنّه WorkManager

تتضمّن "مؤشرات Android الحيوية" مقياسًا لعمليات قفل التنشيط الجزئي الزائدة عن الحد، والذي يوضّح عمليات قفل التنشيط التي تساهم في استنزاف البطارية. قد تتفاجأ بمعرفة أنّ يستحوذ WorkManager على أقفال التنشيط لتنفيذ المهام، وإذا تجاوزت أقفال التنشيط الحدّ الذي يحدّده Google Play، يمكن أن يؤثر ذلك في مدى ظهور تطبيقك. كيف يمكن تصحيح الخطأ لمعرفة سبب طول مدة قفل التنشيط المرتبطة بعملك؟ يمكنك استخدام الأدوات التالية.

لوحة بيانات "مؤشرات Android الحيوية"

تأكَّد أولاً في لوحة بيانات قفل التنشيط المفرط في مؤشرات Android الحيوية من أنّ مدة قفل التنشيط الطويلة ناتجة عن WorkManager وليست عن تنبيه أو قفل تنشيط آخر. يمكنك استخدام مستندات تحديد عمليات قفل التنشيط التي أنشأتها واجهات برمجة تطبيقات أخرى لمعرفة عمليات قفل التنشيط التي يتم الاحتفاظ بها بسبب WorkManager. 

Perfetto

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

ضمن مسار "حالة الجهاز: المهام"،  يمكنك الاطّلاع على أي مهام تم تنفيذها وأقفال التنشيط المرتبطة بها.

قسم "حالة الجهاز" في Perfetto، يعرض تنفيذ CleanupWorker وBlurWorker

المراجع

راجِع صفحة تصحيح أخطاء WorkManager للحصول على نظرة عامة على طرق تصحيح الأخطاء المتاحة في السيناريوهات الأخرى التي قد تواجهها.

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

الخطوات التالية

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

اسأل Android

سنستضيف جلسة طرح أسئلة (AMA) مباشرة حول الأداء يوم الجمعة. اطرح أسئلتك الآن باستخدام ‎ #AskAndroid واحصل على إجابات من الخبراء.

التحدّي

طلبنا منك يوم الاثنين تفعيل R8. اليوم، نطلب منك إنشاء ملف شخصي للمرجع واحد لتطبيقك.

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

بعد الحصول على هذه البيانات، شغِّل Macrobenchmark لمقارنة CompilationMode.None وCompilationMode.Partial.

شارِك التحسينات التي أجريتها على وقت بدء التشغيل على وسائل التواصل الاجتماعي باستخدام #optimizationEnabled.

المتابعة غدًا

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

انضم إلينا غدًا في اليوم الرابع: دليل تسوية الأداء، حيث سنوضّح بالتفصيل كيفية قياس نجاحك، بدءًا من بيانات الحقل في "مؤشرات Play الحيوية" إلى التتبُّع المحلي المفصّل باستخدام Perfetto.