Dicas para Desenvolvimento otimizado com JavaME

Durante meus estudos sobre a plataforma JavaME, encontrei um material muito bom com dicas de otimização para desenvolvimento de aplicativos móveis. Com aplicação dessas dicas, o desempenho e tamanho do seu aplicativo pode incrementar de forma significativa.

Seguem algumas dicas:

• Utilize StringBuffers em vez de Strings.
  
• Strings são objetos imutáveis, ou seja, quando declaramos strings individuais, estamos criando objetos String distintos. A concatenação de Strings cria múltiplos objetos strings. Com o StringBuffer, ele otimiza o tempo de execução do aplicativo (menos tempo para criação de objetos ) e tamanho de memória (menos Strings para alocar).
• Evite: String a, b, c; String r = a + b + "\n" + c + ".";
• Faça: String a, b,c; StringBuffer str = new StringBuffer(255); str.append(a); str.append(b); str.append("\n"); str.append(c); str.append(".");

• Utilize áreas de clipping ao desenhar.
• Use o Graphics.setClip() para desenhar áreas específicas da tela, em que se deseja alterar. Telas com gráficos consomem muito tempo de execução, Reduzir para o número de pixels específicos da tela em que se deseja desenhar melhor o desempenho do programa.
• Ex: g.setClip(x1,y1,x2,y2); g.drawString("hello World", x,y, Graphics.TOP | Graphics.HCENTER);

• Evite o modificador synchronized desnecessário.
  
• A sua propriedade de execução mutualmente exclusiva, faz com que a execução da classe do seu programa fique mais lenta, pois será necessário ele ter que executar medidas extras para garantir o acesso exclusivo.

• Passe o menor número de parâmetros o possível.
• Ao chamar um método, o interpretador passa os parâmetros para a pilha de execução (implicando em uso de muita memória) . Reduzir o número de parâmetros ajuda no tempo de execução e no tamanho de memória.

• Reduza a chamada de métodos.
• Essa técnica pode ser bastante difícil de ser adotada, especialmente quando se trata do paradigma de orientação a objetos, onde o reuso e legibilidade são fatores importantíssimos. Mas em aparelhos móveis, tempo de execução e tamanho de memória são críticos, então evite chamadas desnecessárias.

• Atrase as inicializações.
• Inicialize os atributos e variáveis globais do seu programa quando forem necessitados. Isso ganha um tempo de início de aplicações significante. Inicializações pesadas tornam o programa com uma impressão não agradável para o usuário à primeira vista. Logo evite de colocar inicializações precoces no startApp() e construtor do seu MIDlet.

• Utilize arrays em vez de Collections.
• Acessar arrays e matrizes é mais rápido que acesso de objetos do tipo Vector.

• Preferencie o uso de variáveis locais em vez de variáveis globais.
• Resposta óbvia: é mais rápido!

• Utilize ofuscadores na criação do seu aplicativo final (quando o mesmo entrar em produção ou entrega final).
• Ofuscadores reduzem o tamanho do aplicativo final e além de dificultar que o código fonte possa ser recuperado (legível) com o uso de descompiladores (famosos "jads") .

• Evite a criação de classes e interfaces desnecessárias.
• Só a declaração de uma classe simples pode consumir até 250 kb (de tamanho de arquivo) no seu pacote de distribuição (.jar) . Entao evite declarar classes vazias ou sem utilidade.

• Evite a construção de classes anônimas e internas.
• As famosas innerClass e anonymus class são classificadas do mesmo modo que o tópico anterior. Mesmo sem nomes, ocupam espaço no seu aplicativo. Então tenha cuidado!

• Utilize o padrão SingleTon para diversos objetos.
• Este padrão de projeto reduz o número de classes instanciadas na sua aplicação. Várias instâncias de um objeto podem aumentar consideravelmente o tamanho do mesmo na memória durante a sua execução.

• Utilizar o pacote padrão.
• Utilize o tamanho do nome do pacote (package) pequeno, o que pode contribuir no tamanho de bytes do aplicativo.

• Combine as imagens em um único arquivo.
• Imagens são comprimidas melhor quando estão agrupadas em um único arquivo de imagem. Isso devido ao método de compressão específico para os formatos .PNG. Há diversas técnicas de se extrair uma imagem específica de uma imagem maior, tal como recortá-la.

• Utilize classes pré-definidas.
• Não reivente a roda! Se já existe alguma classe disponível para aquela funcionalidade, utilize-a. As classes da API geralmente são otimizadas e estáveis, o que reduz o tamanho da aplicação através do seu reuso.

• Utilize threads para conexões de rede.
• Quero destacar esse tópico, porque é uma das falhas mais comuns no desenvolvimento de aplicativos em que se usa conexõe remotas. Utilize uma thread separada para conexão de rede, para evitar possíveis travamentos de tela.

• Comprima os dados trafegados da rede.
• Utilize dados comprimidos para o trafégo de rede na sua aplicação. Claro que ambos aplicativos cliente e servidor devem estar conversando a mesma língua (protocolos de rede e métodos de compressão). XML é uma boa dica para compressão de dados, já que eles são específicos representação de formato texto.

• Evite o uso de comandos desnecessários dentro do trecho de código de conexão.
• Comunicações via rede já são lentas e onerosas , logo tente evitar o máximo possível colocar dentro de uma requisicão de conexão de rede, comandos desnecessários. Isso reduzirá a sobrecarga imposta pelo protocolo de rede.

• Use estrutura de dados mais simples.
• Evite o uso de estrutura de dados complexas. Lembre-se memória é pouca e velocidade que se exige é muito, logo otimize! Arrays podem ser uma boa dica nessa técnica.

• Libere os objetos não utilizados para o Garbage Collector.
• Ajude o Garbage Collector. Libere os objetos não mais utilizados pelo seu aplicativo. Atribuindo valore null aos mesmos, informamos ao Garbage Collector que estes objetos podem ser seguramente descarregados da memória.

• Crie telas raramente usadas como classes Anônimas ou internas.
• Telas de auxilio, help que são raramente acessadas, podem declaradas como objeto internos e anônimos, o que libera o uso de memória heap. Claro que pagamos um preço de execução mais lenta na hora de carregar tais telas, mas em compensação não teria uma ocupação desnecessária de memória no heap.

Acho que é isso!
Boas práticas de programação são essenciais para o desenvolvimento de aplicativos móveis especialmente onde o custo de memória restrita e exigência por velocidade são sempre levadas em conta.

é isso ae!!

At+.