Per comprendere come è possibile migliorare le prestazioni di un'applicazione, è fondamentale conoscere i meccanismi di esecuzione del codice runtime nella piattaforma Flash. Il runtime segue un andamento ciclico, con determinate azioni che vengono eseguite su ogni "fotogramma". In questo caso, per fotogramma si intende semplicemente un blocco di tempo determinato dalla frequenza dei fotogrammi specificata per l'applicazione. La quantità di tempo assegnata a ciascun fotogramma corrisponde direttamente alla frequenza dei fotogrammi. Ad esempio, se specificate una frequenza fotogrammi di 30 fotogrammi al secondo, il runtime tenta di assegnare a ciascun fotogramma un trentesimo di secondo.
La frequenza fotogrammi iniziale di un'applicazione viene specificata in fase di creazione (authoring). Potete specificare la frequenza fotogrammi mediante le impostazioni di Adobe® Flash® Builder™ o di Flash Professional. Oppure, potete anche specificare la frequenza fotogrammi iniziale nel codice. Per impostare la frequenza fotogrammi in un'applicazione basata esclusivamente su ActionScript, applicate il tag di metadati
[SWF(frameRate="24")]
alla classe documento principale. In MXML, impostate l'attributo
frameRate
nel tag Application o WindowedApplication.
Ogni ciclo (loop) di fotogramma consiste di due fasi, divise in tre parti: gli eventi, l'evento
enterFrame
e il rendering.
La prima fase comprende due parti (gli eventi e l'evento
enterFrame
), che possono entrambe determinare una chiamata al codice. Nella prima parte della prima fase, arrivano e vengono inviati gli eventi runtime. Questi eventi possono rappresentare il completamento o l'avanzamento di operazioni asincrone, ad esempio una risposta dal caricamento di dati su una rete. Includono inoltre gli eventi generati dall'input dell'utente. Quando gli eventi vengono inviati, il runtime esegue il codice dell'applicazione nei listener che avete registrato. Se non si verifica alcun evento, il runtime completa questa fase senza eseguire alcuna azione. Il runtime non accelera mai la frequenza fotogrammi a causa di una mancanza di attività. Se gli eventi si verificano durante altre parti del ciclo di esecuzione, il runtime li inserisce in coda e li invia nel fotogramma successivo.
La seconda parte della prima fase è costituita dall'evento
enterFrame
. Questo evento si distingue da tutti gli altri perché viene inviato una volta per ogni fotogramma.
Una volta che tutti gli eventi sono stati inviati, ha inizio la fase di rendering del ciclo di fotogramma. A questo punto il runtime calcola lo stato di tutti gli elementi visibili e li disegna sullo schermo. Il processo viene quindi ripetuto come in una corsa su pista.
Nota:
per gli eventi che includono una proprietà
updateAfterEvent
, potete impostare forzatamente l'esecuzione immediata del rendering anziché attendere la fase di rendering. Evitate tuttavia di utilizzare
updateAfterEvent
se è spesso causa di problemi di prestazioni.
Per semplificare, possiamo immaginare che le due fasi del ciclo di fotogramma abbiano la stessa durata. In questo caso, la prima metà del ciclo di fotogramma sarebbe occupata dall'esecuzione dei gestori di eventi e del codice dell'applicazione e l'altra metà verrebbe utilizzata per il rendering. Nella realtà, tuttavia, le due fasi hanno spesso una durata diversa. A volte il codice dell'applicazione utilizza più della metà del tempo disponibile nel fotogramma, riducendo il tempo a disposizione per il rendering. In altri casi, soprattutto in presenza di contenuti visivi complessi come filtri e metodi di fusione, il rendering occupa più della metà del tempo del fotogramma. Poiché il tempo effettivamente occupato dalle due fasi è flessibile, il ciclo di fotogramma viene detto anche “pista elastica”.
Se le due operazioni del ciclo di fotogramma (esecuzione del codice e rendering) richiedono troppo tempo, il runtime non è in grado di rispettare la frequenza fotogrammi. Il fotogramma si espande, occupando un intervallo di tempo superiore a quello assegnato, e determina un ritardo nell'attivazione del fotogramma successivo. Se, ad esempio un ciclo di fotogramma impiega più di un trentesimo di secondo, il runtime non è in grado di aggiornare lo schermo a 30 fotogrammi al secondo. La riduzione della frequenza fotogrammi influisce negativamente sulle prestazioni. Nella migliore delle ipotesi, le animazioni vengono riprodotte in maniera discontinua. Nel peggiore dei casi, l'applicazione si blocca e il contenuto della finestra scompare.
Per ulteriori informazioni sul modello di rendering e sull'esecuzione del codice runtime nella piattaforma Flash, vedete le seguenti risorse:
