Le d\u00e9marrage \u00e0 froid est la premi\u00e8re impression qu\u2019une application donne \u00e0 son utilisateur. Si elle met plus d\u2019une seconde \u00e0 devenir utilisable, nous avons d\u00e9j\u00e0 donn\u00e9 \u00e0 l\u2019utilisateur l\u2019impression qu\u2019il s\u2019agit d\u2019une application lente, quelle que soit la rapidit\u00e9 avec laquelle elle fonctionnera par la suite.<\/p>\n
C'est aussi le moment que les utilisateurs vivent le plus souvent. Une application de suivi des habitudes est ouverte pendant quelques secondes pour cocher une case. Une application de suivi des migraines est ouverte lorsqu'une personne ne se sent pas bien et souhaite noter rapidement son \u00e9tat. Pour ce type d'applications, le lancement n'est pas un simple pr\u00e9lude \u00e0 l'exp\u00e9rience : il constitue l'essentiel de celle-ci.<\/p>\n
Notre objectif est de moins de 600 ms<\/strong> De l\u2019appui sur une ic\u00f4ne \u00e0 l\u2019interface utilisateur interactive sur un iPhone vieux de cinq ans. Et cela, une fois que le syst\u00e8me d\u2019exploitation a charg\u00e9 le fichier binaire, allou\u00e9 de la m\u00e9moire et mis le thread principal \u00e0 notre disposition. Tout ce qui se passe entre ce transfert et la premi\u00e8re image rel\u00e8ve de notre responsabilit\u00e9.<\/p>\n \u201cLe mot cl\u00e9, c\u2019est \u201d interactif \u00bb. Un \u00e9cran de d\u00e9marrage qui s\u2019affiche instantan\u00e9ment puis reste fig\u00e9 ne compte pas. Pas plus qu\u2019une premi\u00e8re image remplie d\u2019\u00e9l\u00e9ments de remplissage qui se r\u00e9organisent quelques instants plus tard. L\u2019objectif, c\u2019est le moment o\u00f9 l\u2019on peut appuyer sur ce que l\u2019on est venu chercher et o\u00f9 cela r\u00e9agit.<\/p>\n Nous effectuons les mesures sur l'ancien appareil, et non sur le nouveau, pour la m\u00eame raison qui nous pousse \u00e0 effectuer ces tests : le t\u00e9l\u00e9phone le plus r\u00e9cent masquera pratiquement toutes les erreurs.<\/p>\n Atteindre ce chiffre met rapidement fin \u00e0 bien de discussions. Le r\u00e9seautage n\u2019est pas possible pendant la phase de lancement. Les SDK tiers sont difficiles \u00e0 faire accepter : la plupart d\u2019entre eux g\u00e9n\u00e8rent des t\u00e2ches en arri\u00e8re-plan avant Il en d\u00e9coule quelques principes. Le premier \u00e9cran s'appuie sur les donn\u00e9es d\u00e9j\u00e0 pr\u00e9sentes sur l'appareil ; ainsi, l'application affiche imm\u00e9diatement des informations r\u00e9elles et se met \u00e0 jour en arri\u00e8re-plan si n\u00e9cessaire. Les fonctionnalit\u00e9s qui ne sont pas n\u00e9cessaires sur le premier \u00e9cran ne sont activ\u00e9es que lorsque l'utilisateur en fait la demande. Et chaque fois que nous sommes tent\u00e9s d\u2019ajouter une biblioth\u00e8que, nous nous demandons d\u2019abord ce qu\u2019elle fait au lancement avant de nous demander ce qu\u2019elle peut nous apporter.<\/p>\n Cette rigueur a un co\u00fbt. Renoncer \u00e0 un SDK pratique implique parfois d\u2019\u00e9crire et de maintenir soi-m\u00eame le code \u00e9quivalent. Afficher en priorit\u00e9 les donn\u00e9es locales signifie concevoir l\u2019application en tenant compte du fait qu\u2019elles puissent \u00eatre l\u00e9g\u00e8rement obsol\u00e8tes. Le chargement diff\u00e9r\u00e9 n\u00e9cessite une attention particuli\u00e8re pour \u00e9viter tout ralentissement lors de la premi\u00e8re ouverture d\u2019un \u00e9cran plus lourd. Nous acceptons ces co\u00fbts car l\u2019alternative serait une petite perte de performance \u00e0 chaque lancement, pour toujours, pour tout le monde.<\/p>\n Le temps de lancement ne se d\u00e9t\u00e9riore que rarement d\u2019un seul coup. Il s\u2019\u00e9rode progressivement : un peu de code de configuration par-ci, une v\u00e9rification suppl\u00e9mentaire par-l\u00e0, chacun inoffensif en soi. Nous l\u2019avons appris \u00e0 nos d\u00e9pens, en remarquant trop tard qu\u2019une application mettait d\u00e9sormais plus de temps \u00e0 s\u2019ouvrir, sans qu\u2019aucun commit en particulier ne soit en cause. D\u00e9sormais, le temps de lancement est v\u00e9rifi\u00e9 sur l\u2019appareil de r\u00e9f\u00e9rence \u00e0 chaque version, ce qui permet de d\u00e9tecter les d\u00e9rives d\u00e8s qu\u2019elles sont encore minimes.<\/p>\n Ce principe s'applique \u00e9galement \u00e0 nos autres plateformes. Une application Windows ou une fen\u00eatre contextuelle d'extension de navigateur dispose de sa propre version du \u00ab d\u00e9marrage \u00e0 froid \u00bb, et la m\u00eame r\u00e8gle s'applique : afficher imm\u00e9diatement quelque chose d'utile, et remettre tout le reste \u00e0 plus tard.<\/p>\n La rigueur est rentable. Une fois que le lancement est rapide, tout le reste l'est aussi \u2014 car les m\u00eames r\u00e8gles s'appliquent partout.<\/p>","protected":false},"excerpt":{"rendered":" Pourquoi nous mesurons le temps de lancement d'une application en millisecondes \u2014 et pourquoi cela change la fa\u00e7on dont tout le reste est con\u00e7u.<\/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":"\nCe que cela impose<\/h2>\n
application(_:didFinishLaunching\u2026)<\/code> m\u00eame les r\u00e9sultats. Les caches d'images se chargent de mani\u00e8re diff\u00e9r\u00e9e. Les migrations de base de donn\u00e9es s'ex\u00e9cutent dans une file d'attente en arri\u00e8re-plan, sans jamais bloquer la file d'attente principale.<\/p>\nLes compromis<\/h2>\n
Nos erreurs<\/h2>\n
Pourquoi cela en vaut la peine<\/h2>\n