ScrollView vs RecyclerView per bambini dissimili su Android

Question

Ho un mix di 10-15 viste e frammenti personalizzati da visualizzare in un elenco verticale. Non sono sicuro che RecyclerView abbia qualche vantaggio negli scenari in cui tutte le visualizzazioni sono dissimili. RecyclerView sembra aggiungere molto codice della piastra della caldaia e penso che l'unico vantaggio che otterrei sia l'animazione di entrata/uscita più facile.

Le mie viste/frammenti personalizzati rendono anche la chiamata al servizio Web in fase di creazione. Non memorizziamo le richieste web in cache per motivi commerciali. La mia comprensione è che RecyclerView attiverebbe queste chiamate al servizio web su ogni binding, risultando in chiamate ridondanti e latenza visibile. Comparativamente ScrollView dovrebbe caricare le viste una volta e le conserva tutte in memoria, evitando chiamate multiple.

La mia comprensione è corretta? Ho bisogno di aiuto per capire le implicazioni di performance con ScrollView, nello scenario dato.

Answer 1

ScrollView

Con un ScrollView, tutti i suoi subviews verranno creati in una sola volta, a prescindere dalla visibilità sullo schermo. Se si utilizza ScrollView per la propria soluzione, è probabile che si desideri "ascoltare" quando le sue visualizzazioni secondarie diventano visibili per aggiornare il loro contenuto, utilizzando inizialmente i segnaposto. Potresti anche creare qualcosa che recuperi il contenuto in un thread in background. Questo potrebbe diventare più complesso di quanto tu voglia molto rapidamente.

RecyclerView

A RecyclerView offre il vantaggio di differire la creazione di punti di vista del bambino fino a quando non diventano automaticamente visibili, e possibile riutilizzare vista del bambino con layout comuni.

Utilizzando "tipi di visualizzazione delle voci" diversi per ciascun figlio, si disabilita la parte "riciclaggio" di RecyclerView, ma si ottiene comunque il vantaggio di posticipare la creazione di viste finché non vengono visualizzate nella vista.

RecyclerViews fornisce un modello abbastanza strutturato per lavorare con l'adattatore e ViewHolders. Anche se non ha familiarità con esso, RecyclerView ha anche uno RecyclerView.ViewCacheExtension che è destinato a fornire allo sviluppatore il controllo sulla memorizzazione nella cache delle visualizzazioni.

Nel complesso, il vantaggio del binding tardivo (non creare e caricare viste che potrebbero non essere mai visualizzate) e la flessibilità di RecyclerView produrranno probabilmente buoni risultati.

Answer 2

Prima di tutto devi decidere che cosa stai usando View o Fragment o forse entrambi. Non confrontarecon Fragment c'è un malinteso comune su questi due, non sono simili, in realtà uno Fragment è vicino a un Activity in termini di architettura e implementazione.

In secondo luogo, è possibile riutilizzare alcuni di questi View/Fragment, se sì, quindi RecycleView può essere di grande aiuto.

Dopo aver deciso sugli argomenti di cui sopra:

mia comprensione è che RecyclerView innescherebbe questi web-service chiamate su ogni legame

No, questo non è vero, il metodo di rilegatura viene chiamato ogni volta che viene visualizzato un nuovo oggetto (riutilizzato o appena creato), è possibile implementare l'adattatore per eseguire l'API Web solo una volta su un elemento, questa è la vostra scelta.

Vado sempre per RecycleView/ListView quando possibile, aiuta a ridurre l'ingombro di memoria e può ridurre l'implementazione. In alcuni casi, in cui non è presente un enorme utilizzo della memoria nelle viste e non riesco a riutilizzare alcune delle implementazioni, quindi vado per il ScrollView, ma ci penso due volte prima di implementarlo.