Ростислав Сирык: PureMVC в картинках, доклад c UAFPUG-1

Молодца!

Да... больше про рефакторинг, чем про PureMVC, придется делать вторую часть :)

А по какому принципу идет подгрузка, как то квадратами.
И еще, какие используется приемы избавления от тормозов, при большом кол. объектов при драге и тд..
если это не секрет ;)

Это не секрет и малая часть этого рассказывалас собственно на встрече (но очень сжато: и даже так я не уместился в отведенное время).

Если коротко:

- Подгрузка идет слоями (19 шт), деленными на квадраты (я назвал их Patches, хотя стоило назвать Tiles), а квадраты поделены на собственно объекты.
- По этому же принципу идет рендеринг / показ / сокрытие подгруженного.

- Приемы избавления от тормозов:
1. Карта растрируется перед каждым перетаскиванием (тащим растр, а не вектор).
1.1 Переключается качество сцены для перетаскивания: stage.quality = StageQuality.LOW / HIGH
2. Интерактивные объекты карты (а таковым может быть любой) не работают с событиями -- за все события отвечает один объект, а именно сама карта.
3. Форсируется сбощик мусора для освобожения памяти.
4. Для всех addEventListener - используются weak references:
newPoint.addEventListener(MouseEvent.CLICK, onPointClick, false, 0, true);
5. Для всех спрайтов (объектов карты) по умолчанию отключены mouseEnabled, mouseChildren, buttonMode и tabEnabled -- равны false.
6. Для всех словарей также используюится Weak References -- new Dictionary(true);
7. Для отображения адресов используется собсвенная реализация Bitmap fonts -- все адреса это не текстовые поля, а именно генеренные картинки.
8. Прячутся выходящие за пределы экрана квадраты карты / объекты втутри квадратов карты.
9. Используются типы ints/uints вместо Number -- для оптимизации памяти.
10. Для отрисовки названий улиц (текст вдоль кривой) используются классы проекта Bezier.ru -- очень помогли, буквально спасли этот функционал.

Есть еще несколько оптимизаций, и я вижу, что надо писать отдельную статью и делать отдельный доклад о них.

Наверное, я так и сделаю )

> 1. Карта растрируется перед каждым перетаскиванием (тащим растр, а не вектор).
пробовал тоже так делать, но не реально растет используемая память (доходило до 300МБ и более).
мне приходилось применять cacheAsBitmap=true для каждого объекта, к родителю применить не мог так как его размеры быль больше 2880.
> 3. Форсируется сбощик мусора для освобожения памяти.
а это как?
> 8. Прячутся выходящие за пределы экрана квадраты карты / объекты втутри квадратов карты.
примерно тоже так делал. подписывал все объекты (dispatcher) и каждый драг опрашивал на hitTestObject экрана, то что true отображал и cacheAsBitmap остальное обратное. может можно как то оптимальнее?

>> 1. но не реально растет используемая память (доходило до 300МБ и более).

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

if(bmpMap != null) { bmpMap.dispose() };

каждый раз, когда "старая" битмапа тебе уже не нужна (у меня это происходит каждый раз при обновлении данных).

>> 3. Форсиование сборщика мусора:

Это "незаконный" хак с созданием двух одноименных локальных соединений (не люблю хаки):
private function tryRemoveGarbage():void
{
try
{
new LocalConnection().connect('pleaseRemoveGarbage');
new LocalConnection().connect('pleaseRemoveGarbage');
}
catch (e:*)
{
}
}

Кстати, у меня этот код оказался закомментированным -- то есть данная карта сейчас работает и без этого хака. Так что этот третий пункт можно уже вычеркнуть :)

> 8. Прячутся выходящие за пределы экрана квадраты карты / объекты втутри квадратов карты.

Я думаю, что голая математика оптимальнее. Я использовал такой подход: есть viewRect: Rectangle, описывающий видимую область экрана. А каждый квадрат карты имеет свой thisRect: Rectangle, описывающий его габариты. При перетаскивании карты проверяется на пересечение этих Rectangle'ов:

isEnabledInView = thisRect.intersects(viewRect);

если isEnabledInView == true, то как минимум visible = isEnabledInView; кроме этого, может потребоваться рендеринг объекта, если он еще не был загружен.

Из презентации понятно только то, что PureMVC - это типо круто.
И снова имел возможность помедитировать на Чисто Диаграмму (она у меня почему-то всё время ассоциируется с множеством Мандельброта).

Но вот что это такое, с чем его едят и с чего вообще начать - так и не понял.

С нетерпением жду следующую презентацию - "PureMVC для тупых".
Предлагаю сделать на флеше - чтобы не просто статичные кадры были, а всякие фигулинки летали, копошились и прыгали, чтобы продемонстрировать, что вообще куда идёт и кто кого использует.

// взрывающийся вертолет не обязательно

Dan, твоя критика совершенно уместна. К сожалению, в этот доклад я попытался слишком много втиснуть. По времени рассказ о рефакторинге занял большую половину, а еще нужно было рассказать о самой карте, так что на сам PureMVC осталась приблизительно треть времени. Хотя он нем я все же рассказал практически все -- но именно рассказал ("презентация оптимизирована под устный доклад").

Так что будет еще одна презентация. Не для тупых, а для заинтересовавшихся, и оптимизированная под собственно изучение вопроса.

Идея с анимацией хороша (я тоже об этом думал).

А диаграма была использована как коврик для медитации :)

> на сам PureMVC осталась приблизительно треть времени.
Рост, а тебя не затруднит подготовить полноценный доклад, ну чтоб монументально так? :)

ЗЫ: а то тема больно интересная! :)

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

Поэтому просьба: уточни, какие конкретно моменты монументальности тебя интересуют, я постаряюсь это _очень учесть при составлении монументального доклада. Именно твои соображения / вопросы интересуют оч сильно, так что пиши все, что придет в голову (плиииииз).

Ну да, меня как раз и интересует (наверное не меня одного) и сам рефакторинг и дисциплина разработки на PureMVC. Я имею ввиду следующее: трудозатраты по полному/частичному преобразованию внутренней структуры с ... на pureMVC; юнит-тестирование (FlexUnit, AsUnit) в частности, и вообще регрессионное тестирование; паттерны (вообще отдельно интересная тема); общие отличия ООП от других парадигм - к примеру, от аспектно-ориентированного программирования (Fling, AIoC) в сравнении; полный цикл разработки/рефакторинга... Ээээ, ну вот примерно это интересует. :) Ну это пожалуй будет супер-монументальный труд. :)