Отрисовать за 16 мс / Глеб Михеев (Beta Digital Production)
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,548 views
Здесь мы поговорим о производительности в браузере, а особенно об производительных анимациях и внутреннем устройстве браузера. Основные тезисы выступления: - Что такое лаги, и почему они происходят. - Как браузер отрисовывает сайт. - Что такое Vsync, и почему наша цель ~60fps. - Как сделать анимацию плавной. - Как браузер "ускоряется" при помощи GPU. - Как браузеру помочь "правильно" ускориться. - Основные ошибки при анимации (антипаттерны производительной анимации). - CSS анимации vs JS анимации. - Инструментарий для высокопроизводительных анимаций. - Анимация на мобильных устройствах. - Блокировка интерфейса, откуда берется и как избежать. - Психология пользователя: -- Мертвый интерфейс (почему критически важно, чтобы интерфейс реагировал). -- Излишне быстрая реакция интерфейса. -- Фиксация изменений (кейс от 37signals). -- Почему индикаторы прогресса важны. -- Нативный индикатор против собственного (кейс от facebook).
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Mehr von Ontico
Mehr von Ontico (20)
Отрисовать за 16 мс / Глеб Михеев (Beta Digital Production)
- 3. Лаги
- 4. Что такое лаги? Lag - задержка между действием и ожидаемым резуль
- 5. Какие лаги бывают — Прерывистая анимация — Подвисание при изменениях на странице — Подлагивания при скролле — Блокировка экрана при вычислениях
- 6. Почему они нас раздражают?
- 7. Почему они нас раздражают? — Прерывистая анимация — Подлагивания при скролле
- 8. — Подвисание при изменениях на странице — Блокировка экрана при вычислениях Почему они нас раздражают?
- 9. — Медленный отклик — Недостаточно быстрая смена кадров Причины Почему они нас раздражают?
- 11. 60hz ≈ 16ms Может виноват браузер?
- 13. — Отрисовать ~60 кадров в секунду — На один кадр не более 16мс Чтобы обеспечить плавность нужно: Может виноват браузер?
- 15. Что значит отрисовать? PARSING HTML/CSS РАСЧЕТ СТИЛЕЙ Отрисовка это процесс визуализации состоит из 5-ти стадий
- 16. PARSING HTML/CSS htmlhead h1 p aspan body Ссылка для домашнего чтения: http://bit.ly/2eM71AE font-size: 16px body font-size: 16px color: #252525 p font-size: 16px color: #333 display none span font-size: 16px font-size: 46px h1 font-size: 16px color: blue a DOM CSSOM РАСЧЕТ СТИЛЕЙ Что значит отрисовать?
- 17. PARSING HTML/CSS РАСЧЕТ СТИЛЕЙ htmlhead h1 p aspan body font-size: 16px body font-size: 16px color: #252525 p font-size: 16px color: blue a font-size: 16px color: #333 display none span font-size: 16px font-size: 46px h1 Ссылка для домашнего чтения: http://bit.ly/2eM8eIq Render Tree РАСЧЕТ МАКЕТА Что значит отрисовать?
- 18. PARSING HTML/CSS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА КОМПОНОВКА СЛОЕВ h1 p Ссылка для домашнего чтения: http://bit.ly/2eM8eIq ОТРИСОВКА ЭЛЕМЕНТОВ Что значит отрисовать?
- 19. PARSING HTML/CSS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ Ссылка для домашнего чтения: http://bit.ly/2eM8eIq КОМПОНОВКА СЛОЕВ Что значит отрисовать?
- 20. PARSING HTML/CSS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ Ссылка для домашнего чтения: http://bit.ly/2frF5Ws Что значит отрисовать?
- 21. — Парсинг HTML/CSS — Вычисление стилей Итак, какие стадии отрисовки мы знаем? — Расчет макета — Визуализация элементов — Магическая компоновка Что значит отрисовать?
- 23. Изменения страницы Какую работу влекут за собой изменения? Ссылка для домашнего чтения: http://bit.ly/2f7rFOW ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ — Перерисовка (repaint) ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ — Перерасчет макета (reflow)
- 24. Ссылка для домашнего чтения: http://bit.ly/2f7rFOW Магия компоновки — Некоторые блоки выносятся в отдельные слои — К слоям применяются матричные трансформации — К слоям применяется прозрачность — Трансформации считаются на видеокарте — Слои клеятся между собой на видеокарте Изменения страницы
- 26. Изменения в документе — Перерисовка (repaint) ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ — Перерасчет макета (reflow) ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ Ссылка для домашнего чтения: http://bit.ly/2f7rFOW — Компоновка слоев (Composite layer) ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ Изменения страницы
- 27. Полезные факты — Для старичков: translateZ или translate3d — Используйте will-change — CSS анимации слоев не блокируются конвейером — Избегайте большого количества слоев — Убирайтесь за собой Изменения страницы — Выгружайте из памяти невидимые слои
- 29. ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ
- 30. ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ
- 31. ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ
- 32. ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ
- 33. ИСПОЛНЕНИЕ JS РАСЧЕТ СТИЛЕЙ РАСЧЕТ МАКЕТА ОТРИСОВКА ЭЛЕМЕНТОВ КОМПОНОВКА СЛОЕВ
- 35. Разберем ситуацию — Спрашиваем высоту (получаем из кеша) — Обходим в цикле 200 элементов — Устанавливаем высоту (сброс кеш документа) — Запрашиваем высоту следующего блока — Браузер досрочно делает рефлоу Досрочная инвалидация — Повторяем упражнение 199 раз!!!
- 38. Перерисовки — Все анимации должны работать на Composition — Стоит избегать Repaint и Reflow — CSS анимации и Web Animation API ультрабыстрые — JS анимации дороже, но не хуже — Разделяйте цикл на чтение и запись — Используйте requestAnimationFrame
Hinweis der Redaktion
- 00:30:00 И сегодня я вам расскажу о том, как добиться высокой производительности в интерфейсах и анимациях Но прежде, давайте поговорим об обратной стороне производительности->
- О лагах!
- Что такое лаги? Этим словом называют все, что не устраивает пользователя в работе программы или игры. ——— Если быть точным - лаг это задержка между действием и ожидаемым результатом ———
- Наиболее часто мы с вами встречаемся со следующими проблемами: ——— Анимация идет рывками ——— Подергивается страница при скролле ——— интерфейс виснет при изменениях на странице: например, при добавлении новой порции товаров в конец списка. ——— Ну и конечно блокировка экрана при явных фоновых вычислениях. ———
- Почему они нас раздражают, в чем причина негативной реакции при восприятии?
- Первая группа, раздражает из-за потери ощущения постоянства движения. Для простоты - плавности анимации. Наше с вами зрение имеет эффект, который называется “Инерция зрения” (для любителей красивых терминов - Персистенция зрения). ——— Я думаю вы уже догадались о чем речь: Этот термин обозначает эффект, при котором быстросменяющиеся картинки принимаются нашим мозгом за плавное движение. Как видите, на подобранной мной анимации и рядом нет ощущение плавности. Наоборот, создается ощущение, что мой компьютер еле работает
- Вторая группа нас раздражает из-за неоправданно долгого ожидания. ——— Из-за той самой задержки между действием и результатом. Причем, чем сильнее задержка, тем неприятнее пользоваться.
- Давайте перефразируем причины нашего раздражения? ——— Медленный отклик интерфейса ——— Недостаточное быстрая смена кадров ———
- 00:25:00 Может быть все дело в браузере? Давайте разберёмся что он думает по этому поводу) --------
- Для начала стоит сказать, что обычный бытовой монитор обновляет изображение ——— в среднем 60 раз в секунду. ——— Весь софт, которым мы пользуемся, при отрисовке изменений, синхронизирует свой цикл отрисовки, с частотой обновления монитора. ——— Это получается, что на каждый кадр в среднем приходится 16мс. Хочу заметить, что применимо к частоте обновления экрана и всем производным я произношу слово в среднем, так как реальная частота колеблется и зависит от монитора, блока питания и напряжения в электросети. ———
- Если программа не успевает отрисовать новый кадр, то по истечению 16мс она покажет предыдущий кадр, продолжая отрисовку длинного кадра. И это будет происходить снова и снова, пока кадр не будет закончен. ——— Этот бедный мужик явный нам тому пример) …… Разумеется по этому же принципу работает и наш браузер. ——— Получается, что фризы и рванные анимации, которые мы ругали, это ничто иное как продукт долгой прорисовки кадра и сорванного дедлайна по поставке обновлённого кадра к пользователю на экран ———
- Чтобы обеспечить плавную анимацию, нам нужно: ——— Отрисовывать примерно 60 кадров в секунду ——— И следовательно, при такой частоте, мы должны уложиться примерно в 16 миллисекунд, иначе браузер покажет старый кадр
- 00:23:00 Но что значит отрисовать? Что такое отрисовка? ———
- Отрисовка это процесс визуализации вашего html и css в конечную картинку, с последующей передачей ее на экран. ——— Отрисовка состоит из 5-ти основных стадий. Давайте разберемся, что это за стадии и какую роль каждая из них исполняет ———
- Первая - это парсинг файлов разметки и стилей. По ним создается 2 модели данных: DOM и CCSOM ——— Первая модель содержит дерево всех элементов, присутствующих в HTML Вторая - дерево всех селекторов с их стилями, а так же общие наследуемые свойства родителей. Обратите внимание, на правой диаграмме присутствуют только стили из CSS файла. На самом деле в ней еще должны быть стили элементов по умолчанию. (те самые стили, которые для каждого браузера свои, и различия между которыми мы сбрасываем при помощи normalize.css) Далее, оба дерева передаются по конвейеру дальше ———
- Вторая стадия - расчет стилей. На этой стадии, на DOM элементы накладываются стили в соответствии с CSS селекторами, а так же пропускаются элементы, скрытые через display: none. В результате строится так называемое Render Tree - дерево, которое будет передано далее по конвейеру. ———
- Третья стадия - расчет макета. На этой стадии браузер вычисляет геометрическую форму объектов и подготавливает блочную модель, отображающую положение и размер каждого элемента. ———
- Четвертая стадия - визуализация. На этой стадии браузер заполняет макет пикселями: рисует фоны, прорисовывает тексты и растеризирует картинки.
- И последняя, пятая стадия. Самая магическая из всего процесса) К ней мы вернемся чуть позже, так как ее имеет смысл обсуждать только в контексте обновления изображения. ———
- Итак, Какие стадии мы теперь знаем? ——— Парсинг сырого HTML и CSS кода в обьектные модели ——— Вычисление стилей и подготовка единой объектной модели для дальнейшей работы ——— Расчет геометрии документа ——— Заполнение макета пикселями (или визуализация) ——— Ну и конечно наш пятый магический ингредиент - компоновка ———
- 00:18:00 С процессом отрисовки все ясно. Но наше веб приложение живет во времени, пользователи с ним взаимодействуют, да и js машина тоже на месте не стоит. Следствием этого у нас происходят изменения в документе. Как же происходит отрисовка этих изменений?
- Изменения бывают нескольких типов и влекут за собой разный объем работы. Они отличаются по глубине инвалидации: ——— Первый тип изменения - это перерисовка Перерисовка происходят в случае, когда структура документа и геометрия остается прежней, и изменяются только свойства отображения: цвет фона, текста или картинка на бэкграунде В этой ситуации у нас отрабатывает расчет стилей, и визуализация ——— Второй тип перерисовки - это Перерасчет макета Он происходит в случае если мы изменили свойство макета (к примеру высоту элемента). В этой ситуации у нас к процессу добавляется расчет макета Тут мы сделали практически все, что и при полной отрисовке страницы, благо хоть парсить заново ничего не нужно ——— Но как же тогда делать анимации? Мы понимаем что постоянные перерисовки и расчеты макета это медленно и трудозатратно для процессора. Вот был бы способ разделить страницу на отдельные слои, чтобы избежать полной инвалидации макета в случае перерисовок. Да, и еще было бы круто двигать слои относительно друг друга, менять прозрачность и применять матричные трансформации? Собственно этот способ есть)) Это тот самый, магический способ, представленный в конвейере как компоновка слоев. ———
- На самом деле браузер выносит некоторые блоки в отдельные слои, разделяя рендеринг страницы с цельного на послойный, и держит все слои в памяти. ——— Наиболее близкая нам аналогия, это слои в фотошопе. В браузере они как в фотошопе имеют свой индекс, и могут изменятся без перерасчета всего документа. ——— К слоям можно применить матричные трансформации ——— и прозрачность ——— И теперь самый главный бонус: трансформации считаются на видеокарте. Ну и конечно наша радость была бы не полная без последнего пункта: ——— Финальное изображение так же клеется на видеокарте.
- Вот так выглядит мобильная версия сайта второго ангуляра. А вот как она выглядит в слоях: ——— Я конечно не сдержался и добавил пару свойств, чтобы браузер вынес в слои логотип и копилайн для большего эффекта. Как видите все элементы висят по своим слоям, их можно крутить/вертеть как душе угодно, и это не вызовет не единой перерисовки. Теперь здесь больше нет места магии. ——— Так что теперь в списке изменений в документе у нас появился самый производительный и как следствие - предпочтительный тип изменений: ———
- Компоновка слоев. ——— Теперь при изменении свойств компоновки у нас отрабатывает только расчет стилей и сама компоновка. Это происходит супер быстро. Можно считать, что компоновка вообще не занимает времени. Кстати, обратите внимание, что я в репейнты и рефлоу добавил компоновку слоев - дело в том, что документ по умолчанию представляет из себя слой, поэтому компоновка присутствует всегда.
- И на закрепление хочу рассказать несколько полезных фактов, которые сэкономят вам время работая со слоями: ——— Для того, чтобы гарантировано вынести элемент в слой, нужно дать ему свойство will-change. Это свойство сигнализирует браузеру, что мы будем изменять элемент, поэтому он его вынесет в отдельный слой и приготовиться к изменениям ——— В старых браузерах это делалось при помощи css свойства transform со значением translateZ или translate3d. ——— Забавный факт, css анимации будут применяться к слоям даже если вы заблокируете работу конвейера, и он откажется рисовать вам новые растры и исполнять js код. ——— На предыдущем слайде я сказал, что компоновка практически не занимает времени, это не до конца правда. Слои - это прекрасно, но когда их много вся польза сходит на нет. поэтому контролируйте количество слоев, перемещайте на них только те элементы, которые необходимо вынести в отдельный слой ——— Не забывайте, ваш интерфейс живет во времени. Если ваши анимации исполнились - уберите лишние элементы из слоев ——— Если вы дали слою opacity 0 он продолжит висеть в памяти и занимать место. Дайте слою visibility: hidden, и он сбросит битмап из кеша, но при этом останется слоем. И как только вы вернете ему видимость, он по новой отрисуется и будет служить вам верой и правдой. Касаемо этого хинта: если вы используете greensock, то присмотритесь к свойству autoAlpha. ———
- 00:10:00 Мы готовы рваться в бой) Пора перейти к практическим кейсам! *****Посмотрим сколько у нас осталось времени, попытаемся выжать максимум и будем притапливать на поворотах ———
- Давайте вживую посмотрим как работают перерисовки. Начнем с репейнта. Прежде чем мы будем рассматривать кейс я хочу вам кое что показать. В devtools есть 2 крайне удобные настройки: ——— заходим в меню, выбираем more tools, и в выпадающем списке кликаем по пункту rendering В открывшейся панели выбираем: отображать перерисовки и отображать слои. Как видите, у нас появилось зеленое поле поверх блока с элементом - таким подсвечивается область, по которой отработал отрисовщик на прошлом кадре. Золотистой же рамочкой отмечены слои компоновки. Но в нашем документе их нет, только разве что сам документ Теперь давайте посмотрим какая работа проходит в браузере. Хочу сразу оговориться, сейчас мы используем css анимации. Поэтому примеры будут без джаваскрипта. ———
- Здесь у нас есть кружочек, у которого плавно меняется цвет фона ——— Давайте запишем таймлайн и посмотрим какая работа проводится при отрисовке каждого кадра. …… Мы видим, что главный тред был занят работой, а ниже во вкладке event log мы можем посмотреть детальную информацию об этих событиях Как видно из лога, тут прошел: Перерасчет стилей Обновление геометрии Отработал отрисовщик И прошла компоновка ———
- Так же посмотрим общее процессорное время, потраченное на кадр: 47 сотых милисекунды ———
- Теперь я добавил анимацию, которая изменяет ширину и высоту. ——— Делаем запись, и смотрим на объем работы, которую выполнил браузер. Все тоже самое, но добавился перерасчет макета, так как мы анимировали его свойства. Смотрим общее процессорное время, потраченное на кадр: 65 сотых милисекунды На 18 сотых больше, чем прошлый пример ———
- Теперь сравним с анимацией свойств трансформации. Я заменил изменение высоты и ширины на скейл, поле чего, круг был вынесен браузером в отдельный слой и получил свою золотистую обводку. ——— Давайте посмотрим как он себя ведет в таймлайне: Записываем таймлайн……, смотрим на кадр, а работы то там и нет… вообще. ——— Main thread вообще отсутствует, где расчеты, где composition? опять магия?? Помните, я говорил, что цсс анимации могут проигрываться при полностью заблокированном main thread’e? Это было частным случаем наблюдаемого нами поведения. В чем идея? В отличие от непредсказуемых для браузера js анимаций, css анимации и анимации при помощи Web Animation API, объявлены заранее и от начала до конца проходят внутри движка браузера. Поэтому он может их делегировать в соседний тред, и исполнить параллельно. Вот почему, при блокировании main thread’a они у нас продолжают работать ——— Кстати, это хороший способ резко повысить производительность вашего мобильного устройства. Приглядитесь к тому как библиотеки слайдеров, такие как Fullpage или iScroll делают анимацию под мобильные устройства.
- Хочу привести еще один пример: это досрочная инвалидация. Самый гадкий антипаттерн при анимациях под управлением из js. У нас есть 200 блоков на странице, и мы хотим, чтобы каждый кадр их высота увеличивалась на 1 пиксель. Антипаттерн заключается в том, что мы считываем размер у блока и потом добавляем к нему +1 пиксель. И это повторяется для каждого блока в документе. ——— Давайте посмотрим как это работает. ……. В итоге мы получили скорость отрисовки одного кадра около 100мс, это значит, что в секунду мы сможем сделать всего 10 кадров. Давайте разберемся как там получилось? Посмотрите на таймлайн, видите тут проходит безумное количество работы. Мы не отпускаем main thread ни на секунду! Приглядитесь, видите фиолетовые блоки расчета макета помеченные красным? Мы делаем 200 расчетов македа за кадр!! 200! Но почему это произошло, что мы сделали не так? Давайте разбираться: ———
- Какие конкретно операции происходили в этом примере ——— Начинаем обходить в цикле все 200 элементов на странице ——— Читает высоту первого элемента (она читается из рассчитанной в прошлом цикле геометрической модели макета) ——— После - мы устанавливаем новое значение высоты. Все дерево документа инвалидируется, а браузер ждет, пока js закончит работу, чтобы пойти по конвейеру дальше: рассчитать стили, геометрию, отрисовать изменения и провести компоновку ——— Но тут мы берем следующий элемент, и снова спрашиваем его высоту. А модель то уже инвалидирована! ——— Вот тут браузер понимает, что дело дрянь, и надо досрочно провести расчет макета, чтобы вернуть актуальный размер блока в исполняемый javascript код. И проводит досрочный расчет. И это повторяется оставшиеся 198 раз!!! ——— В итоге 199 досрочных перерисовок! И только после этого мы выходим из цикла, а браузер проходит конвейер до конца перед выводом изображения на экран Получается, мы сами того не желая, по незнанию сделали 200 перерисовок вместо одной. Теперь не удивительно, что это заняло 100 миллисекунд)
- Теперь, понимая откуда растут ноги давайте исправим наш код так, чтобы он не вызывал досрочных перерисовок. Для этого нам достаточно разделить цикл на чтение и запись. В этом примере я использовал библиотечку, которая называется fastdom. Ее функциональность сводиться к тому, что мы можем передавать ей функции, которые будут исполнены при чтении или записи, тем самым разделяя работы с DOMом на этапы в рамках цикла. Что нам это даст? Сначала у нас пройдет 200 чтений И после мы сделаем 200 записей Как вы уже догадались, нам это нужно, чтобы быстро получить ВСЕ значения высоты из рассчитанной в прошлом кадре модели лейаута. А после - инкрементировать и применить. Породив при этом всего лишь одну инвалидацию лейаута. ——— Смотрим что из этого вышло: …… Выглядит намного бодрее) Теперь на отрисовку одного кадра у нас тратится 4,5 миллисекунды (более чем в 25 раз быстрее чем мой прошлый пример). Ну что-ж, если все так хорошо, то давай повысим ставки, увеличим количество элементов в 10 раз ———
- И посмотрим как быстро это отрендериться! ——— ….. Что-ж, по прежнему достаточно быстро, …… в среднем мы укладываем в 22-24 миллисекунды, исключая небольшие пики. К слову есть еще 3й вариант - сделать переменную и инкриментить ее при каждом проходе. Этот вариант я не стал включать в доклад, так как он не отличается по производительности.
- Итак, что мы вынесли из этих примеров: ——— Стоит избегать перерисовок и перерасчетов в макете (особенно при анимациях) ——— Все анимации должны работать на стадии компоновки ——— CSS анимации и анимации при помощи Web Animation API работают ультрабыстро, так как браузер может их вывести в отдельный тред. ——— Анимации, управляемые JS нельзя вывести в отдельный тред, так как они не предсказуемы со стороны движка браузера. Но, у них масса других преимуществ, таких как: Сложные таймлайны, гарантированная кроссбраузерность, полный контроль за исполнением, можно комбинировать их по всякому, анимировать данные, использовать свои переменные и многое многое другое. Так, что не отказывайтесь от них, но помните об альтернативах. ——— Так же, избегайте досрочных перерасчетов и перерисовок, проверяйте себя даже если нет видимых лагов. Никто вам не гарантирует, что девайс послабее прожует ваши перерисовки в рамках 16мс. Не грейте атмосферу зазря. ——— Так же хочу отметить, что есть удобный способ синхронизировать свой код, производящий изменения в DOM, с браузером при помощи requestAnimationFrame.
- 00:00:00 На этом все, всем спасибо!) …. Ваши вопросы!