Ситуация. Я работаю над довольно прилично сложным одностраничным Backbone-приложением, которое потенциально может работать в течение 8-12 часов. Из-за этого необходимо обеспечить, чтобы приложение не просачивалось и не имело репутации сбоя после X часов или резко сократилось.
Приложение: приложение построено на Backbone (mv *), Zepto (похоже на jquery), Curl (amd loader) и Mustache (templating).
Проблема. Я только что победил слушателей событий. Кажется, что сборщик мусора отлично справляется с этими парнями, , но DOM Node Count не перестанет лазать.
Вопросы:
- Есть ли способ утилизации узлов DOM, чтобы они были правильно собраны мусором или это DOM Node Подсчитайте текущую сумму, которая никогда не уменьшится?
- Кто-нибудь знает какие-либо из этих фреймворков, чтобы плохо обрабатывать узлы DOM? Возможно Усы?
- Является ли DOM Node Count даже надежной цифрой?
Я действительно просто ищу начало своего приключения, чтобы остановить рост DOM Nodes. Любая помощь или руководство были бы с благодарностью оценены (и соответственно поддержаны).
Я предположил, что после того, как прослушиватели событий были правильно удалены, DOM Node Count будет просто управлять собой, но это, похоже, не так.
Испытания
- Первый тест: 6,8 минуты, 110 000 узлов DOM.
Изменить. Без записи по временной шкале я повторяю один и тот же script случайным образом перепутал ссылки и сделал снимок экрана с отметкой в 7 минут. После того, как GC прошел, у меня были эти результаты.
- Второй тест: 7.1 минут, 141 000 узлов DOM (без записи временной шкалы)
Изменить: после исправления:
После обновления магистрали и использования listenTo и stopListening везде
- 7 минут: 6,926 узлов DOM (см. примечание ниже).
- 20 минут: 6 000 узлов DOM, 20 слушателей событий, память 20 МБ.
- 25 минут: 11 600 узлов DOM, 44 прослушивателя, память 21,7 МБ.
- 28 минут: 9 000 узлов DOM, 22 прослушивателя событий, память 21,7 МБ.
- 30 минут: 13 700 узлов DOM, 123 прослушивателей событий, память 21.7.
- 31 минута: 7 040 узлов DOM, 30 прослушивателей, память 21.7.