A máquina s40 tem melhor memória para jogos, ciência popular.

Existem dois tipos principais de uso de memória, nomeadamente programas e recursos. ·A classe do programa será compilada em um arquivo de bytecode de classe e carregada na memória quando o MIDlet for iniciado, e será adicionada de uma só vez. Ou seja, quanto mais classes houver no MIDlet, mais longo será um programa de classe única e quanto mais constantes de string e dados dentro da classe, maior será o arquivo de classe compilado e mais memória ele ocupará após o carregamento. Costumo usar o método Runtime no construtor da classe MIDlet para verificar a quantidade de memória ocupada por todo o programa após o início do MIDlet. //Método de otimização: 1. O programa MIDlet é escrito em duas classes para reduzir o uso de memória, mas às custas dos recursos OOP do Java. Esta desvantagem será particularmente óbvia quando o programa for relativamente grande. Além disso, uma vez o CoCoMo encontrou uma situação em que uma única classe era muito grande e o tempo de carregamento era muito longo, o que violou o limite de 6 segundos no logotipo do baú do tesouro. //2. Tente escrever um código elegante, reduza o número de funções, remova o try catch quando o programa for lançado e minimize o número de linhas do programa. Geralmente isso não é possível no antigo 40, mas agora o CoCoMo não depende mais disso para economizar memória. //3. Grave dados e strings em arquivos, carregue-os na memória quando estiverem em uso e defina-os como nulos quando não estiverem em uso. 4. Operação de E/S getClass(). getResourceAsStream(file);, operação de banco de dados RecordStore. openRecordStore(nome, true);, Gerenciador de criação de som. createPlayer();, criação de imagem Image. criarImagem(arquivo); ocupará uma grande quantidade de memória em um curto período de tempo e a liberará mais tarde. Se a memória restante do programa MIDlet for insuficiente, ocorrerá um estouro de memória quando essas funções forem chamadas com frequência, resultando no chamado pico de memória, que é especialmente comum nos antigos 40. Ao encontrar OutOfMemoryError novamente, use Runtime para encontrar o local onde ocorre o pico de memória e tente chamar essas instruções separadamente e faça uso flexível de System. gc() para coletar a tempo. //·Recursos Imagens: Ocupam grande quantidade de memória, principalmente jogos mobile com muitos recursos de imagens. Calcular o uso de memória de recursos de imagem tornou-se uma tarefa regular para desenvolvedores de jogos J2ME. CoCoMo explicará como calcular o uso de memória das imagens: //Uso de memória = largura * altura * número de bytes de pixel, onde o número de bytes de pixel varia dependendo do modelo. //Por exemplo, o uso de memória de uma imagem 64*64 no 7210 = 64*64*1,5 = 614 4 (bytes) = 6K, uso de memória no S60 = 64*64*2 = 8192 (bytes) = 8K. O número de bytes de pixel varia de acordo com o modelo. Por exemplo, o 7210 é um modelo de 4.096 cores, o que significa que 12 bits são usados ​​para representar um pixel, então multiplique por 1,5, enquanto o S60 é um modelo de 65.536 cores, e 16 bits são usados ​​para representar um pixel, então multiplique por 2. //Método de otimização//É errado pensar que compactar imagens pode economizar memória. De acordo com a explicação acima, depois que a imagem é carregada na memória, ela está relacionada apenas à largura e altura, e não tem nada a ver com o tamanho dos dados da imagem. A compactação da imagem só pode reduzir o tamanho do jar, mas não o uso de memória. //1. Método estático: Reduza o tamanho da imagem. Se a largura e a altura forem menores, o resultado será menor. Com base nessa ideia, surgiram ferramentas como editores de animação, como o Prince of Persia da Gameloft. Após a divisão dos personagens, as partes do corpo humano podem ser reaproveitadas. O posicionamento compacto de cada parte visa reduzir o tamanho da imagem e aproveitar ao máximo cada centímetro de espaço da imagem. //2. Método dinâmico: Reduza o número de imagens carregadas na memória ao mesmo tempo. CoCoMo uma vez encontrou esta situação no projeto Naruto Samurai. Havia 6 tipos de monstros naquela época. Se eles fossem carregados na memória ao mesmo tempo, definitivamente explodiria nos antigos 40. No entanto, apenas dois ou três tipos de monstros apareciam em cada nível, então cada nível só precisava carregar as imagens dos monstros que apareciam naquele nível. Agora que penso neste projeto, estouros ocorriam com frequência no antigo 40. //Som//O som também é um recurso que consome relativamente memória. Os bytes ocupados pela trilha de áudio no som serão convertidos em um fluxo de bytes e carregados na memória. Portanto, reduzir os bytes ocupados pela trilha de áudio pode reduzir o consumo de memória. A abordagem atual da Gameloft é usar uma ferramenta de conversão de som para converter mid em ott e, em seguida, transformá-lo em um fluxo de bytes ByteArrayInputStream para criar um Player.