Ho sviluppato un'applicazione per iPhone e ora la voglio su App Store. Così tanti miei amici geek iOS mi hanno detto di testarlo sul dispositivo vero e proprio su iPhone.
Quindi mi chiedo il motivo per cui è necessario testare la mia app per iPhone sul vero dispositivo iPhone anche se loro (Apple) hanno dato "simulatore" che è vicino all'incirca al mio dispositivo?
Devi testare l'applicazione sul dispositivo reale almeno per vedere come si comporta:
Sviluppatori iOS, continua questo elenco.
Una cosa che non saprai mai quando testare con l'emulatore è come ci si sente davvero per un utente che tiene in mano un dispositivo reale, facendo scorrere le dita sullo schermo. Di conseguenza, le azioni dell'utente che sembravano fluide durante la simulazione con il touchpad del laptop, potrebbero risultare piuttosto ingombranti per un reale utilizzo del dispositivo. Per assicurarti che la tua applicazione sia OK, testala con un dispositivo reale.
Un'altra cosa che vale la pena provare con un dispositivo reale è il consumo della batteria. È davvero più sicuro testare con un dispositivo reale piuttosto che contare sul modo in cui gli sviluppatori di simulatori sono riusciti a riprodurlo nel loro strumento.
Potrebbero esserci altre cose che non sono abbastanza vicine al simulatore. Ad esempio, il volume audio e il bilanciamento - il modo in cui suona il laptop, potrebbero differire da come sarà su un telefono reale. La vibrazione è un altro esempio che è appena possibile ottenere con il simulatore. Il modo in cui i sensori giroscopici funzionano al telefono reale. Roba relativa al GPS / localizzazione. Ecc ecc ecc ...
Il simulatore contro il test dei dispositivi reali è una questione abbastanza importante. In uno dei miei progetti precedenti, una parte importante del successo commerciale era un attento bilanciamento tra questi tipi di test, che sostanzialmente si riduceva a chiedere continuamente domande come perché sul dispositivo?
Il vero lavoro inizia quando si chiede perché , scegliendo i motivi per scegliere tra test sul dispositivo e sul simulatore in casi e situazioni particolari.
Ignorare i test dei dispositivi espone il tuo prodotto a un (piuttosto elevato) rischio di rottura nelle mani dell'utente finale, distruggendo completamente tutti gli sforzi che hai messo in sviluppo. Ma la cosa è che il test del simulatore è molto più economico e molto più facile per l'automazione. Se ci si attiene ciecamente ai test solo su dispositivo, le loro versioni potrebbero diventare sostanzialmente in seguito e più costose di quelle dei concorrenti.
Dall'esperienza e un decollo dalla risposta più votata:
Le dita invece del mouse rappresentavano la differenza maggiore quando sviluppammo Decimation X2 per Windows Phone 7. Era codificato su un emulatore, poiché non avevamo un WP7 e prima che venisse rilasciato il WP7. Potremmo aver ricevuto potenzialmente un WP7 gratuito prima del rilascio, nel caso che l'ultima frase non avesse senso per te, visto che siamo stati invitati da Microsoft ad avere un titolo di lancio sul loro telefono. Risultò che ciò che volevamo che l'utente facesse con le dita era molto duro sul telefono reale, ma facile con un mouse. E aveva a che fare con casi di schermo. Sfortunatamente il nostro gioco richiedeva sempre le dita di essere sempre al margine dello schermo, cosa che alcuni telefoni facevano fatica a fare a causa del loro schermo incassato e di casi spessi. Realmente distribuiamo una patch per risolvere questo problema. Ciò significa che a tutti i nostri utenti per la prima volta è stata mostrata una versione errata e potenzialmente inutilizzabile del nostro gioco. : (
La diversa differenza hardware era la più grande differenza. Abbiamo dovuto indovinare letteralmente con il metodo impreciso di prendere la nostra versione Xbox 360 del gioco e ridurla di conseguenza a metà del frame-rate (da 60fps a 30fps) e un terzo del GHz (da 3.0GHz a 1.0GHz), e abbiamo indovinato sbagliato. I processori erano diversi, ovviamente, e lo sapevamo. Senza l'hardware, rimanemmo zitti a congetture. Non è stata una nostra scelta dato che non avevamo il WP7, ma abbiamo imparato la lezione che sto condividendo con te ora. Su alcuni telefoni, durante le parti più intense del gioco, ha fatto cadere i frame. :( A nessuno sembrava importare perché ritenevano che il rallentamento fosse appropriato per parti così intense, quindi non era un grosso problema, ma il punto è: se fosse stato un grosso problema, la "app" sarebbe stata spezzata dalle nostre zoppe ipotesi.
Test su hardware reale. E quando esegui il codice per vari hardware del telefono, esegui il test su quelli di fascia più bassa se le prestazioni sono un problema.
L'iPhone Simulator implementa alcune API che l'iPhone stesso non ha (Il principale che viene in mente essendo l'API DOM XML, dove l'iPhone supporta solo SAX per quanto ne so, questo potrebbe essere cambiato anche se ora.)
Ti permetterà anche di "sentire" l'app, i tuoi pulsanti sono della misura giusta? I pulsanti giusti cadono sotto il pollice? L'iPhone è in grado di eseguire l'app? Il simulatore non è un emulatore e funziona aggiungendo semplicemente Cocoa Touch al tuo desktop Mac per quella app. Devi simulare gli avvisi di memoria esaurita e simili.
Perché non avrai molti utenti in giro con un simulatore in tasca.
EDIT: Ogni volta che stai testando la tua app su un simulatore (o emulatore), stai utilizzando un dispositivo falso che non può essere, per definizione, una rappresentazione accurata al 100% della cosa reale. Un emulatore potrebbe essere più preciso di un simulatore, ma ci saranno ancora delle differenze. L'unico emulatore accurato al 100% è il dispositivo stesso.
Progettare, testare, ottimizzare il codice su un simulatore porta a un'applicazione ottimizzata per lavorare in modo ottimale su un simulatore .. I tuoi utenti non avranno i simulatori, però; stai prendendo di mira il dispositivo sbagliato. Uno molto simile; ma non lo stesso dispositivo che useranno gli utenti.
Questo può portare a diversi tipi di problemi. Gravi problemi come bug, crash sono sicuramente la tua priorità. Ma ce ne sono altri; come l'ergonomia. Cerca di tenere in mano il simulatore. Prova. Gli elementi dell'interfaccia utente sono resi su uno schermo diverso, con una resa cromatica possibilmente diversa, e di certo dimensioni diverse (un problema esacerbato dai bellissimi display retina, non completamente risolti usando anche un macbook retina, per esempio). Quelle squisite sfumature di grigio sono ugualmente distinguibili su un dispositivo al sole?
Piccole differenze di velocità e una diversa emulazione del sensore (o la sua mancanza), a volte possono modificare drasticamente l'esperienza.
Se la tua applicazione si basa sulla connettività Internet, non è possibile passare da LTE, 3G, EDGE o GPRS, per testare scenari diversi o persino provare diversi operatori.
Supporterai i dispositivi jailbroken? Forse non lo sei, ma se lo sei, probabilmente sei disposto a testare la tua app con uno. Oppure, se non lo sei, sei sicuro che stai rilevando un ambiente jailbreak?
Il gioco iPad che stai sviluppando sul simulatore è ugualmente utilizzabile quando un utente tiene il suo peso e usa le dita per giocare? I tocchi multipli involontari sono in grado di interrompere la tua app, cosa che non eri in grado di prevedere nell'ambiente del simulatore sicuro single-touch (o simmetrico con doppio tocco)?
Sarebbe comodo salire su un aereo comandato da un pilota che non ha mai realmente lasciato il terreno?
La linea di fondo è: prima della spedizione, si prega di utilizzare lo stesso dispositivo che gli utenti useranno. Nessuno di loro userà un simulatore.
motivo pratico:
1) Non hai "invia posta" funzionante.
2) Non puoi mettere il dispositivo a testa in giù ..
e ovviamente già detto motivo:
3) larghezza di banda ridotta
4) potenza di calcolo molto piccola rispetto al simulatore
5) Le chiamate GL aperte sono implementate in modo un po 'diverso nel simulatore
6) spazio su disco / RAM ..
Anche se è stato detto che le prestazioni dell'hardware sono generalmente peggiori, va notato che questo non è il caso di OpenGL ES. Il simulatore lo implementa nel software, quindi non è raro che noti prestazioni enormi aumentare durante l'esecuzione sul dispositivo stesso.
Inoltre, ci sono alcune piccole differenze tra le implementazioni software e hardware di Open GL ES, ad es. gli hint di precisione dello shader potrebbero avere output diversi.
Quando implementiamo le cose per iOS (o Android o Windows Phone), sviluppiamo non per il desktop ma per il dispositivo. Per alcune applicazioni di calcolo / risorse pesanti, ciò potrebbe significare un comportamento normale sui problemi del simulatore BUT sul dispositivo reale.
Quindi situazioni come questa possono essere incontrate in fasi successive se non testiamo sul dispositivo dall'inizio: -
Ci sono alcune funzionalità come PushNotification , utilizzando la videocamera , ecc. che possiamo testare solo su un dispositivo; queste sono funzionalità che non possono essere testate su un simulatore.
E testare la tua app su un dispositivo reale prima dell'invio all'App Store riduce le possibilità di rifiuto dell'app; a volte un'app funziona correttamente nel simulatore ma si blocca su un dispositivo reale, che è il motivo principale per i rifiuti dell'app.
Possono esserci reali differenze di prestazioni tra il dispositivo reale e l'emulatore. Abbiamo riscontrato che solo i test con l'emulatore hanno generato un'app molto lenta in molti casi, cosa che non ci aspettavamo.
L'esperienza utente varia da un dispositivo a un altro a causa del diverso sistema operativo e
specifiche hardware. Quindi, è necessario testare un'app per iPhone sull'effettivo
dispositivi - dispositivi mobili che eseguono varie versioni di iOS nel marketplace.
Sebbene un simulatore sia utile per identificare eventuali problemi affrontati dall'utente finale,
testare l'app sul dispositivo originale ti aiuterà a identificare e indirizzare i principali
preoccupazioni dell'utente.