- Descrição do problema
O programa foi eliminado pelo sistema de telefonia móvel de um fabricante durante o processo de execução residente em segundo plano, e foi constatado que o processo de interrupção era um processo relacionado ao gerenciamento de energia do sistema. Mas o telefone celular nos deu todas as permissões do aplicativo e ainda será morto.
Ao ativar o modo de engenharia do telefone, obtemos os seguintes logs:
- Análise
Através da análise de log, verificou-se que o processo de download foi iniciado 124 vezes em um curto período de tempo e agora o problema pode ser determinado inicialmente como: processo de download. Ao pesquisar o código-fonte, verifica-se que o processo é um processo de Serviço e mata o próprio processo após o uso.
Log:
O código correspondente:
- Razão
O motivo agora está mais claro: depois que o processo do serviço executou sua tarefa, ele cometeu suicídio (matando System.exit (0)) e é considerado uma falha do sistema, e depois é puxado pelo sistema, e o serviço detecta periodicamente o suicídio. , Cometeu suicídio, e depois foi puxado novamente ... Dessa forma, o sistema pensará que o processo está travando constantemente, para que o aplicativo tenha problemas e, em seguida, adicione o aplicativo à "lista de inicialização proibida", o aplicativo fica bloqueado e, em seguida, mata todo o grupo de processos (somos aplicativos multiprocessos).
- Resolver
Use o método stopself do serviço ou o método onDestroy, após o término do serviço, a reciclagem do processo é transferida para o mecanismo de coleta de lixo do Android e o problema é resolvido.
- Recomendações e especificações
Método de destruição de serviço
Após o processo do Serviço concluir a tarefa, ele precisa usar o método stopself do serviço Android ou o método onDestroy para finalizar o Serviço, e a reciclagem do processo é transferida para o mecanismo de coleta de lixo do Android. Como o desempenho de diferentes ROMs pode ser diferente, algumas ROMs terão fenômenos de saída anormais, algumas ROMs mostrarão lembretes de alto consumo de energia e algumas ROMs não aparecerão. Se não for necessário, é recomendável não interromper manualmente o processo (Nota: chamar System.exit (0) depois que stopSelf () não encontrou um problema no problema de exemplo da rom, mas isso não significa que todas as ROMs estejam corretas).
Além disso, android.os.Process.killProcess (android.os.Process.myPid ()) e System.exit (0) terão o mesmo problema .
valor de retorno onStartCommand
É recomendável não modificar o valor de retorno do método onStartCommand; é melhor deixar o sistema lidar com isso. (Por exemplo, retorne START_NOT_STICKY se realmente travar inesperadamente, o processo não será interrompido
Reinicie, este não é o resultado que queremos).
- Expandir
O valor de retorno do método onStartCommand () é um número inteiro e o intervalo disponível é:
START_STICKY
START_NOT_STICKY
START_REDELIVER_INTENT
START_STICKY_COMPATIBILITY
O valor de retorno quando START_STICKY, o serviço é anormalmente matar, o sistema vai ser puxado para cima, mas a perda de conteúdo Intenção.
Quando o valor de retorno é START_NOT_STICKY, se o Serviço for eliminado por uma exceção, ele não será exibido pelo sistema.
Quando o valor de retorno é START_REDELIVER_INTENT , quando o Serviço é eliminado por uma exceção, ele é puxado pelo sistema e o conteúdo Intent é retido.
Quando o valor de retorno é START_STICKY_COMPATIBILITY , uma versão compatível do START_STICKY, mas não há garantia de que o serviço será reiniciado após o término.
