[Перевод] Современный браузер внутри секрета (часть четвертая)

Оригинальный адрес:Inside look at modern web browser (part 4)

Оригинальный автор:Mariko Kosaka

Перевод с:Программа перевода самородков

Постоянная ссылка на эту статью:GitHub.com/rare earth/gold-no…

Переводчик:ThomasWhyne

Корректор:llp0574 CoolRice

Поведение пользователя и синтезаторы

В серии блогов Insider рассказывается, как современные браузеры обрабатывают код и отображают страницы. Это последний из четырех блогов в этой серии. В прошлом блоге мы узналиПроцесс рендеринга и композитор. Здесь мы рассмотрим, как композиторы продолжают обеспечивать гладкое взаимодействие при вводе данных пользователем.

Входные события с точки зрения браузера

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

Когда происходит жест пользователя, например прикосновение к экрану, процесс браузера первым фиксирует его. Однако информация, хранящаяся в процессе браузера, ограничена областью, в которой происходит поведение, поскольку содержимое вкладки обрабатывается процессом рендеринга, поэтому процесс браузера будет использовать тип события (например,touchstart) и его координаты отправляются в процесс рендеринга. Процесс рендеринга найдет цель события, запустит прослушиватель событий и соответствующим образом обработает событие.

Рис. 1. События ввода отправляются из процесса браузера в процесс рендерера

Синтезатор получает входные события

Рис. 2. Окно просмотра, наведенное на слой страницы

В прошлой статье мы рассмотрели, как компоновщики могут добиться плавной прокрутки страниц путем компоновки растеризованных слоев. Если на страницу не были добавлены прослушиватели событий, поток компоновщика создает новый кадр композитинга, независимый от основного потока. Но что, если на страницу будут добавлены прослушиватели событий? Как поток компоновщика узнает, нужно ли обрабатывать событие?

Понимание областей, не требующих немедленной прокрутки

Поскольку выполнение скрипта JavaScript — это работа основного потока, после синтеза страницы процесс синтеза помечает область, в которую добавляются прослушиватели событий на странице, как «область, не допускающую непосредственной прокрутки». С помощью этой информации, если в этой области происходит входное событие, процесс композиции может определить, что оно должно быть отправлено в основной поток для обработки. Если входное событие происходит за пределами этой области, процесс компоновки определяет, что ему не нужно ждать основного потока, и он может продолжить компоновку новых кадров.

Рисунок 3: Схематическая диаграмма ввода описания области, не предназначенной для непосредственной прокрутки.

Будьте осторожны при настройке обработчиков событий

Распространенным шаблоном обработки событий, используемым в веб-разработке, является делегирование событий. Поскольку события всплывают, вы можете добавить обработчик событий к самому верхнему элементу, который делегирует задачи, созданные целью события. Возможно, вы видели или писали код, подобный следующему.

document.body.addEventListener('touchstart', 
event => {
    if (event.target === area) {
        event.preventDefault();
    }
});

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

Рис. 4. Схематическая диаграмма описания ввода в области, не предназначенной для непосредственной прокрутки, охватывающей всю страницу.

Вы можете добавитьpassive:trueвозможность свести к минимуму этот негативный эффект. Это подскажет браузеру, что вы хотите продолжить прослушивание событий в основном потоке, но компоновщик не должен останавливаться и может затем создать новый кадр композитинга.

document.body.addEventListener('touchstart', event => {
    if (event.target === area) {
        event.preventDefault()
    }
 }, {passive: true});

Проверить, можно ли отменить событие

Рис. 5. Веб-страница с некоторыми областями, прокручиваемыми только по горизонтали

Представьте себе такую ситуацию: на странице есть блок, и вы хотите ограничить его направление прокрутки горизонтальным.

Установить для целевого событияpassive:trueвозможность сделать прокрутку страницы плавной, но когда вы используетеpreventDefaultДля ограничения направления прокрутки может быть запущена вертикальная прокрутка. использоватьevent.cancelableЭто можно проверить и предотвратить.

document.body.addEventListener('pointermove', event => {
    if (event.cancelable) {
        event.preventDefault(); // 阻止默认的滚动行为
        /*
        *  这里设置程序执行任务
        */
    } 
}, {passive:: true});

Кроме того, вы также можете подать заявкуtouch-actionТакие правила CSS полностью блокируют обработчики событий.

#area { 
  touch-action: pan-x; 
}

Найдите цель события

Рисунок 6: Основной поток проверяет запись рисования и спрашивает, что рисовать по координатам x, y

После того, как компоновщик отправляет событие ввода в основной поток, первое, что запускается, — это обнаружение попаданий. Обнаружение попадания использует данные записи чертежа, созданные в процессе визуализации, для поиска содержимого по координатам, в которых произошло событие.

Уменьшить частоту отправки событий в основной поток

В предыдущей статье мы рассмотрели, как обычные дисплеи обновляются со скоростью 60 кадров в секунду, и как мы можем идти в ногу с их частотой обновления для создания плавной анимации. Для пользовательского поведения ввода частота передачи событий обычных устройств с сенсорным экраном составляет 60–120 раз в секунду, а частота передачи событий обычных устройств с мышью составляет 100 раз в секунду. Можно видеть, что входное событие имеет более высокую точность, чем экран дисплея.

Если рядtouchmoveТакие события отправляются в основной поток 120 раз в секунду, что может привести к чрезмерному обнаружению попаданий и выполнению сценария JavaScript. Напротив, наша частота обновления экрана намного ниже.

Рис. 7. Приток событий на временную шкалу кадра компоновки приводит к мерцанию страницы

Чтобы уменьшить количество вызовов, передаваемых в основной поток, Chrome объединяет эти последовательные события (например:wheel, mousewheel, mousemove, pointermove, touchmoveд.) и отложить до следующего разаrequestAnimationFrameперед отправкой.

Рис. 8. События объединяются и отправляются с задержкой на одной и той же временной шкале.

Все независимые события, такие как:keydown, keyup, mouseup, mousedown, touchstart, а такжеtouchendОн будет немедленно отправлен в основной поток.

использовать`getCoalescedEvents`Получить внутрикадровые события

Объединение событий помогает большинству веб-приложений создать удобный пользовательский интерфейс. Однако, если вы разрабатываете приложение для рисования, вам необходимоtouchmoveКоординаты события рисуют линию, тогда при попытке провести плавную линию некоторые координатные точки в интервале также могут быть потеряны из-за слияния событий. В этом случае вы можете использовать целевое событиеgetCoalescedEventsМетод получает информацию после объединения события.

Рис. 9. Слева — путь плавного сенсорного жеста, справа — ограниченный путь после слияния событий

window.addEventListener('pointermove', event => {
    const events = event.getCoalescedEvents();
    for (let event of events) {
        const x = event.pageX;
        const y = event.pageY;
        // 使用 x、y 坐标画线
    }
});

Следующие шаги

В этой серии статей мы много говорили о внутренней работе веб-браузеров. Если вы никогда не задумывались об этом раньше: почему Devtools рекомендует добавлять обработчики событий{passive:true}Варианты, почему иногда нужно добавить в скрипт тегasyncАтрибуты? Поэтому я надеюсь, что эта серия статей помогла вам понять, почему передача этой информации в браузере делает его быстрее и более гладким веб-опытом.

Использовать Маяк

Если вы хотите создать более удобный для браузера код, но ничего не знаете, вы можете начать с использованияLighthouseНачинать. Lighthouse — это инструмент, который может помочь вам просмотреть свой веб-сайт и предоставить отчеты о производительности страницы. Отчеты об эффективности сообщат вам, что было сделано хорошо, а что можно было бы улучшить. Просмотр списка отзывов также может дать вам представление о том, на чем сосредоточено внимание браузера.

Научитесь измерять эффективность

Для разных сайтов оковы их производительности могут быть разными, поэтому первоочередной задачей является настроить набор планов оценки производительности для вашего собственного сайта и выбрать лучшие технологические приложения. Команда Chrome DevtoolsКак проверить производительность вашего сайтаДля справки доступны соответствующие руководства.

Добавьте политику функций на свой сайт

Если вы хотите пойти дальше с дополнительными возможностями,Feature Policy— это новая веб-платформа, которая заботится о вас во время разработки. Включение политики функций может ограничить поведение приложения и уберечь вас от многих технических недостатков. Например, если вы хотите, чтобы ваше приложение не блокировало синтаксический анализ, вы можете запустить свое приложение в схеме синхронного сценария. включиsync-script:'none', сценарий JavaScript, вызвавший блокировку синтаксического анализа, будет заблокирован. Это гарантирует, что ваш код не блокирует синтаксический анализ, и браузеру не нужно думать о приостановке синтаксического анализа.

Суммировать

Когда я впервые встал на путь разработки, я почти сосредоточился только на том, как писать код и как повысить свою производительность. Конечно, это важно, но в то же время мы должны думать и о том, что браузер будет делать с написанным нами кодом. Современные браузеры всегда пытаются выяснить, как обеспечить лучший пользовательский опыт. Написание удобного для браузера кода, в свою очередь, обеспечивает дружественный пользовательский интерфейс. Нам предстоит пройти долгий путь, и я надеюсь, что мы сможем работать вместе над созданием более удобного для браузера кода.

Автор искренне благодаритAlex Russell,Paul Irish,Meggin Kearney,Eric Bidelman,Mathias Bynenes,Addy Osmani,Kinuko Yasuda,Nasko Oskovи Чарли Рейсу и др. за корректуру первого проекта этой серии.

Вам понравилась эта серия статей? Если у вас есть какие-либо комментарии или предложения для будущих статей, пожалуйста, оставьте их в разделе комментариев ниже или в Twitter@kosamariОставляйте свои ценные комментарии здесь.

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,товар,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.