Если кто не в курсе, то уже почти месяц как Intellij Idea 9 имеет возможность просмотра UML-диаграмм для ActionScript и Flex классов, а это значит, что у нас есть возможность анализировать код своих Flex проектов при помощи UML диаграм классов.
Если кто не в курсе, то уже почти месяц как Intellij Idea 9 имеет возможность просмотра UML-диаграмм для ActionScript и Flex классов, а это значит, что у нас есть возможность анализировать код своих Flex проектов при помощи UML диаграм классов.
В одном из разделов форума Flasher.ru был задан вопрос о том, каким образом нужно правильно удалять всех детей из объекта DisplayObjectContainer.
В ходе обсуждения были предложены следующие варианты (орфография и пунктуация авторов сохранены =):
Так какой же из вариантов самый оптимальный?
Внимание, правильный ответ. В плане быстродействия лидирует вариант номер три от пользователя wvxvw (761 миллисекунд против 1757, получаемых во втором варианте при 10000 итерациях):
Коментарии по этому поводу от Дениса «__etc» Коляко:
«Разница в том, что код wvxvw в цикле запрашивает геттер numChildren и удаляет ребенка с нулевого индекса.
Постоянный запрос геттера, как вызов функции, по определению должен быть медленнее обращения к локальной переменной. При работе с массивами удаление первого элемента занимает больше времени, чем последнего, из-за происходящего смещения индексов элементов.
Как выяснилось, в модели DisplayObjectContainer элемент на нулевом индексе оказывается последним в массиве элементов, а не наоборот. Именно поэтому удаление последнего элемента в display list медленнее, чем первого. Ну а геттер numChildren оказался таким же быстрым, как и декремент локальной переменной, вероятно в силу того, что декремент выполяется в несколько действий, с конвертацией и прочим.»
Посмотрим, как метод удаления всех детей реализован во Flex Framework:
По всей видимости, над этим фреймворком работали не такие уж и бестолковые программисты…
На этом все. Эффективного вам кода!
Предлагаю нам продолжить разговор о тонкостях работы с классом Vector, начатый ранее в этой статье.
В ходе перевода некоторых классов разрабатываемого мною в том числе приложения на использование класса Vector, возник вопрос: «Каким образом можно наполнять экземпляр вектора нужными нам элементами при его создании?».
В случае использования массива это делается достаточно просто. Можно прибегнуть к конструктору массива:
либо же к литералу:
У конструктора класса Vector есть всего два строго фиксированных параметра: первый указывает длину создаваемого экземпляра, второй отвечает за то, возможно ли изменение длины вектора со временем. Поэтому передать нужные нам элементы в конструктор класса Vector у нас не получится. Литерала вектора не существует. Обратившись к документации по этому классу, максимум, что мы можем найти — это метод concat(...args):Vector.<T>, присоединяющий переданные аргументы к объекту. Т.е. следующий код:
может превратиться в:
Однако если взглянуть на документацию более внимательно, то мы можем найти там глобальную функцию Vector, принимающую в качестве параметра исходный массив или вектор, элементы которого будут являться элементами будущего вектора, и возвращающую этот новый вектор. Синтаксис этой функции в точности повторяет синтаксис конструктора класса Vector, однако оператор new в этом случае использовать не нужно. И наш код превращается в следующий красивый и краткий кусок кода:
Вот такие тонкости. Удачного вам программирования!
См. также:
Возрадуйтесь начинающие флэшеры и флексеры! Вышла в свет новая книга Колина Мука на русском языке «ActionScript 3.0 для Flash. Подробное руководство» (страница книги на Books.ru).
Меня немного смущает перевод названия книги, который в оригинале звучит как «Essential ActionScript 3.0», что буквально означает «Основы ActionScript 3.0». Будем надеяться, что такой не совсем корректный перевод названия книги — это просто маркетологический ход, призванный повысить продажи, и в целом перевод основного содержимого книги будет на высоте, как и как и переводы двух прошлых книг Колина.
Лично я уже заказал эту книгу для своей коллекции. =)
Майк Чемберз опубликовал полный список нововведений во Flash Player 10 API. Кому интересно, тот может ознакомиться с этим списком на сайте Майка. Хотя меня мучают подозрения, что он не совсем полный...
Кроме того, Майк задает своим читателям вопрос, получивший просто огромное количество откликов: «Используете ли вы ActionScript 2 или 1? И если да, то почему?». Мне стало тоже интересно, кто-нибудь из читателей этого блога программирует еще на прошлых версиях ActionScript? И, в противоположность, начал ли кто-нибудь использовать в своих приложениях новшества Flash Player 10?
От себя добавлю, что мы в разрабатываемом приложении, о котором будет рассказано на ближайшем RAFPUG 11, решили заранее ориентироваться на Flash Player 10, поскольку не смогли отказаться от таких вкусностей, как FileReference.load() и FileReference.save(), от класса Vector, более продвинутого рендеринга текста, ну и, конечно, от интеграции движка Alternativa 3D с этой версией плеера.
Признаюсь честно, в последнее время я писал статью о том, как разрабатывать Flex-приложения при помощи InlelliJ IDEA. Но сейчас я сомневаюсь, стоит ли мне продолжать, поскольку понимаю, что написать статью, наполненную большей любовью к этой среде разработки, чем ее написал пользователь Develar на Хабрахабре, в настоящий момент я не смогу. =)
Поэтому сейчас я отсылаю вас к статье «Разработка на Flex в IntellliJ IDEA с использованием maven». Не жалейте на знакомство со статьей свое время — IDEA восполнит его вам сторицей. Ну а сам я все же сконцентрируюсь на неосвещенных в статье вопросах: интеграции с Apache Ant, рефакторингах, автогенерации кода и горячих клавишах.
С любезного разрешения Майка Чемберза (Mike Chambers), публикую перевод на русский язык его статьи «Using Vectors in ActionScript 3 and Flash Player 10». Дальнейшее повествование идет от имени Майка.
Одной из новых возможностей, появившихся в Flash Player 10 Public Beta, является включение в эту версию плеера нового класса Vector. По существу, класс Vector является массивом, но в дополнение к функционалу массива он отслеживает тип хранимых элементов данных, и поэтому может обеспечить (иногда довольно существенный) прирост производительности по сравнению с обычным массивом.
Пользоваться классом Vector так же просто, как и пользоваться классом Array. Фактически, класс Vector содержит все те же методы, что и класс Array, и главным отличием между ними является то, как вы создаете экземпляры этих классов.
Для примера, вот так вы инстанцируете экземпляр массива:
ну или вот так:
А это пример создания экземпляра вектора, который будет хранить объекты с типом int:
Точно так же, как и в случае использования массива, вы можете инстанцировать экземпляры вектора конкретного размера, передавая длину в качестве первого необязательного параметра конструктора:
Кроме того, конструктор вектора имеет второй необязательный аргумент в виде булева флага, определяющего должен ли текущий экземпляр Vector быть фиксированного размера (true), либо же его длина в дальнейшем может изменяться (false). По умолчанию этот параметр имеет значение false. В дальнейшем его можно изменить обратившись к свойству fixed экземпляра класса Vector:
Имейте в виду, что если свойство fixed установлено в true, то далее вы уже не можете вызывать методы изменяющие длину массива, например, методы pop(), push(), shift() и т.д.
Кроме того, Vector следит и за соблюдением единообразия типа хранимых в нем переменных, в то время как в массиве можно хранить элементы разных типов:
Однако в этом случае у вас возникнут ошибки на этапе компиляции:
Если не принимать во внимание эти различия, то работа с классом Vector очень похожа на работу с массивом. API обоих классов абсолютно идентичные. Кроме того, так же как и в случае использования массива, вы можете получить доступ к элементам Vector-а, обратившись к ним непосредственно по их индексу:
И последнее, что нужно иметь в виду при работе с векторами, заключается в том, что Vector представляет собой вариант «уплотненного» массива. Фактически, это означает, что все элементы, содержащиеся в экземпляре класса Vector должны иметь какое-либо значение или быть равными null. Например, при использовании массива вы можете свободно сделать следующее:
Однако, если вы попробуете проделать то же самое с экземпляром Vector, то вы получите ошибку RangeError на этапе исполнения:
Чтобы исправить это, зададим вектору длину при его создании:
Ниже приведен пример, который показывает разницу в производительности при работе с вектором и массивом, каждый из которых содержит по миллиону чисел. Имейте в виду, что представленный ниже код — это только один специфичный тест, и повышение производительности в случае использования класса Vector в каждом конкретном приложении может быть как больше, так и меньше.
На моей машине вывелись следующие значения:
Что является довольно значительной разницей, с учетом простоты теста (выборка значения элемента по индексу).
Вы можете найти больше информации о классе Vector, обратившись к документации по Flash Player 10 Beta, а так же к информации о Flash Player 10 на Adobe Labs.
См. также:
С любезного разрешения Колина Мука (Colin Moock) публикую свой вольный перевод его статьи «Things you must do before unloading a SWF file». Дальнейшее повествование пойдет от имени Колина.
Если вы загрузили SWF-файл, содержащий ActionScript 3, во Flash Player 9 и теперь хотите удалить его из памяти, то вы должны перед этим его деактивировать. Иначе этот файл так и будет продолжать занимать ресурсы, и в некоторых случаях не подвергнется удалению Garbage Collector-ом.
Ниже представлен неофициальный список действий, проведение которых необходимо для деактивации SWF файла:
Loader, URLLoader, Socket, XMLSocket, LocalConnection, NetConnection и NetStream.Event.ENTER_FRAME и событий клавиатуры).clearInterval().Timer вызовом метода Timer.stop().Помните, что представленный список по определению не является полным, так как он не был официально утвержден Adobe и, следовательно, не может являться исчерпывающим. Если вы знаете еще действия, которыми можно пополнить этот список, то присылайте их мне не почту (пользователь colin, домен moock.org).
Что касается Flash Player 10, то там вышеперечисленные действия можно выполнить автоматически вызовом метода unloadAndStop() класса Loader.
Для дальнейшего ознакомления с этой темой, смотрите вторую главу моей статьи «The Charges Against ActionScript 3.0», опубликованную на сайте Inside RIA и статью Гранта Скиннера «Additional Information on Loader.unloadAndStop()».
Не секрет, что ActionScript 3 не поддерживает перегрузки методов. Иногда это может привести к затруднительным ситуациям. Например, у нас есть два интрефейса, в которых объявлены одноименные методы, но с различной сигнатурой, и требуется создать класс, который должен реализовывать оба этих интерфейса. При попытке реализовать классом оба таких интерфейса мы совершенно законно столкнемся с ошибкой. Чтобы быть более конкретным приведу пример.
У нас есть два интерфейса IHuman и IMonster, в которых объявлен метод kill, только в первом случае метод в качестве аргумента принимает IMonster-жертву, а во втором — в роли жертвы должен выступать IHuman. При попытке создать класс Werewolf, который должен являться как и IHuman, так и IMonster мы окажемся в затруднительной ситуации, поскольку как я уже сказал ранее ActionScript 3 не поддерживает перегрузки методов.
В сложившейся ситуации у нас есть два варианта наших действий. Первый вариант предполагает изменение условий задачи, проще говоря мы можем переименовать методы, например killMonster для IHuman и killHuman для IMonster. Если у вас есть возможность пойти по этому пути, то можете не колебаться и смело выбирать его. Второй вариант, исходит из того, что вы не можете изменить имена методов. В этом случае, можно создать два отдельных класса, каждый из которых реализует необходимый интерфейс и использовать их вместе в составе третьего класса Werewolf. Здесь есть маленькая тонкость. Как между двумя этими классами расшарить внутреннюю логику Werewolf. Например, в методе kill этих классов вызвать приватный метод prepareToKill класса Werewolf. В этой ситуации я для себя нашел небольшой workaround — создание класса оборотня.
Для начала нам потребуются выше обзначенные интерфейсы.
Переходим к созданию класса Werewolf, содержащий в себе как класс реализующий IHuman, так и класс реализующий IMonster. Оба эти классы возможны только как составляющие Werewolf, соответственно их можно смело сделать вложенными, то есть объявить за скобками пакета в том же файле, что описывает собственно сам класс Werewolf.
И так мы имеем класс Werewolf, который может быть использован как IMonster, так и IHuman, для этого необходимо вызвать соответсвующий метод. Теперь вернемся к условиям, а именно, кроме реализации классов Monster и Human, нам требуется расшарить для них внутреннюю логику Werewolf. Так как эти классы могут существовать только в составе Werewolf мы могли бы смело дать им возможность вызывать приватные методы Werewolf. Однако, как мы знаем приватный метод, он на то и приватный, чтобы быть доступным только в рамках своего класса. Но нам никто не мешает создать собственную область видимости. А помогут нам в этом пространтсва имен. Чтобы создать неймспейс, видимый только в пределах наших классов, объявим его как и классы Monster и Human вне пакета. Таким образом методы, объявленные в этом неймспейсе, могут быть вызваны, любым из наших трех классов.
Таким образом, мы получили метод prepareToKill видимый только в пределах наших классов. Аналогичным образом можно расшарить и прочую логику. На этом можно было бы и остановиться, но есть один момент, каждая из составляющих как Human, так и Monster не являются Werewolf-ом. Решается это достаточно просто. Введем интерфейс IWerewolf, где и обозначим соответствующий API.
Теперь остается только реализовать этот интерфейс всеми тремя классами.
Проверим что у нас получилось.
Напоследок напомню, при возможности изменить условия, а именно устранить конфликт путем смены сигнатуры методов, не раздумывайте и выбирайте этот вариант. Описанный прием является скорее крайней мерой и способом сделать код менее прозрачным.
О выходе Flash Player 10 beta aka «Astro» не писал только ленивый и «Garbage Collector». Однако последний, из этих двух, все же решил исправиться.
Одной из «фишек» нового плеера стала возможность создавать свои собственные графические фильтры. Вот, собственно, об этом сегодня и пойдет речь.
Создание собственных фильтров стало возможно благодаря новому продукту от Adobe под названием Pixel Bender Toolkit (раннее известного как Adobe Image Foundation Toolkit). Pixel Bender Toolkit использует собственный C-подобный язык описания алгоритмов преобразования изображений. Что ж, давайте попробуем создать собственный фильтр и применить его в нашем ActionScript 3 приложении.
Прежде чем приступить к нашему знакомству с обозначенной темой, нам придется немного подготовиться. Во-первых, нам потребуется сам Pixel Bender Toolkit для написания фильтра и его компиляции. А во-вторых, нам потребуется настроить свою среду разработки. Приступим.
Инструкцию по скачиванию и установке Pixel Bender Toolkit можно найти на Adobe Labs. О том, как настроить свою среду разработки, можно почитать следующие статьи:
Для первого знакомства, я думаю, стоит взять простой эффект — сепия. Так как пока мои навыки написания собственных фильтров на Pixel Bender не велики, я решил воспользоваться готовым решением (правда код подвергся небольшой корректировке в свете некоторых изменений в языке).
<languageversion : 1.0;>
kernel Sepia
< namespace: "popforge::ImageProcessing";
vendor: "Joa Ebert";
version: 1;
description: "A good looking sepia filter using Y transform";
>
{
input image3 source;
output pixel3 result;
void evaluatePixel()
{
pixel3 color = sampleLinear(source, outCoord());
float y = 0.299 * color.r + 0.587 * color.g + 0.114 * color.b;
float r = min(1.0, y + 0.19);
float g = max(0.0, y - 0.055);
float b = max(0.0, y - 0.22);
result = pixel3(r, g, b);
}
}
И так у нас есть исходный код фильтра. Скомпилируем его.
Запускаем Pixel Bender Toolkit и создаем новый фильтр (File → New Pixel Bender Kernel Filter). Теперь в окно редактора вставляем исходный код и компилируем его (File → Export Pixel Bender Byte Code for Flash). Полученный файл с расширение .pbj мы и будем использовать в нашем приложении.
Для демонстрации применения фильтра мы напишем простое приложение. В его задачи будет входить загрузка изображения, его отображение, загрузка фильтра и показ этого же изображения, но уже с применением фильтра. Дальше подробно расписывать не буду, ибо вся суть в коде. Остановлюсь лишь на некоторых моментах. Для применения фильтра нам потребуется новоиспеченный класс flash.display.Shader, который должен получить фильтр в бинарном виде. Результат применения фильтра мы отрисовываем в экземпляре Shape с помощью метода graphics.beginShaderFill.
Необходимость в загрузке фильтра во время исполнения иногда может вызвать некоторые трудности. Но мы можем это легко обойти, включив байткод фильтра в приложение на этапе компиляции (как это делается, можно узнать из статьи «Включение файлов в SWF в виде байтовой последовательности»). В этом случае наше приложении будет выглядеть так:
Исходный код проекта можно скачать здесь.
Новые возможности Flash Player 10 вскоре сильно изменят внешний вид будущих flash-приложений. И с одной из таких возможностей мы уже познакомились. Замечу, мы рассмотрели пример применения простого фильтра, не требующего параметризации. В остальных случаях читайте документацию (она идет в комплекте с Pixel Bender Toolkit), пишите фильтры и делайте мир лучше (жду русскоязычный блог про Pixel Bender). Что ж, на этом на сегодня все. Надеюсь вам было интересно.
Напоследок, несколько полезных ссылок: