为何Android开发者在Application类中创建全量DI组件而非按需在Activity中创建？

Great question—this is something a lot of us scratch our heads over when first diving into dependency injection on Android. Let’s break down the reasoning behind this approach, and also address your valid point about Activity-specific dependencies like presenters.

Key Reasons for a Global Application-Level Component #

• Singleton Efficiency for Shared Dependencies
  Many core dependencies (like OkHttpClient, Retrofit instances, database helpers, or a user session manager) are used across multiple parts of the app. Creating them once in the Application component ensures they’re true singletons—no redundant instances eating up memory or wasting resources. If you created a separate component for each Activity, you’d end up reinitializing these heavy objects every time, which is inefficient.

• Component Hierarchy Reusability
  Most DI frameworks (like Dagger or Hilt) support component hierarchies. The Application component acts as a "root" parent, and Activity/Fragment components can be child components that inherit dependencies from the root. This means you don’t have to redefine shared dependencies in every Activity component—you just reference the root, keeping your code DRY.

• Lifecycle Alignment for Global State
  The Application class has the longest lifecycle in your app—it exists as long as the app is running. This makes it perfect for dependencies that need to maintain state across screens, like a global cache, analytics tracker, or authentication manager. If you tied these to an Activity’s lifecycle, they’d get destroyed when the Activity finishes, losing critical state.

• Simplification for Small-to-Medium Apps
  For many apps, the overhead of creating separate components for every Activity isn’t worth it. A single global component keeps setup simple, especially for teams new to DI. It’s a starting point that works well until the app grows large enough to need more granular scoping.

But What About Activity-Specific Dependencies Like Presenters? #

You’re absolutely correct that presenters (or view models tied to a single screen) shouldn’t be global. Best practice here is to use a component hierarchy instead of cramming everything into the Application component:

• The root ApplicationComponent handles only singleton, app-wide dependencies.
• Each Activity has its own child component (e.g., ProfileActivityComponent) that depends on the root component. This child component adds Activity-specific dependencies like presenters, which are scoped to the Activity’s lifecycle.

This way, you get the efficiency of global singletons and the proper scoping for screen-specific code.

When Would You Create a Component Directly in an Activity? #

There are rare cases where this makes sense:

• If you have a completely isolated feature that doesn’t share any dependencies with the rest of the app.
• If you need strict isolation for testing purposes, where a feature’s dependencies shouldn’t leak into other parts of the app.

But for most mainstream Android apps, the root Application component + child Activity components is the sweet spot.

内容的提问来源于stack exchange，提问作者Johann