Com o desenvolvimento da Internet móvel, o desenvolvimento de aplicativos Android tornou- se cada vez mais popular. Todos sabem que o sucesso de um aplicativo é inseparável da experiência de desempenho do aplicativo. Se um aplicativo fica aberto por muito tempo, deslizar não é suave, etc., então acredito que não importa o quão bom seja o seu produto, quão bom seja o seu funcionamento, ele não vai ganhar o favor dos usuários. Portanto, melhorar o desempenho é especialmente importante no desenvolvimento de aplicativos.
Claro, calçados infantis engajados no desenvolvimento do Android devem saber a importância da melhoria do desempenho do aplicativo, mas a dificuldade está em como melhorar o desempenho do aplicativo Android e como tornar a experiência do usuário melhor? ? O editor a seguir compartilhará com você um engenheiro de desenvolvimento de aplicativos do Google que se concentra em alto desempenho, sobre a otimização do desempenho do aplicativo e uma solução para evitar o vazamento de atividade . Sem muita bobagem, apresse-se e pegue essa nova habilidade ~~
Como o vazamento de atividade aconteceu?
Na otimização do desempenho do aplicativo Android, o primeiro problema que precisa ser reparado são os vazamentos de atividade. Como ocorreram os vazamentos de atividade e por que eles vazaram? O vazamento de atividade é um tipo de vazamento de memória. Se você mantiver uma referência para uma atividade não utilizada, na verdade, você mantém o layout da atividade e, naturalmente, inclui todas as visualizações. A coisa mais complicada é manter uma referência estática. Não se esqueça, Activity e Fragment têm seu próprio ciclo de vida. Assim que tivermos uma referência estática, Activity e Fragment não serão limpos pelo coletor de lixo. É por isso que as referências estáticas são perigosas.
m_staticActivity = staticFragment.getActivity ()
Além disso, o vazamento de Listener também é uma ocorrência comum. Por exemplo, tenho o seguinte código. LeakActivity herda de Activity. Temos um singleton: NastyManager. Quando vinculamos Activity como Listener e NastyManager por meio de addListener (this), coisas ruins acontecem.
public class LeakActivity extends Activity {
@Sobrepor
protected void onCreate (Bundle savedInstanceState) {
super.onCreate (savedInstanceState);
NastyManager.getInstance (). AddListener (this);
}
}
Para consertar esse bug, na verdade é bastante simples, basta desassociá-lo com NastyManager quando sua atividade for destruída.
@Sobrepor
public void onDestroy () {
super.onDestroy ();
NastyManager.getInstance (). RemoveListener (this);
}
Comparada com a solução acima, naturalmente temos uma melhor. Por exemplo, realmente precisamos usar singletons? Normalmente, não é necessário. Mas às vezes pode ser realmente necessário. Temos que pesar e projetar. Em qualquer caso, lembre-se de que, quando a Activity for destruída, remova a referência à Activity no singleton. Vamos discutir isso a seguir: O que acontece se for uma classe interna? Por exemplo, temos um pequeno Handler não estático na Activity. Embora pareça curto, enquanto estiver vivo, a Atividade que o contém sobreviverá. Se você não acredita, pode experimentar na VM. Este é outro caso de vazamento de memória: Handler dentro da Activity.
public class MainActivity extends Activity {
// ...
Trades trades;
@Sobrepor
protected void onCreate (Bundle savedInstanceState) {
super.onCreate (savedInstanceState);
// ...
handler = new Handler () {
@Sobrepor
public void handleMessage (mensagem msg) {
}
}
}
Handler é uma classe muito comum e útil, assíncrona, thread-safe e assim por diante. O que aconteceria se houvesse um código como o seguinte? handler.postDeslayed, supondo que o tempo de atraso seja de várias horas ... o que isso significa? Isso significa que, enquanto a mensagem do manipulador não for processada, ela sempre viverá, e a Activity que a contém viverá. Vamos encontrar uma maneira de corrigi-lo. A correção é WeakReference, que é a chamada referência fraca. O coletor de lixo ignora referências fracas ao reciclar, portanto, a Activity que o contém será limpa normalmente. Provavelmente, o código é o seguinte:
classe estática privada MyHandler extends Handler {
final privado WeakReference <MainActivity> mActivity;
// ...
public MyHandler (MainActivity activity) {
mActivity = nova WeakReference <MainActivity> (atividade);
// ...
}
@Sobrepor
public void handleMessage (mensagem msg) {
}
// ...
}
Resumindo: temos uma classe interna, assim como Handler. A classe interna não estática não pode viver independentemente da classe a que pertence. Android geralmente é Activity. Portanto, observe as classes internas em seu código para ter certeza de que não estão vazando.
Em comparação com classes internas não estáticas, é melhor usar classes internas estáticas. A diferença é que as classes internas estáticas não dependem da classe a que pertencem e têm diferentes ciclos de vida. Costumo ver vazamentos de memória causados por motivos semelhantes.
Como evitar vazamentos de atividade?
1. Remova todas as referências estáticas.
2. Considere o uso de EventBus para desacoplar o Listener.
3. Lembre-se de desvincular o Listener quando não for necessário.
4. Tente usar classes internas estáticas.
5. Faça a revisão do código. Experiência pessoal: a Code Review pode encontrar vazamentos de memória muito cedo.
6. Compreenda a estrutura do seu programa.
7. Use ferramentas como MAT, Eclipse Analyzer, LeakCanary para analisar a memória.
8. Imprimir registro em retorno de chamada.
Os motivos acima são os motivos e as soluções para vazamentos de atividade na otimização de desempenho de aplicativos Android. Ao desenvolver aplicativos, você também pode usar os métodos acima para detectar, resolver ou evitar vazamentos de atividade.
Digitalize o código QR para seguir a conta oficial : " White Code Xiaoxifeng ", digite " Perguntas da entrevista " para obter 1500 perguntas reais da entrevista BAT !