A obsessão pelo arranque a frio
O arranque a frio é a primeira impressão que uma aplicação transmite ao utilizador. Se demorar mais de um segundo a ficar operacional, já transmitimos à pessoa do outro lado a ideia de que se trata de uma aplicação lenta, independentemente da rapidez com que tudo o resto funcione a partir daí.
É também o momento que as pessoas vivem com mais frequência. Uma aplicação para registar hábitos é aberta durante alguns segundos para marcar algo como concluído. Uma aplicação para registar enxaquecas é aberta quando alguém se sente mal e quer registar isso rapidamente. Para aplicações como estas, a abertura não é um prelúdio da experiência — é a maior parte da experiência.
O nosso objetivo
O nosso objetivo é menos de 600 ms Desde o toque num ícone até à interface de utilizador interativa num iPhone com cinco anos. Isso acontece depois de o sistema operativo ter carregado o ficheiro binário, atribuído memória e-nos ter passado o fio condutor principal. Tudo o que acontece entre essa transferência e o primeiro fotograma fica a nosso cargo.
“Interativo” é a palavra-chave. Um ecrã inicial que aparece instantaneamente e depois fica ali parado não conta. Nem um primeiro fotograma cheio de marcadores de posição que se reorganizam um momento depois. O objetivo é o momento em que se pode tocar naquilo que se veio procurar e este responde.
Fazemos as medições no aparelho antigo, e não no novo, pela mesma razão pela qual fazemos os testes nesse aparelho: o telemóvel mais recente irá disfarçar praticamente qualquer erro.
O que isso implica
Atingir esse número põe fim a muitas discussões logo no início. O networking não pode ocorrer na fase de lançamento. Os SDKs de terceiros são difíceis de vender — a maioria deles gera tarefas em segundo plano antes de application(_:didFinishLaunching…) retorna sempre. As caches de imagens são carregadas de forma diferida. As migrações da base de dados são executadas numa fila em segundo plano, sem nunca bloquear a fila principal.
Daí decorrem alguns hábitos. O primeiro ecrã é construído a partir de dados que já se encontram no dispositivo, pelo que a aplicação mostra imediatamente algo concreto e atualiza-se discretamente caso seja necessário. As funcionalidades que não são necessárias no primeiro ecrã só são configuradas quando alguém 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ós.
As vantagens e desvantagens
Esta disciplina tem o seu preço. Recusar um SDK conveniente significa, por vezes, ter de escrever e manter nós próprios o código equivalente. Apresentar primeiro os dados locais implica conceber a aplicação 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ã mais pesado. Aceitamos esses custos porque a alternativa é um pequeno impacto em cada lançamento, para sempre, para todos.
O que fizemos de errado
O tempo de arranque raramente sofre uma alteração drástica de uma só vez. É um processo gradual: um pouco de código de configuração aqui, uma verificação extra ali, cada uma inofensiva por si só. Aprendemos isso da maneira mais difícil, ao percebermos tarde demais que uma aplicação tinha ficado mais lenta a abrir, sem que houvesse um único commit a que se pudesse atribuir a culpa. Agora, o tempo de arranque é verificado no dispositivo de referência como parte de cada lançamento, para que qualquer desvio seja detetado enquanto ainda é pequeno.
O mesmo princípio aplica-se às nossas outras plataformas. Uma aplicação Windows ou um pop-up de uma extensão do navegador tem a sua própria versão de «arranque a frio», e aplica-se a mesma regra: mostrar imediatamente algo útil e adiar tudo o resto.
Por que vale a pena
A disciplina compensa. Quando o lançamento é rápido, tudo o resto também o é — porque as mesmas regras aplicam-se em todo o lado.