Hintergrund
Mit der kontinuierlichen Innovation der Internettechnologie und der rasanten Entwicklung der Fernsehbranche ist das Ansehen von Online-Videos über das Fernsehen nach und nach zu einer wichtigen Unterhaltungsmethode für die Öffentlichkeit geworden. Als eine der Anwendungen mit der höchsten Benutzeraktivität auf TV-Geräten bietet die Kiwi-App eine Fülle von Inhaltswiedergabediensten. Darüber hinaus bietet sie auch Mitgliedschaftsvorgänge, Sonderveranstaltungen und andere Dienste, die eine extrem hohe Online-Effizienz erfordern. Um den Anforderungen des letzteren gerecht zu werden, haben wir die aktuellen Mainstream-Dynamik- und Cross-End-Technologien untersucht: H5, Flutter und React Native, und uns schließlich im Hinblick auf Entwicklungseffizienz, Arbeitskosten, dynamische Fähigkeiten und Leistung für die H5-Lösung entschieden. Die H5-Seite ist für eine Vielzahl von Kassierer-, Betriebsaktivitäten, Sonderthemen und anderen Geschäften in der Kiwi-App verantwortlich. Die Hauptschwierigkeit besteht jedoch darin, dass das Laden der H5-Seite auf TV-Geräten zu lange dauert. Wie wir das Benutzererlebnis von H5-Seiten auf TV-Geräten verbessern können, müssen wir dringend lösen.
Vor Herausforderungen gestellt
Herausforderung 1: Der Austauschzyklus von TV-Geräten ist lang und das Problem der Systemfragmentierung ist schwerwiegend. Derzeit machen Geräte mit TV-Systemen unter 5,0 einen sehr hohen Anteil aus. Bei der Optimierung geht es zunächst um die Versionsspanne, wobei die Kompatibilität mit niedrigeren Versionen im Vordergrund steht. Die folgende Abbildung zeigt den Anteil der TV-Systemversionen:
Herausforderung 2: Die Leistung von TV-Geräten ist hauptsächlich in drei Typen unterteilt: TV, Box und Projektor. Die Konfiguration der oben genannten Geräte ist in unserem Leistungsniveau erheblich niedriger Bei der Klassifizierung handelt es sich bei der CPU um 4. Ein Gerät mit einer Kern-A53-Architektur und mehr als 1,5 GB Speicher kann als Hochleistungsgerät eingestuft werden. Unter Geräten mit geringer Leistung gibt es immer noch viele Geräte mit A7-Architektur-Prozessoren oder 512 MB Speicher.
Herausforderung 3: Aufgrund der Komplexität der aktuellen Kooperationssituation in der TV-Branche streben viele Sender nach Stabilität und sind bei Upgrades vorsichtiger sind nach dem Verkauf nahezu wartungsfrei; die Komplexität des Kooperationsmodells führt zu vielen Anpassungen und Schwierigkeiten bei der Aktualisierung, was große Herausforderungen für die Optimierung und Einführung auf SDK-Ebene darstellt.
Optimierungsprozess
1. Vorbereitung
Vor der Optimierung besteht die wichtigste Arbeit darin, das Leistungskaliber zu vereinheitlichen und statistische Indikatoren zu formulieren. Auf Kaliberebene haben wir nicht die herkömmliche Ladezeit der Front-End-Seite verwendet, sondern ein Szenario übernommen, das eher der realen Erfahrung des Benutzers entspricht: von dem Zeitpunkt, an dem der Benutzer auf die Schaltfläche klickt, bis zu dem Zeitpunkt, an dem sie für die Realität sichtbar ist Benutzer. Obwohl dies den Gesamtzeitverbrauch unserer statistischen Indikatoren erhöht, ist dieser Indikator nach der Auswertung für die Richtung unserer nachfolgenden Optimierungsarbeit förderlicher. Das Anzeigekaliber wird wie folgt erklärt
1) Die Zeit, die benötigt wird, bis die Seite sichtbar ist: Beginnend mit dem Client-Klick -> Client-Seitensprung -> Web-Container-Initialisierung -> Das Front-End-DOM-Rendering ist abgeschlossen und sichtbar.
2 ) Die gesamte interaktive Zeit: die sichtbare Zeit der Seite + die Gesamtzeit, die auf die Fernbedienungstaste des Benutzers reagieren kann.
3) Native Seite zeitaufwändig: Client-Seitensprung zeitaufwändig.
4) Webview-Initialisierung: Die Initialisierung des Webcontainers ist zeitaufwändig.
5) Der Aufruf von h5 dauert einige Zeit: Die Ausführung der ersten Codezeile von LoadUrl bis h5 dauert einige Zeit.
6) Die Zeit, die zum Laden von h5 benötigt wird: Die Zeit, die h5 benötigt, um mit der Ausführung der ersten Codezeile zu beginnen, bis sie auf der Seite sichtbar ist.
7) Es braucht Zeit, bis h5 interaktiv ist: Es braucht Zeit, bis die h5-Seite sichtbar ist und die Seite reagiert.
Nachdem die statistischen Standards vereinheitlicht sind, liefern wir die oben genannten Zeitpunkte auf webSDK-Ebene, sammeln Online-Daten und führen gezielte Optimierungen auf der Grundlage der von den Indikatoren zurückgemeldeten Probleme durch. Ohne Optimierung beträgt die Ladegeschwindigkeit von H5 durchschnittlich etwa 5,5 Sekunden und die Benutzererfahrung ist sehr schlecht. Durch die Online-Datenanalyse nimmt die H5-Ladezeit einen großen Teil der Gesamtzeit ein. Die Optimierung der H5-Ladezeit ist ein Problem, das wir dringend lösen müssen.
2. Optimierung der H5-Ladezeit
Die H5-Ladezeit hängt hauptsächlich von der Optimierung des Front-End-Teils ab. Aufgrund der begrenzten Länge des Artikels werden die herkömmlichen H5-Seitenoptimierungsarbeiten nicht im Detail beschrieben, wie zum Beispiel:
1) Ressourcenzusammenführung
2) Zusammenführung von Datenanfragen
3) Optimierung der Geschäftslogik
4) Optimierung der DOM-Struktur
5) Laden des asynchronen Routings in verschiedenen Modi unter derselben Adresse
3. SSR-Optimierung
Zusätzlich zu der oben genannten Optimierung ist die SSR-Technologie (Server-Side Pre-Rendering) in unser Blickfeld gerückt, eine Technologie, die die Leistung von Webanwendungen und SEO optimiert, indem sie die Seitenladegeschwindigkeit verbessert Suchmaschinenleistung und Benutzererfahrung. Durch Auswahl des geeigneten Frameworks, Erstellen von Routen, Schreiben von Komponenten, Serverkonfiguration und Datenerfassung können Entwickler serverseitiges Rendering implementieren und so Benutzern ein besseres Webanwendungserlebnis bieten und ein schnelleres Rendering des ersten Bildschirms gewährleisten.
Diese Methode zur Reduzierung des Verarbeitungsdrucks am Ende eignet sich sehr gut für Szenarien, in denen die Leistung von TV-Endgeräten schlecht ist. Obwohl SSR auch seine eigenen Mängel aufweist, kann es beispielsweise die Gesamtladegeschwindigkeit der Seite verbessern, ist jedoch nicht förderlich für das progressive Laden der Seite. Nach wiederholten Experimenten und Online-Daten sind wir immer noch davon überzeugt, dass die allgemeinen Vorteile von SSR positiv sind, und haben mit Forschung und Entwicklung begonnen. Experimente haben gezeigt, dass die SSR-Lösung die Ladegeschwindigkeit von H5-Seiten deutlich verbessert.
Der durch SSR optimierte H5-Seitenladeprozess ist in der folgenden Abbildung dargestellt:
Nach der Optimierung der oben genannten Frontend-Lösungen wurde die Ladegeschwindigkeit jeder Version deutlich verbessert. Die für den H5-Rendering-Teil aufgewendete Zeit wurde von durchschnittlich 4 Sekunden auf weniger als 1,5 Sekunden und die Gesamtzeit auf etwa 3,5 Sekunden reduziert. Derzeit ist die reine Front-End-Optimierung auf einen Engpass gestoßen, und auch das Input-Output-Verhältnis ist niedrig. Es ist notwendig, weiterhin über Optimierungsmethoden aus der Gesamtperspektive des Kunden nachzudenken.
4. Ressourcen-Offline-Caching
CDN stellt einige wichtige H5-Ressourcen bereit (z. B. CSS, JS, PNG, TTF usw.), von denen viele während des Front-End-Versionszyklus unverändert bleiben und groß sind, und der Client lädt sie zu gegebener Zeit vorab herunter . Beim Rendern der Seite können wir den ShouldInterceptRequest-Rückruf des WebView-Kernels verwenden, um die Ladeanforderung der Online-H5-URL abzufangen. Wenn die Ressource nicht im Offline-Cache gefunden wird, wird sie über das Online-Netzwerk geladen Im Offline-Cache gefunden, werden die Ressourcen direkt von der lokalen Festplatte geladen und an WebView zurückgegeben. Diese Methode kann die Geschwindigkeit beim Laden von Ressourcen erheblich verbessern.
Das allgemeine Flussdiagramm der Offline-Caching-Lösung lautet wie folgt:
Gleichzeitig haben wir während des Prozesses festgestellt, dass sich die native Android-Anforderungsbibliothek HttpUrlConnection in niedrigeren Versionen noch im http1.0-Stadium befindet und die Optimierung von http2.0 (z. B. Kanalwiederverwendung) nicht nutzen kann, wodurch die Anforderung während des Prozesses gestellt wird Vorspannzeit höher. Derzeit gibt es auf der TV-Seite eine große Anzahl von Geräten mit niedriger Version und Versionen unter 5.0. Daher haben wir uns entschieden, auf die von der TV-Seite unabhängig entwickelte Netzwerkbibliothek umzusteigen. Diese Netzwerkbibliothek unterstützt http2.0 und verbessert so die Anforderungsleistung Geräte mit niedriger Version. Darüber hinaus sehen wir, dass vom Klick des Benutzers bis zum Öffnen der H5-Seite eine gewisse Systemplanungszeit vergeht. Diese Zeit kann auch zur Optimierung verwendet werden, dh für das unten erwähnte parallele Laden.
5. Paralleles Laden
Zusätzlich zu den oben genannten Lösungen zum Vorab-Caching von JS/CSS und anderen Ressourcen ist das Vorab-Caching von HTML-Seiten auch eine gängige Optimierungsmethode in der Branche. Bevor die Seite SSR ist, hat dieser Caching-Mechanismus keine guten Ergebnisse erzielt Ein Leistungsengpass besteht nicht beim Herunterladen von HTML-Daten. Nachdem die Rendering-Daten generiert wurden, kann ein solcher Caching-Mechanismus theoretisch eine größere Rolle spielen.
Gleichzeitig sind wir jedoch auf andere Schwierigkeiten gestoßen, da personalisierte Algorithmen in Unternehmen weit verbreitet sind. Die Methode, Seiten im Voraus zwischenzuspeichern und den Inhalt für einen bestimmten Zeitraum unverändert zu lassen, steht im Widerspruch zu den geschäftlichen Anforderungen, Seiten aufzubewahren Daten werden in Echtzeit aktualisiert. Dies erfordert, dass wir optimierte technische Lösungen finden, die besser für Geschäftsszenarien geeignet sind.
Das Android-System verbraucht beim Wechseln der Aktivitätsseite Systemzeit. Dieser Zeitverbrauch ist umgekehrt proportional zur Geräteleistung. Wir fangen den Klick des Benutzers auf die Webseite beim Seitensprung ab, um die Aufgabe im Voraus zu starten und die SSR zu laden H5-Seite parallele Daten. Anschließend wird basierend auf der URL und den Cookie-Parametern ein eindeutiges Token generiert. Wenn es an der Zeit ist, das WebView tatsächlich zu rendern, leiten Sie die URL in den Cache um. Gleichzeitig werden Multithread-Sperrsynchronisations- und Timeout-Mechanismen verwendet, um die Ladegeschwindigkeit von H5 weiter zu verbessern.
Das allgemeine Flussdiagramm der Parallelladelösung lautet wie folgt:
Nach Abschluss dieser Optimierungen wurde unsere Ladegeschwindigkeit weiter von 3,5 Sekunden auf etwa 2,8 Sekunden optimiert, was einer Steigerung von etwa 23 % entspricht. Durch eine Reihe oben genannter Optimierungsmaßnahmen konnte die Ladezeit unseres H5 von ursprünglich durchschnittlich 5,5 Sekunden auf etwa 2,8 Sekunden reduziert werden. Im Vergleich zu rein nativen (nativen) Seiten besteht jedoch immer noch eine große Lücke in der Ladegeschwindigkeit, und wir müssen weiterhin nach effektiveren Optimierungsmethoden suchen. Um das Benutzererlebnis weiter zu verbessern, haben wir verschiedene technische Versuche unternommen und durch aktive Kommunikation und Zusammenarbeit mit anderen technischen Teams haben wir neue Ideen.
6. Vorwärmen des Behälters
Wenn die APP gestartet wird und der Hauptthread inaktiv ist, können wir die WebView-Engine vorheizen und einen WebView-Cache-Pool erstellen, sodass der vorgewärmte Container wiederverwendet werden kann und die WebView-Ladegeschwindigkeit verbessert werden kann. Diese Optimierungsstrategie zielt hauptsächlich auf Geräte mit mittlerer bis hoher Leistung und Geräte mit geringer Leistung und großem Speicher ab. Wenn das Gerät im Leerlauf ist, heizen wir den WebView-Container vor und fügen den vorgewärmten Container dem Cache-Pool hinzu.
Bei unserer späteren Verwendung beziehen wir den vorgewärmten WebView-Container direkt aus dem WebView-Cache-Pool. Dies spart Zeit beim Erstellen von Webcontainern und Jscore.
7. Vorrendern der Seite
H5 weist auf der TV-Seite viele Einschränkungen in Echtzeit-Geschäftsszenarien auf, insbesondere bei operativen Aktivitäten, die sehr zeitkritisch sind, was unserer Optimierung gewisse Einschränkungen auferlegt. Wir haben jedoch einige Szenarien gefunden, die angepasst und optimiert werden können. Wenn beispielsweise Nicht-Mitglieder Inhalte nur für Mitglieder ansehen, gibt es normalerweise eine 6-minütige kostenlose Testzeit bis H5. Diese Art von Szenario bietet uns natürliche Vorteile für das Vorrendering. In ähnlichen Szenarien wird das Vorrendering automatisch ausgelöst, wenn der Countdown beginnt, sodass H5-Inhalte im Voraus geladen werden können und der sofortige Öffnungseffekt von H5 erzielt wird. Wie im GIF unten gezeigt, ist das obere Bild der Ladevorgang ohne Optimierung, und Sie können den offensichtlichen schwarzen Bildschirm und den Ladevorgang sehen, der das Ergebnis der Optimierung vor dem Rendern ist, wodurch ein echter Sekunden-zu-Sekunde-Start erreicht wird.
Nachdem wir die oben genannten Optimierungsmaßnahmen abgeschlossen und die Daten des Vorjahreszeitraums verglichen haben, können wir anhand der Online-Daten erkennen, dass sich die Ladezeit weiter verkürzt hat, von ursprünglich durchschnittlich 5,5 Sekunden in Nicht-SSR-Szenarien und 3,5 Sekunden in SSR-Szenarien Szenarien auf den aktuellen Durchschnitt von 2 Sekunden. Dies hat das Benutzererlebnis erheblich verbessert.
Erfolge
Am Ende führten wir AB-Experimente zur Optimierung durch. Die Testdaten nach Aufschlüsselung und Mittelung zeigten, dass unsere Optimierungsmaßnahmen die Conversion-Rate der Bestellgenerierungsseite im Durchschnitt um etwa 21 % steigerten und auch die Conversion-Rate der Zahlungserfolgsrate um durchschnittlich 2,4 % stieg.
Experimente haben gezeigt, dass die Verbesserung der Ladegeschwindigkeit und des Benutzererlebnisses wichtiger Unternehmensseiten einen sehr direkten positiven Einfluss auf das Geschäft hat, was uns auch ausreichend Selbstvertrauen und Motivation gibt, die Optimierung auch in Zukunft weiter voranzutreiben.
Zukunftsplan
Wir hoffen, in Zukunft weitere Möglichkeiten zu finden, um Leistungsindikatoren weiter zu reduzieren, die durchschnittliche Seitenzeit auf weniger als 2 Sekunden zu kontrollieren und die Verschlechterung zu kontrollieren.
Darüber hinaus haben wir festgestellt, dass die Durchschnittsdaten die tatsächliche Benutzererfahrung nicht vollständig widerspiegeln. Wir werden die tatsächliche Situation der Benutzer nach dem 90. Perzentil weiter analysieren. Gleichzeitig werden wir weiterhin maßgeschneiderte Optimierungen für wichtige Geschäftsszenarien wie den Kassenschalter durchführen, um die Ladegeschwindigkeit wichtiger Geschäfte weiter zu verbessern und so das Benutzererlebnis und die Geschäftskonvertierung kontinuierlich zu verbessern.
Vielleicht möchten Sie es auch sehen
Dieser Artikel wurde vom öffentlichen WeChat-Konto geteilt – iQIYI Technology Product Team (iQIYI-TP).
Bei Verstößen wenden Sie sich bitte zur Löschung an [email protected].
Dieser Artikel ist Teil des „ OSC Source Creation Plan “. Alle, die ihn lesen, sind herzlich eingeladen, mitzumachen und ihn gemeinsam zu teilen.
