Análise superficial de métodos de prevenção de overflow de memória no Android

Este exemplo ilustra as técnicas de excesso de memória em programação Android e as medidas de prevenção. Partilho com vocês para referência, conforme detalhado a seguir:

　O virtual machine do Android é baseado no registrador Dalvik, e o tamanho máximo do heap geralmente é16M. No entanto, o Android é escrito em Java, então em grande parte, o mecanismo de memória do Android é equivalente ao mecanismo de memória do Java, e no início do desenvolvimento, problemas de limites de memória podem nos trazer problemas graves de excesso de memória. Quando não estamos usando certa memória, devemos tentar evitar, no Android ou em outras plataformas, salvar estados necessários ao executar outros programas, para que alguns processos mortos causem problemas de memória. Devemos tentar liberar esses problemas de memória ao fechar o programa ou salvar o estado, para que possamos melhorar a fluidez do sistema ao executar.

A memória do Android se manifesta principalmente:

1No Android, manter referências a recursos por longos períodos pode causar que certas memórias não sejam liberadas, resultando em muitos problemas de vazamento de memória. Por exemplo: Contexto (nos textos a seguir, Activities são mencionadas como Contexto), em alguns casos onde você precisa manter o estado de sua primeira classe e passar esse estado para outras classes, você deve primeiro liberar a classe recebedora antes de eliminar a primeira classe. Algo a notar é: porque no mecanismo de memória do Java ou Android, o nó de ponta deve garantir que nenhum outro objeto o chame antes de ser liberado pelo GC do sistema. Vamos ver um trecho de código:

@Override
protected void onCreate(Bundle state) {
   super.onCreate(state);
   TextView label = new TextView(this);
   label.setText("Leaks are bad");
   setContentView(label);
}

O significado deste código é que carregamos uma instância de TextView para o Activity (Contexto) que estamos executando. Portanto, através do mecanismo de reciclagem de GC, sabemos que para liberar o Contexto, é necessário primeiro liberar alguns objetos que o referenciam. Se não houver, ao tentar liberar o Contexto, você descobrirá que há uma grande quantidade de erros de excesso de memória. Portanto, em caso de erro, o excesso de memória é uma coisa muito fácil de acontecer. Ao salvar alguns objetos, também pode causar vazamento de memória. O mais simples, por exemplo, é o Bitmap, por exemplo: ao rotacionar a tela, destrói o estado atual mantido pelo Activity e solicita a criação de um novo Activity, até que o novo estado do Activity seja salvo. Vamos ver outro trecho de código:

private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Vazamentos são ruins");
if (sBackground == null) {
   sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}

Este código é muito rápido, mas também errado. O vazamento de memória é fácil de ocorrer na mudança de direção da tela. Embora possamos descobrir que não há salvamento explícito do exemplo Context, quando conectamos o desenho a uma visão, o Drawable será configurado como chamada de volta pelo View, o que significa que, no código acima, quando desenhamos o TextView na atividade, já referenciamos essa atividade. A situação de ligação pode ser expressa como: Drawable->TextView->Context.

portanto, quando queremos liberar o Context, ele ainda está armazenado na memória e não foi liberado.

como evitar essa situaçãoprincipalmente devido ao. As threads são mais propensas a erros. Não subestime as threads, no Android, as threads são mais propensas a causar vazamento de memória. A principal razão para o vazamento de memória das threads é o controle não contínuo do ciclo de vida das threads. Abaixo está um trecho de código:

public class MyTest extends Activity {
  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    new MyThread().start();
  }
  private class MyThread extends Thread{
    @Override
    public void run() {
      super.run();
      //faça algo
    }
  }
}

O código é simples, mas no Android surgem novos problemas, quando mudamos de tela de exibição (横向或纵向), a Activity de tela larga ou estreita é recriada. Acreditamos que a Activity anterior será reciclada, mas e a verdade? O mecanismo Java não nos oferece a mesma sensação, pois antes de liberar a Activity, devido ao fim da função run, o MyThread não foi destruído, então a Activity que o referencia (Mytest) também não foi destruída, resultando em problemas de vazamento de memória.

Alguns gostam de usar AsyncTask fornecido pelo Android, mas na verdade, os problemas do AsyncTask são mais graves. Thread só apresenta problemas de vazamento de memória quando a função run não termina, no entanto, o mecanismo de implementação interno do AsyncTask utiliza ThreadPoolExecutor, cujos objetos Thread têm um ciclo de vida incerto e não controlável pelo aplicativo. Portanto, se o AsyncTask for uma classe interna da Activity, é mais provável que apareça um problema de vazamento de memória.

As principais maneiras de melhorar problemas de thread são:

① Converta a classe interna da thread para uma classe interna estática.
② Tente usar weak references para salvar Context no código.

2Bitmap... malévolo...

Bitmap é um objeto particularmente malévolo, para um objeto de memória, se o objeto ocupar uma grande quantidade de memória e exceder o limite de memória do sistema, o problema de vazamento de memória é muito evidente.
A solução para bitmap principalmente é evitar que ele ocupe memória ou reduzir a taxa de amostragem. Em muitos casos, devido ao alto número de pixels das imagens, que não são necessárias para a dimensão da tela do telefone, podemos reduzir a taxa de amostragem das imagens antes de realizar as operações UI originais.

Se não precisarmos salvar a referência do objeto bitmap, também podemos usar soft references como substituição. Muitos exemplos de código específicos podem ser encontrados no Google.

Em resumo, para evitar vazamento de memória, é necessário seguir os seguintes pontos principais:

Primeiro: Não mantenha referências longas para Context (ao precisar de referência para Context, deve-se manter o ciclo de vida do objeto de referência consistente com o próprio Context).

Segundo: Se precisar usar Context, prefira usar ApplicationContext para substituir Context, pois o ciclo de vida do ApplicationContext é mais longo, evitando assim problemas de vazamento de memória em situações de referência.

Terceiro: Evite usar variáveis estáticas em suas Activities quando não controlar o ciclo de vida dos objetos. Tente usar WeakReference para substituir uma static.

Quarto: O coletor de lixo não garante que possa recolher corretamente a memória, então, ao usar o conteúdo necessário, é principal manter o ciclo de vida e liberar os objetos não necessários em tempo hábil. Tente liberar os objetos que fazemos referência no onDestroy no final do ciclo de vida do Activity, por exemplo: cursor.close().

Na verdade, podemos usar menos código em muitos aspectos para concluir programas. Por exemplo: podemos usar mais9Imagens patch, etc. Muitos detalhes podem valer a pena serem descobertos e explorados para mais problemas de memória. Se conseguirmos fazer com que o C/C++Para o princípio 'quem cria, quem libera' do programa, nossa compreensão da memória não é pior do que a do mecanismo GC do Java ou do Android, e uma melhor controle da memória pode fazer nosso telefone rodar mais suavemente.

Leitores interessados em mais conteúdo sobre Android podem consultar as seções especiais do site: 'Resumo de técnicas de memória e cache no desenvolvimento Android', 'Tutorial de entrada e avançado de desenvolvimento Android', 'Resumo de técnicas de depuração e solução de problemas comuns no desenvolvimento Android', 'Resumo de técnicas de operação de multimídia no desenvolvimento Android (áudio, vídeo, gravação, etc.)', 'Resumo de técnicas de uso de componentes básicos no desenvolvimento Android', 'Resumo de técnicas de uso de View no desenvolvimento Android', 'Resumo de técnicas de uso de layout no desenvolvimento Android' e 'Resumo de técnicas de uso de controles no desenvolvimento Android'.

Espero que o conteúdo deste artigo ajude a todos a melhorar o design de programas Android.

Declaração: O conteúdo deste artigo é extraído da internet, pertence ao respectivo proprietário, é contribuído e carregado voluntariamente pelos usuários da internet, o site não possui direitos de propriedade, não foi editado manualmente e não assume responsabilidade legal relevante. Se você encontrar conteúdo suspeito de violação de direitos autorais, por favor, envie um e-mail para notice#w.3Se encontrar conteúdo suspeito de violação de direitos autorais, por favor, envie um e-mail para notice#w, substituindo # por @, e forneça provas relevantes. Apenas após a verificação, o site deletará o conteúdo suspeito.