Pull to refresh

О том, как работают JavaScript таймеры

Reading time4 min
Views101K
Original author: John Resig
Чрезвычайно важно понимать, как работают JavaScript таймеры. Зачастую их поведение не совпадает с нашим интуитивным восприятием многопоточности, и это связано с тем, что в действительности они выполняются в одном потоке. Давайте рассмотрим четыре функции, с помощью которых мы можем управлять таймерами:
  • var id = setTimeout(fn, delay); — Создает простой таймер, который вызовет заданную функцию после заданной задержки. Функция возвращает уникальный ID, с помощью которого таймер может быть приостановлен.
  • var id = setInterval(fn, delay); — Похоже на setTimeout, но непрерывно вызывает функцию с заданным интервалом (пока не будет остановлена).
  • clearInterval(id);, clearTimeout(id); — Принимает таймер ID (возвращаемый одной из функций, описанных выше) и останавливает выполнение callback'a.
Главная идея, которую нужно рассмотреть, заключается в том, что точность периода задержки таймера не гарантируется. Начнем с того, что браузер исполняет все асинхронные JavaScript-события в одном потоке (такие как клик мышью или таймеры) и только в то время, когда пришла очередь этого события. Лучше всего это демонстрирует следующая диаграмма:



На этом рисунке довольно много информации, которую нужно усвоить, но понимание этого даст вам более глубокое понимание механизма работы асинхронности выполнения JavaScript. на этой диаграмме вертикально представлено время в миллисекундах, синие блоки показывают блоки JavaScript кода, который был выполнен. Например, первый блок выполняется в среднем за 18мс, клик мышью блокирует выполнение примерно на 11мс и т.д.

JavaScript может выполнять только одну порцию кода (из-за однопоточной природы выполнения), каждая из которых блокирует выполнение других асинхронных событий. Это значит, что при возникновении асинхронного события (такого как клик мышью, вызов таймера или завершение XMLHttp-запроса) он добавляется в очередь и выполняется позже (реализация, конечно же, варьируется в зависимости от браузера, но давайте условимся называть это «очередью»).

Для начала представим, что внутри JavaScript блока стартуют два таймера: setTimeout с задержкой 10мс и setInterval с такой же задержкой. В зависимости от того, когда стартует таймер, он сработает в момент, когда мы еще не завершили первый блок кода. Заметьте, однако, что он не срабатывает сразу (это невозможно из-за однопоточности). Вместо этого отложенная функция попадает в очередь и исполняется в следующий доступный момент.

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

После того, как первый блок JavaScript кода был выполнен, браузер задается вопросом «Что ожидает исполнения?». В данном случае обработчик клика мышью и таймер находятся в состоянии ожидания. Браузер выбирает один из них (обработчик клика) и выполняет его. Таймер будет ожидать следующей доступной порции времени в очереди на исполнение.

Заметьте, что пока обработчик клика мышью выполняется, срабатывает первый interval-callback. Так же как и timer-callback, он будет поставлен в очередь. Тем не менее, учтите, что когда снова сработает interval (пока будет выполняться timer-callback), то он будет удален из очереди. Если бы все interval-callback'и попадали в очередь пока исполняется большой кусок кода, это бы привело к тому, что образовалась бы куча функций, ожидающих вызова без периодов задержек между окончанием их выполнения. Вместо этого браузеры стремятся ждать пока не останется ни одной функции в очереди прежде чем добавить в очередь еще одну.

Таким образом, мы можем наблюдать случай, когда третье срабатывание interval-callback совпадает с тем моментом, когда он уже исполняется. Это иллюстрирует важную особенность: интервалы не заботятся о том, что выполняется в текущий момент, они будут добавлены в очередь без учета периода задержки между исполнениями.

Наконец, после того как второй interval-callback завершится, мы увидим что не осталось ничего, что JavaScript-движок должен выполнить. Это значит, что браузер снова ждет появления новых асинхронных событий. Это случится на отметке 50мс, где interval-callback сработает опять. В этот момент не будет ничего, что блокировало бы его, поэтому он сработает незамедлительно.

Давайте рассмотрим пример, который хорошо иллюстрирует разницу между setTimeout и setInterval.
   setTimeout(function(){
     /* Some long block of code... */
     setTimeout(arguments.callee, 10);
   }, 10);
   
   setInterval(function(){
     /* Some long block of code... */
   }, 10);

Эти два варианта эквивалентны на первый взгляд, но на самом деле это не так. Код, использующий setTimeout будет всегда иметь задержку хотя бы 10мс после предыдущего вызова (он может быть больше, но никогда не может быть меньше), тогда как код, использующий setInterval будет стремиться вызываться каждые 10мс независимо от того, когда отработал предыущий вызов.

Давайте резюмируем все сказанное выше:
— JavaScript движки используют однопоточную среду, преобразовывая асинхронные события в очередь, ожидающую исполнения,
— Функции setTimeout и setInterval принципиально по-разному исполняются в асинхронном коде,
— Если таймер не может быть выполнен в данный момент, он будет отложен до следующей точки исполнения (которая будет дольше, чем желаемая задержка),
— Интервалы (setInterval) могут исполняться друг за другом без задержек, если их исполнение занимает больше времени, чем указанная задержка.

Все это является чрезвычайно важной информацией для разработки. Знание того, как работает JavaScript движок, особенно с большим количеством асинхронных событий (что зачастую случается), закладывает отличный фундамент для построения продвинутых приложений.
Tags:
Hubs:
+51
Comments20

Articles

Change theme settings