Accentsconagua

Alt du kanskje vil vite om importerklæringer *

Kode
Share

* Ikke egentlig alt.

Import er nødvendig **

I AS2-dagene kan du komme deg og måtte skrive en importere setning ved å bare bruke det fullt kvalifiserte klassenavnet i klassekroppen (for eksempel flash.display.Sprite i motsetning til bare Sprite). Mens du er velkommen til å bruke det fullt kvalifiserte klassenavnet når du skriver koden din, importere uttalelser for hver klasse er nødvendig i AS3.

Så det er ikke mye behov for å skrive fullt kvalifiserte klassenavn, med mindre du kommer til å bruke to klasser som deler samme korte navn i samme klasse - kanskje hvis du bruker Flash Kamera klassen sammen med et 3D-bibliotek Kamera klasse.

** Med mindre klassen er i samme pakke

Unntaket fra forrige regel er om klassen du bruker og klassen du skriver, er begge i samme pakke. Alle klasser i en pakke er implisitt tilgjengelige for hverandre uten en importere uttalelse.

Det er fortsatt ikke en dårlig ide å skrive importere uttalelse uansett, fordi:

Importerklæringer er selvdokumenterende kode

Ved å notere all din import, oppretter du en slags manifest av hvilke andre klasser klassen din stoler på for å kunne gjøre jobben sin. Det kan virke som en triviell ting, men denne informasjonen kan faktisk være ganske nyttig. Vurder følgende klasse ***:

 pakke com.activetuts import com.activetuts.SuperTrace; importer com.activetuts.ActiveTween; offentlig klasse QuickTip offentlig funksjon QuickTip var sporer: SuperTrace = ny SuperTrace (); tracer.log ("Quick Tip"); var tween: ActiveTween = new ActiveTween (); tween.go ();

*** Forhåpentligvis er det åpenbart at denne klassen er illustrerende, ikke funksjonell.

Hvis du bruker dette Raskt tips klasse, vil Flash automatisk sørge for at SuperTrace og ActiveTween klasser er også samlet i den resulterende SWF, fordi du brukte Raskt tips, og Raskt tips krever disse klassene.

Enkelt nok, men vurder nå mer realistiske klasser som bruker dusinvis av andre klasser. Hvis du trenger å vite hvilke klasser som er i bruk, en rask titt på importere seksjonen kan gi deg en anstendig idé. Det er ikke uttømmende, og det er litt villedende selv, men du vil bli hardt presset for å finne noen som mener at selvdokumenterende kode er en dårlig ting.

blits Klasser trenger å importere, men er ikke kompilert

Det er en vanlig misforståelse rundt ideen om at bruk av mange klasser nødvendigvis betyr at filstørrelsen til SWF vil øke. Normalt er det sant. Men hvilken som helst klasse som starter med blits er en levert av Flash Player, og vil ikke ha noen effekt på størrelsen på SWF. Byte-koden for, si, Sprite er inneholdt i Flash Player, og du registrerer bare det faktum at du vil bruke en Sprite, ikke bunte den byte-koden inn i SWF-en. Dette er snakk om å ha Flash Player.

Jeg forventer ikke at du skal tro på dette. Jeg forventer at du skal være litt utrolig, og kreve bevis. Jeg ønsker deg velkommen til å bevise dette for deg selv, ved å følge disse trinnene:

  1. Lage en ny FLA og tilknyttet dokument klasse.

  2. I dokumentet klassen, skriv minimumet du trenger å faktisk definere det som en dokument klasse:

     pakke import flash.display.Sprite; offentlig klasse Dokument utvider Sprite offentlig funksjon Dokument ()
  3. Åpne opp Publiser innstillinger ved å trykke på Alternativ-Skift-F12 / Alt-Skift-F12 (eller ved å velge Arkiv> Publiser innstillinger?).
  4. Klikk på "Blits"fanen.
  5. I "Avansert"delen, sjekk"Generer størrelsesrapport"alternativet.
  6. Også i "SWF-innstillinger"delen, sjekk"Eksporter SWC"alternativ, en unUndersøk "Inkluder XMP-metadata"alternativet (dette siste alternativet fjerner en masse metadata fra SWF som oppblåser størrelsen på SWF og gjør også et rot i størrelsesrapporten vi ser på).
  7. Trykk på Control / Command-Enter til Test filmen.
  8. Trykk på Control / Command-B for å åpne Båndbreddeprofil (også tilgjengelig under Vis> Båndbreddeprofil mens du ser på SWF)
  9. Legg merke til antall byte denne SWF er (min er for øyeblikket 354, kjørelengde kan variere, men det kommer til å ligge i ballparken). Pass på å merke bytes, og ikke Kilobytes. Husk dette nummeret.
  10. Lukk SWF.

  11. Rediger din dokument klasse å bruke en haug med blits klasser. For eksempel:

     pakke import flash.display. *; importer flash.media. *; importer flash.net. *; importer flash.text. *; offentlig klasse Dokument utvider MovieClip offentlig funksjon Dokument () var l: Loader = ny Loader (); l.load (ny URLRequest ("someasset.swf")); var tf: TextField = nytt TextField (); var format: TextFormat = nytt TextFormat ("Verdana"); format.align = TextFormatAlign.CENTER; tf.defaultTextFormat = format; var v: Video = ny video (); var s: Lyd = nytt lyd (); Var kanal: SoundChannel = s.play ();

    Vi bruker ganske mange klasser, som selv innlemmer enda flere klasser. Alle disse klassene er imidlertid blits klasser.

  12. Test filmen en gang til. Båndbreddeprofileren bør fortsatt være åpen fra siste gang; Hvis ikke, åpne den igjen.
  13. Merk størrelsen på SWF: Jeg rapporterer 596 byte med koden ovenfor, en økning på 242 byte. Det er ikke mye med tanke på at jeg bruker Filmklipp (som utvider en hel haug med andre klasser), loader, URLRequest, Tekstfelt, tekstformat, TextFormatAlign, video, Lyd, og SoundChannel. Det er mye funksjonalitet for 242 byte.

  14. I Utdata-panelet ser du noe som følger (hvis du brukte den ovenfor angitte koden ordentlig, ser du også lyd- og lastfeil, men de er ikke viktige):

     flash-test.swf Movie Report ---------------------------- Ramme # Ramme Byte Total Bytes Scene ------- - ---------- ----------- ----- 1 598 598 Scene 1 (AS 3.0 Klasser Eksporter ramme) Sceneform Bytes Tekstbyte ActionScript Bytes ----- - ----------- ---------- ------------------ Scene 1 0 0 546 ActionScript Bytes Beliggenhet - ----------------- -------- 546 Scene 1: Ramme 1: Dokument

Denne testen skal illustrere at selv om vi har brukt mange Flash-gitt klasser, er den resulterende størrelsen på vår SWF relativt liten. Beviset kommer med størrelsesrapporten, men vi ser ingen oppføringer for noen av de innebygde klassene. Vi ser vår Dokument klasse men ingen andre klasser, og den ene klassen er ansvarlig for alle ActionScript bytes.

Hvis dette ikke er nok bevis for deg, kan du ikke utvide eksperimentet. Du kan legge til enda flere Flash-gitt klasser, mens du måler økningen i størrelsen på SWF som fortsatt bare er et spørsmål om bytes. Du kan inkludere klasser av dine egne, og sørg for at de vises i klasselisten, og også påvirker størrelsen på SWF på en mer åpenbar måte. For eksempel laget jeg dette enkle Test klasse:

 pakke public class Test public function Test () trace ("TEST");

Inkludert denne enkle 7-linjesklassen, som ikke bruker andre klasser selv, støtte min test SWF til 717 byte, en økning på 121 bytes. Denne økningen er halvparten av økningen vi så da vi tilføyde alle disse blits klasser; Byte-til-funksjonalitetsforholdet skal indikere at blits klasser er ikke samlet i SWF.

Vær også oppmerksom på at du vil se en ekstra oppføring i størrelsesrapporten for den ekstra klassen; noe sånt som dette:

 flash-test.swf Movie Report ---------------------------- Ramme # Ramme Byte Total Bytes Scene ------- - ---------- ----------- ----- 1 719 719 Scene 1 (AS 3.0 Klasser Eksporter Frame) Sceneform Bytes Tekstbyte ActionScript Bytes ----- - ----------- ---------- ------------------ Scene 1 0 0 673 ActionScript Bytes Beliggenhet - ----------------- -------- 179 Scene 1: Ramme 1: Test 494 Scene 1: Ramme 1: Dokument

Historienes moral: vær så snill å bruke så mange blits klasser som du vil ****. De vil ikke påvirke størrelsen på SWF (selv om koden som bruker disse klassene vil selvsagt)

**** Husk at komponenter og Flex-klasser er ikke levert av Flash Player. Disse klassene ser ut til å være integrert, men hvis pakken ikke starter med blits, da er den ikke gitt av spilleren.

Wildcard-import er ikke ineffektiv

Jeg beklager den dobbelte negative *****, men dette er en annen vanlig misforståelse som jeg ønsker å rydde opp.

Først en rask definisjon. EN wildcard import er en som ser slik ut:

 importer flash.display. *;

Dette gjør at alle klassene er tilgjengelige i flash.display pakke. Dette er kortfattet sammenlignet med (for eksempel):

 importer flash.display.Bitmap; importer flash.display.BitmapData; importer flash.display.BlendMode; importer flash.display.Graphics; importer flash.display.Sprite;

Nå misforståelsen. Når jeg sier, "dette gjør tilgjengelig alle klasser," gjør jeg IKKE mener det hver klassen i den pakken blir automatisk samlet inn i din SWF. Jeg mener at enhver klasse i den pakken er tilgjengelig for deg i kortnavn når du skriver klassen. Så i det forrige eksempelet, ville jeg være fri til å skrive dette:

 var sp: Sprite = ny Sprite; var g: Graphics = sp.graphics; g.beginFill (0); g.drawRect (0, 0, 100, 100); sp.blendMode = BlendMode.MULTIPLY;

Den koden bruker Sprite, Graphics og BlendMode, som alle er i flash.display-pakken, og alle må importeres. Enten tilnærming har det samme resultatet. Du er velkommen til å bruke villkortsimport.

Igjen, et enkelt eksperiment for de som trenger bevis. For dette eksperimentet trenger vi ikke-blits klasser. Du må ha eksterne klasser tilgjengelige, enten du har skrevet, eller noe som Papervision3D eller TweenMax. Jeg kommer ikke til å laste ned og installere disse pakkene, men i form av min prøvekode bruker jeg en enkel pakke med fire klasser opprettet for dette formålet. Du kan finne dem, sammen med testfiler, i nedlastingspakken, i mappen "wildcard-import". Klassene er i bibliotek pakke.

  1. Lage en ny FLA, og tilknyttet dokument klasse.
  2. I koden din, importere en enkelt klasse. For eksempel:
    importere bibliotek. En.
  3. Og vær sikker på at bruk det, som med
    var o: One = new One ();
  4. Test filmen (trykk Kommando-retur / Kontroll-Enter, eller gå til Kontroll> Testfilm).
  5. Åpne båndbreddeprofilen med SWF kjører (trykk Kommando-B / Kontroll-B eller gå til Vis> Båndbreddeprofil)
  6. Merk størrelsen av SWF (igjen, i byte, ikke Kilobytes).
  7. Lukk SWF
  8. Rediger dokumentklassen din slik at Import bruker et vill kort i stedet. For eksempel:
    importer biblioteket. *;
  9. Test filmen en gang til.
  10. Merk størrelsen av SWF. Det bør være identisk som forrige gang.
  11. Du kan også aktivere størrelsesrapporten (ikke glem å slå på SWC-alternativet og slå av XMP-alternativet) for å se hvilke klasser som blir samlet.

Dette skulle tyde på at selv om det ser ut som om vi importerer alt fra pakken sammenfatter vi egentlig bare de klassene vi faktisk bruker.

***** Nei jeg er ikke

En importerklæring alene vil ikke kompilere klassen

Det er i dette følgende hypotetiske eksempelet:

 pakke import SuperTrace; importere ActiveTween; offentlig klasse QuickTip offentlig funksjon QuickTip ()

De SuperTrace og ActiveTween Klasser er importert. Men de er aldri Brukt innenfor klassen. Flash-kompilatoren er vanligvis smart nok til å finne ut dette, og bestemme at de to klassene ikke trenger å bli kompilert for Raskt tips klasse.

Selvfølgelig, hvis en annen klasse bruker den SuperTrace klassen, så blir det samlet. Poenget er at kompilatoren er ganske god til ikke å inkludere unødvendige klasser i SWF.

Du kan bevise dette ved å sette opp en test som ligner på tidligere tester: sammenlign både byte størrelse og størrelsesrapporter for to SWFer som er identiske med unntak av bruken av en importert klasse. Du kan se et slikt eksempel ved å sammenligne prosjektene "import uten bruk" og "import-med-bruk" som er inkludert i kildeposten.

Hvis du av en eller annen grunn må sørge for at SuperTrace og ActiveTween klasser kompilere, selv om du ikke bruker dem i denne klassen, kan du tvinge det ved å bare henvise dem i kroppens kropp. For eksempel:

 pakke com.activetuts import com.activetuts.SuperTrace; importer com.activetuts.ActiveTween; offentlig klasse QuickTip offentlig funksjon QuickTip SuperTrace; ActiveTween;

Det er nok å få kompilatoren til å se disse som nødvendige klasser, selv om linjene ikke gjør mye når koden kjøres.

Kode
×