IntersectionObserver утечки памяти: почему колбэки не отпускают компоненты

hannadev

Вы когда-нибудь замечали, как приложение медленнеет после часа интенсивной работы? Браузер начинает лагать, а девелопер-тулы показывают, что память растёт как на дрожжах. Часто виноват обычный IntersectionObserver, который выглядит безобидно, но на самом деле держит мёртвые компоненты за горло.

Эта проблема встречается чаще, чем кажется. Особенно больно заметна на мобильных устройствах и в SPA, где компоненты монтируются-демонтируются тысячи раз. Давайте разбираться, почему это происходит и как это вообще возможно, если API выглядит логичным.

Как работает обычная утечка памяти

Сначала нужно понять механику. IntersectionObserver - это нативный браузерный API, который следит за видимостью элементов в viewport. Звучит просто, но дьявол, как всегда, в деталях.

Когда вы создаёте observer и передаёте ему колбэк, браузер держит ссылку на функцию. А функция - это замыкание, которое захватывает контекст компонента. Если компонент был демонтирован, но observer так и не отписался от элемента, замыкание продолжает удерживать ссылку на весь компонент целиком: его state, props, children, DOM-ноды - всё.

Это классическая ловушка: элемент удалили из DOM, компонент размонтировали, но garbage collector не может очистить память, потому что где-то есть живая ссылка. И эта ссылка - тот самый колбэк в observer.

Проблема усугубляется в полифиллах. Нативный IntersectionObserver в старых браузерах часто заменяют полифиллом, а те - о ужас - иногда используют массивы вместо WeakMap для отслеживания элементов. Сильные ссылки в массиве - это гарантированная утечка. Элемент никогда не будет удалён из памяти, пока он там лежит.

Основная причина: observer держит живую ссылку на элемент и его контекст через замыкание колбэка
Полифильные кошмары: старые реализации используют обычные массивы вместо WeakMap, создавая сильные ссылки
Каскадный эффект: один забытый observer может удерживать весь граф компонентов

Где утечка особенно заметна

Виртуальные скроллы - это масло в огонь. Представьте компонент, который рендерит огромный список, но показывает только видимую часть. Элементы постоянно добавляются и удаляются из DOM при скролле. Если каждый элемент использует IntersectionObserver и его правильно не отписать, вы создаёте тысячи мёртвых ссылок в памяти.

Мобильный Safari - ещё один популярный виновник проблем. На мобилах память ограничена сильнее, чем на десктопе, поэтому даже небольшая утечка становится заметной за пару минут интенсивного использования. Пользователь скроллит быстро, приложение начинает подвисать, и вот уже вкладка падает с изящным Chrome-овским “Aw, snap!”.

Есть конкретные фреймворки, которые усложняют ситуацию. Ionic, к примеру, использует IntersectionObserver для lazy-load картинок. Если вы используете их компоненты вместе с полифиллом и виртуальным скроллом - это идеальный шторм. Компоненты демонтируются, но observer так и не отпускает их.

Виртуальные скроллы: элементы удаляются из DOM, но остаются в памяти observer
Мобильный Safari: утечка становится критичной из-за ограничений RAM
Lazy-loaded компоненты: особенно опасны в сочетании с полифиллами

Стратегия без библиотек: правильный disconnect

Нативный фикс - это почти всегда правильный disconnect. Звучит банально, но часто о нём просто забывают. Правило простое: если вы создали observer для элемента, вы должны его отписать, когда элемент удаляется из DOM или компонент размонтируется.

В React это означает cleanup-функцию в useEffect. Не забудьте передать зависимость - сам элемент или его ref. В Vue это происходит в beforeUnmount. В vanilla JavaScript - это может быть событие, которое вы сами отправляете, когда элемент удаляется.

Но есть нюанс. Если observer следит за элементом, которого больше нет в DOM, это уже утечка. Полифиль может продолжить его отслеживать. Поэтому disconnect нужно вызывать до того, как элемент полностью удалится из памяти.

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      // Ваша логика
    }
  });
});

const element = document.querySelector('.my-element');
observer.observe(element);

// Критически важно! Отписываемся, когда элемент удаляется
window.addEventListener('before-element-remove', () => {
  observer.unobserve(element);
});

// Или в React:
useEffect(() => {
  const element = ref.current;
  observer.observe(element);
  
  return () => {
    observer.unobserve(element); // Cleanup!
  };
}, []);

Стратегия работает, но требует дисциплины. Легко забыть disconnect в одном месте, и вот уже у вас есть утечка.

Когда disconnect недостаточно

Иногда disconnect не помогает. Это может быть, если полифиль работает неправильно или если вы используете совсем старый браузер. В этих случаях нужна более хитрая стратегия.

Одна из них - не создавать сильные ссылки через массивы. Вместо этого можно использовать маркер-атрибут на самом элементе. Observer ищет элементы с этим маркером, не хранит их в памяти, а просто отслеживает через DOM-запросы. Это выглядит немного странно, но работает.

// Плохо - сильная ссылка в массиве
const observedElements = [];
observedElements.push(element);

// Хорошо - маркер на элементе
element.setAttribute('data-observed', 'true');
const observed = document.querySelectorAll('[data-observed="true"]');

Другой подход - избегать полифиллов, если возможно. Нативный IntersectionObserver поддерживается во всех современных браузерах. Если вам нужна поддержка IE11 - это отдельный разговор, но для остальных случаев лучше просто проверить в runtime и не использовать полифиль, если есть нативная версия.

Маркер-атрибут вместо массива: элемент не хранится в памяти, только отмечен
Проверка нативной поддержки: используйте полифиль только если нужен IE11
Явный контроль lifecycle: observer живёт только столько, сколько нужно

Таблица сравнения подходов

Подход	Плюсы	Минусы	Когда использовать
Правильный disconnect	Просто, надёжно, нативно	Требует дисциплины	Всегда, в первую очередь
Маркер-атрибут	Не создаёт сильные ссылки	Выглядит странновато	Если полифиль глючит
WeakMap вместо массива	Автоматическая очистка	Нужно писать свой полифиль	Для критичных приложений
Полный отказ от observer	Нет утечек	Нужна альтернатива	Если можно обойтись без

Ловушки в боевых условиях

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

Вторая - это косвенные ссылки. Вы вроде отписали observer, но колбэк ссылался на функцию, которая ссылается на объект, который ссылается на компонент. Garbage collector не может разрубить этот гордиев узел.

Третья - это внешние библиотеки, которые используют IntersectionObserver под капотом и забывают его отписать. Вы можете даже не знать, что используется observer, пока не откроете девелопер-тулы.

Четвёртая ловушка специфична для фреймворков. Vue может не вызвать cleanup-функцию, если компонент удалился неожиданно. React может закэшировать эффект неправильно. Svelte может не очистить контекст. Поэтому всегда проверяйте в Memory Profiler, действительно ли утечка исчезла.

Забытые условия: disconnect только в happy path, остальные пути оставляют ссылку
Косвенные ссылки через замыкания: колбэк -> функция -> объект -> компонент
Скрытые observer в библиотеках: вы не подозреваете, что используется
Фреймворк-специфичные баги: cleanup может не вызваться в нестандартных ситуациях

Инструменты для отладки

Чтобы найти утечку, нужны правильные инструменты. Chrome DevTools Memory Profiler - ваш друг. Возьмите heap snapshot, выполните действие (скролл, например), возьмите ещё один snapshot, и посмотрите разницу. Если детектед нечто, что не было до этого, это ваша утечка.

Фильтруйте по типам объектов. Ищите много экземпляров вашего компонента или много функций обработчиков. Если вы видите, что Observer-объектов стало в 10 раз больше после нескольких скроллов - это точно проблема.

В Firefox DevTools есть аналогичный Allocations profiler. Он работает немного иначе, но суть та же. Можно запустить профайлирование, выполнить действие, остановить и посмотреть, какие объекты удерживаются в памяти.

Для более точной отладки создайте минимальный репродукс. Возьмите только компонент с observer, удаляйте его 100 раз подряд и следите за памятью. Если память растёт линейно с количеством удалений - это 100% утечка.

Chrome Memory Profiler: heap snapshots и diff между ними
Фильтрация по типам: ищите ваши компоненты и Observer-объекты
Firefox Allocations: альтернатива для верификации
Минимальный репродукс: удаляйте компонент 100 раз и смотрите графики

Профилактика вместо лечения

Лучше не допустить утечку, чем потом её искать. Первый принцип - всегда пишите cleanup. Если вы создали обработчик события, observer или таймер, вы должны его очистить. Это должно быть автоматическим в вашей голове.

Второй принцип - избегайте полифиллов, если есть возможность. Современные браузеры поддерживают IntersectionObserver хорошо. Если вам нужна поддержка старых версий, проверяйте в runtime и используйте полифиль только когда нужно.

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

Четвёртый - изолируйте observer. Не заставляйте observer работать со сложной логикой в колбэке. Передайте observer только то, что ему нужно. Если колбэк ссылается на весь компонент, это плохая архитектура.

Автоматический cleanup: это рефлекс, не опция
Проверка поддержки нативного API: используйте полифиль только где нужно
Регрессионные тесты на утечки: создавайте и удаляйте 1000 раз в тесте
Минимальная логика в колбэке: observer должен знать только про видимость

О чём не говорят в доках

Одна деталь, которую часто пропускают - это поведение IntersectionObserver с detached элементами. Если элемент удалён из DOM, но observer всё ещё на него ссылается, браузер не может его переиспользовать. Это не столько утечка памяти в классическом смысле, сколько недополучение преимуществ garbage collection.

Есть и более тонкие моменты. Если вы создаёте много observer-объектов вместо одного с несколькими элементами, это может быть менее эффективно. Один observer может следить за несколькими элементами - это лучше для памяти и производительности.

И ещё: полифиль от какой-то случайной библиотеки может вести себя совсем иначе, чем нативный IntersectionObserver. Если что-то работает на десктопе, но ломается на мобиле, первое, что нужно проверить - это полифиль. Может быть, его вообще там не нужно.