Flash Site Architecture - один SWF против многих?

Question

Я собираюсь приступить к созданию сайта полностью во флэш-памяти (по запросу клиента) с использованием AS3, и мне было интересно узнать, как это сделать с точки зрения архитектуры приложений. Сайт не слишком большой - например, домашняя страница, постоянная навигация, 8 подразделов или около того, каждый со своим содержанием, но схожим дизайном между подразделами. В прошлом я использовал несколько SWF-файлов (скажем, один для навигации и по одному для подразделов) и загружал их динамически; теперь, однако, я рассматриваю возможность выбора другого маршрута и использования более объектно-ориентированного дизайна, с большим количеством классов и одним SWF (плюс предзагрузчик для его загрузки).

Существуют ли передовые практики для определения того, лучше ли динамически загружать меньшие swfs по сравнению со сборкой одного большого swfs? В AS2 я думаю, что загрузка множества небольших SWF-файлов имела больше смысла, но с более сильными объектно-ориентированными возможностями AS3 мне интересно, так ли это до сих пор.

Я знаю, что одним аргументом против дизайна с одним swf был бы дополнительный вес загрузки всего при начальной загрузке сайта, но я не думаю, что есть достаточно тяжелый контент, который здесь действительно вызывает беспокойство.

Есть мысли?

Answer 1

По моему опыту, в наши дни обычной практикой для (большинства) небольших и средних Flash-сайтов / приложений является архитектура с двумя SWF, оболочкой, которая загружает ядро. Иногда вы можете обойтись только одним SWF, который отслеживает собственную загрузку. Тем не менее, вы хотите загружать контент и ресурсы по требованию; изображения, видео, анимация и большой текстовый контент. Обычно они не должны быть встроены в основной SWF-файл, а загружаться по запросу пользователя. Основным преимуществом в любом случае здесь (один против двух SWF) является поддержание кода. Вам необходимо перекомпилировать основной SWF-файл только при обновлении приложения. В этой модели вы все равно можете загружать дополнительные SWF-файлы, содержащие анимации на временной шкале, если вы сохраняете код приложения в ядре.

Надеюсь, это поможет!

Answer 2

Никогда не существует одного способа «СКАЖАТЬ ВСЕ». Один проект может быть небольшим и подходящим для процедурного кодирования, так как другой может быть сложным, иметь много рук и, безусловно, сможет принять изменения, тогда ООП и шаблоны проектирования могут быть подходящим способом. Для производственного сайта, который наверняка будет разбит на разделы, абстрагирование каждого раздела в свой собственный FLA / SWF / DOCUMENT CLASS позволяет поддерживать ваш код в обслуживании. Если что-то в разделе about требует изменений, мы просто открываем, например, AboutDocumentClass.as, и вносим наши изменения. Давайте будем реальными, вы должны использовать SWFAddress сейчас, чтобы предложить глубокие ссылки; включение кнопок избранного, назад и вперед для флеш-сайтов. С надлежащей реализацией SWFAddress и хорошим предварительным загрузчиком можно получить очень плавный и компактный сайт, которым легко управлять и масштабировать.

При этом я считаю, что любой разработчик флэш-памяти производственного уровня должен знать о GAIA Framework. Всего за несколько минут вы получите полную структуру костей FLA, классов документов, SWF и т. Д. GAIA не только упорядочивает выходные файлы в интеллектуальной иерархии, но также настраивает SWFObject и SWFAddress, а также предварительный загрузчик.

Все это делается путем предварительного редактирования файла XML, который находится в папке bin, где бы вы ни выводили GAIA файлы нового проекта. Как только вы закончите редактирование XML и любых других элементов, вы говорите GAIA скаффолду: для каждого раздела, который вы учли в XML, создается FLA, класс документа с привязками к переходу на основе временной шкалы или реализация TweenLite / Max. в зависимости от вашего выбора перед лесами. Опять же, это занимает около пяти минут, и у вас есть кости вашего сайта с предварительной загрузкой, глубокими ссылками SWFAddress и переходами к переходам.

Результатом является аккуратный вывод файлов с использованием стандартного набора имен и соглашений, которые должны легко читаться и сокращать избыточность в десять раз.

Answer 3

Я думаю, что это сильно зависит от содержимого страниц и от того, сколько ресурсов вы уже включили в свой файл SWF.

Обычно мы просто делаем 2 swfs: один preloader и реальное приложение.

В приложения не включены текст или изображения. Все (кроме шрифтов) загружается динамически с сервера, так как контент является динамическим в большинстве наших случаев. Размер SWF сильно не увеличивается, вы добавляете еще 10 классов.

Трудно дать 100% прямой ответ на ваш вопрос, так как он зависит от веса контента (и от того, динамический он или статичный).

Answer 4

Это зависит от того, что вы подразумеваете под "меньшим".

Не разбивайте его на куски, которые слишком малы, иначе вы убьете себя из-за подключения. Не упаковывайте весь сайт в одну мамонтовую пачку, на загрузку которой уйдут недели.

Хорошее эмпирическое правило: если вы пытаетесь придумать броские или занимательные вещи для отображения, пока ваши пользователи ждут его загрузки, реструктурируйте вместо этого.

- MarkusQ

Answer 5

Ваше время загрузки может быть важным фактором, но дополнительный фактор, который необходимо учитывать, - это то, склонен ли «внешний вид» вашего SWF изменяться, в то время как базовый код остается прежним. Для нескольких «скиновых» игр, над которыми я работал, где игровой процесс был идентичен, но мы хотели иметь возможность изменить образ в соответствии с клиентами-спонсорами, мы разделили заголовок на два SWF-файла, один со всем исполняемым кодом (Application.swf), и другой со всеми художественными активами в нем (Library.swf). Это сработало хорошо, так как наша команда художников могла пойти и покопаться в Library.swf, и пока они поддерживали одну и ту же схему именования экспорта мувиклипа (и метки кадров в зависимости от обстоятельств), они могли создавать новые произведения искусства и просто менять свой «скин» "swf без необходимости перекомпилировать или знать что-либо об исходном коде.

Я думаю, что мы использовали LoadMovieClip () для обработки активов библиотеки, и, конечно, все клипы библиотеки нужно было пометить для экспорта в кадре 1 с соответствующими метками. Кроме того, весь наш код был в отдельных файлах AS, и, поскольку мы использовали AS2.0, мы включали фрагменты ролика в качестве членов классов, а не вставляли логику в сами фрагменты ролика. Это почти полностью отделило искусство от кода, за исключением нескольких базовых видеоклипов в Application.SWF, которые использовались для инициализации и обработки функций OnEnterFrame (), а затем передавали любые входные или тиковые функциональные возможности по цепочке дочерних элементов. объекты.

Прошло около года с тех пор, как я работал над этим, так что моя терминология может быть немного неправильной. Тем не менее, я надеюсь, что это полезно.

Answer 6

нет, я знаю о
(«Рекомендации по определению, лучше ли динамически загружать меньшие SWF-файлы») но я могу придумать вескую причину для загрузки всего контента в начале
что я обычно делаю

• я пишу весь код в одном место

• динамически загружать SWF с графикой

Answer 7

один аргумент против конструкции с одним swf будет дополнительным весом загрузки всего при начальной [...]

Вы захотите сохранить части, которые часто меняются, из тех, которые не отделяются, если они есть. Есть что-то под названием Ordered Creation и creationPolicy, чтобы позаботиться о времени загрузки. Но кроме этого все сводится к тому, что вам будет удобно поддерживать.