Trop d'activités sur Android?

Question

Lorsque j'ai commencé mon projet Android, j'ai eu un malentendu sur le fait que chaque écran affiché dans l'application doit être une nouvelle activité. Maintenant, j'ai terminé avec le projet, je l'ai vérifié sur mon émulateur ainsi que sur un couple de téléphones Android. Jusqu'à présent, je ne suis pas témoin de problèmes, mais récemment, j'ai lu quelque part que trop d'activités dans l'application sont une très mauvaise idée.

Actuellement, mon application a environ 15-20 activités.Ideally j'ai entendu dire qu'il devrait être d'environ 5-6. Ai-je besoin de restructurer mon code ou de simplement terminer chaque activité après l'avoir fait, c'est suffisant?

Answer 1

Lors de la création d'applications complexes, vous devez créer de nombreuses activités. Cela dépend donc de votre application du nombre d'activités dont vous avez besoin. Aucune activité d'un projet n'affecte la performance.

L'effet est produit par le nombre d'activités dans la pile de votre Android. Il est donc préférable de garder 5-6 activités dans la pile (Terminer les activités si elles ne sont plus nécessaires).

Créez donc autant d'activités que votre application l'exige, mais gardez une taille plus petite d'activités ouvertes à la fois.

Answer 2

Cela dépend finalement de ce que vous faites. Il y a des moments où vous ne pouvez pas modifier suffisamment la vue pour faire la différence. Idéalement, 5-6 activités sont super, mais dans certains cas ce n'est pas seulement faisable. J'ai fait une application mobile avec environ 40 classes différentes, et environ 18 activités. Il devait juste être fait de cette façon en fonction de la façon dont l'application devait interagir avec l'utilisateur. Si vous pouvez fusionner 2 ou 3 activités en une, c'est génial. Cela aidera aussi à la taille du fichier et à l'optimisation, mais si vous ne pouvez pas ... Ne vous inquiétez pas trop.

Answer 3

Je dirais 15 écrans différents = 15 activités différentes. Je pense que l'une des raisons pour lesquelles certains sont capables de réduire le nombre d'activités est l'introduction de fragments. Bien qu'on puisse argumenter pourquoi utiliser des fragments si les activités individuelles fonctionnent. Je suppose que cela dépend de la préférence des développeurs.

Answer 4

Le système Android essaie de maintenir un processus d'application aussi longtemps que possible, mais doit éventuellement supprimer les anciens processus pour récupérer la mémoire pour les processus nouveaux ou plus importants. Cela s'applique aux Activity s qui tournent en arrière-plan ... les anciens Activity sont gérés pour vous et sont détruits lorsque le système a besoin de récupérer de la mémoire pour de nouveaux processus.

Cela étant dit, je pense qu'il ya deux choses que vous devriez considérer:

1. expérience utilisateur. Votre application nécessite-t-elle vraiment 15-20 Activity s? Pouvez-vous réduire le nombre d'écrans en quelque sorte? Moins Activity s est généralement préférable, car il nécessite moins d'interaction lorsque l'utilisateur navigue dans l'application.

2. Exécution de code. Bien que chaque Activity aura sa propre classe distincte, cela ne vous empêche pas de prendre des décisions de conception intelligentes lors de la mise en œuvre de votre application. Par exemple, vous pouvez essayer de regrouper les Activity similaires en leur attribuant un abstract class. Au fur et à mesure que les projets Android prennent de l'ampleur, ils deviennent plus difficiles à gérer. Le partage de code entre des classes similaires de cette manière vous permettra de faire de simples modifications au cœur de votre application sans trop de problèmes.

Answer 5

Si votre projet comporte de nombreuses activités mais que certaines activités ne sont pas importantes, cela signifie que vous n'avez besoin d'aucune activité après le démarrage d'une autre activité.

dans le jeu de fichier manifeste: android:noHistory="true"

Exemple:

Activity1 -> Activity2 -> Activity3 -> Activity4..................-> Activity20 

Dans le fichier manifeste:

activity android:name=".Activity1" android:label="@string/app_name" android:noHistory="true" 

si u appeler à nouveau Activity1 utilisant intention de finition de consigne() avant startActivity()

Je pense que cela peut vous aider