Требуется обратная связь от разработчиков – API синхронизации кадров

За последние несколько лет браузеры добились огромных успехов в плане производительности рендеринга, особенно на мобильных устройствах. Если раньше у вас не было надежды добиться плавной частоты кадров в чем-то отдаленно сложном, то сегодня это, по крайней мере, достижимо, если вы позаботитесь.

Однако для большинства из нас существует разрыв между тем, что мы можем разумно протестировать на наших собственных устройствах, и тем, что испытывают наши пользователи. Если они не получат плавных и плавных 60 кадров в секунду, их впечатления ухудшятся, и в конечном итоге они уйдут в другое место, а мы пострадаем. Хорошо, что W3C обсуждает новый API, который может помочь нам увидеть то, что видят наши пользователи: API синхронизации кадров .

Джейк Арчибальд и я недавно записали видеообзор API, поэтому, если вы предпочитаете смотреть, а не читать, посмотрите:

Использование API синхронизации кадров

Несомненно, с помощью API синхронизации кадров вы можете сделать множество вещей, и, что особенно важно, вы сможете измерить то, что важно для вас и для вашего проекта. Тем не менее, вот несколько идей:

  • Отслеживание частоты кадров вашей анимации JavaScript и CSS.
  • Отслеживание плавности прокрутки вашей страницы (или, возможно, вашего изящного бесконечного списка прокрутки).
  • Автоматическое уменьшение эффектов шоу-бизнеса в зависимости от текущей нагрузки устройства.
  • Регрессионное тестирование показателей производительности во время выполнения.

Презентация в лифте

Вот как сейчас выглядит API в спецификации: с его помощью вы сможете получать данные о синхронизации потоков рендеринга, где выполняются 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 .

Дополнительная информация

Этот API еще не поставляется, но, надеюсь, скоро появится. А пока вот кое-что, что вы можете прочитать и сделать: