J'ai trouvé cet article sur l'implémentation d'un pipeline d'entrée pour Android, mais je ne comprends pas vraiment comment cela fonctionne. Je ne comprends pas non plus complètement le concept de programmation d'un pipeline ou d'un pool. Quelqu'un pourrait-il expliquer ces concepts et comment ils fonctionnent en tant que pipeline d'entrée?
Réponses:
Je n'ai pas examiné le code en profondeur, mais l'idée de base est que les événements d'entrée sont asynchrones dans Android, ce qui signifie qu'ils peuvent se produire à tout moment. Vous ne voulez pas interrompre votre code de boucle principale pour traiter les événements d'entrée, car cela pourrait ralentir votre jeu et modifier votre état de jeu de manière inattendue.
L'approche traditionnelle utilisée dans l'exemple Lunar Lander est d'avoir un bloc synchronisé autour de la boucle principale et autour de chacun de vos gestionnaires d'entrée pour garantir qu'ils ne se produiraient jamais en même temps. Cela peut être une approche valable pour un petit jeu, mais à mesure que votre jeu se complique, vous constaterez qu'il n'est pas très efficace et qu'il pourrait ne pas fonctionner correctement.
L'article suggère une meilleure approche pour stocker les événements d'entrée dans une file d'attente et les traiter à un point connu de votre boucle principale. Les gestionnaires d'entrée poussent simplement l'événement (après les avoir encapsulés dans un InputObject qui les décrit) à la fin de la file d'attente, et ils sont ensuite traités dans la méthode processInput dans le thread de jeu.
L'auteur de l'article utilise en fait deux files d'attente, une file d'attente d'entrée et un pool d'objets d'entrée. Le pool d'objets d'entrée dans l'activité principale est utilisé parce que nous ne voulons pas continuer à créer de nouveaux objets d'entrée chaque fois que nous obtenons un événement d'entrée. Ceci est mauvais car les événements d'entrée se produisent fréquemment et la création de beaucoup d'objets entraînera l'exécution fréquente du garbage collector, ce qui rend votre jeu saccadé et ne répond pas. La meilleure approche consiste à créer un pool d'objets une fois (essentiellement une file d'attente) et à prendre des objets de la file d'attente lorsque vous en avez besoin et à les retourner dans la file d'attente lorsque vous avez terminé. C'est à cela que sert la file d'attente de l'activité principale. L'autre file d'attente est une file d'attente d'entrée dans le thread de jeu qui contient réellement les événements d'entrée reçus et qui est traitée en boucle de jeu en utilisant la méthode processInput.
La file d'attente de pool aura toujours un nombre fixe d'objets (spécifié par la constante INPUT_QUEUE_SIZE qui peut être 30 par exemple) qui sont alloués dans la méthode createInputObjectPool lorsque l'activité est créée, tandis que la file d'attente d'entrée aura un nombre variable d'événements d'entrée qui sont alimentés par l'activité et retournés à la file d'attente du pool une fois qu'ils sont traités à l'aide de la méthode returnToPool. Ces files d'attente sont des ArrayBlockingQueue qui sont des files d'attente normales (premier entré, premier sorti) implémentées à l'aide d'un tableau (par opposition à une liste liée par exemple) qui se bloquerait, dans les cas où une file d'attente normale déborderait et déborderait, jusqu'à ce que la file d'attente soit prête pour le opération.