Задачи для кадров анимации в браузере - PullRequest
0 голосов
/ 22 февраля 2020

Итак, я понимаю, что для того, чтобы поддерживать стандартные 60 кадров в секунду при запуске анимации в веб-браузере, нам нужно всего около 16 мс на кадр для выполнения любой задачи, которую мы хотим. Браузер обычно go выполняет все этапы конвейера рендеринга для рендеринга каждого кадра: enter image description here

Однако такие эксперты, как Пол Льюис, говорят, что у нас реально есть только 10 мс каждый кадр для выполнения наших задач, так как браузер имеет некоторые «накладные расходы» и «домашнее хозяйство» для каждого кадра. Я хотел бы знать, каковы эти «накладные расходы» и «домашние дела» на самом деле?

1 Ответ

1 голос
/ 22 февраля 2020

«Накладные расходы» варьируются в зависимости от браузера, и большинство из них не встречаются в «каждом кадре», но все это складывается, и накладные расходы выполняются либо вашим браузером, либо обычным сторонним кодом клиента, таким как Google Analytics, также занимает ценные миллисекунды. Общие накладные задачи включают в себя:

  • Сборка мусора
  • Прослушивание и обработка часто повторяющихся событий, таких как scroll, mousemove, и некоторых событий касания (например, если у вас есть аналитика библиотеки, которые генерируют тепловые карты, это программное обеспечение может отслеживать каждую операцию мыши и операцию касания)
  • Анимации на вашей странице (CSS или JavaScript -управляемые), которые "накладные расходы" на операцию вашей страницы касаются
  • Стороннего (или вашего) кода, который делает свое дело только после выполнения определенных условий (например, отложенная загрузка изображений, когда изображения загружаются (и окрашиваются и компонуются) только тогда, когда на экране или почти на экране
  • Объявления, обслуживаемые рекламными сетями
  • Ваш собственный асинхронный код (запускается setTimeout(), setInterval(), обработчиками событий и т. д. c. и т. 1055 *. et c.) и тот из любых сторонних библиотек, которые выполняются в какой-то момент, и когда это происходит, съедают ваши 16ms (очевидно, есть много совпадений между этим и предыдущим p oint)
  • Блокировщики рекламы и подобные плагины (они запускаются в другом потоке, но взаимодействуют с вашим потоком, например, когда необходимо манипулирование DOM или любое другое межпотоковое взаимодействие)
  • Загрузка потоковое мультимедиа (которое часто состоит из множества сетевых запросов за кулисами), которое может включать даже относительно короткие, постоянно c видео
  • накладные расходы на запуск GIF-анимации или видео (ваших или UG C) - который отделен от предыдущего пункта, который касается только сетевого взаимодействия)
  • Перерисовка, которая должна происходить всякий раз, когда пользователь прокручивает или переходит на другую часть вашей страницы (независимо от любых слушателей для scroll, resize, et c.)
  • Потенциальная полная перерисовка DOM, если некоторые типы элементов добавляются, удаляются или изменяются в размерах вами или пользователем
  • Обработка XHR или Ответы сервера Iframe или другие данные, поступающие из сети (например, websockets traffi c)
  • Отслеживание пикселей (загрузка g, обрабатывая их требования ценного JavaScript времени двигателя); обратите внимание, что на крупных сайтах часто есть дюжина или два пикселя отслеживания разных типов, и все, что требуется, это один плохо написанный, чтобы предъявлять огромные требования к ограниченным ресурсам вашего браузера)
  • logi c, который пытается предвидеть, что произойдет дальше, и выполнить необходимые оптимизации
  • интенсивное использование ЦП другими приложениями, работающими в вашей ОС (или другими страницами, запущенными на других вкладках вашего браузера), которые отбирают ресурсы у движка JavaScript, механизм рендеринга и т. д. c.
  • Служебные события Event-l oop - событие JavaScript l oop - это элегантный способ обработки однопоточного кода, но при его работе возникают накладные расходы

Все вышеперечисленное (список, даже не близкий к исчерпывающему) будет считаться «накладным» на любой конкретный материал c, который вы пытаетесь выполнить sh в течение 10 мс или 16 мс или что-то в этом роде.

Также обратите внимание, что некоторые устройства просто не способны поддерживать 60fps в браузере или где-либо еще; медленный процессор, отсутствие достаточного объема памяти или постоянной памяти и т. д. c., может замедлять всех приложений, включая браузеры.

Возможно, вы ищете что-то более конкретное c, не уверен - но я думаю, что я знаю, о чем вы упоминаете Пола Льюиса (где он говорит о 10 мс против 16,66 мс и т. д. 1072 *), и я не совсем точно знаю, о каких накладных расходах он говорит - но если, например, вы пытаетесь сделать одну анимацию на веб-странице с частотой 60 кадров в секунду, тогда все вышеперечисленное будет «непроизводительным» по сравнению с вашей конкретной задачей c оптимизации анимации.

Надеюсь, это поможет!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...