Tenho trabalhado muito com o Snap.svg recentemente e o senhor já deve ter visto um artigo há algum tempo sobre animações SVG.
Depois que o artigo foi publicado, tirei um tempo para revisar o código que havia escrito e descobri que havia criado alguns vazamentos de memória. A menos que o senhor monitore o desempenho do seu site, normalmente não perceberia que isso estava ocorrendo. Para mostrar aos senhores como encontrar vazamentos de memória, usarei como exemplo a animação Hill Valley que escrevi.
Chromes ‘Take Heap Snapshot’ (Tire uma foto da pilha)
O Chrome tem algumas ferramentas excelentes para entender se o senhor está introduzindo vazamentos de memória. A maneira mais fácil de fazer isso é usar “Take Heap Snapshot”. Encontrado em Ferramentas do desenvolvedor -> Perfis. Basta pressionar o botão de registro.
A primeira coisa a verificar é se uma animação em loop causou o vazamento de memória. Para fazer isso, tire um instantâneo do heap em uma série de intervalos. Como o senhor pode ver abaixo, o tamanho da memória está crescendo inexplicavelmente.
Agora que temos esses instantâneos, podemos usar a ferramenta de comparação para descobrir onde está o principal crescimento na memória. Para fazer isso, escolha o último instantâneo e clique em “Comparison” (Comparação) no menu suspenso de resumo.
Agora, escolha seu primeiro snapshot no menu suspenso à direita do filtro de classe.
Uma vez que o Chrome tenha descoberto o que precisa para classificar sua tabela pelo #Delta. Agora o senhor verá de onde vêm esses vazamentos. Comece no topo e vá descendo. Observe que nem todas essas coisas novas serão vazamentos de memória; às vezes, a memória é simplesmente necessária.
Quando cliquei no meu #Delta superior, pude ver no rastreamento de pilha que o evento de finalização do snap.svg e o algoritmo de atenuação do mina causaram isso. Muitas partes do código podem causar isso, o que discutirei agora.
O algoritmo Mark-and-Sweep
Infelizmente, com a maneira como, às vezes, escrevemos animações em JavaScript, podemos facilmente introduzir padrões que o algoritmo Mark-and-Sweep para coleta de lixo não detectará.
O algoritmo Mark-and-Sweep, em termos simples, funciona tentando descobrir se um objeto é inalcançável. Se ele descobrir que o objeto é inacessível, aplicará a coleta de lixo a esse objeto.
Isso significa que, quando o senhor cria um singleton de uma biblioteca de animação em um loop, mas nunca define essa atribuição como nula, a coleta de lixo nunca será aplicada a esse objeto. Como um objeto ainda pode ser acessado.
A maneira mais fácil de superar isso é simplesmente redefinir a variável como nula quando a animação terminar.
Animações em desenvolvimento
Com o uso de bibliotecas de animação, é muito fácil ter animações acumuladas na memória. A maioria das bibliotecas tem uma função incorporada para tentar superar isso. Como criamos o tutorial anterior com o Snap.SVG, explicarei sua versão.
O Snap.SVG usa o mesmo método que o jQuery, que é o stop() . Ele interrompe todas as animações enfileiradas e continua com a nova animação.
Os temporizadores nunca são apagados
Provavelmente o vazamento de memória mais comum, não apenas em animações, mas em interfaces de UI em geral na Web. Se o senhor não remover a referência a um timer, ele simplesmente ficará na memória e nunca será removido pela coleta de lixo.
Para a maioria dos aplicativos, isso não é um problema, pois a atualização da página ao mudar entre as páginas o removerá. Entretanto, agora que a Web está repleta de aplicativos de uma página, o senhor pode ver como isso se torna um problema rapidamente.
A melhor maneira de limpar os temporizadores é adicioná-los a uma matriz e, em seguida, quando o senhor achar melhor, geralmente no início de uma nova animação ou logo antes de uma transição de página js. Limpe esses temporizadores e redefina a matriz.
