Wie behandeln native Apps eine große Anzahl von Knoten in der Ansicht?

Question

Ich bin ein Webentwickler und eines der aktuellen Probleme ist die Migration zu Single-Page-Anwendungen (SPA) und die damit verbundenen Herausforderungen. Wenn wir zum Beispiel das unendliche Scrollen implementieren, können wir uns leicht mit Hunderten von DOM-Knoten (Document Object Model) finden, die im Browser gerendert werden.

Anschließend, wenn wir einige Änderungen vornehmen müssen, die sich durch alle von ihnen ausbreiten, kann dies einen riesigen Abschlag von unserer Leistung nehmen. Das ist teilweise ein Grund, warum Bibliotheken wie React Popularität gewonnen haben - virtuelles DOM.

Das virtuelle DOM erstellt eine virtuelle Darstellung des gesamten DOM-Baums. Wenn Änderungen vorgenommen werden, vergleicht es den alten und neuen Status und aktualisiert nur die Knoten, die sich geändert haben. Ionic, ein hybrides App-Framework, hat seine eigene Lösung für infinite scroll, die diejenigen Knoten versteckt, die nicht in der Ansicht sind, um die Leistung zu beschleunigen.

Also frage ich mich, wie können native Apps mit einer großen Anzahl von Knoten in der Ansicht umgehen? Jede soziale App mit einem Feed kann diese Nummer nach ein paar Sekunden Scrollen erreichen. Wird es vom Betriebssystem behandelt? Ist es überhaupt ein Problem?

Answer 1

Es ist ein Problem, wenn Sie einige Best Practices nicht einhalten. So laden Sie variable Bilder asynchron oder halten das Layout so flach wie möglich. Für Listenansichten ist die ViewHolder Technik.

Die List-Implementierungen auf Android instanziieren normalerweise nicht so viele Ansichten, wie Inhalt in dem bereitgestellten Dataset vorhanden ist, sondern nur so viele (und einige zusätzliche), wie auf dem Bildschirm angezeigt werden können. Wenn eine Ansicht ausfällt, speichert der ListView diese Instanz zwischen und zeigt sie Ihnen an, wenn ein neuer Eintrag aus dem Dataset angezeigt werden soll. Sie fügen dann einfach die Werte aus dem Modell in die bereitgestellte Ansicht (oder besser in den zugehörigen ViewHolder) ein und fertig.

Weitere Probleme können auftreten, wenn der Datensatz häufig geändert wird oder einfach zu groß ist. Wenn sich ein Eintrag im Dataset ändert, möchten Sie wahrscheinlich nicht das gesamte ListView neu zeichnen, sondern nur die Ansicht, die sich geändert hat. Ältere List-Implementierungen können damit nicht umgehen. Wenn sich etwas ändert, wird jede sichtbare Ansicht in der Liste neu gezeichnet. Moderne List-Implementierungen wie RecyclerView haben diese Einschränkung nicht. Es erzwingt nicht nur die ViewHolder-Technik, sondern bietet auch Methoden, um dem RecyclerView mitzuteilen, welches Element geändert wurde, damit es von einer effizienten Neuzeichnungs-Magie profitieren kann.

Wenn das Dataset zu groß ist, besteht der beste Weg zur Vermeidung von Speicher- oder Leistungseinschränkungen darin, nur die neuesten Elemente aus dem Dataset zu laden und den Benutzer aufzufordern, mehr zu laden. Oder Paging.

Also ja, das Framework hilft Ihnen in den meisten Fällen. Aber es gibt genug Platz, um Dinge durcheinander zu bringen.