L'avvio a freddo \u00e8 la prima promessa che un'app fa al proprio utente. Se ci vuole pi\u00f9 di un secondo prima che diventi utilizzabile, abbiamo gi\u00e0 fatto capire a chi la sta utilizzando che si tratta di un'app lenta, indipendentemente dalla velocit\u00e0 con cui funzioner\u00e0 in seguito.<\/p>\n
\u00c8 anche il momento che gli utenti vivono pi\u00f9 spesso. Un\u2019app per monitorare le abitudini viene aperta per pochi secondi per spuntare qualcosa. Un\u2019app per monitorare l\u2019emicrania viene aperta quando qualcuno non si sente bene e vuole registrare rapidamente il disturbo. Per app come queste, l\u2019avvio non \u00e8 un preludio all\u2019esperienza: \u00e8 la maggior parte dell\u2019esperienza stessa.<\/p>\n
Il nostro obiettivo \u00e8 meno di 600 ms<\/strong> Dal tocco dell\u2019icona all\u2019interfaccia utente interattiva su un iPhone di cinque anni fa. Questo avviene dopo che il sistema operativo ha caricato il file binario, allocato la memoria e ci ha fornito il thread principale. Tutto ci\u00f2 che accade tra quel passaggio di consegne e il primo fotogramma dipende da noi.<\/p>\n \u201cInterattivo\u201d \u00e8 la parola chiave. Una schermata iniziale che appare all\u2019istante e poi rimane l\u00ec ferma non conta. E nemmeno un primo fotogramma pieno di segnaposto che si riorganizzano un attimo dopo. L\u2019obiettivo \u00e8 il momento in cui puoi toccare ci\u00f2 che stavi cercando e questo risponde.<\/p>\n Effettuiamo le misurazioni sul vecchio dispositivo, non su quello nuovo, proprio per lo stesso motivo per cui effettuiamo i test proprio l\u00ec: il telefono pi\u00f9 recente nasconderebbe praticamente qualsiasi errore.<\/p>\n Raggiungere quella cifra mette subito fine a molte discussioni. Il networking non pu\u00f2 avvenire durante la fase di lancio. Gli SDK di terze parti sono difficili da far accettare: la maggior parte di essi genera attivit\u00e0 in background prima che Da ci\u00f2 derivano alcune abitudini. La prima schermata viene generata dai dati gi\u00e0 presenti sul dispositivo, quindi l\u2019app mostra immediatamente contenuti reali e si aggiorna in modo discreto se necessario. Le funzionalit\u00e0 non necessarie nella prima schermata non vengono configurate finch\u00e9 qualcuno non le richiede. E ogni volta che siamo tentati di aggiungere una libreria, ci chiediamo innanzitutto quale sia la sua funzione al momento del lancio, prima ancora di chiederci cosa possa fare per noi.<\/p>\n Questa disciplina ha un costo. Rinunciare a un SDK pronto all\u2019uso a volte significa scrivere e mantenere da soli il codice equivalente. Mostrare prima i dati locali significa progettare tenendo conto del caso in cui questi siano leggermente obsoleti. Il caricamento differito richiede un\u2019attenzione particolare per evitare rallentamenti la prima volta che si apre una schermata pi\u00f9 pesante. Accettiamo questi costi perch\u00e9 l\u2019alternativa \u00e8 un piccolo rallentamento ad ogni singolo avvio, per sempre, per tutti.<\/p>\n Il tempo di avvio raramente subisce un cambiamento drastico in un colpo solo. Si deteriora gradualmente: un po\u2019 di codice di configurazione qui, un controllo in pi\u00f9 l\u00e0, ciascuno innocuo di per s\u00e9. L\u2019abbiamo imparato a nostre spese, accorcendocene troppo tardi che un\u2019app era diventata pi\u00f9 lenta ad aprirsi senza che ci fosse un singolo commit da incolpare. Ora il tempo di avvio viene verificato sul dispositivo di riferimento come parte integrante di ogni release, in modo che eventuali scostamenti vengano individuati quando sono ancora minimi.<\/p>\n Lo stesso principio vale anche per le nostre altre piattaforme. Un'app Windows o un popup di un'estensione del browser hanno una propria versione di \"cold start\", e vale la stessa regola: mostrare subito qualcosa di utile, rimandando tutto il resto.<\/p>\n La disciplina si ripaga da sola. Quando il lancio \u00e8 veloce, lo \u00e8 anche tutto il resto \u2014 perch\u00e9 le stesse regole valgono ovunque.<\/p>","protected":false},"excerpt":{"rendered":" Perch\u00e9 misuriamo il tempo di avvio delle app in millisecondi \u2014 e perch\u00e9 questo cambia il modo in cui viene sviluppato tutto il resto.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-570","post","type-post","status-publish","format-standard","hentry","category-journal"],"yoast_head":"\nCosa impone<\/h2>\n
application(_:didFinishLaunching\u2026)<\/code> restituisce anche i risultati. Le cache delle immagini vengono caricate in modo differito. Le migrazioni del database vengono eseguite in una coda in background, senza mai bloccare quella principale.<\/p>\nI compromessi<\/h2>\n
Cosa abbiamo sbagliato<\/h2>\n
Perch\u00e9 ne vale la pena<\/h2>\n