Optimizing Dagger on Android: Developer Workflow and Runtime Performance
summary
Generated Dagger code causes heavy class loading so component initialization measures about 200 ms first init versus 2 ms subsequent inits; the concrete fixes shown are codegen that inlines factories, using Guava’s Android-optimized collections, and avoiding unnecessary Provider/Lazy and scopes. Practical changes demonstrated: inject instances instead of providers when get() is called once, use bindsInstance to pass singletons without double-check wrappers, prefer component dependencies over subcomponents to compile less, and enable ErrorProne extensions to flag wasteful lazy/provider usage.
AI-written summary · about
chapters (11)
- 0:00Introduction to Dagger optimization
- 1:35Key Dagger concepts explained
- 4:22Dependency request lifecycle
- 8:37Provider performance impact
- 11:09Next Dagger version improvements
- 15:50Reducing unnecessary providers
- 21:33Reconsidering scoping strategies
- 28:06Dagger Android framework
- 32:22Faster builds with Dagger
- 36:43Component dependencies vs subcomponents
- 37:03Summary and Q&A
related talks
29mForging the Dagger for the modern Android world
30mPowering up Dagger for Less Code and Cleaner Architecture
15mDagger Party Tricks
38mDagger 2, 2 Years Later
22mDependency Injection in Android using Dagger 2
25mDagger 2 Android : Defeat the Dahaka
45mDagger 2 - Back to Basics
41mA (K)night with Dagger - Slicing problems of newbies