ملاحظات من المطوّر مطلوبة - واجهة برمجة تطبيقات Frame Timing

Paul Lewis

ملاحظة: لم يتمّ تنفيذ واجهة برمجة التطبيقات هذه بعد، لذا نريد ملاحظات من المطوّرين.

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

ومع ذلك، بالنسبة إلى معظمنا، هناك تناقض بين ما يمكننا اختباره بشكل معقول على أجهزتنا وما يواجهه المستخدمون. وإذا لم يحصلوا على بث سلس بمعدّل 60 لقطة في الثانية، ستتأثر تجربتهم، وسينتقلون في النهاية إلى مكان آخر، ما سيؤثّر سلبًا فينا. من المفيد أيضًا أنّ W3C تناقش واجهة برمجة تطبيقات جديدة يمكن أن تساعدنا في الاطّلاع على ما يراه المستخدمون: Frame Timing API.

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

استخدامات Frame Timing API

هناك بلا شكّ الكثير من الإجراءات التي يمكنك اتّخاذها باستخدام Frame Timing API، ومن المهمّ أن تتمكّن من قياس ما يهمّك أنت ومشروعك. مع ذلك، إليك بعض الأفكار:

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

العرض الترويجي القصير

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

var rendererEvents = window.performance.getEntriesByType("renderer");

يظهر كل سجلّ من سجلّات سلسلة المحادثات الخاصة بوحدة العرض التي تتلقّاها على النحو التالي تقريبًا:

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

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

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

بالإضافة إلى سلسلة المخطِّط، يمكنك أيضًا سحب بيانات عن توقيت سلسلة المُركِّب، حيث يحدث الرسم والتركيب:

var compositeThreadEvents = window.performance.getEntriesByType("composite");

ويعرض كلّ منهما أيضًا رقم إطار المصدر الذي يمكنك استخدامه لربطه بأحداث سلسلة المحادثات الرئيسية:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

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

مزيد من المعلومات

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

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