Flash, velocizzare ottimizzando il codice Actionscript

Questo articolo vuole fare un pò di luce sul delicato argomento dell’ottimizzazione. Non abbiamo più a che fare con progetti di qualche anno fa, soprattutto per quanto riguarda Flash: l’ingresso in scena di Molehill, senza considerare il crescere in maniera esponenziale di soluzioni dedicate per tutti i tipi di piattaforme e scopi, ha contribuito ad una maggiore richiesta di codice sempre più testato, performante ed allo stesso tempo senza intoppi.

Tuttavia, prima di cominciare a guardare cos’è l’ottimizzazione in flash e come raggiunge un livello accettabile, occorre fare una premessa molto importante: bisogna evitare di partire con la pretesa di ottimizzare da subito. Chiunque abbia esperienza a riguardo potrà confermarlo: il primo passo è scrivere codice pulito, leggibile e facilmente manutenibile.

Ovviamente esistono dei metodi e degli strumenti anche per verificare quali sono le “zone calde” del nostro codice. Uno degli strumenti più usati è il Flash Builder Profiler della Adobe. Utilizzandolo con il nostro progetto potremo facilmente localizzare tutti i momenti in cui è necessaria una maggiore elaborazione da parte del sistema, e quindi una conseguente ottimizzazione da parte nostra.

Accorgimenti Basilari

I primi accorgimenti con i quali veniamo a contatto sono decisamente elementari. A volte, infatti, i dettagli da sistemare sono i più semplici, che apparentemente possono rivelarsi efficaci ma in fase di elaborazione occupano più memoria del previsto.

Un primo consiglio riguarda le iterazioni. In molti casi, per affrontare un ciclo, si utilizza il tipo “Number”. L’uso di un semplice int può migliorare notevolmente le cose. Soprattutto per quanto riguarda Actionscript 3, i miglioramenti sono tangibili.

Inoltre, un altro consiglio molto utile è di rimanere sempre strong typed. In poche parole, evitare di utilizzare un qualsiasi oggetto in forma generica, ma assicurarsi di sapere sempre con cosa si ha a che fare. Insomma, se un oggetto è di classe “Cane” identificarlo sempre come “Cane” e non come Object. Un esempio può essere un oggetto di tipo Vector a tre dimensioni (x, y e z) che nel contesto di un metodo viene preso genericamente come un Object.  Lavorando con questi tipi di oggetti nel contesto di molte iterazioni (dalle mille ai dieci milioni) e facendo dei test, molti programmatori hanno notato un cambiamento di velocità sorprendente.

Specificando l’uso di oggetti di classe ben definite abbiamo un guadagno di oltre metà del tempo che andrebbe invece speso per fare le stesse elaborazioni con un Object generico. Nello specifico dell’esempio della classe Vector, infatti, abbiamo un guadagno di tempo medio del 50% circa. Un cambiamento sicuramente superfluo quando si ha a che fare con pochi elementi e poche strutture, che acquisice invece ben altra rilevanza con un programma che deve valutare o elaborare dati per milioni e milioni di campi, magari presi da un database. In quest’ottica il tempo inizia a pesare.

Sempre rimanendo nel campo “basilare” dell’ottimizzazione del codice è necessario prendere provvedimenti anche per quanto riguarda il Casting. Per casting si intende un’operazione esplicita di conversione partendo da un tipo di dato ad un altro definito. In alcuni casi, il casting aiuta sensibilmente a guadagnare tempo, specie quando si esegue l’accesso ad un campo di un determinato oggetto.

Quindi, un’istruzione come:

array[0].x = 1;

sarà molto più lenta di:

Vector3D(array[0]).x = 1;

Da non sottovalutare, inoltre, ciò che riguarda il riutilizzo delle istanze per risparmiare spazio in memoria. Usare diverse istanze durante l’esecuzione del nostro progetto, rallenta enormemente la memoria, fino ad arrivare a situazioni spiacevoli nel caso di cicli piuttosto lunghi e complessi. La creazione di istanze infatti può creare un sacco di “spazzatura” e il garbage collector è costretto a fare del lavoro extra. Per iterazioni dell’ordine del milione, infatti, il tempo che viene “perso” possiamo quantificarlo nell’ordine di secondi.

Per capire meglio il discorso facciamo un esempio.

La sintassi

for(; i < n; i++)
c1 = new Classe1();
c1.x = 0;
c1. y = 2;

non è da tenere in considerazione, in quanto lenta e svantaggiosa. Ecco infatti la versione più “leggera” da usare:

c1 = new Classe1();
for(; i<n; i++)
c1.x = 0;
c1.y = 2;

Il risultato, utilizzando questa tecnica, è notevole: il miglioramento può addirittura velocizzare l’esecuzione del codice con un guadagno di tempo di oltre il 90%.

Per concludere questa sezione base, un’osservazione sui blocchi “try, catch”. Quando c’è la possibilità di fare un controllo con il valore “null”, con un nullable, è opportuno preferire un semplice “if(x == null)” anzichè mobilitare un intero blocco di codice “try, catch”.

Per rendere l’idea della potenza di un tale piccolo e semplice accorgimento, basti pensare che lavorando nell’ordine del milione di iterazioni in un ciclo il miglioramento è del 99%. In alcuni test eseguiti, infatti, partendo da un tempo campione di 30 secondi per un milione di iterazioni si è arrivati addirittura a 10 millisecondi. Un cambiamento abissale.

Insomma, massima attenzione al proprio codice e a cosa si può ottimizzare, dato che il guadagno di tempo può fare la differenza. Adesso diamo uno sguardo a qualcosa di più avanzato: grafica, animazioni e chiamate ai server.

Grafica, Animazioni e Chiamate ai Server

Nonostante gran parte del lavoro di ottimizzazione si basi su alcune attente modifiche del codice “puro”, altri accorgimenti possono essere presi per quanto riguarda le altre “zone di lavoro”. Flash oggi è famoso soprattutto per i giochi, data la diffusione di prodotti pensati anche per la piattaforma di Facebook quali Farmville e Music Challenge. Quando si parla di giochi online si parla soprattutto di grafica e di dati memorizzati su un server online.

Occorre quindi tenere a mente e conoscere qualche piccolo trucco anche per quanto riguarda questi settori, in modo da capire se c’è la possibilità di fare un lavoro migliore. Iniziamo a vedere qualcosa per quanto riguarda la grafica.

• In primo luogo, evitare dei framerate troppo alti ed inutili. Far lavorare un gioco a 60 frame per secondo può essere inutile, se il risultato può essere raggiunto senza problemi e in maniera fluida a 30. Da notare che da 60 a 30 il cambiamento è decisamente significativo: si tratta infatti di risparmiare, per ogni secondo di gioco, la metà del tempo per controlli, elaborazioni, rendering e tutte le altre operazioni;
• Se possibile, evitare in tutti i casi l’utilizzo di filtri grafici in fase di runtime. Sono molto lenti e richiedono risorse in maniera significativa: se si può ottenere lo stesso risultato tramite programmi esterni, in modo tale da mandare in rendering il risultato già elaborato, tanto di guadagnato. Anche le animazioni ne risentiranno positivamente, mostrandosi più fluide e senza scatti fastidiosi;
• Evitare di disegnare oggetti con trasparenze al di sopra di altri oggetti con trasparenze. I calcoli relativi ai canali alpha aumentano in maniera significativa quando due oggetti con trasparenza si sovrappongono. Nel caso fosse possibile, infatti, tale accorgimento può rendere il tutto molto più fluido, anche se è comprensibile che non sempre si può raggiungere una tale condizione;
• Imparare ad usare una proprietà quale “cacheAsBitmap” non è sbagliato, anche se si tratta di un’arma a doppio taglio. Se impostata su “true”, infatti, permette di memorizzare nella memoria cache una rappresentazione del bitmap del filmato. Questo può essere produttivo nel caso di immagini statiche, ma per quanto riguarda le animazioni l’effetto potrebbe essere diametralmente opposto.

Anche per quanto riguarda l’utilizzo di connessioni a fonti esterne di dati e server remoti ci sono molti consigli utili sul miglioramento dei propri progetti. In questo settore, tra l’altro, il tempo che si può guadagnare può risultare molto più significativo di tutto ciò che abbiamo visto finora.

• Evitare caricamenti troppo frequenti, soprattutto se totalmente inutili. Si pensi ad un programma che gestisce un insieme di utenti. Caricare il nome e i dati dell’utente ogni volta è dispendioso: basta memorizzare tutto in locale all’avvio della sessione, aggiornare eventualmente i dati in caso di modifica e cancellare tutto alla fine dell’esecuzione. Si sa: che la memoria costa poco, ma la banda no;
• Per ogni richiesta effettuata, bisogna trovare il giusto quantitativo di dati da richiedere, ogni volta. Se la quantità è bassa si potrebbe perdere molto tempo inutilmente ad aprire, chiudere connessioni e preparare il trasferimento. Se invece la quantità è troppo alta si potrebbe bloccare l’esecuzione per un bel pò;
• Seguendo il punto precedente, lavorando con files molto piccoli è meglio caricarne di più per volta. In caso di tipologie diverse d’uso (magari una galleria di immagini o di video) il discorso cambia, e conviene “mettere in coda” i vari download necessari.

Adesso tocca all’ultimo argomento, sicuramente uno dei più interessanti: la gestione del Garbage Collector.

Il Garbage Collector

Il Garbage Collector (da ora in poi GC) è uno strumento importantissimo quando si parla di linguaggi che gestiscono in maniera automatica la memoria. Imparare a capire come e quando un determinato oggetto venga effettivamente rimosso dalla memoria è quindi essenziale a capire cosa fare per evitare dei fastidiosi problemi con la memoria, che nei casi peggiori possono portare ad un utilizzo spropositato di risorse utilizzabili più intelligentemente.

Per quanto riguarda Flash, tutto avviene senza l’ausilio dell’utente: un qualsiasi oggetto in memoria viene automaticamente rimosso nel momento in cui non si contano suoi riferimenti all’interno del programma in esecuzione. Quindi, volendo fare un esempio, se noi dichiarassimo l’oggetto

ogg1 = new Classe1();

questo rimane nella memoria fin quando non impostiamo a “null” il riferimento ad ogg1, ovvero

ogg1 = null;

Tuttavia, a volte, per questioni legate al timing del programma in esecuzione o ad alcune imperfezioni, accade che il GC non funzioni correttamente, e lasci in memoria ciò che non deve rimanere. Ovviamente, anche a questa problematica c’è una soluzione: basta infatti forzare l’esecuzione del GC, prendendone il controllo per fugare ogni dubbio.

Ci sono due modi per forzare le operazioni del GC.

Il primo approccio, semplice, basilare e forse anche meno elegante, consiste nel richiamare per due volte (si, scrivere la stessa riga di codice per due volte) il metodo di richiamo del GC (System.gc()) nel nostro codice in modo tale da essere sicuri al 100% che abbia funzionato. Richiamando il GC una volta sola, infatti, non se ne ha la certezza totale.

Riprendendo l’esempio di prima, quindi, supponendo che le nostre istruzioni siano contenute in un metodo “metodo1()”:

ogg1 = new Classe1();
ogg1 = null;

System.gc();
System.gc();

Il secondo metodo, invece, apparentemente più raffinato ma che in realtà è tendenzialmente classificato come un semplice hack, prevede la creazione di un nuovo metodo che a sua volta usi il metodo LocalConnection. Di seguito il codice necessario.

public function hackGC():void {
	try {
		new LocalConnection().connect('metodo1');
		new LocalConnection().connect('metodo1');
	} catch (e:Error) {}
}

Ovviamente le possibilità di ottimizzazione non finiscono qui, anzi, sono molte di più di quanto se ne possa immaginare. Molte, forse, non sono ancora state scoperte, viste le possibilità di un qualsiasi linguaggio di programmazione. Ad ogni modo il concetto chiave non cambia: alla base di una buona ottimizzazione bisogna prima vedere cosa davvero necessita un miglioramento prima di effettuare modifiche alla cieca, in modo da bilanciare efficienza ma anche velocità di scrittura del codice e di realizzazione.