Limiti nelle performance di progetti in Flash, gli stessi da anni.

www.fantasy-interactive.comIn un articolo pubblicato su Search-this.com, Bartek Drozdz di Fantasy Interactive (FI) dì  alcuni consigli su come rendere le applicazioni realizzate in Flash più veloci e più performanti:
Una delle domande che mi pongono maggiormente è qual’è il punto debole di progetti realizzati in Flash. La mia risposta è la stessa da anni; Ritengo che il punto debole è la lentezza“.

Di seguito Bartek propone dei piccoli accorgimenti per rendere le applicazioni in Flash8/As2 un pò più veloci e performanti:

Punto 1. Evitare, per quanto possibile, di usare in flash immagini con alpha channel (.gif, .png). Ancor meno consigliabile è l’uso di immagini sovrapposte con alpha channel, in questo caso flash impegna il processore con molti calcoli per renderizzare le immagini pixel per pixel.

Punto 2. Assicurarsi che siano gestiti soltanto gli elementi che compongono l’animazione visibili sullo stage. Preferibile quindi che ci siano pochi movie clips da gestire.

Punto 3. E’ preferibile che gli elementi grafici o testuali importati nel FLA siano il minor numero possibile e comunque caricati nello stage nel momento in cui bisogna mostrarli.

Punto 4. E’ necessario gestire elementi grafici piatti (Flatten). Ad esempio nel caso di un pulsante composto da più elementi come background, ombra, icona, ed etichetta di testo, è preferibile comporre tale oggetto in photoshop ed importarlo come immagine nel nostro FLA (si addirittura comprensivo di testo).

Punto 5. E’ consigliabile comprimere le immagini da usare nel nostro progetto in flash utilizzando Photoshop che possiede un modulo di compressione migliore a quello di Flash. In tal caso è necessario che nella fase di esportazione in swf, Flash non comprima ulteriormente l’immagine attivando l’opzione lossless PNG/GIF compression.

Punto 6. Minimizzare sempre la quantità  di codice che scrivete. Spesso si incorre nell’errore di inserire nei nostri progetti codice per funzioni che ci saranno “forse” utili nel futuro. Tra l’altro l’AS è indispensabile per funzioni interattive e se il vostro codice consiste per il 50% di attachMovie allora c’è qualcosa di errato.

Applicare la maggior parte di questi punti renderanno meno flessibile il processo di sviluppo del progetto, questo è vero, ma renderanno la vostra applicazione molto più performante e leggera.

Nella mia piccola esperienza con Flash a partire dalla versione 5 ho sempre combattuto con questi limiti di  flash e anno in anno,  con  il lancio sul mercato di versioni sempre più evolute, ho sperato in soluzioni definitive a questi limiti.  Una speranza mal riposta se a distanza di anni un flasher guru come Bartek Drozdz mi conferma che i limiti sono quelli di sempre  così come le soluzioni.

 

7 commenti su “Limiti nelle performance di progetti in Flash, gli stessi da anni.”

  1. Pingback: diggita.it

  2. Ciao
    Personalmente ritengo Flesh una teconologia di cui in molti siti per mostrarli di “spettacolari” si abusa.
    Innanzi tutto nascondo le informazioni ai motori di ricerca e questo annulla tutto ciò che riguarda il S.E.O.
    In secondo luogo rende stressante fare click e aspettare il caricamento di altre animazioni che a volte richiede molto più tempo del normale html.
    Terzo, per poter usufruire del contenuto devi (sempre in alcuni casi) aspettare le paranoiche animazioni ideate da funamboli web designer senza dare la minima possibilità del “Skip Intro”.

    Concludo dicendo che se usato sapientemente da una indiscutibile professionalità al sito e aspetto grafico interessante. Basta dosare le tecnologie.

    Ciao

  3. @pasquale ti ringrazio del commento, condivido in pieno il tuo parere su flash, mi capita ancora adesso, in piena era web 2.0, di non riuscire a convincere il cliente ad evitare di intasare il sito con inutili animazioni, di indirizzare il budget economico nel realizzare progetti puliti, usabili e soprattutto SEO.
    E’ stato un piacere scoprire il tuo blog, i contenuti sugli ideogrammi giapponesi sono molto interessanti. a presto

  4. A dire il vero a me queste considerazioni paiono un po’ datate – se è vero che sono vecchiotte – perchè nel frattempo la potenza di calcolo dei computer è aumentata.
    …no?
    ciao!

  5. Beh, allora facciamo lo stesso discorso per qualsiasi applicativo. Fattostà che la velocità percepita del mio vecchio pc (P133) è identica a quello nuovo che uso ora. Solo perchè gli applicativi sono più complessi. L’ottimizzazione del codice dove sta?

    Rimanendo in tema, io flash l’ho usato poco e non lo conosco a pieno. Ho però più piacere a visitare un sito in html puro, che aspettare di caricare una animazione flash con pochi contenuti!

    Ciao!

  6. Beh, allora facciamo lo stesso discorso per qualsiasi cosa(?!).
    Andiamo a piedi invece che coi mezzi di trasporto, mangiamo roba cruda perchè il fuoco è venuto dopo, ecc ecc.
    Per i programmi il discorso è differente: che le cose basilari che si possono fare con PsCs3 si potevano fare anche con Ps4 è vero, ma chi lo spiega all’utente che esistono interessi incrociati tra chi crea software e chi crea hardware, in modo da rinnovare sempre la richiesta di nuove macchine, e viceversa la richiesta di nouvo software?
    E poi, comunque, “de gustibus”! 😉

  7. Ma che bel guru, un genio, ma dove l’avete pescato?

    La maggior parte dei punti sono mere banalità tipo “far girare meno roba = andare + veloce”. Geniale davvero.

    Il punto 4 è quasi leggendario nella sua perversione, tutto in grafica piatta: se hai 20 pulsanti (e ne devi avere ben tanti per notare un rallentamento di performance su dei cavolo di pulsanti) con la stessa identica forma, e cambia solo il testo, li dovresti fare tutti e 60 (20 normali+ 20 hilites+20 premuti) in grafica piatta con tanto di scritte!!!! HAhaha!!! Sai che performances! E che grande ottimizzazione dei pesi!

    Poi dopo questa genialata, per compensare andiamo al punto 5: comprimere con Photoshop perché la compressione di Flash perderebbe mezzo byte ad immagine!!

    E poi che faccio? La metto come lossless PNG/GIF!!!! Ma qualcuno è andato nel test a vedere poi quanto pesa???? Il triplo!!! E schiacciata a 256 colori pure. L’opzione giusta è “Usa dati JPEG importati” (può cambiare leggermente il nome a seconda della versione di Flash). L’opzione Lossless non centra proprio un tubazzo. Complimenti!

    Le scelte semai sarebbero due: 1) importarla in Flash SENZA COMPRESSIONE (tiff) e lasciare poi che Flash faccia il suo lavoro comprimendo il JPEG. Questo magari perderà mezzo byte, ma ha il vantaggio di consentirci di regolare il peso all’ultimo momento vedendo il risultato e decidere in base al peso di tutte le altre parti del sito. 2) Comprimerla in Photoshop, magari risparmiando quel mezzo byte, e poi essere costretti a tenerla con quella compressione per sempre (“Usa dati JPEG importati”), altrimenti, se la si deve lasciar ricomprimere a Flash, l’immagine risulterebbe compressa due volte (con perdita di qualità e di bytes).

    Sul punto 6 magari un giorno Mr. The Guru mi spiegherà quanto codice inutilizzato bisognerà mai scrivere per compromettere le performances di Flash????? Tonnellate e tonnellate di enciclopedie di Actionscript. Certo il codice ha il suo peso, ma non è certo un video (in più viene pure zippato) dal punto di vista delle performances poi, se non viene mai usato…

    Comunque il punto 1, alla lontana, un senso, per quanto banale, ce l’ha. Thanks Mr The Guru!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.