در طول چند سال گذشته، مرورگرها پیشرفت های زیادی در زمینه عملکرد رندر، به ویژه در تلفن همراه داشته اند. در جایی که قبلاً هیچ امیدی به دستیابی به نرخ فریم صاف برای هر چیزی که از راه دور پیچیده بود نداشتید، امروز حداقل اگر مراقب باشید، قابل دستیابی است.
با این حال، برای بسیاری از ما، بین آنچه میتوانیم بهطور منطقی روی دستگاههای خود آزمایش کنیم و آنچه کاربرانمان تجربه میکنند، قطع ارتباط وجود دارد. اگر آنها 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 هنوز ارسال نشده است، اما امیدواریم به زودی ارسال شود. در این بین مواردی وجود دارد که می توانید بخوانید و انجام دهید:
- سند توضیح دهنده موجود در مخزن را بخوانید . نکات ظریف زیادی در مورد اینکه چگونه باید دادههای فریم را به بهترین نحو ثبت کنید تا معنیدار باشد، وجود دارد، و توضیح دهنده در اینجا مقداری جهت میدهد.
- آخرین پیش نویس مشخصات را بررسی کنید . بسیار سبک است و ارزش خواندن را دارد.
- مشکلات مربوط به ویژگی های از دست رفته یا سردردهای احتمالی را پرونده کنید . شما می دانید که می خواهید چه چیزی را اندازه گیری کنید، بنابراین اگر فکر می کنید کاری وجود دارد که نمی توانید با API انجام دهید، لطفاً بازخورد خود را ارائه دهید.