Je travaille chez Mutual . Elle travaille au Brésil, dans le domaine de l'égalité de crédit. Nous aidons les emprunteurs et les prêteurs à se connecter les uns aux autres. Les premiers recherchent de bons paris, tandis que les seconds recherchent un revenu supérieur à ce que le marché peut leur offrir. Notre produit est utilisé par un large éventail d'utilisateurs, nous travaillons dans un grand pays. En conséquence, nos applications iOS et Android basées sur React Native se téléchargent sur des appareils très différents.
Il convient de noter que la plupart de nos utilisateurs installent des applications sur des appareils à petit budget. Nous pouvons tirer de telles conclusions en utilisant les données de la bibliothèque de classe d'appareil de Facebook.. Cette bibliothèque, après avoir reçu des informations sur le modèle de l'appareil, indique l'année dans laquelle cet appareil serait considéré comme un téléphone phare haut de gamme. Par exemple, le téléphone le plus populaire parmi nos utilisateurs est le Samsung Galaxy A10. Ce téléphone, bien qu'il soit sorti en 2019, ne pouvait être considéré comme le produit phare qu'en 2013. En analysant les données sur les appareils des utilisateurs, nous pouvons dire que 85% de ces appareils ne pouvaient être reconnus comme des appareils haut de gamme qu'en 2015 ou avant. Pour cette raison, nous avons des exigences particulières pour optimiser notre application mobile. Le but de l'optimisation est que même les utilisateurs avec des appareils faibles puissent utiliser confortablement notre application.Pourcentage d'appareils pouvant être reconnus comme phares au cours d'une année donnéeÀ cet égard, nous avons prêté une attention particulière à la taille de l'application. Dans le cas de sa version Android, il était de 26,8 Mo. Bien que ce ne soit pas une si grande taille, c'est certainement plus que la taille médiane des applications de nos utilisateurs. Selon la console Google Play, ce chiffre est de 16,3 Mo. La taille de l'application peut être un facteur décisif pour les utilisateurs avec des plans tarifaires limités, ou pour ceux avec des dispositifs à faible mémoire, ce qui oblige les utilisateurs à sélectionner soigneusement les applications qu'ils auront installées. Par conséquent, certaines applications doivent être désinstallées. Cela est particulièrement important dans le cas de la demande mutuelle, car les emprunteurs paient des versements mensuels via cette application. Lorsque l'emprunteur désinstalle notre application, les chances qu'il effectue le paiement à temps sont considérablement réduites.Et cela affecte directement les revenus des investisseurs utilisant notre plateforme.
Ensemble d'applications Android
En lisant les recommandations, nous avons appris que la façon la plus simple de réduire la taille d'une application est d'utiliser une nouvelle méthode de distribution d'application appelée Android App Bundle (AAB). Jusqu'à ce moment, nous avons distribué l'application, collecté le bon vieux fichier Android Package (APK), qui peut être exécuté sur la plupart des appareils Android, et téléchargé vers la console Google Play. Mais le bundle AAB ne contient que du code et des ressources compilés. Par conséquent, lors de son téléchargement, Google est responsable de la génération de fichiers APK optimisés pour différents types d'appareils, en tenant compte de leurs spécifications et de leur architecture CPU.Il s'avère qu'en apportant un simple changement au processus de construction du projet, pouvons-nous obtenir une réduction sérieuse de la taille de l'application sans faire plus d'efforts? C'est trop beau pour la vérité!Après avoir lu la documentation, nous venons de changer le script de construction React Native Gradle afin qu'il assembleReleases'exécute à la place du script actuel bundleRelease. C'est tout ce dont nous avions besoin pour créer le fichier AAB. Après quelques modifications supplémentaires apportées à la supplyconfiguration Fastlane concernant le téléchargement automatique de documents directement sur le Play Store, nous sommes passés à AAB et une nouvelle version de notre application est apparue dans la console Google Play.Ce changement à lui seul a entraîné une réduction de la taille des fichiers APK transférés sur les appareils des utilisateurs. La diminution variait de 9,1 à 12,4 Mo. Il s'est avéré que l'utilisation du bundle d'applications Android est une technique efficace qui, en effet, vous permet de réduire la taille de l'application.L'ancien fichier APK et le nouveau bundle AAB, dont l'utilisation conduit au fait que la taille de l'application sur différents appareils peut aller de 14,4 à 17,7 Mo.Vrai, vous devez être prudent ici. Si vous utilisez React Native avec Hermes , vous devrez peut-être mettre à jour votre dépendancesoloader(voir les détails ici ). Sinon, il existe un risque de donner à l'utilisateur une application qui contiendra une erreur critique. Nous avons eu de la chance, nous avons pu identifier ce problème lors des tests de la version alpha du projet. Mais l'erreur pourrait facilement se glisser en production, car elle n'apparaît pas lors des tests locaux ou lors de la création du fichier APK.Optimisation des ressources d'application à l'aide d'Android Size Analyzer
La prochaine suggestion d'optimisation des applications que nous avons trouvée dans la documentation était l'utilisation d' Android Size Analyzer . Il s'agit d'un outil en ligne de commande qui analyse les applications Android et cherche des moyens de réduire leur taille. Nous avons lancé cet outil à l'aide d'une commande de la forme suivante:size-analyzer check-bundle [BUNDLE].aab
En conséquence, nous avons obtenu une liste d'excellentes ressources d'application et d'images que nous pouvons optimiser. Il nous a également été recommandé de configurer ProGuard.Rapport d'analyseur de taille▍ProGuard
ProGuard est un outil pour compresser, masquer et optimiser le bytecode Java. Nous n'avons pas encore exploré la possibilité d'utiliser cet outil, car nous avons appris qu'il pourrait ne pas être compatible avec certaines bibliothèques Android. Puisque nous nous sommes efforcés de réduire la taille de notre application le plus rapidement possible et de rendre cela aussi simple que possible, nous avons décidé de laisser cette méthode d'optimisation à l'avenir.▍Grandes ressources d'application
En l'exécutant à size-analyzernouveau, avec la clé -d, nous avons obtenu une liste de ressources d'application, triées par leur taille. Étant donné que cet outil ne sait rien de la façon exacte dont les utilisateurs travaillent avec l'application, il nous a donné la possibilité de décider indépendamment quelles ressources doivent être supprimées et lesquelles doivent être chargées dynamiquement dans l'application.Liste des ressources d'application volumineuses triées par tailleLa première et la plus grande ressource de cette liste était le bundle React Native JavaScript. Maintenant, nous ne pouvons pas fractionner ce bundle et le charger dynamiquement. Mais plus tard, nous y penserons. Plus bas dans la liste se trouvent de gros fichiers de polices (TTF) et des fichiers d'images (JPG et PNG).▍ Images inutiles
Notre attention a été immédiatement attirée sur les énormes images JPG utilisées dans le livre de contes . Nous utilisons ce système pour développer et tester des composants. Il s'agit de 2 Mo de déchets tombés dans la version de production du projet. Erreur honteuse! Quand quelque chose comme ça se produit, nous avons l'impression d'avoir fait une grave stupidité. Mais dans le monde complexe du développement logiciel, tout le monde fait des erreurs. Je crois que si vous parlez de vos erreurs publiquement, cela aidera les autres développeurs à apprendre de ces erreurs. Il est possible que vous fassiez les mêmes erreurs si vous n'analysez pas la structure des ressources de l'application, dont la taille augmente progressivement.▍ Polices
Après nous être rapidement débarrassés des images inutiles, nous avons procédé à l'analyse d'autres éléments de la liste des ressources. Il était clair qu'il y avait beaucoup de polices intégrées. Après en avoir discuté avec nos concepteurs, ils nous ont dit que de nombreux anciens composants ne diffèrent pas dans le strict respect des manuels typographiques. Par conséquent, nous avons découvert quels composants peuvent être supprimés et dans lesquels vous pouvez utiliser les polices mises à jour appropriées. Grâce à cela, nous avons pu réduire le nombre de polices utilisées de six à quatre.Une autre chose que nous avons remarquée était la taille même des fichiers de polices eux-mêmes. La taille de chacun d'eux était d'environ 670 Kb. Cela signifie que quatre polices du paquet non compressé occupent un superbe 2,7 Mo. Mais, heureusement, il existe un outil appelé FontForge qui vous permet d'analyser et de modifier en profondeur les fichiers de polices. À l'aide de cet outil, nous avons pu découvrir que la principale raison de la grande taille des fichiers de police était les caractères cyrilliques étendus et les glyphes inutiles. Nous pourrions supprimer tout cela en toute sécurité, car la partie texte de notre application est entièrement écrite en portugais. Grâce à ce changement, nous avons pu réduire la taille des fichiers de polices de 670 Ko à 70 Ko - de 90%.Exemples de glyphes inclus dans nos polices.Du fait que nous avons supprimé les polices inutiles et optimisé les autres, nous avons pu réduire la taille de l'application de 3,8 Mo. Cela a entraîné une réduction agréable de 2 Mo de la taille totale du fichier APK.Liste des polices et de leurs tailles avant optimisationListe des polices et de leurs tailles après optimisation▍Optimisation des images
Après avoir analysé les images qui restaient encore dans l'application, nous avons remarqué que certaines d'entre elles sont assez grandes. Nous avons traité plusieurs de ces images avec l' outil d' optimisation graphique TinyPNG et constaté une réduction significative de la taille de ces images. Après cela, nous avons décidé d'optimiser toutes les images JPG et PNG utilisées dans l'application. Il y en avait 41.Image avant et après optimisationCela nous a permis de réduire la taille des images de 2,5 Mo à 756 Ko, soit 70%. Cependant, du fait que les images n'étaient pas optimisées auparavant, elles ont été compressées lors de la création du fichier APK final. Il s'est avéré que notre optimisation a entraîné une diminution de la taille de l'application téléchargée par l'utilisateur de seulement 500 Ko.Après cela, nous avons réalisé que nous avions déjà épuisé toutes les possibilités d'optimisation rapide. La poursuite de l'optimisation des ressources nécessiterait soit de grands efforts, soit seulement des améliorations mineures.React Native JavaScript Bundle Optimization
Après avoir compris les ressources d'application spécifiques à la plate-forme Android, il est temps d'analyser le bundle JavaScript. L'optimisation des bundles peut être considérée comme une bonne idée pour trois raisons. Premièrement, cela réduit la taille du fichier APK fini. Deuxièmement, cela entraîne un lancement plus rapide de l'application, car la machine virtuelle JS doit traiter moins de code. Enfin, et surtout, cela accélère les mises à jour OTA que nous faisons plusieurs fois par semaine en utilisant CodePush .▍ Analyseur de bundles et optimisation de code
Afin de prendre une décision sur la façon de réduire la taille de l'ensemble, vous devez d'abord déterminer ce qui prend le plus de place dans l'ensemble. Pour ce faire, nous avons utilisé l'excellent outil open source react-native-bundle-visualizer . Après avoir analysé le projet avec son aide, nous avons obtenu une visualisation dans laquelle chaque dossier et chaque dépendance d'application étaient présents, indiquant les tailles des entités correspondantes.Instantané des bibliothèques et dossiers de la base de code du frontend de l'application Mutual avec indication des taillesNous avons découvert que la taille totale du bundle est de 5,49 Mo. 57,8% de ce volume est représenté par des dépendances du dossiernode_modules, 27,5% - code d'application. Ce qui reste, l'outil utilisé par nous n'a pas pu être identifié. Pendant le processus d'assemblage du bundle, le code inutilisé a déjà été supprimé, donc ce que nous avons vu était du code qui est réellement utilisé par l'application. Mais, même en tenant compte de cela, dans le bundle, vous pouvez toujours trouver quelque chose qui peut être amélioré.La plus grande dépendance du projet estmath.js. Cette bibliothèque, comme son nom l'indique, implémente de nombreuses opérations mathématiques. Nous n'avons pas un besoin particulier pour cette bibliothèque car nous effectuons tous les calculs importants sur le serveur, après quoi nous envoyons simplement les résultats à l'application. Lorsque nous avons examiné le code de l'application, il s'est avéré que la bibliothèque n'est utilisée que pour effectuer des opérations simples. Il était très probablement utilisé par un développeur qui ne travaillait sur le code du serveur que par habitude. Nous avons rapidement extrait les méthodes appropriées de la bibliothèque et les avons intégrées dans notre base de code, en nous débarrassant complètement de cette dépendance. Cela a permis de réduire la taille du bundle à 4,64 Mo. Le refus d'une seule bibliothèque a permis de réduire la taille du bundle de 15,5%!Comme déjà mentionné, nous utilisons le Storybook pour développer et tester des composants. Certes, les capacités correspondantes ne devraient être disponibles que dans les environnements locaux et intermédiaires. Les utilisateurs finaux n'en ont pas besoin. Grâce à cela, nous avons utilisé la variable ENVIRONMENTpour contrôler l'inclusion de la partie correspondante de l'application. Bien que cela soit approprié pour restreindre l'accès, le regroupeur ne peut pas savoir quelle valeur est écrite dans cette variable. En raison de cette limitation, tout le code Storybook est tombé dans le bundle de production.Afin de résoudre le problème, nous avons isolé l'importation de cette section dans un seul fichier. Ensuite, nous avons créé deux versions de ce fichier: une qui comprend le livre d'histoires et une autre destinée à la production, qui ne contient que la disposition des composants. Pour basculer entre ces fichiers lors de la préparation de la version de production du bundle, nous avons écrit un script qui est exécuté avant la construction du projet et change un fichier en un autre. Grâce à cette méthode, nous avons pu supprimer complètement le code Storybook de la version de production de l'application, supprimant à la fois la dépendance node_moduleset le code habituel concernant la configuration des «histoires» Storybook.Mise à jour du dossier Storybook avec deux versions du fichier d'index.Ces deux modifications ont réduit la taille de l'ensemble de 5,49 Mo à 4,2 Mo. Cela signifie, entre autres, que l'application se chargera plus rapidement et se mettra à jour plus rapidement.La taille de l'ensemble final était de 4,2 Mo.Après toutes ces améliorations, nous avons de nouveau téléchargé l'application dans le Play Store. Maintenant, nous avons été informés que la taille du fichier APK fini sera comprise entre 10,5 et 13,7 Mo. Cela, étant donné que l'application avait à l'origine une taille de 26,8 Mo, signifie simplement une réduction incroyable de la taille du projet d'environ 60%! Ainsi, comme nous l'avons dit dans un article de l'équipe Google Play, nous pouvons nous attendre à ce que le taux de conversion des installations augmente de 3,75%.Comparaison de la version APK d'origine de l'application avec la version AAB finale, dans laquelle toutes les améliorations décrites ci-dessus sont apportéesSommaire
En tant que programmeurs orientés métier, nous savons que, parfois, pour accélérer le développement d'un projet, les entreprises peuvent continuer d'augmenter leur dette technique. Cela est particulièrement vrai pour les jeunes startups comme Mutual, qui essaient de trouver leur place sur le marché. Mais si vous n'observez pas cette dette, vous pouvez faire des erreurs gênantes, comme l'envoi de 2 Mo d'images de test à la production et l'utilisation injustifiée d'une immense bibliothèque. La dette technique ne devrait pas devenir incontrôlable et causer des problèmes.De plus, il arrive souvent que les développeurs manquent tout simplement les opportunités qui s'offrent à eux pour optimiser les projets. Par conséquent, il est parfois recommandé d'analyser de manière critique vos projets. Juste pour vérifier si vous avez manqué une occasion d'optimiser rapidement la taille, la vitesse ou tout autre aspect de l'application. Il nous a fallu seulement deux jours pour analyser l'application, planifier le travail et apporter des améliorations au projet, ce qui nous a permis de réduire la taille de l'application de 60%. Il est difficile de trouver autre chose qui puisse produire les mêmes résultats en si peu de temps.Comment optimisez-vous vos projets React Native?