Does "Avoid dependency injection frameworks" in the Android Memory Guide apply to Dagger as well?

Question

So I have come across this best practices on Android articles on memory performance.

http://developer.android.com/training/articles/memory.html

They said

Avoid dependency injection frameworks

Using a dependency injection framework such as Guice or RoboGuice may be attractive because they can simplify the code you write and provide an adaptive environment that's useful for testing and other configuration changes. However, these frameworks tend to perform a lot of process initialization by scanning your code for annotations, which can require significant amounts of your code to be mapped into RAM even though you don't need it. These mapped pages are allocated into clean memory so Android can drop them, but that won't happen until the pages have been left in memory for a long period of time.

But what about Dagger which they claim to be fast. Not sure which one should I go for?

Decanal

Why this question have -6 votes and is marked as primarily opinion-based?? The author is simple asking if the Dagger framework fits in the context describe in the text provide by the android developer guide, which is a legible question (not opinion-based) – Ricercare

Answer 1

This recommendation does not apply equally to all dependency injection frameworks.

..frameworks [that work like Guice] tend to perform a lot of process initialization by scanning your code for annotations, which can require significant amounts of your code to be mapped into RAM even though you don't need it..

Thus, if using a DI/IoC framework that doesn't scan for said [run-time] annotations, implying the [excessive] use of reflection, then this reason doesn't apply. While Dagger does use annotations these are used differently than by Guice¹ and avoid the problem stated.

Since Dagger was written as "A fast dependency injector for Android and Java", the authors have designed it for this purpose and believe that it is suitable for such a target - go ahead, give it a try.

---

¹ Dagger uses compile-time annotations (well, mostly) instead of relying on run-time annotations and reflection; it is the run-time annotation scanning and reflection that causes the issue the memory guide was warning about.

Warrior

I've created an issue for the android docs. please vote for this issue. – Selfstarter

Toothpick is also a good alternative to Dagger, with the same performances and memory foot print: github.com/stephanenicolas/toothpick – Peshitta

Answer 2

The Android team has recently updated their recommendation to suggest developers use Dagger 2.

The previous recommendation was based on the high cost of reflection. Since Dagger 2 no longer uses reflection - Dagger 1 did - they believe it "can be used in Android apps without needless runtime cost or memory usage".

(Disclaimer: I'm the Dagger 2 team manager.)

Lamoreaux

Answer 3

The creator of Dagger, @JakeWharton, also wrote a simpler view "injection" framework called Butterknife

because all the RoboGuice converts were complaining about lack of "view injection" with Dagger.

You use it like this:

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...
  }
}

Contravention

Answer 4

Dependency injection best practices articles were recently added to Android developer official website. In these articles developers are encouraged to use Dagger 2 as a primary DI library for project medium (4-7 screens) and large (8+ screens) apps.

Dagger facilitates using DI in your app by creating and managing the graph of dependencies for you. It provides fully static and compile-time dependencies addressing many of the development and performance issues of reflection-based solutions such as Guice.

Solidify