O arranque a frio \u00e9 a primeira impress\u00e3o que uma aplica\u00e7\u00e3o transmite ao utilizador. Se demorar mais de um segundo a ficar operacional, j\u00e1 transmitimos \u00e0 pessoa do outro lado a ideia de que se trata de uma aplica\u00e7\u00e3o lenta, independentemente da rapidez com que tudo o resto funcione a partir da\u00ed.<\/p>\n
\u00c9 tamb\u00e9m o momento que as pessoas vivem com mais frequ\u00eancia. Uma aplica\u00e7\u00e3o para registar h\u00e1bitos \u00e9 aberta durante alguns segundos para marcar algo como conclu\u00eddo. Uma aplica\u00e7\u00e3o para registar enxaquecas \u00e9 aberta quando algu\u00e9m se sente mal e quer registar isso rapidamente. Para aplica\u00e7\u00f5es como estas, a abertura n\u00e3o \u00e9 um prel\u00fadio da experi\u00eancia \u2014 \u00e9 a maior parte da experi\u00eancia.<\/p>\n
O nosso objetivo \u00e9 menos de 600 ms<\/strong> Desde o toque num \u00edcone at\u00e9 \u00e0 interface de utilizador interativa num iPhone com cinco anos. Isso acontece depois de o sistema operativo ter carregado o ficheiro bin\u00e1rio, atribu\u00eddo mem\u00f3ria e-nos ter passado o fio condutor principal. Tudo o que acontece entre essa transfer\u00eancia e o primeiro fotograma fica a nosso cargo.<\/p>\n \u201cInterativo\u201d \u00e9 a palavra-chave. Um ecr\u00e3 inicial que aparece instantaneamente e depois fica ali parado n\u00e3o conta. Nem um primeiro fotograma cheio de marcadores de posi\u00e7\u00e3o que se reorganizam um momento depois. O objetivo \u00e9 o momento em que se pode tocar naquilo que se veio procurar e este responde.<\/p>\n Fazemos as medi\u00e7\u00f5es no aparelho antigo, e n\u00e3o no novo, pela mesma raz\u00e3o pela qual fazemos os testes nesse aparelho: o telem\u00f3vel mais recente ir\u00e1 disfar\u00e7ar praticamente qualquer erro.<\/p>\n Atingir esse n\u00famero p\u00f5e fim a muitas discuss\u00f5es logo no in\u00edcio. O networking n\u00e3o pode ocorrer na fase de lan\u00e7amento. Os SDKs de terceiros s\u00e3o dif\u00edceis de vender \u2014 a maioria deles gera tarefas em segundo plano antes de Da\u00ed decorrem alguns h\u00e1bitos. O primeiro ecr\u00e3 \u00e9 constru\u00eddo a partir de dados que j\u00e1 se encontram no dispositivo, pelo que a aplica\u00e7\u00e3o mostra imediatamente algo concreto e atualiza-se discretamente caso seja necess\u00e1rio. As funcionalidades que n\u00e3o s\u00e3o necess\u00e1rias no primeiro ecr\u00e3 s\u00f3 s\u00e3o configuradas quando algu\u00e9m as solicita. E sempre que nos sentimos tentados a adicionar uma biblioteca, perguntamos o que ela faz no momento do arranque antes de perguntarmos o que ela faz por n\u00f3s.<\/p>\n Esta disciplina tem o seu pre\u00e7o. Recusar um SDK conveniente significa, por vezes, ter de escrever e manter n\u00f3s pr\u00f3prios o c\u00f3digo equivalente. Apresentar primeiro os dados locais implica conceber a aplica\u00e7\u00e3o tendo em conta a possibilidade de estes estarem ligeiramente desatualizados. O carregamento diferido exige um cuidado redobrado para evitar atrasos na primeira vez que se abre um ecr\u00e3 mais pesado. Aceitamos esses custos porque a alternativa \u00e9 um pequeno impacto em cada lan\u00e7amento, para sempre, para todos.<\/p>\n O tempo de arranque raramente sofre uma altera\u00e7\u00e3o dr\u00e1stica de uma s\u00f3 vez. \u00c9 um processo gradual: um pouco de c\u00f3digo de configura\u00e7\u00e3o aqui, uma verifica\u00e7\u00e3o extra ali, cada uma inofensiva por si s\u00f3. Aprendemos isso da maneira mais dif\u00edcil, ao percebermos tarde demais que uma aplica\u00e7\u00e3o tinha ficado mais lenta a abrir, sem que houvesse um \u00fanico commit a que se pudesse atribuir a culpa. Agora, o tempo de arranque \u00e9 verificado no dispositivo de refer\u00eancia como parte de cada lan\u00e7amento, para que qualquer desvio seja detetado enquanto ainda \u00e9 pequeno.<\/p>\n O mesmo princ\u00edpio aplica-se \u00e0s nossas outras plataformas. Uma aplica\u00e7\u00e3o Windows ou um pop-up de uma extens\u00e3o do navegador tem a sua pr\u00f3pria vers\u00e3o de \u00abarranque a frio\u00bb, e aplica-se a mesma regra: mostrar imediatamente algo \u00fatil e adiar tudo o resto.<\/p>\n A disciplina compensa. Quando o lan\u00e7amento \u00e9 r\u00e1pido, tudo o resto tamb\u00e9m o \u00e9 \u2014 porque as mesmas regras aplicam-se em todo o lado.<\/p>","protected":false},"excerpt":{"rendered":" Porque medimos o tempo de arranque das aplica\u00e7\u00f5es em milissegundos \u2014 e porque \u00e9 que isso muda a forma como tudo o resto \u00e9 feito.<\/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":"\nO que isso implica<\/h2>\n
application(_:didFinishLaunching\u2026)<\/code> retorna sempre. As caches de imagens s\u00e3o carregadas de forma diferida. As migra\u00e7\u00f5es da base de dados s\u00e3o executadas numa fila em segundo plano, sem nunca bloquear a fila principal.<\/p>\nAs vantagens e desvantagens<\/h2>\n
O que fizemos de errado<\/h2>\n
Por que vale a pena<\/h2>\n