ActionScript 3 import package. * Vs import package.Class

В ActionScript 3 есть ли накладные расходы на катушку между импортом полного пакета и импортом независимых классов?

Например: import flash.display. * vs. import flash.display.Sprite

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

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

Результирующий скомпилированный размер файла и производительность выполнения - это два разных аспекта, которые охватывает этот вопрос.

Ответ 1

Единственным хитом должно быть время компиляции, но rday пишет, что есть небольшой хит. Но это должно быть то, что Adobe исправит в будущем.

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

например. Если вы создали собственный класс Point и он использовался в другом пакете, компилятор должен знать, ссылаетесь ли вы на свой собственный класс Point или класс Adobe Point.

Альтернативой было бы написать полное имя evertime, которое вы указали в классе.

например. var mySprite:flash.display.Sprite = new flash.display.Sprite();

Как отметил Juan Pablo Califano в комментарии, это фактически не работает с компилятором (хотя я думаю, что он может работать с AS2). Я просто хотел указать, почему у нас есть оператор импорта.

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

Что касается "импорта" одного и того же класса более одного раза. Это не изменит ситуацию. Компилятор будет включать один и тот же класс один раз. Иначе размер скомпилированного файла быстро выйдет из-под контроля, так как большинство классов относятся ко многим классам, которые снова относятся к другим и т.д. Но опять же Adobe может оптимистично там сделать.

В нижней строке вы должны импортировать только нужные вам материалы, нет реального преимущества для импорта целого пакета. Просто используйте подходящий инструмент для кодирования, например FlashDevelop (он бесплатный), и вам даже не нужно писать инструкции импорта самостоятельно.

С другой стороны, если вы компилируете библиотеку (в которую также включен класс, на который не ссылаются), я не уверен, что импорт внешнего пакета может включать это в ваш скомпилированный файл. Это может иметь реальное воздействие; хотя, надеюсь, Adobe там не испортилась;)

Ответ 2

Адресация точек ryanday, я не могу объяснить дополнительные 3 байта, но несколько заметок...

Книга шаблонов дизайна ActionScript также препятствует этому из-за избыточного багажа

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

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

Это вроде как, но я не согласен с интерпретацией и ударом. В нем говорится: "Имена членов пакета сделаны видимыми..." (в полном объеме). В этом контексте речь идет о создании имен членов visible для инструментов компилятора и редактора, которые не отображаются в скомпилированном 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.*;

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Greetz

back2dos

Ответ 8

Я обнаружил, что для AS3 просто использование операторов импорта будет включать классы в ваш вывод, независимо от того, ссылаются ли эти классы на фактический код. Контрастируйте это против Java, который будет включать классы только в том случае, если они действительно используются, а не только в операторах импорта. Но я нашел это полезным при разработке Flash API, просто упомяните эти классы в операторах импорта, и они будут включены.