Пакет импорта Actionscript 3.* по сравнению с пакетом импорта. Класс

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

Вы можете попробовать декомпилировать или посмотреть байт-код до и после.

В спецификации ActionScript 3 говорится, что все общедоступные имена из пакета будут импортированы, если вы используете '*'. Итак, есть хит, хотя он может быть не большим, в зависимости от размера упаковки. Книга Шаблоны проектирования ActionScript также не одобряет этого из-за лишнего багажа, а также некоторые советы Adobe ActionScript .

При этом я использовал один как компонент в приложении, которое я написал и

  import mx.containers.*;
  import mx.events.*;
  import mx.managers.*;

Вместо одного имени класса. У меня размер увеличился на 3 байта. Теперь все приложение занимает 935 КБ, поэтому я, вероятно, импортировал эти классы где-то еще, и успех был не очень большим. Готов поспорить, чем меньше ваше приложение, тем больше будет влияние на размер вашей компиляции (в процентном отношении).

  import mx.containers.*;
  import mx.events.*;
  import mx.managers.*;

вместо отдельных имен классов. У меня размер увеличился на 3 байта. Теперь все приложение занимает 935 КБ, поэтому я, вероятно, импортировал эти классы где-то еще, и успех был не очень большим. Готов поспорить, чем меньше ваше приложение, тем больше будет влияние на размер вашей компиляции (в процентном отношении).

  import mx.containers.*;
  import mx.events.*;
  import mx.managers.*;

вместо отдельных имен классов. У меня размер увеличился на 3 байта. Теперь все приложение занимает 935 КБ, поэтому я, вероятно, импортировал эти классы где-то еще, и успех был не очень большим. Готов поспорить, чем меньше ваше приложение, тем больше будет влияние на размер вашей компиляции (в процентном отношении).

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

Однако это более хорошая практика, поскольку она дает гораздо более краткий обзор зависимостей для вашего класса

Хорошая практика в целом - иметь код, который можно читать ... иметь начало класса с 200 операторов импорта, поэтому было бы довольно плохой практикой ...

в as3, операторе импорта только добавляет новую область видимости к разрешению идентификатора компилятора ... то, что скомпилировано в SWF, а что нет, определяется не операторами импорта, а фактическими зависимостями, то есть кодом из класса A с использованием класса B ...

поэтому во время выполнения не имеет значения, как вы импортировали свои классы ...

greetz

back2dos

Вы можете точно проверить, какие классы импортируются, используя параметр компилятора 'link-report'

Компилятору может потребоваться больше времени, чтобы разобраться, что именно включать, а что не включать, но если вы посмотрите отчеты о ссылках, вы заметите, что они включают только то, что они используют. :)

Обращаясь к пунктам Райндея, я не могу объяснить лишние 3 байта, но несколько примечаний ...

Книга шаблонов проектирования ActionScript также не одобряет это из-за лишнего багажа

Да, на странице 115, но я думаю, что это неправильно, и внесены исправления по этому поводу.

В спецификации ActionScript 3 сказано, что все общедоступные имена из пакета будут импортированы, если вы используете '*'. Так что хит есть,

вроде как, но я не согласен с интерпретацией и хитом. В нем говорится: «Имена элементов пакета сделаны видимыми ...» ( полностью ). В этом контексте это относится к тому, чтобы сделать имена членов видимыми для инструментов компилятора и редактора, не видимыми в скомпилированном SWF. то есть не означает, что классы компилируются в SWF - если они не используются на самом деле (объявленная переменная этого типа).

Другой способ взглянуть на это: вы можете вручную импортировать flash.display.MovieClip . Но если вы не создадите ни одного экземпляра MovieClip, класс MovieClip не будет скомпилирован в окончательный SWF-файл.

Чтобы убедиться в этом, я скомпилировал следующий helloworld тремя способами, выводя отчет о ссылках, как это было предложено @secoif ...

package
{
    import flash.display.Sprite;
    import flash.text.TextField;

    public class ASHelloWorld extends Sprite
    {
        public function ASHelloWorld()
        {
            var tf:TextField = new TextField();
            tf.text = "Hello World!";
            addChild( tf );
        }
    }
}

Во-первых, как написано, отчет по ссылкам:

<report>
  <scripts>
    <script name="~/Documents/eclipse3.5carbonFbPlugin-FX4-LS10/ASHelloWorld/src/ASHelloWorld.as" mod="1278415735000" size="682" optimizedsize="344">
      <def id="ASHelloWorld" />
      <pre id="flash.display:Sprite" />
      <dep id="AS3" />
      <dep id="flash.text:TextField" />
    </script>
  </scripts>
  <external-defs>
    <ext id="AS3" />
    <ext id="flash.text:TextField" />
    <ext id="flash.display:Sprite" />
  </external-defs>
</report>

Во-вторых, удалите файл отчета по ссылкам и измените импорт на:

    import flash.display.MovieClip;
    import flash.display.Sprite;
    import flash.text.TextField;

Чистая сборка, и отчет по ссылкам выглядит точно так же.Одинаковый размер, такая же оптимизация, одинаковые связанные классы.

В-третьих, удалите файл отчета по ссылкам и измените импорт на:

    import flash.display.*;
    import flash.text.*;

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

В каждом случае в SWF попадают только классы Sprite и TextField.

Если посмотреть на фактический размер SWF-файла на диске, кажется, что есть небольшое отклонение (1 или 2 байта) по сравнению с 3 версиями. Не хуже, чем для более крупного SWF, о котором говорилось в посте Ряндая.