تعرَّف على كيفية قياس الصور المتحركة، وكيفية التفكير في إطارات الصور المتحركة، وتجانس الصفحة بشكل عام.
من المحتمل أنّك واجهت صفحات "تتوقّف" أو "تتوقّف عن العمل" أثناء الانتقال للأعلى أو للأسفل أو أثناء التمرير المتحرك. نريد أن نشير إلى أنّ هذه التجارب ليست سلسة. لمعالجة هذه الأنواع من المشاكل، عمل فريق Chrome على إضافة المزيد من الدعم إلى الأدوات الاختبارية لرصد الصور المتحركة، بالإضافة إلى إجراء تحسينات ثابتة على بيانات تشخيص مسار العرض في Chromium.
نودّ مشاركة بعض الإنجازات الأخيرة وتقديم إرشادات ملموسة حول الأدوات ومناقشة أفكار حول مقاييس سلاسة الرسوم المتحركة في المستقبل. يسرّنا دائمًا معرفة ملاحظاتك.
ستتناول هذه المشاركة ثلاثة مواضيع رئيسية:
- نظرة سريعة على الصور المتحركة وإطاراتها
- أفكارنا الحالية حول قياس سلاسة الصور المتحركة بشكل عام.
- إليك بعض الاقتراحات العملية التي يمكنك الاستفادة منها في أدوات المختبر اليوم.
ما هي الرسوم المتحركة؟
تُضفي الرسوم المتحركة الحيوية على المحتوى. من خلال جعل المحتوى يتحرك، خاصة استجابةً لتفاعلات المستخدم، يمكن أن تجعل الرسوم المتحركة التجربة تبدو أكثر طبيعية ومفهومة وممتعًا.
ولكن يمكن أن تؤدي الصور المتحركة التي تم تنفيذها بشكلٍ سيئ، أو إضافة عدد كبير جدًا من الصور المتحركة، إلى تقليل جودة التجربة وجعلها غير ممتعة على الإطلاق. من المرجّح أنّنا تعاملنا جميعًا مع واجهة أضافت للتو عددًا كبيرًا جدًا من تأثيرات التحوّل "المفيدة"، والتي تصبح في الواقع غير مناسبة للتجربة عندما يكون أداؤها ضعيفًا. لذلك، قد يفضّل بعض المستخدمين الحركة المخفّضة، وهو ما يفضّله المستخدم.
كيف تعمل الصور المتحركة؟
في ما يلي ملخّص سريع عن مسار العرض: يتألف من بضع مراحل متسلسلة:
- النمط: احسب الأنماط التي تنطبق على العناصر.
- التنسيق: يمكنك إنشاء الشكل الهندسي والموقع لكل عنصر.
- الطلاء: يمكنك ملء ملف bmp بكل وحدات البكسل لكل عنصر في الطبقات.
- مركب: ارسم الطبقات على الشاشة.
على الرغم من أنّ هناك العديد من الطرق لتحديد الصور المتحركة، إلا أنّها تعمل جميعًا بشكل أساسي من خلال أحد الإجراءَين التاليَين:
- ضبط خصائص التنسيق.
- تعديل خصائص الطلاء
- تعديل خصائص المزيج
ولأنّ هذه المراحل متسلسلة، من المهمّ تحديد الرسوم المتحركة في سياق الخصائص التي تكون في مراحل لاحقة من عملية الإنشاء. وكلما تم إجراء التحديث في وقت مبكر من العملية، زادت التكاليف وقلّ احتمال أن يكون التحديث سلسًا. (اطّلِع على أداء معالجة الرسومات لمزيد من التفاصيل).
على الرغم من أنّه قد يكون من المريح تحريك خصائص التخطيط، هناك تكاليف لإجراء ذلك، حتى إذا لم تكن هذه التكاليف واضحة على الفور. يجب تحديد الرسوم المتحرّكة من حيث تغييرات المواقع المركبة كلما أمكن ذلك.
إنّ تحديد الصور المتحركة في CSS الوصفية أو استخدام "الصور المتحركة على الويب"، والتأكّد من إضافة تأثيرات متحركة للخصائص المركّبة، هي خطوة أولى رائعة لضمان الحصول على صور متحركة سلسة وفعّالة. ومع ذلك، لا يضمن ذلك وحده سلاسة العرض لأنّ حتى الرسوم المتحركة الفعّالة على الويب لها حدود أداء. لهذا السبب من المهم دائمًا القياس!
ما هي إطارات الصور المتحركة؟
يستغرق ظهور التعديلات على التمثيل المرئي للصفحة بعض الوقت. سيؤدي أي تغيير مرئي إلى إنشاء إطار جديد للصورة المتحركة، والذي يتم عرضه في نهاية المطاف على شاشة المستخدم.
تعرِض هذه السمة التحديثات بعد فاصل زمني معيّن، وبالتالي يتم تجميع التعديلات المرئية. ويتم تحديث العديد من الشاشات خلال فاصل زمني ثابت، مثل 60 مرة في الثانية (أي 60 هرتز). يمكن أن توفّر بعض الشاشات الحديثة معدّلات تحديث أعلى (أصبح معدّل التحديث من 90 إلى 120 هرتز شائعًا). وغالبًا ما تتكيف هذه الشاشات بشكل نشط بين معدلات التحديث حسب الحاجة، أو يمكنها حتى توفير معدلات متغيرة تمامًا لعرض الإطارات.
إنّ الهدف من أي تطبيق، مثل لعبة أو متصفّح، هو معالجة كل هذه التحسينات المرئية المُجمَّعة وإنشاء إطار متسلسل كامل من الناحية المرئية في مهلة زمنية محددة في كل مرة. يُرجى العِلم أنّ هذا الهدف يختلف تمامًا عن مهام المتصفّح المهمة الأخرى، مثل تحميل المحتوى من الشبكة بسرعة أو تنفيذ مهام JavaScript بكفاءة.
في مرحلة ما، قد يصبح من الصعب جدًا إكمال جميع التعديلات المرئية في مهلة زمنية محددة من قِبل الشاشة. وعندما يحدث ذلك، يُوقف المتصفّح عرض إطار. لا تتحول الشاشة إلى اللون الأسود، بل تتم إعادة عرض المحتوى عليها. يظهر لك تعديل المرئيات نفسه لفترة أطول قليلاً، وهو إطار الصورة المتحركة نفسه الذي تم عرضه في فرصة عرض الإطار السابقة.
يحدث ذلك كثيرًا. وقد لا يكون هذا التأثير محسوسًا بالضرورة، خاصةً بالنسبة إلى المحتوى الثابت أو المشابه للوثائق، والذي يكون شائعًا على منصة الويب على وجه الخصوص. لا تظهر لقطات الإعادة إلا عند إجراء تعديلات مرئية مهمة، مثل الرسوم المتحركة التي نحتاج إلى تدفق ثابت من تعديلات الرسوم المتحركة لعرض حركة سلسة.
ما الذي يؤثر في إطارات الصور المتحركة؟
يمكن لمطوّري البرامج على الويب التأثير بشكل كبير في قدرة المتصفّح على عرض التحديثات المرئية وتقديمها بسرعة وكفاءة.
إليك بعض الأمثلة:
- استخدام محتوى كبير جدًا أو يستهلك موارد كثيرة بحيث لا يمكن فك تشفيره بسرعة على الجهاز المستهدَف
- استخدام عدد كبير جدًا من الطبقات يتطلب الكثير من ذاكرة وحدة معالجة الرسومات.
- تحديد أنماط CSS أو صور متحركة على الويب معقدة للغاية
- استخدام أنماط تصميم تؤدي إلى إيقاف تحسينات العرض السريع
- استخدام JavaScript بشكل مفرط في سلسلة المحادثات الرئيسية، ما يؤدي إلى ظهور مهام طويلة تمنع التحديثات المرئية
ولكن كيف يمكنك معرفة متى لم يظهر لقطة متحركة خلال الموعد النهائي لها وتسبب في عدم عرض لقطة؟
من الطرق الممكنة استخدام اقتراع
requestAnimationFrame()،
إلا أنّ له العديد من الجوانب السلبية. يخبر requestAnimationFrame()، أو "rAF"، المتصفح برغبتك في إنشاء صورة متحركة ويطلب فرصة
لتنفيذ ذلك قبل مرحلة العرض التالية لمسار العرض. إذا
لم يتمّ استدعاء وظيفة الاستدعاء في الوقت المتوقّع، يعني ذلك أنّه
لم يتمّ تنفيذ عملية طلاء، وتمّ تخطّي إطار واحد أو أكثر. من خلال الاستطلاع ومحاولة معرفة عدد مرات استدعاء rAF، يمكنك احتساب نوع من مقياس "اللقطات في الثانية"
(FPS).
let frameTimes = [];
function pollFramesPerSecond(now) {
frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
requestAnimationFrame(pollFramesPerSecond);
console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);
ولا ننصح باستخدام استطلاع باستخدام requestAnimationFrame() لعدة أسباب، منها:
- يجب أن ينشئ كل نص برمجي حلقة استطلاع رأي خاصة به.
- يمكن أن يؤدي ذلك إلى حظر المسار الحرج.
- حتى إذا كان الاستطلاع في rAF سريعًا، يمكن أن يمنع
requestIdleCallback()من إمكانية جدولة وحدات وقت الاستراحة الطويلة عند استخدامها بشكل مستمر (الوحدات التي تتجاوز إطارًا واحدًا). - وبالمثل، يمنع عدم توفّر فترات طويلة من عدم النشاط المتصفّح من جدولة مهام أخرى تستغرق وقتًا طويلاً (مثل جمع المهملات لفترة أطول وغيرها من المهام التي تعمل في الخلفية أو المهام التوقّعية).
- في حال تفعيل الاستطلاع وإيقافه، ستفقد الحالات التي تم فيها تجاوز ميزانية الإطار.
- سيُبلغ الاستطلاع عن نتائج إيجابية خاطئة في الحالات التي يستخدم فيها المتصفّح وتيرة تعديل متغيرة (على سبيل المثال، بسبب حالة الطاقة أو مستوى الرؤية).
- والأهم من ذلك، أنها لا تسجّل في الواقع جميع أنواع تحديثات الرسوم المتحركة!
وقد يؤثر بذل الكثير من الجهد على سلسلة التعليمات الرئيسية في إمكانية رؤية إطارات الصور المتحركة. اطّلِع على مثال على التنقّل غير السلس لمعرفة كيف يؤدي استخدام رسوم متحركة مستندة إلى رسومات معدل عرض اللقطات المتغيرة (rAF) إلى إسقاط اللقطات وانخفاض عدد عمليات الاستدعاء لرسومات معدل عرض اللقطات المتغيرة وانخفاض عدد اللقطات في الثانية، وذلك بعد أن يصبح هناك الكثير من العمل على الخيط الرئيسي (مثل التنسيق).
عندما يصبح الخيط الرئيسي بطيئًا، تبدأ التحديثات المرئية في التقطُّع. شكرًا لك.
ركّزت العديد من أدوات القياس بشكل مكثّف على قدرة السلسلة الأساسية على الأداء في الوقت المناسب، وعلى تشغيل إطارات الرسوم المتحركة بسلاسة. ولكن هذه ليست القصة الكاملة! راجع المثال التالي:
يعرض الفيديو أعلاه صفحة تُضيف بشكل دوري مهام طويلة إلى السلسلة الرئيسية
. تؤدي هذه المهام الطويلة إلى إيقاف قدرة الصفحة على تقديم
أنواع معيّنة من التحديثات المرئية، ويمكنك في أعلى يمين الشاشة ملاحظة
انخفاض مفاجئ في عدد اللقطات في الثانية من requestAnimationFrame() إلى 0.
ومع ذلك، على الرغم من هذه المهام الطويلة، يستمر الانتقال بسلاسة في الصفحة. ويعود سبب ذلك إلى أنّ الانتقال غالبًا ما يكون متعدد المواضيع في المتصفّحات الحديثة، ويعتمد بالكامل على أداة الدمج.
هذا مثال يحتوي في الوقت نفسه على العديد من اللقطات التي تم إسقاطها في سلسلت الرسائل الرئيسية، ومع ذلك لا يزال يتضمّن العديد من اللقطات التي تم عرضها بنجاح أثناء الانتقال في سلسلت الرسائل المركّبة. بعد اكتمال المهمة الطويلة، لن يكون هناك تغيير مرئي في تحديث عرض سلاسل المحادثات الرئيسي على أي حال. اقترح استطلاع rAF انخفاضًا في عدد اللقطات في الثانية إلى 0، ولكن مرئيًا، لن يتمكن المستخدم من ملاحظة أي اختلاف.
بالنسبة إلى إطارات الصور المتحركة، لا تكون القصة بهذه البساطة.
إطارات الصور المتحركة: التحديثات المهمة
يوضّح المثال أعلاه أنّ هناك المزيد من التفاصيل في القصة غير
requestAnimationFrame().
متى تكون تحديثات الرسوم المتحركة وإطارات الرسوم المتحركة مهمة؟ إليك بعض المعايير التي نفكر فيها ونود الحصول على ملاحظات بشأنها:
- تعديلات على سلسلة التعليمات الرئيسية وسلسلة تعليمات أداة الدمج
- عدم توفّر تعديلات الطلاء
- جارٍ رصد الرسوم المتحركة
- الجودة مقابل الكمية
تحديثات سلسلة التعليمات الرئيسية وأداة الإنشاء
تعديلات إطارات الصور المتحركة ليست منطقية. لا يتعلق الأمر بأن الإطارات قد يتم إسقاطها بالكامل أو تقديمها بالكامل. هناك العديد من الأسباب التي قد تجعل إطار الرسوم المتحركة متاحًا جزئيًا. بعبارة أخرى، يمكن أن تشتمل على بعض المحتوى القديم مع عرض بعض التحديثات المرئية الجديدة.
وأكثر الأمثلة شيوعًا على ذلك هو عندما يتعذّر على المتصفّح إنشاء تعديل جديد في سلسلة المهام الرئيسية خلال الموعد النهائي لعرض اللقطة، ولكنّه يتضمّن تعديلًا جديدًا في سلسلة المهام الخاصة بالتركيب (مثل مثال الانتقال المتسلسل الذي سبق ذكره).
من الأسباب المهمة التي تدفع إلى استخدام الرسوم المتحرّكة الوصفية لتحريك الخصائص المركبة هو أنّ ذلك يتيح تشغيل الرسوم المتحرّكة بالكامل من خلال سلسلة المكوّنات حتى عندما تكون السلسلة الرئيسية مشغولة. يمكن أن تواصل هذه الأنواع من الرسوم المتحركة إنشاء تعديلات مرئية بكفاءة وبطريقةٍ متزامنة.
من ناحية أخرى، قد تكون هناك حالات يصبح فيها تعديل الخيط الرئيسي متاحًا للعرض أخيرًا، ولكن بعد تجاوز عدة تواريخ نهائية للإطارات. في هذه الحالة، سيتضمّن المتصفّح بعض التحديثات الجديدة، ولكن قد لا يكون أحدث إصدار.
بشكل عام، نعتبر الإطارات التي تحتوي على بعض التعديلات المرئية الجديدة، بدون جميع التعديلات المرئية الجديدة، إطارًا جزئيًا. الإطارات الجزئية شائعة إلى حد ما. من المفترض أن تتضمّن التحديثات الجزئية على الأقل أهم العناصر المرئيّة التي تم تعديلها، مثل الصور المتحركة، ولكن لا يمكن أن يحدث ذلك إلا إذا كانت الصور المتحركة تتم معالجتها من خلال سلسلة المكوّن.
تعديلات سرعة عرض محتوى الصفحة
هناك نوع آخر من التحديث الجزئي، وهو عندما لا تكتمل عملية ترميز الوسائط مثل الصور وتحويلها إلى شبكة بكسل في الوقت المناسب لعرض اللقطة.
وحتى إذا كانت الصفحة ثابتة تمامًا، قد لا تزال المتصفحات لا تعرض التحديثات المرئية أثناء التمرير السريع. ويعود السبب في ذلك إلى أنّه قد يتم تجاهل تحويلات البكسل للمحتوى خارج إطار العرض المرئي لتوفير ذاكرة وحدة معالجة الرسومات. ويستغرق عرض وحدات البكسل بعض الوقت، وقد يستغرق وقتًا أطول من إطار واحد لعرض كل العناصر بعد تمرير كبير، مثل التمرير بالإصبع. يُعرف هذا عادةً باسم لوحة المعلومات
مع كل فرصة لعرض الإطار، من الممكن تتبُّع مقدار آخر التعديلات المرئية التي تم عرضها على الشاشة. يُعرف قياس القدرة على إجراء ذلك عبر العديد من اللقطات (أو الوقت) على نطاق واسع باسم سرعة معالجة الإطارات.
إذا كان أداء وحدة معالجة الرسومات بطيئًا جدًا، قد يبدأ المتصفّح (أو المنصة) في تقليل معدّل محاولات إجراء تعديلات مرئية، ما يؤدي إلى خفض معدلات عرض اللقطات الفعّالة. على الرغم من أنّ ذلك يمكن أن يقلل من عدد عمليات تعديل اللقطات التي تم إسقاطها، سيظلّ المعدل الظاهر للعرض أقل.
ومع ذلك، ليست كل أنواع سرعة معالجة بيانات اللقطات المنخفضة ضارة. إذا كانت الصفحة غير نشطة في معظم الأوقات ولم تكن هناك صور متحركة نشطة، يكون عدد اللقطات في الثانية المنخفض ممتعًا للعين مثل عدد اللقطات في الثانية المرتفع (ويمكن أن يحافظ على عمر البطارية).
إذًا، متى يكون لسرعة نقل بيانات الإطارات؟
جارٍ رصد الرسوم المتحركة
يكون معدل نقل بيانات الإطارات أمرًا مهمًا خاصة خلال الفترات التي تتضمن رسومًا متحركة مهمة. ستعتمد أنواع الصور المتحركة المختلفة على التحديثات المرئية من سلسلة تعليمات محددة (رئيسية أو أداة إنشاء أو عامل)، لذا يعتمد التحديث المرئي على سلسلة التعليمات هذه التي توفّر تحديثها خلال الموعد النهائي. نقول أنّ سلسلة المحادثات المحدّدة تؤثر في السلاسة عندما تكون هناك صورة متحركة نشطة تعتمد على تحديث سلسلة المحادثات.
من الأسهل تحديد بعض أنواع الرسوم المتحركة ورصدها مقارنةً بأنواع أخرى. إنّ الرسومات المتحرّكة التعريفية، أو الرسومات المتحرّكة المستندة إلى إدخال المستخدم، أكثر وضوحًا في التحديد مقارنةً بالرسومات المتحرّكة المستندة إلى JavaScript والتي يتم تنفيذها كتعديلات دورية على خصائص الأنماط التي يمكن تحرّيكها.
حتى مع استخدام requestAnimationFrame()،
لا يمكنك دائمًا افتراض أنّ كل طلب رسوم متحركة للواقع المعزّز يؤدي بالضرورة إلى إجراء تعديل مرئي
أو إنشاء صورة متحركة. على سبيل المثال، يجب ألا يؤثر استخدام الاستطلاع rAF فقط لتتبّع عدد اللقطات في الثانية (كما هو موضّح أعلاه) في قياسات السلاسة نظرًا لعدم توفّر تعديل مرئي.
الجودة مقابل الكمية
أخيرًا، لا يزال رصد الرسوم المتحركة وتعديلات إطارات الرسوم المتحركة جزءًا فقط من القصة لأنّه لا يرصد سوى عدد تعديلات الرسوم المتحركة، وليس جودتها.
على سبيل المثال، قد ترى معدّل عرض إطارات ثابتًا يبلغ 60 إطارًا في الثانية أثناء مشاهدة فيديو. من الناحية الفنية، هذا المعدل سلس تمامًا، ولكن قد يكون للفيديو نفسه معدل نقل بيانات منخفضًا أو مشاكل في التخزين المؤقت على الشبكة. ولا يتم تسجيل ذلك من خلال مقاييس سلاسة عرض الرسوم المتحركة مباشرةً، ولكن قد يظل ذلك مزعجًا للمستخدِم.
أو قد تكون اللعبة التي تستخدِم <canvas> (ربما باستخدام تقنيات مثل
canvas
خارج الشاشة لمحاولة
ضمان معدّل عرض ثابت للإطارات) سلسة من الناحية الفنية تمامًا من حيث
إطارات الرسوم المتحركة، مع تعذُّر تحميل مواد عرض اللعبة العالية الجودة في
المشهد أو عرض عناصر المعالجة.
وبطبيعة الحال، يمكن أن يتضمّن الموقع الإلكتروني بعض الصور المتحركة السيئة جدًا. 🙂
أعتقد أنّها كانت رائعة في وقتها.
حالات إطار صورة متحركة واحد
بما أنّه قد يتم عرض اللقطات جزئيًا أو قد يتم حذف اللقطات بطرق لا تؤثّر في السلاسة، بدأنا نعتبر أنّ كل لقطة لها نتيجة اكتمال أو سلاسة.
في ما يلي مجموعة الطرق التي نتّبعها لتفسير حالة ملف واحد للصورة المتحركة، مرتبة من الحالة الأفضل إلى الحالة الأسوأ:
| لا أريد إجراء أي تعديل | وقت الاستراحة، تكرار الإطار السابق |
| معروض بالكامل | تم إرسال تعديل السلسلة الرئيسية في غضون الموعد النهائي، أو لم يكن هناك تعديل مطلوب على السلسلة الرئيسية. |
| معروضة جزئيًا | المُركِّب فقط، لم يؤدّي تأخُّر تعديل الخيط الرئيسي إلى أيّ تغيير مرئي. |
| معروض جزئيًا | أداة الدمج فقط: تم إجراء تعديل على المقطع الرئيسي، ولكن لم يتضمّن هذا التعديل صورة متحركة تؤثر في السلاسة. |
| معروضة جزئيًا | كمركّب فقط: تضمّنت سلسلة التعليمات الرئيسية تحديثًا مرئيًا يؤثر في السلاسة، إلا أنّ إطارًا قديمًا كان يتضمّن إطارًا قديمًا وتم استخدامه بدلاً من ذلك. |
| معروضة جزئيًا | أداة الدمج فقط، بدون التحديث الرئيسي المطلوب، وتتضمن أداة الدمج تحديثًا للحركة يؤثر في السلاسة. |
| معروضة جزئيًا | أداة الدمج فقط، ولكنّ تحديث أداة الدمج لا يحتوي على صورة متحركة تؤثّر في السلاسة. |
| الإطار الذي تم إسقاطه | ما مِن تعديل. لم يكن هناك تحديث مطلوب للتركيب، وتم تأجيل الإصدار الرئيسي. |
| الإطار الذي تم إسقاطه | كان المطلوب تحديث أداة التركيب، ولكن تم تأخيره. |
| الإطار القديم | كان مطلوبًا إجراء تعديل، وقد تم إنشاؤه بواسطة أداة التقديم، ولكن لم تعرضه وحدة GPU قبل الموعد النهائي لالتزامن. |
من الممكن تحويل هذه الحالات إلى نتيجة. ولعلّ إحدى طرقinterpreting this score هي اعتبارها احتمالية رصده من قِبل المستخدِم. قد لا يكون لقطة واحدة غير ظاهرة بشكل كبير، ولكن تسلسل العديد من اللقطات غير الظاهرة التي تؤثّر في السلاسة على التوالي يكون ملحوظًا بالتأكيد.
تجميع كل العناصر معًا: مقياس "النسبة المئوية للّقطات المفقودة"
في حين أنه قد يكون من الضروري أحيانًا التعمق في حالة كل إطار رسوم متحركة، إلا أنه من المفيد أيضًا تعيين درجة "نظرة سريعة" سريعة للحصول على تجربة.
بما أنّ اللقطات قد يتم عرضها جزئيًا، ولأنّه حتى في حال تخطّي تعديلات اللقطات بالكامل، قد لا تؤثر سلاسة الفيديو، نريد التركيز بشكل أقل على عدّ اللقطات، والتركيز بشكل أكبر على مدى عدم تمكّن المتصفّح من تقديم تعديلات كاملة من الناحية المرئية عندما يكون ذلك مهمًا.
يجب أن ينتقل النموذج العقلي من:
- عدد اللقطات في الثانية، إلى
- رصد التحديثات المفقودة والمهمة للرسوم المتحركة، وذلك من أجل
- النسبة المئوية للانخفاض خلال فترة زمنية معيّنة.
ما يهم هو: نسبة الوقت في انتظار التحديثات المهمة. ونعتقد أن هذا يتوافق مع الطريقة الطبيعية التي يختبر بها المستخدمون سلاسة محتوى الويب عمليًا. حتى الآن، كنّا نستخدم ما يلي كأحد المجموعات الأولية للمقاييس:
- متوسط النسبة المئوية للإطارات التي تم إسقاطها: لجميع لقطات الرسوم المتحركة غير المتوقفة خلال المخطط الزمني بأكمله
- أسوأ نسبة لقطات تم إسقاطها: يتم قياسها على مدار نوافذ زمنية متحركة مدّتها ثانية واحدة.
- النسبة المئوية التسعون لعدد اللقطات المفقودة: يتم قياسها على مدار ثانية واحدة باستخدام نوافذ زمنية متحركة.
يمكنك العثور على هذه النتائج في بعض أدوات مطوّري برامج Chrome اليوم. على الرغم من أنّ هذه المقاييس تركّز فقط على إجمالي معدل نقل اللقطات، فإنّنا نقيّم أيضًا عوامل أخرى، مثل وقت استجابة اللقطة.
جرِّب ذلك بنفسك في أدوات المطوّرين.
شاشة معلومات أداء السيارة
يحتوي Chromium على شاشة معلومات أداء رائعة مخفية خلف علامة
(chrome://flags/#show-performance-metrics-hud). يمكنك العثور فيها على علامات قياس أداء حية
لعناصر مثل "مؤشرات أداء الويب الأساسية"، بالإضافة إلى بعض التعريفات التجريبية
لسلاسة الرسوم المتحركة استنادًا إلى نسبة اللقطات المفقودة بمرور الوقت.
إحصاءات العرض للإطارات
فعِّل "إحصاءات عرض اللقطات" في "أدوات المطوّر" من خلال إعدادات العرض لعرض عرض مباشر لإطارات الرسوم المتحركة الجديدة، التي يتم ترميزها حسب اللون للتمييز بين التعديلات الجزئية والتعديلات التي تم إسقاط اللقطات بالكامل فيها. يتم تسجيل عدد اللقطات في الثانية للّقطات المعروضة بالكامل فقط.
ميزة "عارض الإطارات" في تسجيلات الملف الشخصي للأداء في "أدوات مطوّري البرامج"
تحتوي لوحة أداء أدوات مطوّري البرامج منذ فترة طويلة على مشاهد الإطارات. ومع ذلك، لم يتطابق إلى حد ما مع الطريقة التي يعمل بها مسار العرض الحديث. وقد تم إدخال الكثير من التحسينات مؤخرًا، حتى في أحدث إصدار من Chrome Canary، والتي نعتقد أنها ستخفف كثيرًا من أخطاء الصور المتحركة عند تصحيح الأخطاء.
ستلاحظ اليوم أنّ الإطارات في "عارض اللقطات" تتماشى بشكل أفضل مع حدود مزامنة اللقطات، ويتم ترميزها حسب الحالة. لا يزال هناك تصور كامل لجميع الفروق الدقيقة الموضحة أعلاه، ولكننا نخطط لإضافة المزيد في المستقبل القريب.
تتبُّع Chrome
أخيرًا، باستخدام ميزة "تتبُّع Chrome"، وهي الأداة المفضّلة للتوغّل في التفاصيل،
يمكنك تسجيل عملية تتبُّع "عرض محتوى الويب" من خلال واجهة مستخدم Perfetto
الجديدة (أو about:tracing)، والتعمّق في مسار معالجة الرسومات في Chrome. قد تكون مهمة شاقة، ولكن تمت إضافة بعض الأشياء
مؤخرًا إلى Chromium لجعلها أسهل. يمكنك الاطّلاع على نظرة عامة على ما هو
متاح في مستند رحلة
الإطار
.
من خلال أحداث التتبّع، يمكنك تحديد ما يلي بدقة:
- الصور المتحركة التي يتم تشغيلها (باستخدام الأحداث المُسمّاة "
TrackerValidation") - الحصول على المخطط الزمني الدقيق لإطارات الصور المتحركة (باستخدام الأحداث المُسمّاة
PipelineReporter) - للحصول على تحديثات غير تقليدية للصور المتحركة، عليك أن تعرف بالضبط ما الذي يحول دون عمل الرسوم المتحركة بشكل أسرع (باستخدام تقسيمات الأحداث ضمن أحداث
PipelineReporter). - بالنسبة إلى الرسوم المتحرّكة المستندة إلى الإدخال، يمكنك معرفة الوقت المستغرَق للحصول على تعديل مرئي
(باستخدام الأحداث التي تحمل الاسم
EventLatency).
الخطوات التالية
تهدف مبادرة مؤشرات أداء الويب إلى توفير مقاييس وإرشادات ل تقديم تجارب رائعة للمستخدمين على الويب. إنّ المقاييس المستندة إلى المختبر، مثل Total Blocking Time (TBT)، هي ضرورية لرصد وتحديد المشاكل المحتملة في التفاعل وحلّها. ونخطّط لمحاولة تصميم مقياس مماثل يستند إلى اختبارات معملية لقياس سلاسة الرسوم المتحركة.
سنطلعك على آخر الأخبار بينما نواصل العمل على أفكار لتصميم مقياس كامل يستند إلى بيانات إطارات الرسوم المتحركة الفردية.
وفي المستقبل، نرغب أيضًا في تصميم واجهات برمجة تطبيقات تتيح قياس مدى سلاسة الصور المتحركة بشكل جيد للمستخدمين الحقيقيين في المجال وكذلك في المختبر. يُرجى متابعتنا لمعرفة آخر الأخبار.
ملاحظات
نحن متحمّسون بشأن كل التحسينات وأدوات المطوّرين التي تم طرحها مؤخرًا في Chrome لقياس سلاسة الرسوم المتحركة. يُرجى تجربة هذه الأدوات، وقياس أداء الرسومات المتحركة، وإعلامنا بالنتائج التي تحقّقها.
يمكنك إرسال ملاحظاتك إلى مجموعة Google web-vitals-feedback مع تضمين "[Smoothness Metrics]" في سطر الموضوع. نحن نتطلع حقًا إلى سماع ما تفكر فيه!