¿Se aplica también a Dagger "Evitar frameworks de inyección de dependencias" en la Guía de memoria de Android?
performance dependency-injection (3)
Así que me he encontrado con estas mejores prácticas en artículos de Android sobre el rendimiento de la memoria.
http://developer.android.com/training/articles/memory.html
Ellos dijeron
Evite los marcos de inyección de dependencia
Usar un marco de inyección de dependencias como Guice o RoboGuice puede ser atractivo porque pueden simplificar el código que se escribe y proporcionar un entorno adaptable que es útil para las pruebas y otros cambios de configuración. Sin embargo, estos marcos tienden a realizar una gran cantidad de inicialización del proceso escaneando su código para anotaciones, lo que puede requerir que cantidades significativas de su código se mapeen en la memoria RAM aunque no lo necesite. Estas páginas asignadas se asignan a la memoria limpia para que Android pueda soltarlas, pero eso no sucederá hasta que las páginas se hayan dejado en la memoria durante un largo período de tiempo.
Pero qué pasa con Dagger que dicen ser rápido. ¿No estoy seguro de a cuál debo ir?
El creador de Dagger, @JakeWharton, también escribió un marco de "inyección" de vista más simple llamado Butterknife
porque todos los conversos de RoboGuice se quejaban de la falta de "inyección de vista" con Dagger .
Lo usas así:
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... } }
El equipo de Android ha actualizado recientemente su recomendación para sugerir a los desarrolladores que utilicen Dagger 2 .
La recomendación anterior se basó en el alto costo de la reflexión. Dado que Dagger 2 ya no usa el reflejo, Dagger 1 lo hizo, ellos creen que "se puede usar en aplicaciones de Android sin costos innecesarios de tiempo de ejecución o uso de memoria" .
(Descargo de responsabilidad: soy el administrador del equipo Dagger 2)
Esta recomendación no se aplica por igual a todos los marcos de inyección de dependencia.
..frameworks [que funcionan como Guice] tienden a realizar una gran cantidad de inicialización del proceso escaneando su código para las anotaciones , lo que puede requerir que cantidades significativas de su código se mapeen en la memoria RAM , aunque no lo necesite.
Por lo tanto, si se utiliza un marco DI / IoC que no analiza esas [anotaciones en tiempo de ejecución], lo que implica el uso [excesivo] de la reflexión, esta razón no se aplica. Si bien Dagger sí utiliza anotaciones, éstas se usan de forma diferente a Guice 1 y evitan el problema planteado.
Dado que Dagger fue escrito como "Un inyector de dependencia rápido para Android y Java", los autores lo han diseñado para este propósito y creen que es adecuado para ese objetivo: adelante, pruébalo.
1 Dagger usa anotaciones en tiempo de compilación (bueno, mostly ) en lugar de confiar en las anotaciones y reflexiones en tiempo de ejecución; es el análisis y la reflexión de la anotación en tiempo de ejecución lo que causa el problema sobre el que advertía la guía de memoria.