Performance test con Appcelerator Titanium

Ci sono tante scelte che possono portare o non portare all’uso di un framework mobile come Appcelerator Titanium. Tra queste, sicuramente, le performance delle applicazioni realizzate.

Per fare alcuni test ho usato il progetto KitchenSink, fornito da Titanium stessa come “banco di prova” per dimostrare quello di cui e’ capace. Effettivamente la meraviglia c’e’ stata, vedere la stessa identica app (a livello di sorgente JavaScript) girare su un Android e su un iPhone riprendendo aspetto e comportamenti tipici del sistema applicativo.

Titanium infatti crea un progetto in codice nativo (Android o iPhone) dal file Javascript di origine e quel progetto viene poi compilato per il dispositivo. Non ci sono quindi librerie grafiche intermedie di supporto e, a meno di personalizzazioni grafiche, il look’nd feel dell’applicazione realizzata e’ quello del particolare dispositivo dove si andra’ ad eseguire. Quindi conta molto la bonta’ del codice generato nella valutazione delle performance. Ovvio che nessun codice generato automaticamente per uno scenario medio-complesso puo’ essere allo stesso livello di un codice scritto a manina e ottimizzato per quella specifica esigenza, ma a volte le differenze sono trascurabili.

Purtroppo non e’ successo cosi’ per una delle viste di Titanium, composta da una ListView per Android o da una UITableView per iPhone un po’ complessa. Come si puo’ vedere dal video, le performance sono bassine su Android, sotto l’usabile, mentre rimangono soddisfacenti su iPhone.

httpv://www.youtube.com/watch?v=X2KVO3H7u7Q

Per fare le prove, ho usato l’ultima versione di KitchenSink trovata su GitHub, ho compilato l’applicazione Titanium con il mobile SDK 1.6.2 e i device sono un Samsung Galaxy Tab e un iPhone 4G. Ho ripetuto la prova su un Nexus One per sicurezza, ma il risultato e’ lo stesso.

Peccato, magari riprovo tra qualche mese per vedere se le cose sono migliorate.

6 Comments

  1. Il supporto di Titanium per Android ha anche parecchi bugs e l’illusione di poter avere un unico codice multipiattaforma è sparita quasi subito. Infatti KitchenSink é pieno di if (android) … else …
    Forse la lentezza si può spiegare con il diverso processo di creazione dell’applicazione: per ios viene creato codice completamente nativo, su android viene mantenuto il javascript che sarà interpretato a runtime da Rhino…
    Un’altra conseguenza di questa differenza: quando crei un app per ios gli errori javascript ti vengono segnalati alla compilazione, su android te ne accorgi sul dispositivo!

    @svzdvd

  2. Ciao Davide,

    sei davvero sicuro di quello che dici? Ammetto di essere un profano di Titanium, ma mi sembra strano che l’implementazione di iPhone e Android sia cosi’ diversa.

    Inoltre ho guardato il codice di KitchenSink, e gli if(android) presenti mi sembrano tutti abbastanza sensati. Si usano per togliere/mettere voci di menu’ relative ad esempi di feature che sono supportate solo da iOS o solo da Android (tipo vari modi di gestire la camera), oppure per piccoli aggiustamenti grafici (un font piu’ piccolino) oppure per cose specifiche di Android (come la gestione del ciclo di vita di un’Activity (pause, resume, start stop ecc), che non esiste in iOS). Pero’ non ho mai trovato if del tipo “per android fai cosi’, mentre per iPhone invece fai cosi'”. Poi magari qualcuno me ne e’ sfuggito, e ci sta tutto…

    Hai qualche link da darmi dove c’e’ scritto come viene creata un’app per iphone e una per Android?

  3. Ciao,
    se posso dire la mia, penso che per quanti problemi abbia Titanium Mobile come piattaforma (performance ridotte, bug di vario tipo, incongruenze di implementazione tra piattaforme target, ecc.), l’approccio che fornisce per lo sviluppo cross-platform vada nella giusta direzione. In sostanza, quello fornito da Titanium non è un modello di programmazione basato sul minimo comune denominatore tra le piattaforme supportate. E’ piuttosto un modello che vuole tendere a semplificare lo sviluppo di app cross-platform (attraverso un unico linguaggio – Javascript e un’API ben fornita), evidenziando comunque le differenze tra piattaforme target e dando allo sviluppatore la possibilità di massimizzare il risultato, “contenendo” gli sforzi. Quindi Titanium non prende a modello il “Write once run everywhere” di Java, bensì fornisce dei mezzi, che se sfruttati correttamente, organizzando in modo opportuno il codice, consentono nella maggior parte dei casi di poter riutilizzare l’intero codice del nucleo di un’app (i modelli, l’accesso ai dati, spesso anche i controller), riadattando o riscrivendo solo una parte limitata delle funzionalità (principalmente legate all’UI) per le varie piattaforme target. Da qui la necessità di avere porzioni di codice delimitate da if.
    Chiaramente il framework attualmente non è abbastanza maturo e non soddisfa appieno le promesse del modello al quale si rifà, però release dopo release i bachi vengono corretti e i problemi vengono risolti e sono convinto che in tempi ragionevoli sarà una buona piattaforma per lo sviluppo *nativo* cross-platform.
    Riguardo alla gestione del codice JS, dopo aver analizzato i sorgenti di Titanium e fatto qualche esperimento debugger alla mano, posso dire con certezza che su iOS il codice JS è interpretato e non compilato. Posso ragionevolmente affermare che lo stesso accada su Android (ma in questo caso non ho analizzato troppo in profondità). Resta il fatto che in entrambi i casi il prodotto è un’applicazione nativa a tutti gli effetti che, eseguendo codice JS attraverso un interprete e una libreria di runtime, istanzia oggetti e widget del sistema target.

  4. Inutile dire che sono un profano di Titanium anch’io… :)
    Ho dedotto che il Javascript su iPhone venisse compilato in qualche modo, dopo aver visto che su Android gli errori mi apparivano a runtime e che gli stacktrace contenevano riferimenti a Rhino, mentre su iPhone mi venivano segnalati in fase di compilazione.

    In realtà il funzionamento è piuttosto complesso:
    http://stackoverflow.com/questions/2444001/how-does-appcelerator-titanium-mobile-work
    http://stackoverflow.com/questions/4217551/what-happens-to-javascript-code-after-app-is-compiled-using-titanium-mobile

    Sono d’accordo sul fatto che quello di Titanium sia un buon approccio e ovviamente apprezzo che l’SDK sia Open Source, sono solo rimasto molto deluso dall’implementazione per Android, ma vedo che i rilasci si susseguono frequenti e questo mi fa ben sperare.

  5. @ Antonio

    si, quello è phonegap.
    Anche con Ti puoi creare una webview e usare vari framework js, ma non con lo stesso “fine” di phonegap.

Leave a Reply