Problemas com carregamento de imagem em aplicações J2ME em telefones Motorola

votos
2

A forma padrão para carregar uma imagem em um aplicativo J2ME é usando o método Image.createImage eo formato de imagem recomendada é PNG.

Agora, as especificações J2ME não estabelece quaisquer restrições sobre a implementação deste método ou a representação em memória de uma imagem de forma, cada fornecedor tem uma implementação diferente.

Motorola em particular, tem essa implementação realmente de baixa qualidade onde no PNG é completamente decodificado em matriz de bytes ARGB no momento da criação da imagem. Isto significa que um 8K png com as dimensões 176x208 ocupa uma memória de pico de cerca de 170K para carregar e a memória utilizada pelo próprio objeto de imagem é de cerca de 145K! Em outros telefones, como Nokia, Sony Ericsson etc, a mesma imagem só leva cerca de 16K para carregar e armazenar em memory.I não sei o que otimizações inteligentes que utilizam, mas por alguma razão incompreensível, JVM da Motorola não.

Isso está causando estragos em meu aplicativo J2ME, tornando quase impossível de executar uma versão decente do que em telefones Motorola. Eu tentei várias soluções alternativas como o uso de uma matriz de bytes ARGB compactados com o gzip da imagem e esvaziando-lo durante a pintura, mas isso faz com que a tinta para retardar por um fator de 10!

Alguém sabe de uma solução para este problema? Uma fonte PNG decoder imagem aberta para J2ME com a inteligência que a Motorola faltam? Ou há algo que pode ser feito para a imagem PNG para reduzir sua pegada na memória? (I usado atualmente modo indexado PNG) Os ponteiros em tudo seria bem-vindo ..

Gowri

Publicado 05/11/2008 em 15:11
fonte usuário
Em outras línguas...                            


6 respostas

votos
3

Uma coisa sobre a Sony Ericsson. Não lhes dê tanto crédito. Eles tomam (image_width x image_height x bytes_per_pixel) de memória, bem ao carregar imagens.

Do desenvolvedor doc SE J2ME, " Todas as imagens são armazenadas na memória do telefone em um 16-bit por pixel formato RGB, possivelmente com um 1-bit ou 8-bits por canal de pixel alfa. " Então, pelo menos 2 bytes. A diferença é que os telefones Sony Ericsson (Eu não posso falar para Nokia) tem um bloco de memória separado para imagens que fica cheio antes de colocar imagens na pilha (você pode ver isso por embalar a carga com Runtime.getRuntime (). FreeMemory () ... o tamanho da pilha vai aumentar em apenas um par de bytes, que é o tamanho da nova Object).

Esta não é a defesa da Motorola como eu certos tiveram meus problemas de portabilidade de telefones SE a Motorola, mas não é porque SE foi capaz de descobrir uma maneira de armazenar imagens em montão de uma forma muito mais otimizado. Motorola apenas armazena tudo na pilha, e é por isso que você correr para fora mais rápido.

As imagens menores é uma boa idéia, não só durante a parte descodificador, mas de um ponto fragmentação heap de vista. Ele permitirá que as imagens para caber em blocos menores de memória em vez de um bloco contínuo grande.

Respondeu 15/11/2008 em 20:46
fonte usuário

votos
1

Bem, a maneira que eu vejo, se todos os formatos de imagem são imediatamente decodificado em uma matriz ARGB quando você criar as imagens, a única coisa que você realmente pode fazer é criar um limite superior para a quantidade de memória que você vai usar para mostrar as coisas na tela.

Você pode criar um cache de imagem que vai saber o quanto memória heap cada imagem é utilizando para esse dispositivo específico, carregamento e descarregamento de imagens são eles são necessários. É claro que isso significa confiar no Grabage Collector talvez muito para manter seu aplicativo responsivo.

gerenciamento de cache provavelmente precisará acontecer em um segmento dedicado.

Mantendo apenas uma pena de tela de imagens carregadas a qualquer momento poderia funcionar se suas telas de aplicativos são estáticos suficiente para não exigir muito de animação.

Também lembro que MIDP lona geralmente não redefinir-se. Se você usar 2 chamadas diferentes para Canvas.paint () para pintar 2 imagens diferentes em 2 diferentes áreas da tela, você deve ser capaz de manter ambas as imagens exibidas por muito tempo após os reais Objetos de imagem ter sido coletado como lond como você don' t pintar nada em cima deles.

Do ponto de vista puramente comercial, é preciso capacidade de dizer a seus clientes que alguns telefones só tem uma implementação do Java tão ruim que você não está indo para apoiá-los.

Respondeu 06/11/2008 em 11:50
fonte usuário

votos
0

Uma maneira de diminuir uma imagem png seria para executá-los através de um programa como o png desafio para reduzir seu tamanho.

Respondeu 27/04/2009 em 15:41
fonte usuário

votos
0

A solução seria melhor é a de armazenar a ARGB como dados (utilizar algum tipo de indexação para comprimindo-o) com advantanges de mudança paleta etc / não PNG Cabeçalho /. em vez de armazenar diferentes imagens PNG e usar a função createImage para criar a imagem.

Respondeu 18/11/2008 em 06:35
fonte usuário

votos
0

Fórum do desenvolvedor Motorola sugere que você cortar imagens maiores até tiras menores e carregar estas tiras menores em vez de toda a imagem grande em um tiro. Note que isso não reduzir o em espaço de memória das imagens. Que ainda precisa sum (largura * altura * bytes-per-pixel) de todas as faixas. Mas reduz a memória necessária para decodificar a imagem png e carregá-lo para cima. Então, isso é o que eu estou fazendo agora. Ela tem ajudado alguns. Mas o uso geral da memória ainda é um problema.

Respondeu 10/11/2008 em 14:43
fonte usuário

votos
0

PNG tendem a ser bloaty.

Por que não usar gif vez.

http://www.ddj.com/mobile/184406435;jsessionid=SBUQN2ECITM5OQSNDLOSKHSCJUNN2JVN?_requestid=76071

Respondeu 05/11/2008 em 16:23
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more