Todos os outros ecrãs desta app, tu escolheste abri-los. Este não — tocaste noutra coisa, e foi o bloqueio que te apanhou. Essa diferença muda completamente o desafio de engenharia. Um ecrã que pediste pode demorar um instante a aparecer; ninguém está a cronometrar. Um ecrã que te interrompe só tem uma oportunidade para não parecer uma falha do telemóvel, e tem de o provar em menos de um terço de segundo.
A única medição que importa
Não é a duração da animação de introdução — é o intervalo antes de ela começar. Porta, entrada, chão, teto, quadro, letreiro, relógio: a sequência tem um cronograma fixo, e cada um desses atrasos foi escolhido e verificado à mão. Nada disso importa se o próprio toque tiver uma hesitação antes. Uma entrada fantástica de 800ms escondida atrás de um ecrã branco vazio de 400ms lê-se como "esta app é lenta", ponto final — o polimento nunca chega a ser visto, porque o veredicto já caiu sobre o ecrã vazio.
Portanto, o verdadeiro objetivo não é "a animação parece suave". É "algo aparece antes de o utilizador ter tempo de se perguntar se o toque foi registado". Isso é, grosso modo, o mesmo orçamento de tempo de uma mudança de app do sistema — algumas centenas de milissegundos — e é um critério muito mais rigoroso do que o exigido à maioria das transições dentro da app.
Nunca bloquear o bloqueio
A sala de aula não pode esperar pela rede. Seja qual for a pergunta feita, tem de vir de dados que já estavam no dispositivo antes de teres tocado no ecrã — obtidos e guardados em cache com antecedência, nos teus termos, e não pedidos no momento em que já estás irritado a olhar para um indicador de carregamento. Se essa cache estiver alguma vez vazia, a falha honesta é um cartão de pergunta mais simples e estático, não uma roda de carregamento à frente de um professor que ainda não apareceu.
A mesma regra aplica-se aos recursos (assets). Um pedido de tipo de letra ou de imagem no caminho crítico é uma dependência de que a rede esteja rápida precisamente no momento em que estás a meio de uma interrupção — que é exatamente quando tens menos paciência para isso. Alojar nós mesmos os quatro tipos de letra que este site usa é o mesmo instinto aplicado à app: nada do que a introdução precisa deve poder falhar só porque alguém está com um Wi-Fi de hotel fraco.
Onde os frames realmente vão
Só propriedades de animação baratas — posição e opacidade, o tipo que um telemóvel consegue mover sem recalcular o layout por baixo, nunca nada que force um reflow a meio da sequência. Uma sala de aula que tem de aparecer com esta frequência não se pode dar ao luxo de ter sequer uma propriedade dispendiosa num dispositivo mais antigo, porque "dispositivo mais antigo" não é aqui um caso extremo — é uma grande parte de quem tem o telemóvel na mão exatamente no momento em que vai tocar em algo bloqueado.
O corolário é que a maior parte do que parece movimento na introdução é, na verdade, muito pouco movimento, bem encenado. Uma porta que abre, uma figura que dá quatro passos, um quadro que desliza para o lugar — nada disto envolve muitos pixels a mudar, envolve muitos pixels a mudar *no momento certo*, o que é um truque mais barato do que parece visto de fora.
Do que ainda não temos a certeza
O arranque a frio é a lacuna honesta. A primeiríssima interrupção depois de o telemóvel reiniciar, ou de a app ter sido encerrada em segundo plano, é mais lenta do que todas as seguintes, porque nada está ainda "quente" — sem pergunta em cache, sem tipos de letra já processados, sem o pacote de JS já residente em memória. Não temos uma solução limpa para essa "taxa" do primeiro toque, além de manter a app o mais leve possível e esperar que o sistema operativo não a feche demasiado depressa. Se o teu primeiríssimo bloqueio do dia parecer um pouco mais lento do que os restantes, é por isso, e não é algo que tenhamos decidido ignorar.
Os Android de gama baixa são a outra questão em aberto — os telemóveis para os quais isto mais importa, já que uma falha de dois segundos representa uma fração muito maior de um orçamento de 300ms nesses aparelhos do que num topo de gama. Estamos a construir tendo essa limitação em mente, não o dispositivo que calhamos ter na mão.