Как освободить ресурсы в jQuery? Есть ли подобная картина?
jQuery будет обрабатывать отсоединение обработчиков событий, которые были присоединены к элементам DOM, используя bind(). В результате должно быть намного меньше свисающих ссылок на элементы DOM, чем если бы разработчик отвечал за отключение самих обработчиков событий. Однако он делает это только тогда, когда страница выгружается (то есть событие unload объекта window). В это время он выполняет итерацию своего кэша событий (jQuery.cache) и удаляет прослушиватели событий из элементов, чтобы браузер мог сделать вывод, что на эти элементы больше нет ссылок, и освободить используемую ими память.
В jQuery отсутствует шаблон IDisposable. Для ваших собственных объектов вы должны сами распоряжаться ими. $(window).bind('unload', myCleanupFunction) хорошее начало для этого. Нет ничего плохого в том, чтобы просто реализовать метод dispose на ваших объектах и вызвать его из этой функции очистки.
В широком смысле, любому свойству объекта или глобальной переменной, которые могут / могут иметь циклическую ссылку, следует уделить особое внимание и уничтожить (delete или null будет достаточно ). Любые ссылки на элементы DOM должны быть удалены или обнулены. Любые ссылки на замыкания , которые закрываются вокруг элементов DOM, должны быть удалены или обнулены (обработчики событий являются распространенным источником этого шаблона). Если вы удаляете элементы из DOM, сделайте это с remove(), что автоматически очистит связанные с jQuery обработчики событий из ваших элементов.
Как / когда функция dispose вызывается библиотекой ASP.NET Ajax?
Как и jQuery, платформа ASP.NET AJAX подключается к событию unload объекта window для выполнения некоторой очистки ссылок. При выгрузке страницы вызывается Sys.Application.dispose и происходит следующее :
- Если вы создали функцию
pageUnload() в своем приложении, эта функция называется
- Он вызывает
dispose() для любого объекта, который вы зарегистрировали в приложении.
- Вызывает событие Application
unload.
- Он располагает экземпляром
ScriptLoader.
Компоненты, элементы управления и поведения ASP.NET AJAX по умолчанию автоматически регистрируются в объекте Sys.Application при создании компонента (в конструкторе Sys.Component). Все, что наследуется от IDisposable, автоматически регистрируется в рамках при создании экземпляра (и помещается в Sys.Application._disposableObjects).
Для объектов, которые реализуют IDisposable, вызывается метод dispose() вашего экземпляра (экземпляров) (как на сервере). Однако вы по-прежнему несете ответственность за фактическое освобождение ссылок (так же, как на сервере).
IOW вам do все еще нужно позаботиться о delete или null свойствах ваших объектов в методе dispose. Здесь применяются те же правила, что и в jQuery: любое свойство объекта или глобальная переменная, которые могут иметь / могут иметь циклическую ссылку, должны быть уделены особое внимание, ссылки на элементы DOM должны быть удалены или обнулены, ссылки на замыкания, закрытые вокруг элементов DOM, должны быть удалены или обнулены .
Однако, в отличие от jQuery, ASP.NET AJAX не будет автоматически удалять слушателей, с которыми вы связались Sys.UI.DomEvent.addHandler (он же $addHandler), когда страница выгружается 1 . Вы должны позаботиться, чтобы сделать это самостоятельно. Фреймворк предоставляет Sys.UI.DomEvent.clearHandlers(element) (он же $clearHandlers), чтобы сделать это легко, однако. Вы бы назвали это в вашей реализации dispose() и передали бы любые элементы, к которым вы прикрепили прослушиватели событий с каркасом.
IDisposable в клиенте подразумевается скорее как удобное место для размещения вашего кода «выгрузки», и как способ для кода самодокументироваться. Я подозреваю, что большинство людей не создают и не удаляют много объектов в течение срока службы приложения, а создают их один раз при загрузке страницы и уничтожают один раз на странице un load.
Должны ли мы беспокоиться об утечке памяти, если страница будет перезагружена через некоторое время?
Много усилий было потрачено на профилирование памяти в деревьях DOM, которые часто не выгружаются. В общем, вам не нужно слишком беспокоиться , если страница часто выгружается (это включает в себя переход пользователей на другие страницы вашего приложения). Если это долгоживущее приложение (например,
Gmail), вы должны быть очень осторожны в отношении утечек памяти. С долгоживущими приложениями сдерживание памяти не должно рассматриваться как преждевременная оптимизация, а очень четкая вероятность. Конечно, это не будет узким местом в производительности (в отличие от, скажем, ввода-вывода), но в современных приложениях DOM - слишком много зверя, чтобы позволить браузеру просто справиться с этим. Однако управление этим очень сложно, чтобы получить право.
1 Эта функция доступна в версии 4.0 в виде параметра autoRemove для Sys.UI.DomEvent.addHandler