تشير أداة عرض وحدة معالجة الرسومات الملف الشخصي إلى الوقت النسبي الذي تستغرقه كل مرحلة من مراحل مسار العرض لعرض الإطار السابق. ويمكن أن تساعدك هذه المعلومات في تحديد المؤثِّرات السلبية في سير العمل، بحيث يمكنك معرفة ما يجب تحسينه لتحسين أداء عرض تطبيقك.
تشرح هذه الصفحة بإيجاز ما يحدث خلال كل مرحلة من مراحل المسار، وتناقش المشكلات التي يمكن أن تسبب العوائق هناك. قبل قراءة هذه الصفحة، يجب أن تكون على دراية بالمعلومات المقدمة في عرض وحدة معالجة الرسومات للملف الشخصي. بالإضافة إلى ذلك، قد يكون من المفيد مراجعة آلية عمل مسار العرض لفهم مدى توافق كل المراحل.
التمثيل المرئي
تعرض أداة عرض وحدة معالجة الرسومات الملف الشخصي المراحل وأوقاتها النسبية في شكل رسم بياني: مدرج تكراري مرمّز بالألوان. يوضح الشكل 1 مثالاً لهذه الشاشة.
الشكل 1. رسم بياني لعرض وحدة معالجة الرسومات
يمثل كل جزء من كل شريط رأسي معروض في الرسم البياني لعرض وحدة معالجة الرسومات للملف الشخصي مرحلةً من مسار المعالجة ويتم تمييزه باستخدام لون معين في الرسم البياني الشريطي. يوضح الشكل 2 مفتاحًا لمعنى كل لون معروض.
الشكل 2. وسيلة إيضاح الرسم البياني لعرض وحدة معالجة الرسومات للملف الشخصي
بمجرد فهم إشارات كل لون، يمكنك استهداف جوانب معينة من تطبيقك لمحاولة تحسين أداء العرض.
المراحل ومعانيها
يشرح هذا القسم ما يحدث خلال كل مرحلة مقابلة للون في الشكل 2، بالإضافة إلى أسباب المؤثِّر الذي يجب الانتباه إليه.
معالجة الإدخال
تقيس مرحلة معالجة المدخلات في مسار التعلّم المدة التي قضاها التطبيق في معالجة أحداث المدخلات. يشير هذا المقياس إلى المدة التي قضاها التطبيق في تنفيذ الرمز كنتيجة لاستدعاءات حدث الإدخال.
عندما تكون هذه الشريحة كبيرة
عادةً ما تكون القيم العالية في هذه المنطقة ناتجة عن جهد كبير جدًا، أو عمل معقد جدًا، يحدث داخل استدعاءات أحداث معالج الإدخال. نظرًا لأن عمليات معاودة الاتصال هذه تحدث دائمًا في سلسلة التعليمات الرئيسية، فإن حلول هذه المشكلة تركز على تحسين العمل بشكل مباشر أو نقل العمل إلى سلسلة رسائل مختلفة.
والجدير بالذكر أيضًا أنه
RecyclerView
يمكن أن يظهر الانتقال في هذه المرحلة.
RecyclerView
يؤدي إلى الانتقال مباشرةً عند استهلاك حدث اللمس. ونتيجة لذلك، يمكن أن تضخم أو تملأ مشاهدات العناصر الجديدة. لهذا السبب، من المهم أن تجعل هذه العملية سريعة قدر الإمكان. يمكن أن تساعدك أدوات التحليل مثل Traceview أو
Systrace في إجراء مزيد من التحقيق.
Animation
توضح لك مرحلة "الصور المتحركة" المدة التي استغرقتها لتقييم جميع صانعي الرسوم المتحركة
التي كانت تعمل في هذا الإطار. أكثر أدوات الرسوم المتحركة شيوعًا هي
ObjectAnimator وViewPropertyAnimator والانتقالات.
عندما تكون هذه الشريحة كبيرة
عادةً ما تكون القيم العالية في هذه المنطقة ناتجة عن العمل الجاري بسبب بعض التغيير في خصائص الرسوم المتحركة. على سبيل المثال، تؤدي الصور المتحركة
السريعة التي تعمل على تمرير ListView أو
RecyclerView إلى تضخيم عدد كبير من المشاهدات وعدد المستخدمين.
القياس/التنسيق
لكي يرسم Android عناصر العرض على الشاشة، ينفِّذ عمليتين محددتين عبر التنسيقات وطرق العرض في التسلسل الهرمي لطريقة العرض.
أولاً، يقيس النظام عناصر العرض. يحتوي كل طريقة عرض وتخطيط على بيانات محددة تصف حجم الكائن على الشاشة. يمكن أن يكون لبعض طرق العرض حجم معين، بينما البعض الآخر له حجم يتكيف مع حجم حاوية التخطيط الرئيسية
ثانيًا، يحدد النظام عناصر العرض. بمجرد أن يحسب النظام أحجام طرق العرض الفرعية، يمكن للنظام متابعة التخطيط وتغيير حجم طرق العرض ووضعها على الشاشة.
يُجري النظام عمليات القياس والتنسيق ليس فقط لرسم طرق العرض، ولكن أيضًا للتسلسلات الهرمية الرئيسية لتلك المشاهدات، وصولاً إلى العرض الجذري.
عندما تكون هذه الشريحة كبيرة
إذا كان تطبيقك يقضي وقتًا طويلاً في كل إطار في هذه المنطقة، يكون ذلك عادةً بسبب الكم الهائل من المشاهدات التي يجب توفيرها أو إلى مشاكل مثل الضرائب المزدوجة في الموضع الخطأ في التسلسل الهرمي. في كلتا الحالتين، تتضمن معالجة الأداء تحسين أداء التدرّجات الهرمية لمرات المشاهدة.
يمكن أن يؤدي الرمز الذي أضفته إلى
onLayout(boolean, int, int, int, int) أو
onMeasure(int, int)
إلى مشاكل في الأداء أيضًا. يمكن أن يساعدك كلٌّ من Traceview وSystrace في فحص حزم الاستدعاءات لتحديد المشاكل التي قد يواجهها الترميز الخاص بك.
رسم
تترجم مرحلة الرسم عمليات عرض العرض، مثل رسم خلفية أو رسم نص، إلى سلسلة من أوامر الرسم الأصلية. يلتقط النظام هذه الأوامر في قائمة عرض.
يسجّل شريط "الرسم" مقدار الوقت المستغرق لإكمال التقاط الأوامر
في قائمة العرض، لجميع طرق العرض التي تحتاج إلى تحديث على
الشاشة في هذا الإطار. ينطبق الوقت الذي يتم قياسه على أي رمز أضفته إلى عناصر واجهة المستخدم في تطبيقك. ومن أمثلة هذه الرموز onDraw() وdispatchDraw() وdraw ()methods المختلفة التي تنتمي إلى الفئات الفرعية لفئة Drawable.
عندما تكون هذه الشريحة كبيرة
بعبارات مبسّطة، يمكنك فهم هذا المقياس على أنّه يوضّح المدة التي استغرقتها
جميع طلبات البيانات إلى onDraw()
لكل عرض تم إلغاء صلاحيته. يشمل هذا القياس أي وقت يتم قضاؤه في إرسال أوامر الرسم إلى الأطفال والعناصر القابلة للرسم التي قد تكون موجودة. لهذا السبب، عندما ترى ارتفاعًا في هذا العدد في الشريط،
قد يكون السبب أنّ مجموعة من المشاهدات أصبحت غير صالحة. يجعل البطلان من الضروري
إعادة إنشاء قوائم العرض الخاصة بالمشاهدات. بدلاً من ذلك، قد يكون السبب وقتًا طويلاً نتيجة بعض طرق العرض المخصّصة التي تنطوي على منطق معقد للغاية في أساليب onDraw() الخاصة بها.
المزامنة/التحميل
يمثل مقياس "المزامنة والتحميل" الوقت المستغرق لنقل كائنات الصور النقطية من ذاكرة وحدة المعالجة المركزية إلى ذاكرة وحدة معالجة الرسومات أثناء الإطار الحالي.
تختلف مساحات ذاكرة الوصول العشوائي (CPU) ووحدة معالجة الرسومات (GPU) عن بقية المعالجات، والمخصَّصة للمعالجة المختلفة في ذاكرة الوصول العشوائي (RAM). عند رسم صورة نقطية على Android، ينقل النظام الصورة النقطية إلى ذاكرة وحدة معالجة الرسومات قبل أن تتمكن وحدة معالجة الرسومات من عرضها على الشاشة. بعد ذلك، تخزِّن وحدة معالجة الرسومات الصورة النقطية مؤقتًا كي لا يحتاج النظام إلى نقل البيانات مرة أخرى ما لم يتم إخراج الهيئة من ذاكرة التخزين المؤقت للزخارف في وحدة معالجة الرسومات.
ملاحظة: في أجهزة Lollipop، تظهر هذه المرحلة باللون الأرجواني.
عندما تكون هذه الشريحة كبيرة
ويجب أن تكون جميع موارد الإطار موجودة في ذاكرة وحدة معالجة الرسومات قبل استخدامها لرسم إطار. يعني ذلك أنّ القيمة العالية لهذا المقياس قد تعني إما عددًا كبيرًا من أحمال الموارد الصغيرة أو عددًا صغيرًا من الموارد الكبيرة جدًا. تتمثل إحدى الحالات الشائعة في عرض تطبيق صورة نقطية واحدة قريبة من حجم الشاشة. هناك حالة أخرى عندما يعرض التطبيق عددًا كبيرًا من الصور المصغّرة.
لتقليص هذا الشريط، يمكنك استخدام أساليب مثل:
- التأكد من أن درجات دقة الصورة النقطية ليست أكبر بكثير من الحجم الذي سيتم عرضها به. على سبيل المثال، يجب أن يتجنّب تطبيقك عرض صورة بحجم 1024×1024 كصورة بحجم 48×48.
-
يمكنك الاستفادة من
prepareToDraw()لتحميل صورة نقطية مسبقًا بشكل غير متزامن قبل مرحلة المزامنة التالية.
إصدار الأوامر
يمثل مقطع أوامر المشكلات الوقت المستغرق لإصدار جميع الأوامر اللازمة لرسم قوائم عرض على الشاشة.
لكي يرسم النظام قوائم عرض على الشاشة، فإنه يرسل الأوامر الضرورية إلى وحدة معالجة الرسومات. ويتم عادةً تنفيذ هذا الإجراء من خلال واجهة برمجة التطبيقات OpenGL ES.
تستغرق هذه العملية بعض الوقت، حيث يجري النظام التحويل النهائي والاقتصاص لكل أمر قبل إرسال الأمر إلى وحدة معالجة الرسومات. بعد ذلك، تنشأ أعباء إضافية على جانب وحدة معالجة الرسومات، الذي يحسب الأوامر النهائية. وتتضمن هذه الأوامر عمليات التحويل النهائية والمقاطع الإضافية.
عندما تكون هذه الشريحة كبيرة
ويُعتبر الوقت المستغرَق في هذه المرحلة مقياسًا مباشرًا لمدى تعقيد وكمية قوائم العرض التي يعرضها النظام في إطار معيّن. على سبيل المثال، يمكن أن تتضخم هذه المرة عند إجراء العديد من عمليات الرسم، خاصة في الحالات التي تكون فيها تكلفة صغيرة كامنة لكل مرحلة أولية للرسم. مثلاً:
Kotlin
for (i in 0 until 1000) {
canvas.drawPoint()
}
Java
for (int i = 0; i < 1000; i++) {
canvas.drawPoint()
}
إصداره أكثر تكلفة بكثير من:
Kotlin
canvas.drawPoints(thousandPointArray)
Java
canvas.drawPoints(thousandPointArray);
لا يوجد دائمًا ارتباط 1:1 بين إصدار الأوامر ورسم قوائم العرض فعليًا. وعلى عكس أوامر المشكلات التي تسجّل الوقت المستغرق لإرسال أوامر الرسم إلى وحدة معالجة الرسومات، يمثل مقياس رسم الوقت المستغرق لتسجيل الأوامر الصادرة في قائمة العرض.
ينشأ هذا الاختلاف لأن النظام يتم تخزين قوائم العرض مؤقتًا حيثما أمكن ذلك. ونتيجة لذلك، هناك مواقف تتطلب فيها عملية الانتقال أو التحويل أو الرسوم المتحركة من النظام إعادة إرسال قائمة عرض، بدون الحاجة إلى إعادة صياغتها، أي إعادة استدعاء أوامر الرسم، من البداية. ونتيجة لذلك، يمكنك رؤية شريط "أوامر المشكلة" العالي بدون ظهور شريط رسم أوامر مرتفع.
المعالجة/تبديل الموارد الاحتياطية
بمجرد أن ينتهي Android من إرسال كل قائمة العرض إلى وحدة معالجة الرسومات، يصدر النظام أمرًا أخيرًا لإعلام برنامج تشغيل الرسومات بأنه انتهى مع الإطار الحالي. عند هذه المرحلة، يمكن للسائق أخيرًا عرض الصورة المحدثة على الشاشة.
عندما تكون هذه الشريحة كبيرة
من المهم أن تفهم أن وحدة معالجة الرسومات تنفِّذ العمل بالتوازي مع وحدة المعالجة المركزية. ترسم مشكلات نظام Android الأوامر في وحدة معالجة الرسومات، ثم ينتقل إلى المهمة التالية. تقرأ وحدة معالجة الرسومات أوامر الرسم هذه من قائمة الانتظار وتعالجها.
في الحالات التي تُصدر فيها وحدة المعالجة المركزية الأوامر بسرعة أكبر مما تستهلكه وحدة معالجة الرسومات، يمكن أن تصبح قائمة انتظار الاتصالات بين المعالجات ممتلئة. عند حدوث ذلك، تحظر وحدة المعالجة المركزية (CPU) وتنتظر حتى تتوفر مساحة في قائمة الانتظار لوضع الأمر التالي. تظهر حالة الانتظار الكامل هذه غالبًا خلال مرحلة التبديل بين الموارد الاحتياطية، لأنه عند هذه المرحلة، يتم إرسال أوامر الشراء بالكامل.
يتمثل مفتاح التخفيف من حدة هذه المشكلة في تقليل تعقيد العمل الذي يحدث على وحدة معالجة الرسومات، على غرار ما تفعله في مرحلة "أوامر المشكلات".
دفعات متنوّعة
بالإضافة إلى الوقت الذي يستغرقه نظام العرض لأداء عمله، هناك مجموعة إضافية من الأعمال التي تحدث في سلسلة التعليمات الرئيسية ولا ترتبط بالعرض. ويتم الإبلاغ عن الوقت الذي يستهلكه هذا العمل على أنه وقت خاطئ. يشير الوقت المتنوّع بشكل عام إلى العمل الذي قد يحدث في مؤشر ترابط واجهة المستخدم بين إطارَين متتاليَين للعرض.
عندما تكون هذه الشريحة كبيرة
إذا كانت هذه القيمة عالية، من المحتمل أن يتضمن تطبيقك استدعاءات أو أغراضًا أو عملًا آخر يجب أن يحدث في سلسلة محادثات أخرى. ويمكن أن توفّر أدوات مثل تتبُّع الطريقة أو نظام التحقّق إمكانية رؤية المهام التي يتم تشغيلها في سلسلة التعليمات الرئيسية. ويمكن أن تساعدك هذه المعلومات في استهداف تحسينات الأداء.