Android使用Dagger Hilt时Retrofit的注入位置问题

首先先澄清一个核心认知偏差：Hilt中将对象绑定到SingletonComponent，并不等价于传统硬编码实现的、可被任意代码随意修改的坏味道全局单例，它的实际语义是对象生命周期和应用进程保持一致，在该作用域内仅初始化一次，和你们团队"避免滥用单例"的原则并不天然冲突。

为什么公开示例普遍将Retrofit绑定到SingletonComponent #

这不是照搬模板的教条做法，是基于Retrofit本身的特性决定的：

• Retrofit实例初始化成本极高：创建过程需要完成大量注解解析、Converter/CallAdapter工厂注册、关联OkHttpClient的拦截器链装配，重复创建会带来不必要的CPU、内存开销，拖慢页面加载速度。
• Retrofit实例本身是无状态、线程安全的：完成baseUrl、序列化配置等初始化操作后，不存在可变的运行时状态，多线程并发访问不会出现数据错乱问题。
• 配套的OkHttpClient本身就需要进程级单例：OkHttpClient内部维护了连接池、线程池、DNS缓存等复用机制，多实例会导致连接无法复用，直接拉低网络请求效率，浪费流量与内存。

判断对象是否需要绑定为Application级全局实例的决策依据 #

不用死记规则，对照三个标准判断即可：

• 看初始化成本：如果对象初始化需要消耗大量资源（涉及IO、重计算、大内存占用），且重复创建没有任何业务收益，直接做进程级单例。典型例子除了Retrofit/OkHttp，还有Room数据库实例、加密持久化存储实例、全局图片加载器等。
• 看状态安全性：如果对象是无状态的，或者持有的状态是全局通用配置、不存在被业务逻辑随意篡改的可变状态，线程安全无副作用，就可以做全局绑定。反之如果对象持有页面/Activity/Fragment这类短生命周期上下文、持有单业务流程的临时状态，绝对不能做全局绑定，否则必然引发内存泄漏、状态错乱问题。
• 看复用范围：如果对象需要跨多个独立业务模块、跨页面、跨生命周期使用，且不同场景下不需要差异化配置，适合做全局绑定。如果对象仅在某个独立业务流程（比如登录流程、实名认证流程）内使用，出了流程范围就不再需要，完全可以绑定到对应业务范围的自定义Hilt组件中，没必要放到全局。

特殊场景的灵活处理 #

如果你们项目存在完全隔离的多套网络配置：比如不同业务模块对接完全不同的域名、使用完全独立的拦截器/超时配置/证书校验规则，不需要全局复用，完全可以将对应配置的Retrofit绑定到对应业务范围的组件中，不需要强行塞到SingletonComponent里。
但要注意不要走极端：不要为了"不用单例"刻意给每个页面、每个ViewModel单独创建Retrofit实例，这属于典型的反模式，除了劣化性能没有任何实际收益。

最后提一句："尽量避免单例"的原则本质是避免全局可变状态、避免对象生命周期失控带来的副作用，不是不分场景拒绝所有长生命周期对象。只要符合上面三个判断标准，放到SingletonComponent就是合理的做法，不用为了符合原则硬做不符合技术规律的设计。

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