2009-08-11 11 views
15

W Actionscript 3, czy istnieje jakikolwiek narzut na szpule między importowaniem pełnego pakietu a importowaniem niezależnych klas?pakiet importu ActionScript 3. * Vs pakiet importujący. Klasa

Np. Import flash.display * vs. import flash.display.Sprite

wiem, że jest to dobra praktyka, aby importować tylko potrzebne klas z pakietu, aby uniknąć konfliktów, ale ja często mówiono ma również koszt pod względem skompilowanego rozmiaru pliku, jeśli importuję pełne pakiety w wielu różnych klasach, które używają tylko niektórych klas z tych pakietów.

Zastanawiam się, czy jedna klasa zostanie zaimportowana raz na zawsze dla całego projektu, czy też import zostanie zwielokrotniony wśród klas, które z nich korzystają.

Wynikowy rozmiar pliku skompresowanego i wydajność środowiska wykonawczego to dwa różne aspekty, które obejmuje to pytanie.

Odpowiedz

7

Jedynym hitem powinien być czas kompilacji, ale rday pisze, że jest apperently mały hit. Ale to powinno być coś, co Adobe naprawi w przyszłości.

Oświadczenia importowe nie powinny być traktowane jako rzeczywisty import, to tylko sposób, aby kompilator wiedział, do których klas się odwołujesz.

np. Jeśli stworzyłeś klasę Point i był on używany w innym pakiecie, kompilator musi wiedzieć, czy odwołujesz się do własnej klasy Point lub klasy Adobe Point.

Alternatywą byłoby napisanie w pełni kwalifikowanej nazwy evertime, której dotyczyła klasa.

np. var mySprite:flash.display.Sprite = new flash.display.Sprite();

Jak podkreślił Juan Pablo Califano w komentarzu, to faktycznie nie działa z kompilatora (chociaż myślę, że może on pracować z AS2). Chciałem tylko wskazać, dlaczego mamy na początku oświadczenie dotyczące importu.

W żadnym wypadku nie powinno to wpłynąć na skompilowany plik, jeśli zaimportujesz cały pakiet (choć on tak robi).Będzie to miało jakikolwiek wpływ na czas kompilacji, ponieważ dajesz kompilatorowi więcej rzeczy, które trzeba przejrzeć.

Co do "importowania" tej samej klasy więcej niż jeden raz. To nie ma znaczenia. Kompilator będzie zawierał tylko tę samą klasę. Inaczej skompilowany rozmiar pliku szybko wymknie się spod kontroli, ponieważ większość klas odwołuje się do wielu klas, które odnoszą się do innych itd. Ale znowu Adobe może optymalizować, aby to zrobić.

Podsumowując, powinieneś tylko importować potrzebne rzeczy, nie ma prawdziwej przewagi przy importowaniu całej paczki. Po prostu użyj odpowiedniego narzędzia do kodowania, takiego jak FlashDevelop (jest ono bezpłatne) i nie musisz nawet sam pisać instrukcji importowania.

Na marginesie, jeśli kompilujesz bibliotekę (do której nie dołączono także klasy), nie jestem pewien, czy importowanie zewnętrznego pakietu może uwzględniać to w twoim skompilowanym pliku. To może mieć rzeczywisty wpływ; choć mam nadzieję, że Adobe nie zepsuć tam;)

+1

Uwaga: nawet jeśli używasz w ścieżce pełnej ścieżki, potrzebujesz importu, inaczej kompilator będzie narzekał. –

+0

Prawda, zapomniałem o tym. Ale bardziej chodziło o to, dlaczego mamy oświadczenia dotyczące importu, ponieważ alternatywa byłaby bardzo denerwująca. –

+0

Bez problemów. I tak, to było zachowanie w AS 2. Jeśli użyłeś w pełni kwalifikowanej nazwy, możesz pominąć import. –

0

Tak jak w przypadku większości języków, ogólny nakład pracy związany z importowaniem całych pakietów jest niewielki lub nie ma znaczenia.

Jednak jest to raczej dobra praktyka, ponieważ daje dużo bardziej zwięzły veiw zależnościach dla klasy

1

ActionScript 3 spec mówi wszystkie nazwy publiczne z pakietu będzie importowany w przypadku korzystania z „*”. Tak więc istnieje trafienie, chociaż może nie być duże w zależności od rozmiaru paczki. Książka ActionScript Design Patterns również odradza to ze względu na nadbagaż, a także niektóre Adobe ActionScript tips.

Mając na uwadze powyższe, wziąłem jedną jako składnik w aplikacji pisałem i

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

zamiast nazw jednej klasy. Mój rozmiar zwiększył się o 3 bajty. Teraz cała aplikacja ma 935kB, więc prawdopodobnie te klasy zostały zaimportowane gdzie indziej, a trafienie nie było zbyt duże. Założę się, że im mniejsza aplikacja, tym większy wpływ na rozmiar kompilacji będzie (procentowo).

+0

Nieco rozczarowujące, że kompilator nie może tego zoptymalizować. –

+0

Ale myślę, że większa optymalizacja oznacza więcej czasu na kompilację (publikowanie), Flash AS3 jest powolnie patetyczny w procesie publikowania. Tak więc, moim zdaniem, najpierw powinni zrobić to lepiej (coś w stylu wyższych języków, kompilować tylko delty) i szybciej, niż powinni myśleć o tych optymalizacjach. !!! :) – DexTer

0

Dobrą praktyką jest w ogóle mieć kod, który jest czytelny ... mający początek klasy z 200 sprawozdań przywozowych zatem byłoby raczej złą praktyką ...

w as3, instrukcja import dodaje tylko nowy zakres do rozdzielczości identyfikatora kompilatora ... co jest kompilowane w SWF, a co nie jest, nie jest określone przez instrukcje importu, ale przez rzeczywiste zależności, tj. kod z klasy A za pomocą klasy B ...

tak przy starcie to nie robi żadnej różnicy, jak zaimportowane klas ...

greetz

back2dos

+0

+1. Osobiście lubię importować wyraźnie każdą klasę. Myślę, że dwa razy, gdybym musiał to zrobić ręcznie. W każdym razie masz rację co do tego, jak działa import. To dyrektywa kompilująca, ale nie wymusza kompilacji. W przeciwnym razie, dlaczego ktoś miałby używać "var dummy: SomeClass;" hack wymusić włączenie do kodu klasy, do której nie ma odniesienia? –

1

nie ma absolutnie żadnej różnicy w skompilowanego kodu, czy zaimportować cały pakiet lub tylko te lekcje, którego używasz. Importowanie jest po prostu ważne dla kompilatora, aby znaleźć miejsce, w którym znajdują się klasy.

Możesz próbować dekompilować lub patrzeć na kod bajtowy przed i po.

1

Można sprawdzić dokładnie, co zajęcia są importowane za pomocą 'link-report' compiler option

Kompilator może trwać dłużej, aby uporządkować to, co należy uwzględnić, a co się nie należą, ale jeśli sprawdzić swoje raporty linku, będziesz zauważ, że obejmuje tylko to, z czego korzysta. :)

5

Adresowanie punktów ryanday jest, nie mogę wyjaśnić dodatkowe 3 bajty, ale kilka uwag ...

Wzory książka ActionScript Projekt zniechęca również to ze względu na nadbagaż

Tak, na stronie 115, ale myślę, że jest źle i złożyłem erratę w tym celu.

Specyfikacja ActionScript 3 mówi, że wszystkie publiczne nazwy z paczki zostaną zaimportowane, jeśli użyjesz "*". Więc jest trafienie, ale nie zgadzam się z interpretacją i trafieniem. Jest napisane: "Nazwy elementów paczki są oznaczone jako widoczne ..." (in full).W tym kontekście chodzi o to, aby nazwy członków nie były widoczne dla narzędzi kompilatora i edytora, niewidocznych w skompilowanym pliku SWF. tj. oznacza, że ​​klasy są kompilowane w SWF - chyba że są faktycznie używane (deklarowana zmienna tego typu).

Inny sposób patrzenia na to, można ręcznie zaimportować flash.display.MovieClip. Ale jeśli nie stworzysz żadnej instancji MovieClip, klasa MovieClip nie zostanie skompilowana do ostatecznego pliku SWF.

Aby zadowolić siebie, Skompilowałem następujące helloworld na 3 sposoby, wyprowadzanie link-raport jak sugeruje @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); 
     } 
    } 
} 

Po pierwsze, jak napisano raport Link:

<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> 

Po drugie, należy usunąć plik raportu łącza i zmienić importu do:

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

czystą kompilację, a link repor t wygląda dokładnie tak samo. Ten sam rozmiar, ta sama optymalizacja, te same połączone klasy.

trzecie, usunąć plik raportu łącza i zmienić importu do:

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

czystą kompilację, a raport Link wygląda dokładnie tak samo. Ten sam rozmiar, ta sama optymalizacja, te same połączone klasy.

Tylko klasy Sprite i TextField przechodzą do pliku SWF w każdym przypadku.

Patrząc na rzeczywisty rozmiar pliku SWF na dysku, wydaje się, że występuje niewielka (1 lub 2-bajtowa) wersja w 3 wersjach. Nie gorsze niż dla większego SWF, o którym mowa w poście ryanday.

0

Odkryłem, że niż dla AS3, tylko użycie instrukcji importu będzie zawierało klasy w twoim pliku wyjściowym, niezależnie od tego, czy te klasy są przywoływane w rzeczywistym kodzie. Porównaj to z Javą, która będzie zawierać tylko klasy, jeśli są one faktycznie używane, nie tylko wspomniane w instrukcjach importu. Ale okazało się to przydatne przy projektowaniu Flash API, wystarczy wspomnieć o tych klasach w instrukcjach importu i zostaną one uwzględnione.