Ho trovato questo articolo sull'implementazione di una pipeline di input per Android, ma non capisco davvero come funzioni. Inoltre non capisco del tutto il concetto di programmazione di una pipeline o di un pool. Qualcuno potrebbe spiegare questi concetti e come funzionano come questa pipeline di input?
Risposte:
Non ho approfondito il codice, ma l'idea di base è che gli eventi di input sono asincroni in Android, il che significa che potrebbero accadere in qualsiasi momento. Non si desidera interrompere il codice del ciclo principale per elaborare gli eventi di input perché potrebbe rallentare il gioco e alterare lo stato del gioco in modi imprevisti.
L'approccio tradizionale utilizzato nell'esempio Lunar Lander è di avere un blocco sincronizzato attorno al loop principale e attorno a ciascuno dei gestori di input per garantire che non si verifichino mai allo stesso tempo. Questo potrebbe essere un approccio valido per un gioco di piccole dimensioni, ma man mano che il gioco diventa più complicato, scoprirai che non è molto efficiente e potrebbe non funzionare correttamente.
L'articolo suggerisce un approccio migliore per archiviare gli eventi di input in una coda ed elaborarli in un punto noto del ciclo principale. I gestori di input semplicemente spingono l'evento (dopo averli inseriti in un InputObject che li descrive) fino alla fine della coda e vengono successivamente elaborati nel metodo processInput nel thread di gioco.
L'autore dell'articolo utilizza effettivamente due code, una coda di input e un pool di oggetti di input. Il pool di oggetti di input nell'attività principale viene utilizzato perché non vogliamo continuare a creare nuovi oggetti di input ogni volta che otteniamo un evento di input. Ciò è negativo perché gli eventi di input si verificano frequentemente e la creazione di un sacco di oggetti farà sì che il garbage collector venga eseguito spesso, il che rende il gioco instabile e non risponde. L'approccio migliore è quello di creare un pool di oggetti una volta (sostanzialmente una coda) e prendere gli oggetti dalla coda quando ne hai bisogno e riportarli nella coda quando hai finito. Ecco a cosa serve la coda dell'attività principale. L'altra coda è una coda di input nel thread di gioco che contiene effettivamente gli eventi di input ricevuti e che viene elaborata dal loop di gioco utilizzando il metodo processInput.
La coda del pool avrà sempre un numero fisso di oggetti (specificato dalla costante INPUT_QUEUE_SIZE che può essere 30 ad esempio) che sono allocati nel metodo createInputObjectPool quando viene creata l'attività, mentre la coda di input avrà un numero variabile di eventi di input che vengono alimentati dall'attività e restituiti alla coda del pool una volta elaborati utilizzando il metodo returnToPool. Queste code sono ArrayBlockingQueue che sono code normali (prima in prima uscita) implementate usando una matrice (al contrario dell'elenco collegato per esempio) che si bloccherebbe, in circostanze in cui una coda normale traboccerebbe e si riverserebbe , fino a quando la coda non è pronta per operazione.