0
- BroadcastReceiver reçoit une émission, ouvre une wakelock, démarre un service
- service ouvre une autre wakelock, puis envoie un "libération wakelock" diffusée
- BroadcastReceiver reçoit l'émission de wakelock de libération et libère son wakelock
- Service ne sa chose et libère son wakelock
Il y a un problème cependant. Actuellement, le BroadcastReceiver stocke son WakeLock en tant que variable membre. Parfois, le garbage collector sera exécuté après que le BroadcastReceiver ait démarré le service mais avant qu'il ne reçoive la diffusion de wakelock, puis j'obtiens une force close car le wakelock est finalisé avant d'être libéré (puisqu'il récupère les ordures).Android BroadcastReceiver attend le service pour démarrer ou transmettre WakeLock au service?
Je dois donc, dans la méthode OnReceive, effectuez l'une des opérations suivantes:
- attente pour le service pour commencer, attendez qu'il établir son wakelock, puis relâchez le BroadcastReceiver wakelock; l'émission « libération wakelock » ne sera plus nécessaire
- ou, transmettre en quelque sorte le wakelock au service, et le service sera responsable de la libération du wakelock unique
Laquelle est la meilleure option et comment pourrais-je l'accomplir?
Y a-t-il une raison pour ne pas simplement éliminer le Service et implémenter tout ce qui est dans mon BroadcastReceiver? Je pense peut-être que j'ai donné trop de poids à l'idée d'avoir un service et peut-être que tout cela est inutile. En fait, je n'aurais même pas besoin de wakelocks, puisque le système établit un WakeLock pour la durée de la méthode onReceive (à l'intérieur de laquelle je ferais tout). – Ricket
"Y a-t-il une raison de ne pas éliminer le Service et de tout implémenter dans mon BroadcastReceiver?" - Si le travail à effectuer est rapide (par exemple, 50 ms), alors je vais tout rouler dans le récepteur. Sinon, vous volerez du temps processeur important du processus de premier plan, et plus le fil principal de l'application pour votre activité si elle se trouve au premier plan. 'onReceive()' s'exécute avec la priorité du premier plan, donc si vous faites un travail sérieux, vous pouvez absorber assez de cycles CPU pour battre le taux de trame d'un jeu que l'utilisateur pourrait jouer à ce moment. – CommonsWare