2009-08-11 11 views
15

En Actionscript 3, ¿hay algún gasto indirecto entre la importación de un paquete completo y la importación de clases independientes?Paquete de importación Actionscript 3. * vs paquete de importación.Clase

Por ejemplo: import flash.display. * En comparación con import flash.display.Sprite

Sé que es una buena práctica para importar sólo las clases necesarias de un paquete para evitar conflictos, pero a menudo me han dicho también tiene un costo en términos del tamaño del archivo compilado si importo paquetes completos en muchas clases diferentes que solo utilizan algunas de las clases de esos paquetes.

Me pregunto si una clase se importará de una vez por todas para todo el proyecto, o si las importaciones se multiplican entre las clases que las utilizan.

El tamaño del archivo compilado resultante y el rendimiento del tiempo de ejecución son dos aspectos diferentes que abarca esta pregunta.

Respuesta

7

El único golpe debe ser el tiempo de compilación, pero rday escribe que parece ser un pequeño golpe. Pero eso debería ser algo que Adobe arreglará en el futuro.

Las sentencias de importación no deberían considerarse realmente como importaciones reales, es simplemente una forma de que el compilador sepa a qué clases se refiere.

por ejemplo. Si hizo su propia clase Point y se estaba utilizando en otro paquete, el compilador necesita saber si se está refiriendo a su propia clase Point o la clase Adobe Point.

La alternativa sería escribir el nombre completo calificado evertime que ha referido a una clase.

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

Como ha señalado Juan Pablo Califano en el comentario, esto no funciona realmente con el compilador (aunque creo que podría funcionar con AS2). Simplemente quise señalar por qué tenemos una declaración de importación para comenzar.

En cualquier caso, no debería afectar al archivo compilado si importa un paquete completo (aunque aparentemente lo hace).Sin embargo, afectará el tiempo de compilación, ya que le está dando al compilador más material que necesita revisar.

En cuanto a "importar" la misma clase más de una vez. No hará la diferencia. El compilador solo incluirá la misma clase una vez. De lo contrario, el tamaño del archivo compilado se saldría rápidamente de control, ya que la mayoría de las clases se refieren a muchas clases que de nuevo se refieren a otros, etc. Pero de nuevo, Adobe podría tener la optimización para hacerlo allí.

En pocas palabras, solo debe importar las cosas que necesita, no existe una ventaja real al importar un paquete completo. Simplemente use una herramienta de codificación adecuada como FlashDevelop (es gratis) y ni siquiera tiene que escribir las declaraciones de importación usted mismo.

En una nota lateral, si está compilando una biblioteca (donde también se incluye una clase no referida), no estoy seguro de si la importación de un paquete externo puede incluir eso en su archivo compilado. Eso podría tener un impacto real; aunque es de esperar Adobe no meter la pata allí;)

+1

Solo una nota: incluso si utiliza la ruta completa en su código, necesita la importación o de lo contrario el compilador se quejará. –

+0

Cierto, lo olvidé. Pero fue más un punto sobre por qué tenemos las declaraciones de importación, ya que la alternativa sería muy molesta. –

+0

Sin problemas. Y sí, ese era el comportamiento en AS 2. Si usaba el nombre completo, podría omitir la importación. –

0

Al igual que en la mayoría de los lenguajes, la sobrecarga del rendimiento es escasa o nula y está relacionada con la importación de paquetes completos en lugar de clases individuales.

Sin embargo es más una buena práctica, ya que da un veiw mucho más concisa de dependencias para su clase

1

El ActionScript 3 spec dice todos los nombres públicos del paquete serán importados si se utiliza el '*'. Entonces hay un golpe, aunque puede no ser grande dependiendo del tamaño del paquete. El libro ActionScript Design Patterns también desalienta esto debido al exceso de equipaje, así como algunos Adobe ActionScript tips.

Dicho esto, me tomó una como componente en una aplicación que escribí y

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

En lugar de los nombres de las clases individuales. Mi tamaño aumentó en 3 bytes. Ahora, toda la aplicación es de 935kB, así que probablemente tenga esas clases importadas en otro lugar, y el golpe no fue muy grande. Apuesto a que cuanto menor sea su aplicación, mayor será el impacto en su tamaño de compilación (en porcentaje).

+0

Un poco decepcionante que el compilador no puede optimizar eso. –

+0

Pero creo que más optimización significa más tiempo para compilar (publicar), Flash AS3 es patéticamente lento en el proceso de publicación. Entonces, en mi opinión, primero deberían hacerlo mejor (algo así como idiomas más altos, compilar solo deltas) y más rápido de lo que deberían pensar en estas optimizaciones. !!! :) – DexTer

0

buena práctica es, en general, tener código que se puede leer ... tener un comienzo de clases con 200 declaraciones de importación por lo tanto sería más bien una mala práctica ...

en as3, un extracto de importación solo agrega un nuevo alcance a la resolución del identificador del compilador ... lo que está compilado en un SWF y lo que no lo es, no está determinado por las declaraciones de importación, sino por dependencias reales, es decir, código de clase A utilizando clase B ...

en tiempo de ejecución por lo que no hace ninguna diferencia, la forma en que ha importado sus clases ...

greetz

back2dos

+0

+1. Personalmente me gusta importar explícitamente cada clase. Aunque lo pensaría dos veces si tuviera que hacerlo manualmente. Pero, de todos modos, tienes razón sobre cómo funciona la importación. Es una directiva de compilación, pero no obliga a la compilación. De lo contrario, ¿por qué alguien usaría el "var dummy: SomeClass"? hack para forzar la inclusión de una clase no referenciada como tal en el código? –

1

no hay absolutamente ninguna diferencia en el código compilado si se importa el paquete completo o sólo las clases que está utilizando. Las importaciones son importantes para que el compilador encuentre dónde están las clases.

Puede intentar descompilar o mirar el bytecode antes y después.

1

Puede comprobar exactamente qué clases se importan mediante el uso de la 'link-report' compiler option

El compilador puede tomar más tiempo para resolver qué incluir y qué no incluir, pero si se echa un vistazo a los informes de vincular, Note que solo incluye lo que usa. :)

5

Dirigiéndose puntos de ryanday, no puedo explicar los 3 bytes adicionales, pero algunas notas ...

El libro Patrones de Diseño de ActionScript también desalienta esto debido a un exceso de equipaje

Sí, en la página 115, pero creo que es incorrecto y envié una errata a ese efecto.

La especificación de ActionScript 3 indica que todos los nombres públicos del paquete se importarán si usa el '*'. Así que hay un hit,

Es algo así como, pero estoy en desacuerdo con la interpretación y éxito. Dice: "Los nombres de los miembros del paquete están hechos visible ..." (in full).En este contexto, se refiere a hacer que los nombres de los miembros sean visibles para las herramientas de compilación y editor, no visibles dentro del archivo SWF compilado. es decir, no significa que las clases se compilan en el archivo SWF, a menos que realmente se utilicen (una variable declarada de ese tipo).

Otra forma de ver esto, puede importar manualmente flash.display.MovieClip. Pero si no crea ninguna instancia de MovieClip, la clase MovieClip no se compilará en el SWF final.

Para satisfacer a mí mismo, he recopilado la siguiente holamundo en 3 maneras, la salida de enlace-informe según lo sugerido por @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); 
     } 
    } 
} 

En primer lugar, como está escrito, informe de enlace:

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

en segundo lugar, eliminar el archivo de informe de enlace y cambiar a las importaciones:

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

generación limpia, y el enlace repor t se ve exactamente igual. Mismo tamaño, mismo tamaño optimizado, mismas clases enlazadas.

En tercer lugar, eliminar el archivo de informe de enlace y cambiar a las importaciones:

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

generación limpia, y el informe de enlace se ve exactamente lo mismo. Mismo tamaño, mismo tamaño optimizado, mismas clases enlazadas.

Solo las clases Sprite y TextField llegan al SWF en cada caso.

Al observar el tamaño real del archivo SWF en el disco, parece haber una ligera variación (1 o 2 bytes) en las 3 versiones. No es peor que para el SWF más grande al que se hace referencia en la publicación de ryanday.

0

Descubrí que para AS3, el mero uso de declaraciones de importación incluirá las clases en su salida, independientemente de si esas clases están referenciadas en el código actual. Contraste esto contra Java, que solo incluirá las clases si se usan realmente, no solo se mencionan en las declaraciones de importación. Pero encontré esto útil al diseñar una API de Flash, solo mencione esas clases en las declaraciones de importación y se incluirán.

Cuestiones relacionadas