Otimizando o aplicativo Android antes do lançamento [fechado]

Estou em uma situação " especial " sobre a eficiência do meu programa. Agora estou em uma fase em que preciso melhorar o desempenho do aplicativo e reduzir o consumo de bateria .

Antes da pergunta:

• Primeiro de tudo, meu aplicativo funciona. Ele funciona muito bem - sem erros de qualquer natureza .
• Em segundo lugar , li Otimizando a vida útil da bateria no site de desenvolvedores do Android e otimizei pequenas coisas que eles solicitaram. Sem problemas de qualquer natureza .

Agora, estou curioso para saber sobre as correções especiais de outros desenvolvedores que eles usaram para otimizar seus próprios aplicativos. Coisas que os usuários podem nunca reconhecer ou prestar atenção. No entanto, as correções aumentarão a vida útil da bateria ou ajudarão a melhorar a manutenção do aplicativo.

Então, qual é o seu truque exclusivo de otimização?

Estou em uma situação específica em que estou realmente procurando conhecimento e acho que essa será uma ótima oportunidade para compartilhar o conhecimento dos desenvolvedores sobre uma situação em que eles já passaram.

Por favor, vote em ótimas respostas, pois isso incentivará grandes desenvolvedores a compartilhar seus conhecimentos.

Em algum momento, você chegará ao ponto em que o uso de truques conhecidos atingirá seus limites. A melhor coisa a fazer neste momento é criar um perfil do seu código e ver quais áreas são os gargalos com base em seus requisitos específicos.

Investigando o uso da RAM usando MAT e Using Traceview : um artigo sobre como usar as ferramentas para criar perfil de seu aplicativo.

Alocações de rastreamento e squash. Quanto mais você aloca, mais frequentemente o coletor de lixo precisará ser executado, impedindo o processo de fazer qualquer outra coisa por períodos relativamente longos, como 100 ms ou mais.

A melhor ferramenta que conheço para isso é o Alocation Tracker incluído no DDMS .

Não apenas o GC pode ter um impacto na experiência do usuário, mas as alocações supérfluas e o GC consomem alguns recursos de computação.

Aqui está um exemplo e um pequeno truque. No meu aplicativo, tenho um relógio que mostra a hora atual (de áudio), incluindo o décimo de segundos. Isso é atualizado com freqüência. E o TextView realiza alocações internamente sempre que você chama setText () com um CharSequence. Mas ele não aloca nada com a variante setText (char [] text, int start, int len). Isso não está documentado e ninguém respondeu quando perguntei sobre isso.

Existem muitos como este. E esse é um dos motivos pelos quais meu aplicativo contém 50% de código nativo (mas existem outros motivos).

Além disso, posso recomendar que você experimente o ProGuard . Ele executa várias passagens de otimização e registra informações como métodos não utilizados no projeto, o que pode ajudá-lo a remover as sobras do seu código.

Se o seu aplicativo tiver muito tempo na tela, use preto sempre que puder . Isso reduzirá o consumo de bateria da pior parte do dispositivo: a tela, especialmente nos telefones e tablets AMOLED.

Para aplicativos com várias atividades, verifique se você não está reiniciando atividades que precisam ser trazidas para a frente usando os sinalizadores de intenção apropriados. Verifique se seu heap está sob controle e se visualizações, ligações e contextos desnecessários não estão sendo criados.

Acho que a melhor ferramenta para mostrar a você tudo isso enquanto o aplicativo é executado é:

adb shell dumpsys meminfo 'your apps package name'

Ao usar o SQLlite, dê atenção especial aos índices. Não assuma nada. Eu tenho tremendas acelerações no Zwitscher, quando coloco índices em colunas comumente usadas para pesquisa.

Algumas dicas que podem ajudar você a otimizar seu aplicativo em termos de interface do usuário :

• use convertViewpara adaptadores de lista - seria muito caro se você criar uma nova exibição, Adapter.getView()pois essa rotina é chamada para todas as posições na lista. Usar convertViewpermite reutilizar a exibição já criada. Um bom exemplo (junto com o uso de ViewHolder) pode ser encontrado no ApiDemos .

• Pode acontecer que seus layouts não estejam totalmente otimizados e possam ser aprimorados (por exemplo, ao mesclar ou remover os pais). O layout da ferramenta Androidopt encontrará essa situação para você. Ele pode ser usado com o HierarchyViewer para inspecionar visualizações individuais. Mais informações aqui .

• remova o drawable de plano de fundo - a estrutura do Android costumava ter (ainda tem?) um problema ao detectar quais visualizações devem ser desenhadas. Há uma chance de que seu drawable de plano de fundo (padrão) seja desenhado apenas para ser ocultado posteriormente pela interface do usuário opaca. Para se livrar desse desenho desnecessário, basta remover o desenho de fundo.

Isso pode ser feito usando um estilo personalizado

<resources>
    <style name="Theme.NoBackground" parent="android:Theme">
        <item name="android:windowBackground">@null</item>
    </style>
</resources>

Algumas dicas que podem ajudar você a otimizar seu aplicativo em termos de uso da bateria :

• verifique o tipo de rede e aguarde até o usuário entrar na área com wifi ou 3G (e não em roaming) e só depois permita que ele use a conexão

• use gzip para dados textuais sempre que possível para acelerar o download e a análise

• reciclar objetos Java complexos, como XmlPullParserFactory/ BitmapFactory/ StringBuilder/ Matcheretc.

Para mais truques sobre bateria, consulte Codificação para toda a vida útil - duração da bateria .

Algo em que pensar: NÃO use demais a String, por exemplo, em um loop enorme. Isso criará muitos objetos String que precisam ser colocados em GC. O exemplo "Bad coding" produzirá 2 objetos de string a cada loop. O próximo exemplo produzirá apenas uma String final e um único construtor de string. Isso faz uma enorme diferença ao otimizar loops enormes de velocidade. Eu usei muito o construtor de cordas ao criar meu aplicativo Wordlist Pro para Android, e ficou muito rápido ao passar 270000 palavras em pouco tempo.

    //Bad coding:
    String s = "";
    for(int i=0;i<999999;i++){
        s = "Number=";
        s = s + i;
        System.out.println(s);
    }

    //Better coding
    final String txt = "Number=";
    StringBuilder sb = new StringBuilder();
    for(int i=0;i < 999999;i++){
        sb.setLength(0);
        sb.append(txt);
        sb.append(i);
        System.out.println(sb);
    }

Escrevi um post mais extenso sobre o assunto. leia aqui

Eu acho que o uso de variáveis ​​"finais" em todos os lugares onde é possível também pode melhorar a velocidade de execução.

Otimize suas imagens PNG com ferramentas como OptiPNG e PNGCrush para economizar alguns bytes (kilo) do tamanho do APK. As dicas de otimização de imagem para sites também se aplicam aqui: use formatos de imagem apropriados, brinque com a compactação JPG, considere usar transparências binárias em vez de transparências de 8 bits etc.

Se você enviar grandes PNGs com canal alfa, você pode trocar alguns tamanho APK para a velocidade de inicialização e usar JPGs separados para canais RGB e A .

Se você estiver fazendo conexões HTTP, verifique se o seu cliente HTTP utiliza compactação de conteúdo. Se ele armazena em cache as respostas HTTP recebidas, verifique se ele entende e usa os cabeçalhos HTTP relacionados ao cache corretamente.

Se você tiver operações de rede, tente reutilizar a mesma instância httpclient. Evite usar expressões regulares.

Tente usar o DDMS para rastrear todos os threads em execução no sistema. Por exemplo, notei que estava usando o webview para exibir conteúdo html, notei que ele cria poucos threads para o gerenciamento de sessões de gerenciamento de cookies, etc., o que aumentou minha pegada de memória. Portanto, a menos que você tenha uma necessidade séria de exibir html complexo, tente usar a classe de utilitário normal "Html" no Android para exibir o conteúdo html. Isso pode ser útil para pessoas que estão exibindo o Eula, já que o eula typicall contém texto html.

Se você precisar executar operações de rede, tente usar o AndroidHttpClient se você é iniciante, ele possui alguns recursos bons para sessões SSL de cache e tudo isso realmente ajuda a melhorar seu desempenho. Sempre defina o tempo limite da conexão do soquete para algo em torno de 60 segundos ou alguns valores finitos, porque o tempo limite infinito pode causar conflitos, especialmente se você interromper a conexão durante o handshake ssl.

Use o Android Resource Tracker para encontrar recursos não utilizados em seu projeto que podem ser excluídos.

Evite usar XPath se você puder analisar sua entrada XML usando rotinas de manipulação de sequência para obter o texto entre as tags. Eu testei e posso confirmar uma melhoria de 10x neste caso, em um conjunto de dados de 50000 itens, em um HTC Desire.

Sei que estou entrando um pouco mais tarde nessa conversa, mas seria perfeito ter muitas boas dicas em um só lugar, por isso espero que esse tópico esteja vivo e atualizado com bastante frequência. Minhas dicas:

• Não bloqueie o thread da interface do usuário com trabalhos caros, o usuário sairá se não houver resposta do aplicativo (use AsyncThreads).
• Use o LINT , nova ferramenta que verifica as fontes de projetos do Android em busca de possíveis erros.

..será atualizado..