Share
Nel mondo iperconnesso di oggi, le persone vogliono risultati veloci. Come sviluppatori di dispositivi mobili, ne siamo più consapevoli rispetto alla maggior parte. I nostri utenti non si siedono di fronte a una scrivania. Sono in movimento, eseguono le nostre app mentre provano a camminare, parlare e guidare, quindi si aspettano esperienze allettanti. Entra, esci.
Diversi studi di Akamai, Google e altri hanno correlato la velocità del sito Web con la conservazione dell'utente. E finora, le prove suggeriscono che le persone sono altrettanto esigenti quando usano app native. In un sondaggio condotto da Apigee sugli utenti di dispositivi mobili, il reclamo principale relativo alle applicazioni mobili si blocca e oltre il 44% degli utenti intervistati ha dichiarato che eliminerebbe immediatamente un'app con prestazioni lente..
Chiedi a Facebook l'importanza delle app mobili veloci. Quando i loro titoli hanno toccato il fondo in adolescenza, Mark Zuckerberg ha dichiarato che basare la loro app su HTML5 è stato il più grande errore che hanno commesso come azienda. Perché? Perché era lento. Entro tre settimane dall'uscita della nuova app nativa più veloce di Facebook, la valutazione dell'applicazione è passata da 1,5 stelle a 4. Le applicazioni lente causano un notevole dolore aziendale. Utenti persi Dollari persi.
Quando in primo luogo si parlava agli sviluppatori del monitoraggio delle prestazioni delle loro app in produzione, la risposta più comune era "La mia app è già veloce".
Il problema è che, come il mondo dei frammenti mobili, è difficile offrire un'esperienza costantemente veloce. Come funziona la tua app in Cina su un vecchio telefono e una rete lenta? Sono disposto a scommettere che non hai idea. Non è certamente la stessa che si esibisce sul tuo nuovo iPhone collegato al tuo ufficio Wi-Fi.
Le prestazioni dipendono completamente dal contesto in cui viene eseguita l'applicazione. Ecco una breve ma certamente non completa lista di trucchi delle prestazioni:
Siamo abituati a pensare a problemi di internet in termini di limitazioni della larghezza di banda, ma nelle reti cellulari la latenza è spesso il fattore dominante. Su una rete 3G, possono passare circa 2,5 secondi per passare da inattivo a connesso prima che venga trasmesso un singolo byte. E Sprint dice che la latenza media sulla loro rete 3G è 400ms. Non importa quanto velocemente il tuo server elabora una richiesta se la risposta è lenta arrivare al telefono.
Come geek, spesso sviluppiamo usando l'ultima e la più grande, ma la maggior parte del mondo, inclusi i mercati massicci che vorresti penetrare, abbandonano la velocità per raggiungere l'accessibilità. I nostri test mostrano che il codice rilegato della CPU su un iPod 4G richiede circa quattro volte di più rispetto a un iPhone 5S. Su Android, la disparità è ancora più significativa.
Se la tua app utilizza troppa memoria, viene uccisa dal sistema operativo. Per l'utente, sembra uguale a un'eccezione di puntatore nullo. Anche se il tuo codice è perfettamente pulito senza una sola perdita di memoria, il tuo high water di memoria può causare incidenti su telefoni meno potenti, ma popolari, in mercati importanti.
Le batterie sono una delle prime cose da ridimensionare quando i produttori cercano di risparmiare spazio e denaro. Ma ciò non renderà gli utenti più comprensivi quando la tua app prosciugherà tutto il loro potere.
Diciamo per un momento che sei convinto che hai bisogno di un'applicazione veloce, e dovrebbe essere veloce ovunque, non solo per te quando esegui la tua app attraverso il profiler della CPU di Apple Instruments. Cosa deve fare uno sviluppatore? In questo momento, hai due opzioni di base:
Un'API veloce indica un'app rapida. Destra? Questa è la mentalità di uno sviluppatore web e, se sei uno sviluppatore mobile, è sbagliato.
Il web è un'architettura thin client. Mettendo da parte le app Web pesanti di JavaScript, la maggior parte del codice interessante dietro i siti Web è in esecuzione sul server. Il client, il browser, è in effetti solo un motore di rendering stateless. Quando le prestazioni diminuiscono, si tratta in genere di un problema di ridimensionamento dell'infrastruttura di back-end.
Le app native e mobili, d'altra parte, sono thick client. Hanno basi di codice grandi, multi-threaded. Mantengono lo stato. E devono esibirsi su una grande varietà di telefoni, sistemi operativi e reti. Il tuo team di server può ancora rovinare l'esperienza dell'utente, ma c'è un intero nuovo set di problemi che non verranno visualizzati negli avvisi del server.
Belle. L'hai capito. Devi assicurarti di testare le tue app in un sacco di mondo reale scenari. Quindi costruirai un laboratorio di QA di lusso con 100 telefoni diversi. Poi li racchiuderai in una gabbia di pazzi per poter simulare condizioni di rete avverse e assumere un esercito di persone QA per eseguire ogni nuova release attraverso ogni azione possibile nella tua applicazione.
Devo ammettere, se puoi permetterti, questa non è una cattiva idea. Ma le combinazioni diventano rapidamente travolgenti. Immagina che ti interessino i 100 telefoni principali, 10 velocità di rete, 20 diversi mercati esteri con latenze diverse e 5 diverse versioni del sistema operativo. Ora immagina di avere 50 azioni distinte nella tua app. Ignorando l'interdipendenza tra le azioni e i dati variabili dell'utente, hai 1 milione di combinazioni da testare. Ahia!
Questo è un classico problema di QA. Assicurazione di qualità significa fare del tuo meglio per testare i casi d'uso più comuni. Ma non è mai pensato per essere un sostituto per il monitoraggio. È semplicemente impossibile rimanere al di sopra di tutti i possibili casi di fallimento.
Abbiamo bisogno di un nuovo set di strumenti, costruito da zero per misurare in modo specifico i problemi di prestazioni delle app mobili. Quali metriche dovrebbero acquisire questi nuovi strumenti?
Niente disturba un utente più di uno schermo bloccato. Catturando ogni volta che la tua app supera una soglia temporale per eseguire il rendering di una cornice, puoi farti un'idea di quanto spesso vedono un congelamento notevole.
Se segui le buone pratiche UI / UX, ogni volta che devi svolgere un lavoro che richiede più di qualche millisecondo, dovresti farlo in background e lanciarne uno spinner. Ma anche se sei in cima alla tua discussione, gli utenti hanno ancora una pazienza limitata.
Dopo 1 secondo, gli utenti dispongono di un interruttore di contesto mentale e, dopo 10 secondi, gli utenti abbandonano il proprio compito. Se acquisisci ogni volta che mostri uno spinner, hai un buon indicatore generico di quanto tempo l'utente tipico è in attesa sulla tua app.
I bug di memoria sono una delle cose più difficili da rintracciare, soprattutto dal momento che Fuori dalla memoria il killer su iOS non genera una traccia dello stack. È troppo costoso tenere traccia di ogni allocazione, ma la registrazione della memoria residente su iOS o VM L'utilizzo dell'heap su Android è buono, con basse misurazioni generali.
Latenza e larghezza di banda sono entrambi altamente variabili sulle reti cellulari e svolgono un ruolo chiave nell'esperienza utente. Per ogni richiesta API, puoi registrare il tempo necessario per ottenere la risposta iniziale (latenza), il tempo necessario per ottenere la risposta completa (tempo di download) e i byte scaricati (byte / tempo di download uguale a larghezza di banda).
Una delle poche ragioni per cui disinstalli le app è l'utilizzo a batteria elevata. Ci sono ovvi problemi di batteria, come l'utilizzo del GPS del dispositivo, ma ci sono altri trucchi inaspettati, come l'attivazione dell'antenna wireless troppo spesso. Sia iOS che Android offrono API per il monitoraggio dei livelli di carica della batteria.
Nel mobile, il contesto è tutto. Quando qualcosa va storto, dovresti almeno conoscere la versione dell'applicazione, la posizione, la rete dell'operatore, la versione del sistema operativo e il dispositivo.
Se sei ambizioso, potresti avere alcuni strumenti di performance fatti in casa nella tua applicazione. Probabilmente hai alcuni timer di base per le azioni chiave nella tua app, quindi chiama a casa i dati tramite un log o un pacchetto specializzato di JSON.
Se è così, datti una pacca sulla schiena. Hai fatto molto più di altri. Ma ci sono molti inconvenienti a questo approccio. Che cosa succede se hai problemi di prestazioni in luoghi inattesi nella tua app? Se hai un problema, come fai a sapere cosa lo ha causato? Era una lunga chiamata di metodo, una lenta richiesta dell'API o troppi dati sul filo?
E una volta ottenuti i dati grezzi sulle prestazioni, come li analizzi e li visualizzi? Se scrivi uno script one-off, quanto spesso lo esegui? E, ci mancherebbe, cosa succede se la vostra strumentazione per le prestazioni causa problemi di prestazioni?
Su Pulse.io, abbiamo lavorato duramente per l'anno scorso costruendo un SDK pieno zeppo di monitoraggio della bontà. Catturiamo tutte le metriche elencate sopra mantenendo un ingombro molto ridotto. Consumiamo meno del 3% della CPU, batch invia i nostri dati per evitare di accendere la radio e limita la nostra memoria scartando le informazioni a bassa priorità.
La parte migliore di Pulse.io è che cattura tutte queste cose in modo automatico. Una cosa è configurare manualmente la tua app con la tua soluzione nazionale. Un'altra cosa è convincere tutti gli ingegneri del tuo team a farlo e applicare la stessa metodologia di strumentazione in modo coerente nel tempo.
Con Pulse.io, basta rilasciare l'SDK e trova automaticamente tutte le interazioni dell'utente all'interno della tua app e registra quando tali interazioni causano un cattivo comportamento come blocchi dello schermo o lunghi task asincroni.
Installare Pulse.io ti richiederà meno tempo rispetto alla lettura di questo articolo. Siamo attualmente in beta privata, ma se ci spari un'email a beta [at] pulse [punto] io e menzioni di leggere su di noi su Tuts +, ti configureremo con un account.
Una volta scaricato l'SDK, l'installazione è semplicissima. Inserisci l'SDK nella tua app, aggiungi alcune dipendenze e chiama [Monitor PulseSDK: @ "YOUR_APP_KEY"] all'interno della tua app main.m. Hai finito.
Spero di averti convinto di tre cose:
Ti incoraggio a esaminare le prestazioni del mondo reale della tua app. Dare una prova a Pulse.io. Non c'è molto da perdere e un sacco di prestazioni da ottenere.
Accentsconagua