войти зарегистрироваться

Flash-платформа whois

индекс
142,26

Уменьшаем размер Flex приложения отвязывая фреймворк

Flex приложение весит 500кб? Легко исправить!

Данная статья посвящается тому, как уменьшить размер Flex приложения не пользуясь никакой магией.
А конкретно — что такое RSL и что это дает.
Ну и пара слов про забивание гвоздей боингами.



Для начала в очередной раз определимся с понятиями Flex SDK и Flex приложения.

Flex SDK/Flex Builder/Flex приложение


Flex SDK — это open-source framework, написаный на языке Actionscript 3 для создания Rich Internet Applications
Link: http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK

Flex Builder — IDE для разработки на Actionscript 3, очень тесно соприкасающееся с Flex SDK.
Links:
Win/Mac: http://www.adobe.com/products/flex/
Linux: http://labs.adobe.com/technologies/flex/flexbuilder_linux/

Flex приложение — приложение, использующее Flex SDK.
Примеры Flex приложений можно посмотреть на том же flex.org

Сколько весит пустое Flex приложение


Создав пустое Flex приложение можно с удивлением заметить, что в publish версии оно весит порядка 176 килобайт.
Это происходит благодаря тому, что Flex приложение включает в себя часть Flex SDK.

<лирическоеОтступление>
Кстати, какие именно классы были включены в swf при компилляции и сколько они весят можно посмотреть в size report-е. Для этого достаточно добавить в свойства компилляции "-link-report size.xml". Например вот так:
Link report

И в папке bin-debug появится файл size.xml. Вид слабочитаем, но тем же excel-ем его можно обработать и просматривать.

Этот параметр так же можно выставлять и не для Flex приложений.
</лирическоеОтступление>

Уменьшаем размер, отвязывая framework


Сначала результат:
После достаточно простых действий приложение будет весить… 70 килобайт.
(не спешите совсем уж сильно радоваться и дочитайте до конца)

В эти 70 килобайт войдет только маленькая часть Flex SDK, которая занимается загрузкой framework* + ваш код.
(* — версия)

И этот размер не будет зависеть от того, какие Flex компоненты вы используете, а какие — нет.

Как это сделать:
Сделать это очень просто — в свойствах проекта выставляем Framework linkage — Runtime shared library (RSL). Не забывая оставить галочку «Verify RSL digest».
Enable rsl
Framework linkage указывает, как будет использоваться framework — либо он будет «встроен» в swf, либо будет жить отдельно.
Verify RSL digests дает плюшку ввиде кроссдоменности.

«Но ведь все равно будет грузиться еще какой-то framework»


Вот тут самое интересное. Этот файл содержит в себе львиную долю Flex SDK. И загрузится он всего один раз. C любого домена.
То есть если сферический Вася Пупкин откроет Flex приложение на сайте site.smth и в этом приложении использовалась отвязка фреймворка через RSL, то эта версия фреймворка у него прокешируется.
И если он откроет какое-то другое Flex приложение на другом сайте, использующее эту же версию фреймворка через RSL, то Flex SDK уже грузиться не будет.

Детали по RSL в хелпе:
http://livedocs.adobe.com/flex/3/html/help.html?content=rsl_09.html

Ложка дегтя


Пользователю, если он открывает Flex приложение, использующее например Flex SDK версии 3.2.0.3958 через RSL первый раз — все равно прийдётся ждать загрузки.
Причем достаточно долго. Размер подписанного sdk — около 550 килобайт.

Здравый смысл


Не стоит использовать Flex SDK там, где он не нужен.

Или вы делаете Rich Internet Application, или утилитку для загрузки файлов на сайт. Если для второго случая использовать Flex SDK — это забивание гвоздей боингом.
+42
18 января 2010, 10:19
AlDev

комментарии (40)

    • fwm
    • fwm
    • 18 января 2010, 10:31
    • #
      • +4
    на Flex SDK и Flex Builder, что в начале, хорошо ссылки поставить, чтобы я вот заинтересовался и сразу скачал.
    • добавлено, спасибо ;-)
  • >> Не стоит использовать Flex SDK там, где он не нужен.
    Вот это самое главное!

    Спасибо за статью…
  • А еще бы сразу небольшой обзор, что использовать на маке для программирования на Flex. У вас же мак правда? :)
    • Да.
      Adobe Flex Builder и использовался.
  • «Если для второго случая использовать Flex SDK — это забивание гвоздей боингом. ». Ну сколько можно уже. Главная хабра весит 680 килобайт. О Боинг!
    • Эта задача легко решается без Flex SDK. Зачем он для такого случая?
      • С Flex SDK эта задача решается проще и быстрей. Обычно задачу важности размера перед скоростью разработки решает менеджер проекта. Важность размера приложения крайне переоценивается разработчиками. Конечному юзеру с мегабитным интернетом вообще пофигу что у него на 4 секунды дольше будет загружаться аппликуха, а эстетствующий процент легко перекроет траффик с рекламы, купленный на сэкономленные с месяца лишней разработки денег. А там уже, когда проект окупится можно будет подумать о том, что-бы его отрефакторить, но обычно на это все пофигу уже и делается новый проект, что еще раз подтверждает мысль о том, что эти 500 килобайт никому не впились.
        • такое можно говорить когда объем посещений не превышает тысяч 10 уников в день а пользователь сайта не приносит этому сайту окупаемость

          на больших проектах снижение времени загрузки сказывается очень серьезно
          секунда например это очень много, если флэш компонент при этом не баннер, а какая то часть функциональности, это может процентов на 5-10 увеличить посещаемость, что для этих самых больших проектов очень существенно
          • Я понимаю, что начиная проект все мы надеемся на то, что сделаум гугл или хотя-бы захудалый яндекс, и тогда при новых 10 миллионах пользователях ухмыльнемся со словами «ха, хорошо, что я сэкономил тогда 10 килобайт, серваки выдержат еще 20 лямов уников не поперхнувшийсь», но увы.
            • ну у нас на поддержке есть несколько проектов с посещаемостью более полумиллиона уников в день
              и очень много — с посещаемостью от 30 тысяч уников в день

              увеличение скорости загрузки даже этих небольших — от 30 тысяч уников и выше проектов принесло очень существенные результаты

              юзер существо такое, у него очень много подсознательного
              большинство не реагирует «вот, сайт стал грузится на 200 мс быстрее», но эффект однозначно есть
              • «А там уже, когда проект окупится можно будет подумать о том, что-бы его отрефакторить» Я писал об этом. Если проект запущен, работает, приносит деньги, то пожалуйста, пилим флеш аппликуху на меленькие кусочки и подгружаем юзеру в фоновом режиме в кеш браузера. Параллельно делаем полноценный клиент с системой апдейта. Но это уже стадия продакшна, а при непроверенной концепции и 2х рублях за пазухой загоняться по поводу пары сотен килобайтов смысла нет. Самое главное, что-бы юзер крестик не нажал.
                • теперь согласен ;)

                  просто хорошо бы если бы это было сразу указано вот в этом комментарии
                  "«Если для второго случая использовать Flex SDK — это забивание гвоздей боингом. ». Ну сколько можно уже. Главная хабра весит 680 килобайт. О Боинг!"

                  ничего личного
                  ;)
                • Я вот, к сожалению, совсем недавно до этой мысли дошел — в начале проекта главное скорость, а пилить можно уже тогда, когда подтверждается полезность проекта.

                  Сейчас думаю, что довольно неплох должен быть такой процесс разработки: быстро-быстро фигачим рабочий прототип, забивая на качество кода, объем и т.п., потом добавляем туда функционал — на этом этапе получаем четкое понимание, во-первых, полезности проекта, во-вторых, того, что нужно в плане архитектуры. И тут уже бац — такой рефакторинг, все приводим к красивому коду (это стало возможно, так как все поняли, чего хотят), и дальше фигачим красиво :)
                  • «Временное решение, так у нас все проекты из временных решений состоят» :)
        • Конкретно эта задача решается проще и быстрее как раз без Flex SDK.
          И все таки каждой технологии — свое применение. Нельзя пихать Flex везде и всюду.
          • По прошлому топику человек просто пробовал Flex на примере загрузчика фотографий для вконтакта. Т.е. как домашнее задание. Если делать боевую версию, то согласен с тем, что для вконтакта загрузчик на флексе не приемлим. Просто так загружать каждому юзеру лишних 250 килобайт довольно дерзкая и даже глупая идея.
      • Это общий пример оптимизации.
  • Ненавижу линкование всего и вся во флешевое приложение, я преверженец минимализма и оптимальности.
    Пример, вот видео сетевой игры, клиентсукую часть которой я делал, SWF весит всего 100Кб. Конечно, у меня еще подгружаются SWF-либы с графикой, музыкой и т.д. Но логика умещена в 100Кб. Пока поиграть не получится, т.к. сейчас приватная версия, да и на просторах России иметь пинг 30-40 — непозволительная роскошь.
    • Хабр съел мой тег-ссылку
      www.youtube.com/watch?v=y7vezqaiZ5E
      • А зачем так быстро? Реальный перфоманс бы показали — было бы интереснее
        • Не я показывал :) Раза в полтора-два увеличена скорость.
  • Джавистам должна понравиться IDE, так как она базируется на eclipse и её можно встроить в уже настроенную сборку того же eclipse for java ee
    • Так это один IDE (Eclipse IDE), он один для всех, все остально — плагины.
      • И с новым релизом Flex Builder будет переименован во Flash Builder, а Flex Framework так и останется.
        • И flash builder можно попробовать уже сейчас на labs.adobe.com
          И стал он в плане работы с классами похож на Eclipse for java

          Ну и да. Flex builder можно поставить как плагин к еклипсу.
          • Я использую FDT 3, это тоже плагин для Eclipse.

            >> И стал он в плане работы с классами похож на Eclipse for java
            Это как? Синтаксисом? IDE не влияет на синтаксис.
            В FDT 3 интерфейс достаточно близок к Java-плагину.
            • Интерфейсом
          • >И стал он в плане работы с классами похож на Eclipse for java
            действительно, он стал похож.
            но по удобству использования он ещё очень далёк от тех возможностей, которые есть у джава разработчиков. Adobe есть над чем работать. возможно, к релизу они добавят каких-нибудь вкусностей, но в бетах пока ничего такого нет.
  • Я как-то не нашёл флексу применения. Наверное нераспробывал. Приведите пожалуйста пример где флекс стоит использывать.
    • Вот пара примеров:
      flex.org/it/showcase_page
    • Запросто.

      Диалог:
      Ув. программисты у меня есть вот такая замысловатая таблица, представляющая весь бизнес-процесс моей компании. Реализуйте редактирование всего это дела, с учётом того, что пользователи будут использовать Linux/Windows/MacOS и по-быстрее. И вот вам в помощь 15кг юскейсов и сценариев работы с таблицей.
      • Ну это уже интранет больше, так?
    • Быстрый способ создать web-приложение. Без проблемам с кроссбраузерностью.
  • Добавлю, что кэшируется RSL при этом флэш-плеером версии выше 9.0.115, и сохраняет «навечно».
    Ранее лишь в кэше браузера.
  • Автор, вот вы молодец. Хорошую тему подняли.

    Хотите, я вам дам задачу с которой вы попытаетесь справиться, а потом нам напишите о своих результатах по оптимизации и отрыванию SDK.

    Задача:
    Программисту выдали три проекта.
    1. Lab.Dashboard
    2. Lab.Contracts
    3. Lab.Applications

    Все три проекта используют Flex SDK 3.4+

    Проект Lab.Contracts (см. п 2) содержит определение интерфейсов, скажем
    public interface IDashboardApplication
    {
    function get applicationName():String;
    }

    Проект Lab.Applications содержит множество .mxml файлов следующего содержания:
    <mx:Application implements=«Lab.Contracts.IDashboardApplication» />

    И последний Lab.Dashboard содержит логику по загрузке и размещению этих приложений в своём визуальном дереве.

    Оптимизируйте это приложение таким образом, что бы каждое _вгружаемое_ приложение не давай +500кб

    Бонус трэк: реализуйте возможность вгружать приложения с разных доменов.

    За подсказками — обращайтесь.)
    • Я не автор топика, чисто ради любопытства предположу:

      Не использовать mxml, не использовать ничего из пакетов mx.*
      Написать на чистом as

      не совсем понимаю, при чем тут разные домены, если это определяется полиси и кроссдоменом? В чем проблема?
    • А вы ее решили? :)
    • Насколько я знаю эти задачи решаемы модульной структурой приложения. RSL определяется в Lab.Dashboard, он же по совместительству и главная аппликуха. Затем грузим Contracts, который даст нам необходимые интерфейсы в эппликейшн домене. А дальше паки с Lab.Applications. Нужно следить что-бы они при компиляции не включали в себя классы фреймворка, но это решается написанием нормального build файла, который будет гарантировать централизованную перекомпиляцию всех кусков.

      Загрузка модулей с другого домена решается allowDomain`ом.

      Если как-то не так, то буду благодарен за поправку. С таким геморроем работал мало.
  • По поводу читаемости link-report:
    Theo Hultberg в своем блоге писал о трансформации link-report.xml в удобочитаемый вид с помощью XSL.
    И xsl-файлик соответствующий прикладывал.
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.