Браузер и фронтенд-рантайм
Воркеры: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — изоляция потоков, стоимость structured clone и transfer, ловушки жизненного цикла service worker, гейт COOP/COEP, backpressure пула и ошибка с DOM в воркере.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает архитектурное решение под реальной нагрузкой — какой примитив подходит, чего он стоит и какой сбой он не способен решить — а не определение для заучивания.
Цель
Убедись, что выбираешь правильный воркер-примитив под задачу, рассуждаешь о стоимости передачи данных и распознаёшь ловушки жизненного цикла и изоляции, которые три примитива сами по себе не решают.
Викторина
Completed
Коллега переносит медленный ре-рендер React-списка в web worker, чтобы убрать джанк при скролле, и ничего не меняется. Почему и что реально помогает?
Heads-up Дело не в скорости — воркер буквально не может трогать DOM. Commit в React пишет реальные элементы, которыми владеет только главный поток. Вычисления переносятся, commit — нет.
Heads-up Нет полифила, дающего воркеру DOM. Ограничение архитектурное: у WorkerGlobalScope нет document. Выноси вывод данных, а commit оставляй на главном потоке.
Heads-up OffscreenCanvas рендерит пиксели, а не DOM-список элементов. Виртуализированный React-список — это DOM-узлы: commit остаётся на главном потоке, выносится только чистое вычисление.
Викторина
Completed
Ты делаешь postMessage с Float32Array на 40 МБ в воркер, и отправляющий поток всё равно замирает на ~40 мс ещё до старта воркера. Лучший фикс?
Heads-up JSON.stringify типизированного массива на 40 МБ намного медленнее structured clone и даёт куда большую строку — блокировка только усугубится.
Heads-up Суммарная стоимость клона — те же 40 МБ, но размазана на 40 task hop с 40-кратными накладными планирования. Transfer убирает копирование полностью.
Heads-up SAB тоже избегает копии, но он для конкурентного общего доступа и требует COOP+COEP. Если отправитель передаёт данные и больше их не трогает, transfer проще и без заголовков.
Викторина
Completed
Ты деплоишь новый service worker, перезагружаешь — и всё ещё старое поведение без ошибок. Новый воркер установился нормально. Что происходит?
Heads-up Браузер скачивает и устанавливает новый воркер; он просто не активирует его над открытыми страницами по умолчанию. Это состояние waiting, а не баг кэша.
Heads-up Ручной unregister никогда не нужен. skipWaiting() + clients.claim() передаёт контроль сразу; иначе это делает закрытие всех вкладок.
Heads-up Браузер перепроверяет sw.js при навигации и устанавливает новый воркер — он лишь ждёт активации. (Отдельно: отдавай sw.js с Cache-Control: no-cache, чтобы перепроверка не была устаревшей.)
Викторина
Completed
Многопоточный WASM-модуль тихо работает однопоточно в проде. typeof SharedArrayBuffer равно 'undefined', а crossOriginIsolated равно false; COOP: same-origin выставлен, а COEP — нет. Точный фикс и его цена?
Heads-up Размер памяти ни при чём — модуль деградирует, потому что SharedArrayBuffer не определён. SAB требует обоих заголовков изоляции; разблокирует его только недостающий COEP.
Heads-up Никакая ручка памяти не разблокирует SAB. Гейт — это пара кросс-доменной изоляции COOP/COEP, и только она.
Heads-up Transfer передаёт эксклюзивное владение — он не может питать потоки, которые все читают/пишут одну память, а именно это нужно pthread. Фикс — разблокировать SAB через COEP, а не заменять его.
Викторина
Completed
Кнопка запускает задачу обработки изображения на 400 мс. Пользователи жмут часто; вкладка спавнит по воркеру на клик, доходит до 400 МБ и убивается на мобиле. Какая правильная архитектура?
Heads-up Терминирование после каждой задачи выбрасывает воркер и заставляет платить свежие 5–20 мс старта на следующем клике. Постоянный пул амортизирует старт; спавн-и-убийство на задачу — нет.
Heads-up Куски сохраняют отзывчивость ввода, но 400 мс всё ещё конкурируют с рендером на одном потоке, и неограниченные клики копятся. Пул + backpressure выносит вычисление И ограничивает очередь.
Heads-up Потолок памяти мобилки не поднять, а реальный баг — утечка воркеров. Ограничь число воркеров пулом, а очередь — backpressure.
Викторина
Completed
Service worker перехватывает навигацию и отдаёт app shell cache-first. Ты выкатываешь баг в shell; часть пользователей бьётся в сломанный кэшированный shell на каждой перезагрузке без кнопки восстановления. Какая архитектурная защита?
Heads-up Обычные пользователи этого не сделают. Восстановление должно быть инженерным: network-first навигация плюс удалённый kill switch.
Heads-up Воркер с навигацией cache-first может отдать кэшированный HTML ещё до проверки обновления, так что skipWaiting не получит шанса. Network-first навигация и kill switch заставляют пройти путь обновления.
Heads-up У браузера нет понятия «сломанный» воркер — успешный сломанный кэш-ответ выглядит как корректный. Путь восстановления нужно строить заранее.
Итог
Сквозная линия юнита — одно дерево решений: выбери примитив под задачу — web worker для вычислений вне главного потока, service worker для сетевого прокси, SharedArrayBuffer для разделяемой памяти — потом заплати правильную стоимость транспорта (clone для мелких данных, transfer для крупного бинарного, SAB для конкурентного доступа за COOP+COEP). Вокруг этого повторяются три ловушки: воркер не может трогать DOM (поэтому мутацию DOM не вынести), service worker ждёт перед активацией и труден в восстановлении, когда ломает навигацию, а пулам нужен backpressure, иначе они текут. Ни один примитив не чинит DOM-боттлнек на главном потоке — эта работа остаётся там, где живёт DOM.