على مدار السنوات القليلة الماضية، أحرزت المتصفّحات خطوات كبيرة في ما يتعلّق بأداء العرض، وخاصةً على الأجهزة الجوّالة. لم تكن لديك الأمل في السابق في إنشاء معدل إطارات سلس لأي شيء معقد عن بُعد، إلا أنه أصبح اليوم قابلاً للتحقيق على الأقل إذا احترست.
ومع ذلك، بالنسبة لمعظمنا، هناك فصل بين ما يمكننا اختباره بشكل معقول على أجهزتنا وبين ما يجربه المستخدمون. فإذا لم تحصل على معدل 60 لقطة في الثانية، فإن تجربة الاستخدام لديك تكون ضعيفة، وفي النهاية سينتقل إلى شيء آخر وسنعاني. بالإضافة إلى ذلك، يناقش W3C واجهة برمجة تطبيقات جديدة يمكن أن تساعدنا في معرفة ما يراه المستخدمون، وهي: Frame Timing API.
لقد سجّلنا أنا وجايك أرشيبالد مؤخرًا فيديو يعرض نظرة عامة حول واجهة برمجة التطبيقات، لذلك إذا كنت تفضّل مشاهدة المحتوى على القراءة، يمكنك إلقاء نظرة:
استخدامات واجهة برمجة التطبيقات Frame Timing
ولا شك في أنّ هناك العديد من الأمور التي يمكنك تنفيذها باستخدام Frame Timing API، ويمكنك قياس ما هو مهم لك ولمشروعك بشكل بالغ الأهمية. ومع ذلك، إليك بعض الأفكار:
- تتبُّع عدد اللقطات في الثانية للصور المتحركة في JavaScript وCSS
- تتبع سلاسة عمليات تمرير الصفحة (أو ربما قائمة التمرير اللانهائي الرائعة لديك).
- تغيير حجم تأثيرات برنامج العرض تلقائيًا استنادًا إلى الحِمل الحالي على الجهاز
- اختبار التراجع في مقاييس الأداء في وقت التشغيل
العرض الترويجي القصير
سنتعرّف في ما يلي على طريقة عرض واجهة برمجة التطبيقات في الوقت الحالي ضمن المواصفات، فباستخدامها ستتمكّن من سحب البيانات على توقيت سلسلة تعليمات العارض حيث يتم تشغيل JavaScript والأنماط والتنسيق. (من المحتمل أنّك سمعت سلسلة التعليمات الخاصة بالعارض التي تُسمى سلسلة التعليمات الرئيسية، ولكنّها تشير إلى اسم آخر).
var rendererEvents = window.performance.getEntriesByType("renderer");
يبدو كل سجلّ من سجلّات سلسلة التعليمات في برنامج العرض على النحو التالي تقريبًا:
{
sourceFrameNumber: 120,
startTime: 1342.549374253
cpuTime: 6.454313323
}
فكل سجلّ هو في الأساس عنصر يحتوي على رقم إطار فريد وطابع زمني عالي الدقة يشير إلى وقت بدء الإطار، ودليلاً آخر لمقدار وقت وحدة المعالجة المركزية (CPU) الذي استخدمه. باستخدام مصفوفة من هذه العناصر، يمكنك إلقاء نظرة على كل من قيم startTime ومعرفة ما إذا كانت سلسلة التعليمات الرئيسية ستسير بسرعة 60 لقطة في الثانية. في الأساس، "هل يرتفع startTime في كل إطار إلى أجزاء تبلغ 16 ملي ثانية تقريبًا؟"
بالإضافة إلى ذلك، ستحصل أيضًا على cpuTime، ما يتيح لك معرفة ما إذا كنت داخل حدود 16 ملي ثانية أو ما إذا كنت على السلك. إذا كانت cpuTime قريبة من حد 16 ملي ثانية، لن يكون هناك أي مساحة كافية لتنفيذ مهام، مثل تجميع البيانات غير الضرورية، وارتفاع استخدام وحدة المعالجة المركزية (CPU) سيكون استهلاك البطارية أعلى أيضًا.
بالإضافة إلى سلسلة التعليمات في العارض، يمكنك أيضًا سحب البيانات حول توقيت سلسلة التعليمات، حيث يحدث الرسم والإنشاء:
var compositeThreadEvents = window.performance.getEntriesByType("composite");
يأتي كلٌ منها أيضًا مع رقم إطار المصدر، والذي يمكنك استخدامه لربطه بأحداث سلسلة التعليمات الرئيسية:
{
sourceFrameNumber: 120,
startTime: 1352.343235321
}
ونظرًا للطريقة التي تعمل بها ميزة الإنشاء غالبًا في المتصفحات، قد يتوفّر العديد من هذه السجلات لكل سجلّ سلسلة تعليمات في العارض، لذلك يمكنك استخدام السمة sourceFrameNumber لربط هذه السجلّات ببعضها البعض مرة أخرى. هناك أيضًا بعض النقاشات حول ما إذا كان يجب تخصيص وقت لوحدة المعالجة المركزية (CPU) في هذه السجلات أيضًا، لذلك إذا كنت تشعر بأهمية عن مشاكل GitHub.
مزيد من المعلومات
لم يتم شحن واجهة برمجة التطبيقات هذه بعد، ولكننا نأمل أن يتم ذلك قريبًا. في الوقت الحالي، إليك بعض الأشياء التي يمكنك قراءتها وتنفيذها:
- يُرجى قراءة المستند التوضيحي في الريبو. هناك الكثير من الفروق الدقيقة حول أفضل طريقة لتسجيل بيانات الإطار حتى تكون ذات مغزى، والشرح يعطي بعض التوجيه هنا.
- اطّلِع على أحدث المسودة من المواصفات، فهي بسيطة جدًا وتستحق القراءة.
- الإبلاغ عن المشاكل المتعلّقة بالميزات الناقصة أو المشاكل المحتمَلة: أنت تعرف ما تريد قياسه، لذا يُرجى تقديم ملاحظاتك إذا كنت تعتقد أنّ هناك شيئًا لا يمكنك فعله بواجهة برمجة التطبيقات الذي ترغب في تنفيذه.