Reduzierung der React Native-Anwendungsgröße um 60% in wenigen einfachen Schritten

Ich arbeite bei Mutual . Sie arbeitet in Brasilien im Bereich der Gleichberechtigung. Wir helfen Kreditnehmern und Kreditgebern, sich miteinander zu verbinden. Die ersteren streben nach guten Wetten, während die letzteren ein Einkommen anstreben, das über dem liegt, was der Markt ihnen bieten kann. Unser Produkt wird von einer Vielzahl von Anwendern verwendet, wir arbeiten in einem großen Land. Infolgedessen werden unsere auf React Native basierenden iOS- und Android-Apps auf sehr unterschiedliche Geräte heruntergeladen.



Es ist zu beachten, dass der Großteil unserer Benutzer Anwendungen auf Budgetgeräten installiert. Wir können solche Schlussfolgerungen aus den Daten aus der Facebook- Geräteklassenbibliothek ziehen .. Diese Bibliothek, die Informationen über das Modell des Geräts erhalten hat, berichtet, in welchem ​​Jahr dieses Gerät als gehobenes Flaggschiff-Telefon gelten würde. Das beliebteste Telefon unter unseren Nutzern ist beispielsweise das Samsung Galaxy A10. Obwohl dieses Telefon im Jahr 2019 veröffentlicht wurde, konnte es erst 2013 als Flaggschiff angesehen werden. Bei der Analyse von Daten auf Benutzergeräten können wir sagen, dass 85% dieser Geräte erst 2015 oder früher als High-End-Geräte erkannt werden konnten. Aus diesem Grund haben wir spezielle Anforderungen an die Optimierung unserer mobilen Anwendung. Ziel der Optimierung ist es, dass auch Benutzer mit schwachen Geräten unsere Anwendung bequem nutzen können.


Prozentsatz der Geräte, die in einem bestimmten Jahr als Flaggschiff erkannt werden konnten

In diesem Zusammenhang haben wir genau auf die Größe der Anwendung geachtet. Bei der Android-Version waren es 26,8 MB. Obwohl dies keine so große Größe ist, ist es definitiv mehr als die mittlere Größe der Anwendungen unserer Benutzer. Diese Zahl beträgt laut Google Play Console 16,3 MB. Die Größe der Anwendung kann ein entscheidender Faktor für Benutzer mit begrenzten Tarifplänen oder für Benutzer mit Geräten mit wenig Speicher sein, wodurch Benutzer gezwungen sind, die von ihnen installierten Anwendungen sorgfältig auszuwählen. Daher müssen einige Anwendungen deinstalliert werden. Dies ist besonders wichtig im Fall des Antrags auf Gegenseitigkeit, da die Kreditnehmer über diesen Antrag monatliche Raten zahlen. Wenn der Kreditnehmer unsere Anwendung deinstalliert, verringert sich die Wahrscheinlichkeit, dass er die Zahlung pünktlich leistet, erheblich.Dies wirkt sich direkt auf die Gewinne der Anleger aus, die unsere Plattform nutzen.


Die Größe der gegenseitigen Anwendung ist viel größer als die mittlere Größe der

Anwendungen unserer Benutzer . Die Größe der Anwendung wirkt sich nicht nur auf den Grad der Deinstallation aus. Die Größe wirkt sich auch auf die Conversion-Rate der Anwendungseinstellungen aus. Hier ist ein guter Artikel dazu, der vom Google Play-Team verfasst wurde. Dieser Artikel beschreibt die Bedeutung der Anwendungsgröße. Insbesondere heißt es, dass jede weiteren 6 MB der Größe der APK-Datei die Konvertierungsrate von Installationen um 1% reduziert.

Sie sprechen auch über die Tatsache, dass in Entwicklungsländern, in denen Haushaltsgeräte die Norm sind, dieser Effekt noch stärker ist. Die Reduzierung der Größe der APK-Datei um 10 MB in Schwellenländern entspricht einer Erhöhung der Konvertierungsrate von Installationen um etwa 2,5%.


Erhöhung der Conversion-Rate von Installationen pro 10 MB Reduzierung der Größe der APK-Datei in verschiedenen Ländern (laut internen Daten von Google)

Wir waren sehr motiviert, wie sich die Reduzierung der Größe der Anwendung auf den Grad der Deinstallation und die Conversion-Rate der Anwendungseinstellungen auswirken kann. Aus diesem Grund haben wir uns daran gemacht, die Größe der Anwendung so weit wie möglich zu reduzieren und dabei die Benutzerfreundlichkeit zu berücksichtigen. Der erste Schritt in diesem Projekt war die Analyse der offiziellenGoogle- Empfehlungen für Android-Entwickler.

Android App Bundle


Beim Lesen der Empfehlungen haben wir festgestellt, dass der einfachste Weg, die Größe einer Anwendung zu reduzieren, die Verwendung einer neuen Anwendungsverteilungsmethode namens Android App Bundle (AAB) ist. Bis zu diesem Moment haben wir die Anwendung verteilt, die gute alte Android-Paketdatei (APK) gesammelt , die auf den meisten Android-Geräten ausgeführt werden kann, und sie auf die Google Play Console hochgeladen. Das AAB-Bundle enthält jedoch nur kompilierten Code und Ressourcen. Daher ist Google beim Herunterladen dafür verantwortlich, optimierte APK-Dateien für verschiedene Gerätetypen unter Berücksichtigung ihrer Spezifikationen und der CPU-Architektur zu generieren.

Es stellt sich heraus, dass wir durch eine einfache Änderung des Erstellungsprozesses des Projekts die Größe der Anwendung ernsthaft reduzieren können, ohne weitere Anstrengungen zu unternehmen. Das ist zu gut für die Wahrheit!

Nachdem wir die Dokumentation zu lesen, wir das Reagieren india Gradle Build - Skript nur geändert , so dass es assembleReleaselaufen würde , statt der aktuellen ein bundleRelease. Das ist alles, was wir zum Erstellen der AAB-Datei benötigen. Nach einigen weiteren Änderungen an der Fastlane-supply Konfiguration bezüglich des automatischen Hochladens von Materialien direkt in den Play Store sind wir zu AAB gewechselt, und eine neue Version unserer Anwendung wurde in der Google Play Console angezeigt.

Diese Änderung allein hat zu einer Verringerung der Größe der auf Benutzergeräte übertragenen APK-Dateien geführt. Der Rückgang lag zwischen 9,1 und 12,4 MB. Wie sich herausstellte, ist die Verwendung des Android App Bundle eine effektive Technik, mit der Sie die Größe der Anwendung reduzieren können.


Die alte APK-Datei und das neue AAB-Bundle, deren Verwendung dazu führt, dass die Größe der Anwendung auf verschiedenen Geräten zwischen 14,4 und 17,7 MB liegen kann.

Richtig, hier sollten Sie vorsichtig sein. Wenn Sie React Native mit Hermes verwenden , müssen Sie möglicherweise Ihre Abhängigkeit aktualisierensoloader(siehe Details hier ). Andernfalls besteht die Gefahr, dass der Benutzer eine Anwendung erhält, die einen kritischen Fehler enthält. Wir hatten Glück, dass wir dieses Problem beim Testen der Alpha-Version des Projekts identifizieren konnten. Der Fehler kann jedoch leicht in die Produktion übergehen, da er beim lokalen Testen oder beim Erstellen der APK-Datei nicht auftritt.

Optimieren von Anwendungsressourcen mit Android Size Analyzer


Der nächste Vorschlag zur Optimierung von Anwendungen, den wir in der Dokumentation gefunden haben, war die Verwendung von Android Size Analyzer . Dies ist ein Befehlszeilentool, das Android-Anwendungen analysiert und nach Möglichkeiten sucht, ihre Größe zu reduzieren. Wir haben dieses Tool mit einem Befehl der folgenden Form gestartet:

size-analyzer check-bundle [BUNDLE].aab

Als Ergebnis haben wir eine Liste großartiger Anwendungsressourcen und Bilder erhalten, die wir optimieren können. Es wurde uns auch empfohlen, ProGuard einzurichten.


Größenanalysatorbericht

RoProGuard


ProGuard ist ein Tool zum Komprimieren, Verschleiern und Optimieren von Java-Bytecode. Wir haben die Möglichkeit der Verwendung dieses Tools noch nicht untersucht, da wir erfahren haben, dass es möglicherweise nicht mit einigen Android-Bibliotheken kompatibel ist. Da wir uns bemüht haben, die Größe unserer Anwendung so schnell wie möglich zu reduzieren und dies so einfach wie möglich zu gestalten, haben wir uns entschlossen, diese Optimierungsmethode in Zukunft beizubehalten.

▍Große App-Ressourcen


Wenn Sie es size-analyzermit dem Schlüssel erneut ausführen, erhalten Sie -deine Liste der Anwendungsressourcen, sortiert nach ihrer Größe. Da dieses Tool nichts darüber weiß, wie Benutzer mit der Anwendung arbeiten, konnten wir unabhängig entscheiden, welche Ressourcen entfernt und welche dynamisch in die Anwendung geladen werden sollen.


Liste der großen Anwendungsressourcen, sortiert nach Größe

Die erste und größte Ressource in dieser Liste war das React Native JavaScript-Bundle. Jetzt können wir dieses Bundle nicht mehr teilen und dynamisch laden. Aber später werden wir darüber nachdenken. Weiter unten in der Liste befinden sich große Schriftdateien (TTF) und Bilddateien (JPG und PNG).

▍Notwendige Bilder


Unsere Aufmerksamkeit wurde sofort auf die riesigen JPG-Bilder gelenkt, die im Storybook verwendet wurden . Wir verwenden dieses System, um Komponenten zu entwickeln und zu testen. Dies sind 2 MB Müll, der in die Produktionsversion des Projekts gefallen ist. Schändlicher Fehler! Wenn so etwas passiert, haben wir das Gefühl, ernsthafte Dummheit getan zu haben. In der komplexen Welt der Softwareentwicklung macht jeder Fehler. Ich glaube, wenn Sie öffentlich über Ihre Fehler sprechen, wird dies anderen Entwicklern helfen, aus diesen Fehlern zu lernen. Es besteht die Möglichkeit, dass Sie dieselben Fehler machen, wenn Sie die Ressourcenstruktur der Anwendung nicht analysieren, deren Größe allmählich zunimmt.

▍ Schriftarten


Nachdem wir unnötige Bilder schnell entfernt hatten, analysierten wir andere Elemente der Ressourcenliste. Es war klar, dass es viele eingebaute Schriftarten gab. Nachdem wir mit unseren Designern darüber gesprochen hatten, sagten sie uns, dass sich viele alte Komponenten nicht in der strikten Einhaltung typografischer Handbücher unterscheiden. Daher haben wir herausgefunden, welche Komponenten entfernt werden können und in welchen Sie die entsprechenden aktualisierten Schriftarten verwenden können. Dank dessen konnten wir die Anzahl der verwendeten Schriftarten von sechs auf vier reduzieren.

Eine andere Sache, die uns aufgefallen ist, war die schiere Größe der Schriftdateien selbst. Die Größe von jedem von ihnen betrug ungefähr 670 Kb. Dies bedeutet, dass vier Schriftarten im unkomprimierten Bundle beeindruckende 2,7 MB belegen. Glücklicherweise gibt es ein Tool namens FontForge , mit dem Sie Schriftdateien gründlich analysieren und ändern können. Mit diesem Tool konnten wir herausfinden, dass der Hauptgrund für die große Größe von Schriftdateien erweiterte kyrillische Zeichen und unnötige Glyphen sind. Wir könnten all dies sicher entfernen, da der Textteil unserer Bewerbung vollständig in Portugiesisch verfasst ist. Dank dieser Änderung konnten wir die Größe der Schriftdateien von 670 KB auf 70 KB reduzieren - um 90%.


Beispiele für einige Glyphen in unseren Schriftarten.

Aufgrund der Tatsache, dass wir unnötige Schriftarten entfernt und die verbleibenden optimiert haben, konnten wir die Anwendungsgröße um 3,8 MB reduzieren. Dies führte zu einer angenehmen Reduzierung der Gesamtgröße der APK-Datei um 2 MB.


Liste der Schriftarten und ihrer Größen vor der Optimierung


Liste der Schriftarten und ihrer Größen nach der Optimierung

▍Optimierung von Bildern


Nach der Analyse der Bilder, die noch in der Anwendung verblieben sind, haben wir festgestellt, dass einige davon ziemlich groß sind. Wir haben mehrere dieser Bilder mit dem TinyPNG- Grafikoptimierungstool verarbeitet und festgestellt, dass die Größe dieser Bilder erheblich reduziert wurde. Danach haben wir beschlossen, alle in der Anwendung verwendeten JPG- und PNG-Bilder zu optimieren. Es waren 41 von ihnen.


Bild vor und nach der Optimierung

Dies gab uns die Möglichkeit, die Größe von Bildern von 2,5 MB auf 756 KB zu reduzieren, dh um 70%. Aufgrund der Tatsache, dass die Bilder zuvor nicht optimiert wurden, wurden sie jedoch bei der Erstellung der endgültigen APK-Datei komprimiert. Es stellte sich heraus, dass unsere Optimierung zu einer Verringerung der Größe der vom Benutzer heruntergeladenen Anwendung um nur 500 KB führte.

Danach stellten wir fest, dass wir bereits alle Möglichkeiten einer schnellen Optimierung ausgeschöpft hatten. Die weitere Optimierung der Ressourcen würde entweder große Anstrengungen oder nur geringfügige Verbesserungen erfordern.

Reagieren Sie auf die native JavaScript-Bundle-Optimierung


Nachdem wir die für die Android-Plattform spezifischen Anwendungsressourcen ermittelt haben, ist es Zeit, das JavaScript-Bundle zu analysieren. Die Bundle-Optimierung kann aus drei Gründen als gute Idee angesehen werden. Erstens wird die Größe der fertigen APK-Datei reduziert. Zweitens führt dies zu einem schnelleren Start der Anwendung, da die virtuelle JS-Maschine weniger Code verarbeiten muss. Schließlich und vor allem beschleunigt es die OTA-Updates, die wir mehrmals pro Woche mit CodePush durchführen .

▍ Bundle-Analysator und Code-Optimierung


Um eine Entscheidung darüber zu treffen, wie die Größe des Bundles reduziert werden soll, mussten Sie zunächst herausfinden, was den größten Platz im Bundle einnimmt. Zu diesem Zweck haben wir das hervorragende Open-Source-Tool React-Native-Bundle-Visualizer verwendet . Nachdem wir das Projekt mit seiner Hilfe analysiert hatten, erhielten wir eine Visualisierung, in der jeder Ordner und jede Anwendungsabhängigkeit vorhanden war und die Größe der entsprechenden Entitäten angab.


Momentaufnahme der Bibliotheken und Ordner der Codebasis des Frontends der Gegenseitigen Anwendung mit der Größenangabe

Wir haben festgestellt, dass die Gesamtgröße des Bundles 5,49 MB beträgt. 57,8% dieses Volumens werden durch Abhängigkeiten aus dem Ordner dargestelltnode_modules, 27,5% - Anwendungscode. Was bleibt, konnte das von uns verwendete Tool nicht identifiziert werden. Während des Assemblierungsprozesses des Bundles wurde nicht verwendeter Code bereits gelöscht. Wir haben also Code gesehen, der tatsächlich von der Anwendung verwendet wird. Aber selbst wenn man dies berücksichtigt, kann man im Bundle immer etwas finden, das verbessert werden kann.

Die größte Projektabhängigkeit istmath.js. Diese Bibliothek implementiert, wie der Name schon sagt, viele mathematische Operationen. Wir haben keinen besonderen Bedarf an dieser Bibliothek, da wir alle wichtigen Berechnungen auf dem Server durchführen und anschließend die Ergebnisse einfach an die Anwendung senden. Beim Betrachten des Anwendungscodes stellte sich heraus, dass die Bibliothek nur zur Ausführung einiger einfacher Vorgänge verwendet wird. Es wurde höchstwahrscheinlich von einem Entwickler verwendet, der nur aus Gewohnheit an Servercode arbeitete. Wir haben schnell die entsprechenden Methoden aus der Bibliothek extrahiert und in unsere Codebasis integriert, um diese Abhängigkeit vollständig zu beseitigen. Dadurch konnte die Größe des Bundles auf 4,64 MB reduziert werden. Durch die Ablehnung nur einer Bibliothek konnte die Größe des Bundles um 15,5% reduziert werden!

Wie bereits erwähnt, verwenden wir das Storybook, um Komponenten zu entwickeln und zu testen. Die entsprechenden Funktionen sollten nur in lokalen und Zwischenumgebungen verfügbar sein. Endbenutzer benötigen dies nicht. Dank dessen haben wir die Variable verwendet ENVIRONMENT, um die Aufnahme des entsprechenden Teils der Anwendung zu steuern. Obwohl dies zur Einschränkung des Zugriffs geeignet ist, kann der Bundler nicht wissen, welcher Wert in diese Variable geschrieben wird. Aufgrund dieser Einschränkung fiel der gesamte Storybook-Code in das Produktionspaket.

Um das Problem zu beheben, haben wir den Import dieses Abschnitts in einer einzigen Datei isoliert. Dann haben wir zwei Versionen dieser Datei erstellt: eine mit dem Storybook und eine für die Produktion, die nur das Komponentenlayout enthält. Um bei der Vorbereitung der Produktionsversion des Bundles zwischen diesen Dateien zu wechseln, haben wir ein Skript geschrieben, das ausgeführt wird, bevor das Projekt erstellt wird, und eine Datei in eine andere ändert. Dank dieser Methode konnten wir den Storybook-Code vollständig aus der Produktionsversion der Anwendung entfernen und sowohl die Abhängigkeit node_modulesals auch den üblichen Code für die Konfiguration von Storybook-Storys entfernen .


Der Storybook-Ordner wurde mit zwei Versionen der Indexdatei aktualisiert. Durch

diese beiden Änderungen wurde die Bundle-Größe von 5,49 MB auf 4,2 MB reduziert. Dies bedeutet unter anderem, dass die Anwendung schneller geladen und schneller aktualisiert wird.


Die Größe des endgültigen Bundles betrug 4,2 MB.

Nach all diesen Verbesserungen haben wir die Anwendung erneut im Play Store heruntergeladen. Nun wurde uns mitgeteilt, dass die Größe der fertigen APK-Datei im Bereich von 10,5 bis 13,7 MB liegen wird. Dies bedeutet angesichts der Tatsache, dass die Anwendung ursprünglich eine Größe von 26,8 MB hatte, einfach eine unglaubliche Reduzierung der Projektgröße um etwa 60%! Wie wir in einem Artikel des Google Play-Teams gesagt haben, können wir also davon ausgehen, dass die Conversion-Rate von Installationen um 3,75% steigen wird.


Vergleich der ursprünglichen APK-Version der Anwendung mit der endgültigen AAB-Version, in der alle oben beschriebenen Verbesserungen vorgenommen wurden

Zusammenfassung


Wir als geschäftsorientierte Programmierer wissen, dass Unternehmen im Interesse einer schnelleren Entwicklung eines Projekts manchmal ihre technische Verschuldung erhöhen können. Dies gilt insbesondere für junge Startups wie Mutual, die versuchen, ihren Platz auf dem Markt zu finden. Wenn Sie diese Schulden jedoch nicht beachten, können Sie ärgerliche Fehler machen, z. B. das Senden von 2 MB Testbildern an die Produktion und die ungerechtfertigte Verwendung einer riesigen Bibliothek. Technische Schulden sollten nicht außer Kontrolle geraten und Probleme verursachen.

Darüber hinaus kommt es häufig vor, dass Entwickler die ihnen zur Verfügung stehenden Möglichkeiten zur Optimierung von Projekten einfach verpassen. Daher wird manchmal empfohlen, Ihre Projekte kritisch zu analysieren. Nur um zu überprüfen, ob Sie eine Gelegenheit verpasst haben, die Größe, Geschwindigkeit oder einen anderen Aspekt der Anwendung schnell zu optimieren. Wir haben nur zwei Tage gebraucht, um die Anwendung zu analysieren, die Arbeit zu planen und das Projekt zu verbessern, wodurch wir die Größe der Anwendung um 60% reduzieren konnten. Es ist schwierig, etwas anderes zu finden, das in so kurzer Zeit die gleichen Ergebnisse erzielen kann.

Wie optimieren Sie Ihre React Native-Projekte?


All Articles