J'ai donc rencontré ces meilleures pratiques sur Android articles sur les performances de la mémoire.
http://developer.Android.com/training/articles/memory.html
Ils ont dit
Évitez les cadres d'injection de dépendance
L'utilisation d'un framework d'injection de dépendances tel que Guice ou RoboGuice peut être attrayante car elle peut simplifier le code que vous écrivez et fournir un environnement adaptatif utile pour les tests et autres modifications de configuration. Cependant, ces frameworks ont tendance à effectuer beaucoup d'initialisation de processus en analysant votre code pour les annotations, ce qui peut nécessiter que des quantités importantes de votre code soient mappées dans RAM même si vous n'en avez pas besoin). Ces pages mappées sont allouées dans une mémoire propre afin que Android puisse les supprimer, mais cela ne se produira que lorsque les pages auront été laissées en mémoire pendant une longue période de temps.
Mais qu'en est-il de Dagger qu'ils prétendent être rapides. Vous ne savez pas lequel choisir?
Cette recommandation ne s'applique pas à tous les frameworks d'injection de dépendances.
..frameworks [qui fonctionne comme Guice] a tendance à effectuer beaucoup d'initialisation de processus en en analysant votre code pour les annotations , ce qui peut nécessite que des quantités importantes de votre code soient mappées dans la RAM même si vous n'en avez pas besoin ..
Ainsi, si vous utilisez un framework DI/IoC qui ne recherche pas lesdites annotations [d'exécution], impliquant l'utilisation [excessive] de la réflexion, alors cette raison ne s'applique pas. Alors que Dagger utilise des annotations ce sont tilisé différemment que par Guice1 et éviter le problème indiqué.
Depuis Dagger a été écrit comme "A injecteur de dépendance rapide pour Android et Java ", les auteurs l'ont conçu à cet effet et pensent qu'il convient à une telle cible - allez-y, essayez-le.
1 Dagger utilise des annotations au moment de la compilation (enfin, principalement ) au lieu de se fier aux annotations et à la réflexion au moment de l'exécution; ce sont l'analyse et la réflexion des annotations au moment de l'exécution qui sont à l'origine du problème sur lequel le guide de la mémoire mettait en garde.
L'équipe Android a récemment mis à jour sa recommandation à suggérer aux développeurs d'utiliser Dagger 2 .
La recommandation précédente était basée sur le coût élevé de la réflexion. Étant donné que Dagger 2 n'utilise plus la réflexion - Dagger 1 l'a fait - ils le croient "peut être utilisé dans les applications Android sans coût d'exécution ni mémoire inutile) utilisation ".
(Avertissement: je suis le chef d'équipe de Dagger 2.)
Injection de dépendance des articles sur les meilleures pratiques ont été récemment ajoutés à Android. Dans ces articles, les développeurs sont encouragés à utiliser Dagger 2 comme bibliothèque DI principale pour le support de projet (4 -7 écrans) et de grandes applications (8+ écrans).
Dagger facilite l'utilisation de DI dans votre application en créant et en gérant pour vous le graphique des dépendances. Il fournit des dépendances entièrement statiques et au moment de la compilation répondant à de nombreux problèmes de développement et de performances des solutions basées sur la réflexion telles que Guice.
Le créateur de Dagger, @JakeWharton, a également écrit un cadre "d'injection" de vue plus simple appelé Butterknife
parce que tous les convertis de RoboGuice se plaignaient du manque de "voir l'injection" avec Dagger .
Vous l'utilisez comme ceci:
class ExampleActivity extends Activity { @InjectView(R.id.title) TextView title; @InjectView(R.id.subtitle) TextView subtitle; @InjectView(R.id.footer) TextView footer; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.simple_activity); ButterKnife.inject(this); // TODO Use "injected" views... } }