Gerenciar a quantidade de memória utilizada é importante para garantir que uma ampla variedade de dispositivos possa executar o seu projeto. Reduzir o uso de memória também pode, em alguns casos, melhorar o desempenho.
Imagens
Normalmente, as imagens de objetos (incluindo animações de sprites) são a parte que consome mais memória em um projeto. Por esse motivo, o Construct estima o uso máximo de memória a partir das imagens e o exibe na caixa de diálogo Estatísticas do Projeto. (Clique com o botão direito no nome do projeto na Barra de Projetos e selecione Ferramentas ► Visualizar estatísticas do projeto para abrir a caixa de diálogo.) Você deve verificar isso de tempos em tempos durante o desenvolvimento do seu projeto, mas lembre-se de que isso deve ser considerado apenas uma estimativa. Lembre-se de que isso se baseia apenas nas imagens, portanto, seu projeto precisará de pelo menos essa quantidade de memória para ser executado. O post do blog "Lembre-se de não desperdiçar sua memória" oferece conselhos sobre como projetar projetos da melhor maneira para minimizar o uso de memória e evitar erros comuns que consomem memória.
O uso estimado de memória máximo é baseado apenas no layout único com o maior requisito de memória, porque apenas as imagens de um layout são carregadas de cada vez. No Construct, isso é chamado de carregamento layout por layout.
Carregamento layout por layout
O Construct carrega apenas as imagens do layout atual. Isso evita o carregamento de todo o projeto na memória, o que seria lento e consumiria uma grande quantidade de memória. Ao iniciar um layout, todas as imagens dos objetos colocados na Visualização do Layout são pré-carregadas. Isso inclui todos os quadros em todas as animações de quaisquer objetos Sprite. (Em outras palavras, os Sprites são carregados totalmente na memória ou não são carregados de forma alguma - eles nunca são carregados parcialmente.) Quando o layout termina, todas as imagens que foram carregadas mas não são usadas no próximo layout são liberadas da memória.
Se um objeto não for colocado na visualização do layout, mas eventos o criarem durante a execução, suas imagens não são pré-carregadas. O Construct é forçado a carregar as imagens do objeto no momento da criação, o que pode causar uma pausa momentânea ou, em casos extremos, uma interrupção constante (também conhecida como "jank"). Para evitar isso, coloque todos os objetos que serão usados pelo layout na Visualização do Layout. Se eles não forem necessários imediatamente, eles podem ser destruídos em um evento "Início de layout". Eles não existirão quando o layout começar, mas o Construct ainda terá pré-carregado suas imagens, garantindo que eles possam ser criados posteriormente durante a execução sem qualquer interrupção.
Calculando o uso de memória de imagens
Em primeiro lugar, é importante observar que o formato da imagem não afeta o uso de memória. Você pode economizar no tamanho de download do seu projeto definindo algumas imagens como formato PNG-8 ou JPEG no editor de imagens. No entanto, isso não afeta o uso de memória: imagens compactadas não podem ser diretamente renderizadas, então, ao serem carregadas, todas as imagens são descompactadas em um formato bitmap ARGB de 32 bits. Isso significa que cada pixel ocupa quatro bytes para os canais alfa, vermelho, verde e azul.
Consequentemente, o uso aproximado de memória de uma imagem é simplesmente o número de pixels multiplicado por 4. Por exemplo, uma imagem de 100x100 usaria 100 x 100 x 4 = 40000 bytes, ou cerca de 39 KB. Uma imagem em alta definição com tamanho de 1920x1080 ocuparia 1920 x 1080 x 4 = 8294400 bytes, ou cerca de 7,9 MB. Portanto, uma boa técnica para minimizar o uso de memória é usar imagens menores. Como destaca o post do blog "Lembre-se de não desperdiçar sua memória", o uso de muitas imagens grandes rapidamente resultará em um enorme requisito de memória e deve ser evitado.
Também é importante observar que o uso de memória é baseado na imagem de origem - ou seja, como ela aparece no editor de imagens. Se o objeto for esticado na visualização do layout ou durante a execução, ele não usará mais nem menos memória. Ele apenas renderiza a imagem de origem na memória (que sempre está no tamanho original) em um tamanho diferente na tela. Uma boa maneira de criar preenchimentos ou gradientes que economizem memória é ter uma imagem muito pequena (por exemplo, 32x32) com um preenchimento e, em seguida, esticá-la muito na visualização do layout.
Não utilize de forma inadequada a 'Qualidade de redimensionamento'
O Construct utiliza várias otimizações, incluindo a criação de folhas de sprite, para economizar memória. Definir a propriedade de projeto "Qualidade de redimensionamento" como "Alta qualidade" força a criação de folhas de sprite para ajustar todos os sprites a tamanhos de potência de dois, anulando a economia de memória das folhas de sprite. Isso pode aumentar significativamente o requisito de memória do seu projeto. O modo de alta qualidade existe apenas para resolver dois problemas relativamente pequenos de renderização (bordas borradas em sprites ou qualidade alterada no último quadro de animação). Ele não deve ser usado a menos que um desses problemas de renderização tenha sido especificamente observado e o problema seja resolvido escolhendo essa opção. Caso contrário, seu projeto estará pagando um preço muito alto em termos de uso de memória sem motivo.
Áudio
Normalmente, as imagens representam a maior parte do uso de memória em um projeto. No entanto, vale a pena entender como o áudio é carregado na memória.
É importante categorizar o áudio entre as pastas de "Som" e "Música" porque eles são carregados de maneiras diferentes e, portanto, têm diferentes usos de memória.
Sons
O áudio na pasta de "Sons" é totalmente descompactado na memória. Isso permite que os efeitos sonoros sejam reproduzidos instantaneamente, sem qualquer latência causada pelo carregamento ou descompressão do áudio, garantindo que os efeitos sonoros sejam ouvidos no momento apropriado. Assim como nas imagens, o tamanho compactado ajuda a reduzir o tempo de download, mas não reduz o uso de memória: o som será descompactado em buffers de onda PCM.
Por padrão, a propriedade do projeto "Pré-carregar sons" está ativada, o que significa que todos os sons são baixados e descompactados enquanto a barra de carregamento é exibida. Como resultado, todos os sons no projeto serão descompactados na memória durante a inicialização. Com uma configuração comum de reprodução de amostras de 16 bits a 44,1 KHz, um segundo de áudio de um único canal usará 88.000 bytes (cerca de 86 KB), e o dobro disso para estéreo (cerca de 172 KB). Para um minuto de áudio, isso representa cerca de 5 MB para um canal único e 10 MB para estéreo. Essa é a principal razão pela qual as faixas de música não devem ser categorizadas como "som": se você tiver 15 minutos de música estéreo, isso consumirá 150 MB de memória. Em algumas plataformas, a decodificação de uma faixa de música completa também pode ser bastante lenta, adicionando muito ao tempo de inicialização.
Se a opção "Pré-carregar sons" estiver desativada, os sons não serão carregados durante a inicialização e o projeto poderá iniciar mais rapidamente. No entanto, a primeira vez que cada som for reproduzido pode ser adiada, pois ele deve ser baixado e decodificado completamente. Usar a ação "Pré-carregar" no objeto de Áudio pode ajudar a mitigar esse problema. Observe que o Construct não libera os sons uma vez carregados para garantir que eles possam ser reproduzidos rapidamente novamente. Para liberar a memória, você deve usar uma das ações de "Descarregar". Isso o torna responsável pelo gerenciamento de memória de áudio em seu projeto.
O áudio na pasta de "Sons" deve ser usado para efeitos sonoros curtos e sensíveis à latência. Considere reduzir a duração de efeitos sonoros muito longos ou, se a latência de reprodução não for importante, considere categorizá-los como "Música" em vez disso.
Música
Ao contrário dos efeitos sonoros, a música é transmitida. Geralmente, isso significa que o mecanismo de áudio terá um pequeno buffer de reprodução com um comprimento fixo e, enquanto o áudio está sendo reproduzido, ele é carregado, decodificado e reproduzido em pequenos fragmentos que se conectam perfeitamente. Isso significa que o uso de memória é baixo, independentemente do tamanho da faixa e, em alguns casos, ela pode começar a ser reproduzida antes mesmo de terminar o download. É por isso que a música não é pré-carregada enquanto a barra de carregamento é exibida - não há necessidade de esperar que o download termine antes de iniciar o projeto. No entanto, a reprodução nem sempre pode começar imediatamente, pois pode ser necessário aguardar o término do buffer de download ou o carregamento e decodificação do primeiro fragmento. Em termos de uso de memória, a principal consideração é garantir que faixas de áudio longas sejam categorizadas como música e não som.