Android DI Hilt

When To Use

适用场景

Use this skill when the request is about: android hilt setup, inject viewmodel repository hilt, scope dependency in android.
Primary outcome: Wire Android dependency injection with Hilt, scopes, testing overrides, and module ownership boundaries.
Reach for this skill when the hard part is component ownership, bindings, scopes, entry points, or test replacement. If the request is only about networking APIs or reducer design, use the neighboring skill instead.
Handoff skills when the scope expands:
```
android-testing-unit
```
```
android-networking-retrofit-okhttp
```

当请求涉及以下内容时使用本技能：android hilt 配置、hilt注入viewmodel和repository、android中的作用域依赖。
核心成果：使用Hilt实现Android依赖注入，包含作用域、测试重写和模块所有权边界相关能力。
当难点在于组件所有权、绑定、作用域、入口点或测试替换时使用本技能。如果请求仅涉及网络API或reducer设计，请改用其他相关技能。
当范围扩大时可移交至以下技能：
```
android-testing-unit
```
```
android-networking-retrofit-okhttp
```

Workflow

工作流程

Identify the injection boundary first: app-wide singleton, activity-retained, ViewModel, worker, service, or entry point from unsupported framework code.
Decide what should be bound: constructor injection,
```
@Binds
```
,
```
@Provides
```
, qualifiers, multibindings, or assisted injection.
Match lifetime to scope explicitly so dependencies do not outlive their owner or rebuild too often.
Verify replacement strategy for tests with Hilt test modules, uninstall modules, or fakes at the right component boundary.
Hand off API-specific or architectural questions only after the DI graph ownership is correct.

首先确定注入边界：应用全局单例、activity保留实例、ViewModel、worker、service，或是来自不支持的框架代码的入口点。
确定需要绑定的内容：构造函数注入、
```
@Binds
```
、
```
@Provides
```
、限定符、多重绑定或是辅助注入。
显式将生命周期与作用域匹配，避免依赖的生命周期长于其所有者，或是频繁重建。
验证测试的替换策略，在正确的组件边界使用Hilt测试模块、卸载模块或是伪造对象。
仅在DI图所有权确认正确后，再移交特定API或架构相关问题。

Guardrails

使用规范

Prefer constructor injection for app code you own.
Use qualifiers and scope annotations deliberately; ambiguous bindings are a graph smell, not a convenience.
Keep Hilt modules close to the ownership boundary they configure.
Treat test replacement as part of the design, not an afterthought.

自有应用代码优先使用构造函数注入。
谨慎使用限定符和作用域注解；歧义绑定是DI图的坏味道，而非便利特性。
保持Hilt模块与其配置的所有权边界紧密关联。
将测试替换视为设计的一部分，而非事后补充。

Anti-Patterns

反模式

Making everything
```
@Singleton
```
to silence scope questions.
Hiding business construction logic inside giant
```
@Provides
```
methods when constructor injection would suffice.
Using Hilt modules as a dumping ground for unrelated bindings across modules.
Confusing DI graph ownership with app architecture ownership.

为了规避作用域问题将所有对象都声明为
```
@Singleton
```
。
明明可以使用构造函数注入，却将业务构造逻辑隐藏在庞大的
```
@Provides
```
方法中。
将Hilt模块当作垃圾场，存放跨模块的不相关绑定。
混淆DI图所有权与应用架构所有权。

Review Focus

评审重点

Component and scope alignment.
Binding style and qualifier clarity.
Unsupported-entry-point bridges and test replacement strategy.
Module ownership boundaries across features and core code.

组件与作用域的对齐情况。
绑定风格与限定符的清晰度。
不支持的入口点桥接方案和测试替换策略。
跨功能和核心代码的模块所有权边界。

Examples

示例

Happy path

正常场景

Scenario: Inject OrbitTasks repositories and dispatchers with clear Hilt scopes.

Command:

cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

场景：使用清晰的Hilt作用域注入OrbitTasks仓库和调度器。

命令：

cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

Edge case

边缘场景

Scenario: Swap fake dependencies in the XML fixture for deterministic tests.

Command:

cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest

场景：在XML测试夹具中替换伪造依赖以实现确定性测试。

命令：

cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest

Failure recovery

故障恢复

Scenario: Catch DI-specific prompts before they drift into architecture-clean or networking.

Command:

python3 scripts/eval_triggers.py --skill android-di-hilt

场景：在DI相关提示偏离到整洁架构或网络相关内容之前及时拦截。

命令：

python3 scripts/eval_triggers.py --skill android-di-hilt

android-di-hilt

Original

Translation

Android DI Hilt

Android DI Hilt

When To Use

适用场景

Workflow

工作流程

Guardrails

使用规范

Anti-Patterns

反模式

Review Focus

评审重点

Examples

示例

Happy path

正常场景

Edge case

边缘场景

Failure recovery

故障恢复

Done Checklist

完成检查清单

Official References

官方参考