2. 依赖注入的隐藏开销概述：什么是隐藏开销，为何关注性能影响

2.1 表面之下：什么是“隐藏开销”

说到依赖注入，很多人的第一反应是「方便」、「解耦」、「好测试」。没错，这些确实是它的核心优势。但你可能没想过，每一次 @Inject 或者 @Provides 背后，系统都帮你做了哪些「额外工作」？

我个人习惯把这种「额外工作」叫做隐藏开销。说白了，就是你代码跑起来了，但有些东西你看不到，却在悄悄消耗资源。

举个例子。你写了一个 @Inject LateInit var repository: UserRepository。Hilt 在背后会做什么？

1. 查找 UserRepository 的构造方法，判断有没有可用的 @Inject 构造函数。
2. 如果它有依赖，比如需要 ApiService，那就递归去解析 ApiService。
3. 检查作用域，是不是 @Singleton？如果是，得去看看容器里有没有现成的实例。
4. 如果没有，创建一个新的，放到容器里，再做代理的绑定。
5. 最后，把实例赋给你的 lateinit var。

这五步，每一步都涉及反射或者字节码生成的调用。等你业务逻辑的 userRepository.fetch() 开始执行时，前面这些步骤已经消耗了一些毫秒级的时间。这就是我讲的「隐藏开销」。

2.2 隐藏开销的三大类

我习惯把隐藏开销分成三类。为什么这么分？因为排查起来思路不一样。

开销类型	典型场景	量级（参考）
反射开销	构造函数查找、方法调用、字段注入	微秒至毫秒级
代理生成开销	作用域代理、懒加载代理、Provider	微秒级（但高频时累加明显）
对象生命周期管理开销	作用域组件创建/销毁、容器查找、实例缓存	毫秒级（尤其在组件重建时）

2.3 为什么要关注这个？性能影响的三个层次

你可能会想：「既然Hilt都做了优化，反射也限制了，那还担心什么？」嗯，这里要注意，性能问题往往不在「一次」，而在「叠加」和「时机」。

我总结了一下，性能影响可以从三个层面来看：

1. 冷启动时间：App第一次启动时，Hilt需要初始化所有的 @HiltAndroidApp 组件和 @Singleton 实例。如果依赖图很大，这个时间就容易被拖长。你想想看，用户打开应用，结果白屏多了一秒，是什么体验？
2. 页面跳转时的瞬时卡顿：当使用 @ActivityScoped 或 @FragmentScoped 注入时，每次创建新的Activity或Fragment，Hilt都要重新解析作用域内的依赖。如果这个作用域里有重量级对象，比如网络客户端、数据库连接，就会出现「跳转一瞬间卡住」的问题。
3. 内存抖动与GC压力：频繁的注入点会创建大量临时对象，比如代理类、反射中的 Method 对象。这些对象如果生命周期短，就会触发频繁的GC（垃圾回收），影响帧率和整体流畅度。我见过一个极端案例，每帧都做依赖注入，结果帧率直接掉到30fps以下。

2.4 隐藏开销与编译时 DI 的对比

其实Hilt的隐藏开销，很大程度上和它「运行时」的特性有关。这里我拿Koin和Dagger做对比，帮你理解为什么会有这些开销。

框架	解析时机	主要隐藏开销来源	性能影响
Dagger / Hilt	编译时生成 + 运行时执行	代理生成、作用域管理、反射调用	冷启动较低（编译时已优化），但作用域复杂时仍有开销
Koin	运行时完全解析	模块解析、作用域查找、实例创建	冷启动较高（全部运行时），但灵活
纯手动注入	无框架开销	无	最低，但开发和维护成本高

2.5 一张图看懂本章脉络

我把隐藏开销的来源、分类和影响链路画出来了。你可以根据这个图来定位问题。

2.6 小结：是时候认真对待隐藏开销了

其实很多人觉得依赖注入性能开销可以忽略，那是因为他们只测了简单的页面。但一旦到了大型应用，几十个甚至上百个依赖点交织在一起，隐藏开销就不可小觑了。