Grab a réduit sa superapplication d’un quart pour survivre

En 2019, Grab, développeur de superapplications d’Asie du Sud-Est, a repéré un problème : la taille de son application augmentait d’un pour cent par mois, ce qui la rendait moins adaptée aux smartphones modestes que l’on trouve dans la région dans laquelle il opère, dégradant l’expérience utilisateur et menaçant finalement ses perspectives de développement. attirer plus d’utilisateurs.

« Alors que l’application continue de se développer avec davantage de fonctionnalités, Grab a identifié le besoin d’une expérience cohérente et de haute qualité pour les nouveaux utilisateurs qui peuvent disposer d’un espace de stockage limité ou d’une bande passante Internet limitée », a expliqué le développeur sur son blog d’ingénierie la semaine dernière.

L’application Grab a commencé par proposer des services de covoiturage et s’est étendue au cours de la décennie suivante à la livraison de nourriture, à la livraison de colis, au paiement mobile et même à ses propres prêts ciblés sur les conducteurs.

Tous les utilisateurs n’utilisent pas toutes les offres, mais toutes les fonctionnalités restent présentes dans l’application qui compte désormais quatre millions de lignes de code.

Au troisième trimestre 2021, la société basée à Singapour a donc lancé Project Bonsai dans le but de réduire la taille de téléchargement et l’empreinte disque de son application. En six mois, il a amélioré le premier de 26 pour cent et a également réduit de manière non spécifiée les besoins de stockage.

Avant Project Bonsai, Grab utilisait déjà une approche de bundle d’applications et adaptait les APK à des configurations d’appareils spécifiques. De plus, il a surveillé les modifications apportées à l’application, établi une surveillance de la construction de débogage (taille du fichier APK) pour chaque validation fusionnée dans la branche principale, utilisé R8/Proguard comme « réducteur de code », utilisé des images vectorielles lorsque cela était possible au lieu d’images raster, a permis à ResourceConfig de se débarrasser des langues non utilisées dans ses régions et a examiné les bibliothèques tierces pour déceler leur gonflement.

Mais tout cela ne suffisait pas. Ainsi, avec Project Bonsai, Grab a cherché à mesurer, réduire et contenir la taille de son application par tous les moyens nécessaires.

Tout a commencé par la création d’un outil personnalisé pour analyser les binaires à partir de fichiers groupés. Il a nommé l’outil App Sizer et intégré à son flux de travail.

L’outil envoie des données à une instance Grafana pour surveiller et observer la taille de téléchargement des applications spécifiques à l’appareil, identifie les bibliothèques et les modules qui utilisent le plus d’espace de stockage et crée une liste de fichiers volumineux.

Saisissez l’intention d’ouvrir l’outil en source dans un avenir proche.

Pour réduire la taille de l’application, Grab a décidé de ne rien ajouter de nouveau, mais de cibler les plus gros contrevenants qu’il pouvait trouver.

« Notre concentration s’est concentrée sur l’optimisation de la taille du fichier dex, le raffinement des ressources et l’élimination de la duplication et de la redondance », a expliqué Grab.

Le code Java/Kotlin était le principal contributeur à la taille de l’application et est donc devenu une priorité absolue en matière d’optimisation. Et dans ce code, les classes R étaient les principaux coupables. « Les classes R contenaient des références d’ID non seulement à leurs propres ressources mais également aux ressources de leurs dépendances transitives », ont noté les auteurs du blog.

« Cela signifiait que si le module A dépendait du module B, et que le module B, à son tour, dépendait du module C (Module A -> Module B -> Module C), alors la classe R du module A incluait des références d’ID aux ressources des modules B et C. , même si le module A n’utilisait pas directement ces ressources. Cela expliquait pourquoi les classes R dans un projet modularisé pouvaient accumuler des millions de lignes de code », expliquent les auteurs.

La boutique de superapplications a également constaté que son application contenait plus de 1 500 modules et bibliothèques tierces, ce qui a conduit à la génération de classes R considérablement volumineuses. Cela explique cependant pourquoi les ingénieurs logiciels ont constaté des pics lors de certaines validations, malgré l’absence d’ajouts significatifs de ressources, de bibliothèques ou de code.

« Ces fluctuations étaient liées à des changements dans le graphe de dépendance, soulignant encore davantage l’impact des classes Transitive R », ont rappelé les développeurs de Grab. De plus, les classes R étaient préservées grâce à des règles par défaut. Ce problème a été corrigé en mettant à jour la version AGP après avoir effectué un test d’automatisation pour éviter de supprimer par inadvertance les champs de classe R utilisés. Ce test a été effectué par script pour rechercher des instances où des réflexions de classe R ont été utilisées. Les bibliothèques tierces ont été décompilées et ont appliqué le même script. Ensuite, Grab a révisé ses règles de configuration R8 à la recherche de redondance.

Bin le ballonnement

Lorsque des fichiers volumineux étaient détectés, l’équipe responsable était encouragée à les supprimer si cela était jugé inutile, à envisager de les décharger sur un serveur cloud ou à les convertir dans des formats de fichiers plus économiques.

Même les polices ont été rationalisées à mesure que la superapplication supprimait les polices rarement utilisées et éliminait les doublons. Grab travaille maintenant à adopter une police unique.

« Notre recommandation est d’explorer l’utilisation d’un style de police principal, avec la possibilité d’incorporer différentes variantes de polices dans votre programmation pour obtenir différentes polices de caractères utilisant la même police », explique le message de Grab.

Il a été constaté qu’une bibliothèque spécifique représentait huit pour cent de l’empreinte de stockage de l’application. Grab l’a supprimé et a travaillé pour supprimer les fonctions en double dans d’autres bibliothèques.

L’ajout à l’application d’une bascule permettant de désactiver une fonctionnalité à distance a également contribué à l’effort de réduction.

« C’est très utile pour réaliser une expérience ou pour désactiver si une fonctionnalité nous pose problème », notent les auteurs du blog.

Grab continue d’explorer des méthodes pour conserver son application, y compris des composants de conception d’interface utilisateur courants et expérimenter la livraison dynamique.

Grab envisage d’attribuer à chaque équipe un « budget de taille d’application » obligatoire.

« En donnant la priorité à l’optimisation du code, à la gestion des ressources, à la modularisation et au regroupement d’actifs, nous avons réalisé des optimisations substantielles de la taille des applications tout en améliorant l’expérience utilisateur », se vante Grab.

Le problème du gonflement des applications n’est pas susceptible de disparaître, particulièrement en Asie du Sud-Est, à mesure que l’utilisation des smartphones continue de croître, mais pas la capacité des consommateurs à les payer.

L’année dernière, une enquête YouGov auprès des consommateurs asiatiques a révélé que les trois quarts des personnes interrogées entre 18 et 40 ans préféraient les téléphones de milieu de gamme en raison de leurs prix attractifs, même si cela signifie manquer certaines fonctionnalités. L’étude a été sponsorisée par la marque Poco soutenue par Xiaomi, alors prenez-la avec précaution.