بازخورد برنامه‌نویس مورد نیاز است - Frame Timing API

در طول چند سال گذشته، مرورگرها پیشرفت های زیادی در زمینه عملکرد رندر، به ویژه در تلفن همراه داشته اند. در جایی که قبلاً هیچ امیدی به دستیابی به نرخ فریم صاف برای هر چیزی که از راه دور پیچیده بود نداشتید، امروز حداقل اگر مراقب باشید، قابل دستیابی است.

با این حال، برای بسیاری از ما، بین آنچه می‌توانیم به‌طور منطقی روی دستگاه‌های خود آزمایش کنیم و آنچه کاربرانمان تجربه می‌کنند، قطع ارتباط وجود دارد. اگر آنها 60 فریم بر ثانیه نرم و ابریشمی دریافت نکنند، تجربه آنها مختل می شود، و در نهایت آنها به جای دیگری خواهند رفت و ما متضرر خواهیم شد. به همان اندازه که W3C در حال بحث درباره API جدیدی است که می تواند به ما کمک کند ببینیم کاربرانمان چه می بینند: Frame Timing API .

من و جیک آرچیبالد اخیراً یک نمای کلی ویدیویی از API ضبط کرده‌ایم، بنابراین اگر تماشا کردن را ترجیح می‌دهید به خواندن نگاهی بیندازید:

موارد استفاده از Frame Timing API

بدون شک چیزهای زیادی وجود دارد که می‌توانید با Frame Timing API انجام دهید، و مهمتر از همه، می‌توانید آنچه را برای شما و پروژه‌تان مهم است اندازه‌گیری کنید. با این حال، در اینجا چند ایده وجود دارد:

  • ردیابی فریم در ثانیه انیمیشن های جاوا اسکریپت و CSS شما.
  • ردیابی نرمی اسکرول های صفحه خود (یا شاید آن لیست پیمایش بی نهایت زیبا که دارید.)
  • به طور خودکار جلوه های نمایشی خود را بر اساس بار فعلی دستگاه کاهش دهید.
  • تست رگرسیون در معیارهای عملکرد زمان اجرا

زمین آسانسور

در اینجا API در حال حاضر در مشخصات به نظر می رسد: با آن می توانید داده ها را در زمان بندی رشته رندر، جایی که جاوا اسکریپت، استایل ها و طرح بندی اجرا می شوند، بکشید. (ممکن است شنیده باشید که رشته رندر به نام رشته اصلی نامیده می شود؛ این همان چیزی است که نام دیگری دارد.)

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 صحبت کنید.

اطلاعات بیشتر

این API هنوز ارسال نشده است، اما امیدواریم به زودی ارسال شود. در این بین مواردی وجود دارد که می توانید بخوانید و انجام دهید: