Je lis depuis longtemps sur les performances du code et les paramètres de réglage.En effet, les programmes Android sont l'un de mes centres d'intérêt.
Introduisons d'abord les concepts de base ou les plus importants dans lesquels nous aider à trouver une solution.
Comme l' a déclaré le développeur Android
le module peut être construit, testé et débogué indépendamment
Par conséquent, les modules ont leurs propres Gradle et dépendances . Et vous pouvez les explorer dans le projet Hierarchy Viewer.
En fait, la modularisation met l'accent sur les questions de maintenance . Contrairement aux performances, la modularisation a cet impact important:
- Augmentez la profondeur de l'héritage
Voici un diagramme que j'ai tracé pour le rendre clair. Comme vous pouvez le voir en utilisant un module discret, afin d'appeler la méthode A, il est 2N micro secscomparé à N micro secssans module discret.
Cette question me vient à l'esprit que les méthodes référencées comptent ce qui est lié à la profondeur de l'héritage?
La réponse est: bien que l'utilisation de la modularisation augmente les méthodes référencées, mais cela n'affecte pas réellement les performances de l'application et le principal problème possible est la profondeur d'héritage dans laquelle, dans la plupart des cas, elle est ignorable .
Je souligne que l'augmentation des méthodes référencées dans la modularisation est due à chaque module Gradle & Dependencies
Comment la modularisation des applications peut-elle augmenter considérablement le nombre de méthodes référencées?
Conditions dans lesquelles l'impact APK analyseur est important Méthodes référencées
Notez également que la minification et la réduction du code peuvent également modifier considérablement le contenu d'un fichier DEX après la compilation du code source.
En plus de la déclaration officielle ci-dessus, je veux ajouter une autre condition dans laquelle l'impact APK analyseur qui est:
Quelle est l'expérience du développeur en modularisation?
la modularisation est comme une maison où l' architecture (développeur) définit où devrait être la cuisine et où devraient être les toilettes et où devraient être les toilettes.
Et si l'architecture décidait de combiner WC et cuisine? Oui, c'est un désastre.
Cela peut se produire lors de la modularisation si le développeur n'est pas très expérimenté.
Répondre aux questions OP en plus d'informations supplémentaires
Ici, je réponds aux questions posées dans les commentaires
Pourquoi Gradle séparé ajouterait-il au nombre de méthodes référencées? Et pour les dépendances distinctes, si le résultat final est un fichier APK unique, je ne pense pas que les dépendances en double dans 'app' et le module de fonctionnalité ajouteraient au nombre de méthodes référencées.
Parce que les modules peuvent être construits, testés et débogués, ils DOIVENT avoir leurs propres Gradle et dépendances.
Pendant que le projet multi-module est en cours d'exécution, le compilateur génère plusieurs .dexfichiers, notamment:
- un
.dexfichier pour les dépendances totalement intégrées
- modules
.dexs
.dexfichier de dépendances est une intégration de tous les modules gradles
Voyons comment un gradle de module impacte le nombre final de mothods référencés?!
il y a 2 APK s avec le même résultat mais une différence dans le nombre de méthodes référencées.
Ce sont deux activités vides qui ont une 1.7kdifférence dans le nombre de méthodes référencées qui est très élevée en fonction de leur fonctionnalité. Leur différence clé est sur le Gradle de leur module, l' un d'eux a été configuré pour
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
}
Un autre configuré pour
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.2.0-alpha01'
implementation 'androidx.constraintlayout:constraintlayout:2.0.0-beta4'
}
Bien que ce ne soient que des activités vides, une différence minimale dans Gradle a provoqué une 1.7kdifférence dans le nombre de méthodes référencées.
Et App Gradle est
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation project(path: ':module')
}
la principale préoccupation est pourquoi l'ajout du nombre de méthodes référencées individuellement est différent du nombre total de méthodes référencées dans Apk Analyzer?
Ce n'est rien d'autre que le filtre IDE. à coup sûr, si vous sélectionnez uniquement un .dexfichier, le nombre de méthodes de référence est égal à la somme des nombres de méthodes référencées de chaque ligne, mais si vous sélectionnez plusieurs .dexfichiers, vous verrez une différence dans la somme et le nombre réel qu'en raison de l'égalité dans les références qu'Analyzer a préféré les filtrer.
dans vos captures d'écran, vous avez sélectionné plusieurs .dexfichiers, puis l'égalité du filtre Analyzer.
dans notre projet, nous utilisons un fichier dependencies.gradle centralisé, il n'y a donc aucune chance de version différente. Donc, pensez-vous que même si nous avons le même ensemble de dépendances et leurs versions dans les modules de fonctionnalités, cela augmentera le nombre de méthodes référencées?
Théoriquement, cela ne devrait PAS augmenter le nombre de méthodes référencées. MAIS , comme je l'ai expliqué, l' expérience développeur a un impact important sur le résultat final.
Team Analyzer doit vérifier et résoudre les problèmes de performances avant la sortie, comme
- règles de proguard
- ressources réduites et réduites
- androidManifest.xml
- paramètres gradle
Maintenant, je veux clarifier comment l' expérience développeur et la maintenance du code affectent le résultat final. MÊME si votre APK utilise des dépendances centralisées
dans l'exemple ci-dessus, j'ai augmenté le nombre 5.1kde méthodes référencées MÊME SI j'avais des dépendances centralisées !!!!!
Comment c'est possible ?
La réponse est: je viens d'ajouter un .jarfichier inutile et caché dans le libsrépertoire du projet. aussi simple que vous pouvez le voir, j'ai affecté le résultat final.
Comme vous pouvez le voir Expérience Developer affecte result.as finale par conséquent, pratiquement il est possible que les méthodes référencées compte pour augmenter Bien que théoriquement devrait -elle pas .
Et pourquoi il n'y a pas de différence dans le nombre de méthodes référencées lorsque je compile uniquement le module «app» en désactivant la compilation parallèle? Il aurait dû diminuer car seules les dépendances du module «app» auraient été utilisées, non?
la compilation n'a aucun rapport avec les méthodes référencées count.it est conforme à ce que le développeur veut se conformer.
Conclusion
J'ai couvert toutes les possibilités autour de la question. En effet, il peut être issu de différentes situations et un développeur en utilisant cette directive peut résoudre le problème.
- J'espère que vous avez trouvé pourquoi les méthodes référencées ont été augmentées et pourquoi dans certains cas, elles pourraient être considérablement augmentées.
- Les modules ont leurs Gradle & Dependencies et modules de modularisation. par conséquent, ces références de méthode.
- La modularisation a en fait un impact sur les performances de l'application, mais elle améliore grandement la maintenance de votre application.
- L'expérience des développeurs en modularisation a également un impact important sur le résultat final.
NOTE IMPORTANTE: presque toutes les déclarations sont mes enquêtes et recherches. en effet, il peut y avoir des erreurs et des défauts et sera mis à jour afin d'ajouter beaucoup plus d'informations à l'avenir.
