Timer против GC.
Все просто. Пока тикает экземпляр Timer, он не может быть удален сборщиком мусора (Garbage Collector).
Теорему доказывал на FP 10.0
Все было известно ранее.
Всего комментариев 16
Комментарии
21.02.2011 23:46
|
|
|
краткость — сестра таланта )
|
|
21.02.2011 23:48
|
|
|
Содержательно
 Насколько помню школьную программу, за каждой теоремой следует доказательство  Хотя на самом деле больше интересует, что именно подвигло на вынесение подобного вывода в блог. |
|
Обновил(-а) TanaTiX 22.02.2011 в 01:32
|
|
21.02.2011 23:57
|
|
|
TanaTiX, Вы правильно помните школьную программу.
Теорема настолько проста, что её доказательство я оставил на домашнюю проверку. Мораль, тем не менее, очевидна. Не оставляйте бесконечных таймеров (88 байт памяти каждый) с подписчиками (еще 64 байта на массив слушателей, итого 152 байта), если дорога память. |
|
Обновил(-а) dimarik 22.02.2011 в 00:39
|
|
22.02.2011 00:11
|
|
|
Знаем, плавали. Но спасибо, что ещё раз напомнил )
|
|
22.02.2011 00:21
|
|
|
|
Тигра, может быть ты сможешь доказать теорему?
|
|
22.02.2011 00:24
|
|
|
Собственно, таймер подписывается на «тикающий» поток в дебрях плеера и висит на нём в виде очередного таска. Поэтому и живёт.
|
|
22.02.2011 00:30
|
|
|
|
а что на счет setTimeout / setInterval ? Там тоже как то все непросто..
|
|
22.02.2011 00:38
|
|
|
|
Это методы. Как можно проследить за их "удалением"? )
|
|
22.02.2011 00:42
|
|
|
@i.o., setTimeout и setInterval - это обёртки вокруг таймера. так что внутренний таймер будет жив.
@dimarik, не так страшны байты таймера, как рутовый класс какой-нить подгруженной свф. |
|
22.02.2011 00:52
|
|
|
|
Цитата:
Тигра, может быть ты сможешь доказать теорему?
|
|
22.02.2011 01:09
|
|
|
|
Цитата:
Сообщение от TanaTiX
Хотя на самом деле больше интересует, что именно подвигло на вынесение подобного вывода в блог.
Вот неудачный пример "несостоявшегося" удаления подписанного таймера  Код AS3:class TimerExample { public function TimerExample() { const timer:Timer = new Timer(1e3, 10);// 10 раз, тикает раз в секунду. timer.addEventListener(TimerEvent.TIMER, this.handler_timer); timer.start(); } private function handler_timer(event:TimerEvent):void { trace( (event.target as Timer).currentCount ); // System.gc(); // Не помогает =) } } А так как мы не создавали ссылок на timer в поле класса, то теперь он должен быть доступен для сбора GC. Однако мы наблюдаем трейсы, что говорит нам о том, что объект таймера жив. "Классики" говорят нам о том, что мы не отписались от события TimerEvent.TIMER, поэтому получаем сообщения от "потустороннего" таймера. А я вам говорю, что работающий (тикающий) таймер ВООБЩЕ не удаляется. И удаление метода слушателя из списка диспетчера вообще не влияет на удаление самого диспетчера. Что является условием удаления объекта из памяти? Правильно, отсутствие на этот объект ссылок. Какие ссылки остались на таймер? Правильно, никаких. Почему он не удаляется? Правильно, он особенный. Упростим. Код AS3:class TimerExample { public function TimerExample() { const timer:Timer = new Timer(1e3, 10);// 10 раз, тикает раз в секунду. timer.start(); } } |
|
Обновил(-а) dimarik 22.02.2011 в 01:15
|
|
22.02.2011 01:24
|
|
|
|
@BloodHound
Цитата:
setTimeout и setInterval - это обёртки вокруг таймера. так что внутренний таймер будет жить
|
|
27.02.2011 15:08
|
|
|
Цитата:
Собственно, таймер подписывается на «тикающий» поток в дебрях плеера и висит на нём в виде очередного таска. Поэтому и живёт.
Хотя да, чем слушать этот внутренний тикающий поток, когда спрайт со слушателем снесен из памяти |
|
27.02.2011 18:18
|
|
|
|
А чем ENTER_FRAME отличается от каких-либо других событий?
|
|
08.03.2011 15:58
|
|
|
Другие события сложно распространять, если все ссылки на распространитель уничтожены
|
|
08.03.2011 18:45
|
|
|
|
Даже если ссылки на объект-источник события уничтожены, то до тех пор, пока он жив, будет распространение событий, покуда GC его не убьет окончательно. Только вот timer не убьется, пока он тикает. Вот и вся разница. Кстати, нашел у Мука этот неудачный пример с setInterval, который является оберткой над таймером.
|
Последние записи от dimarik
- Memory allocation на Vector.<IInterface> (07.05.2015)
- [Starling] Тормози меня плавно! (28.10.2014)
- [Starling идиотизмы] Об интерактивных событиях (02.10.2014)
- О типах исключений. (23.04.2014)
- Немного о Vector и ByteArray (28.03.2014)
