Dialog类是否应该使用依赖注入？对应代码写法是否符合开发规范？

Dialog 是否适合使用依赖注入？ #

分场景判断没有绝对标准，但是你给出的示例代码既不符合Android组件设计规范，也没有发挥依赖注入的核心价值。
依赖注入的核心作用是解耦依赖、降低单元测试成本、统一管控实例生命周期。Dialog作为和页面生命周期强绑定的组件，本身是可以通过DI注入的，但你的写法有明显缺陷：
你直接在Provider里返回SampleDialog()的硬编码实例，首先违反了Android官方对DialogFragment的创建要求：所有DialogFragment必须通过静态工厂方法创建、用setArguments传递参数，避免配置变更（如屏幕旋转）后实例重建参数丢失。其次你直接绑定具体实现类，没有面向抽象，后续要替换Dialog实现时还要修改Module代码，完全浪费了DI的解耦能力。另外加了@FragmentScoped注解意味着整个Fragment生命周期内只会生成一个Dialog实例，多次弹出销毁Dialog时很容易出现状态残留、重复添加到FragmentManager的崩溃问题。

正确的注入方式参考：

• 无参数的通用Dialog：注入Provider<SampleDialog>，每次调用get()生成新实例使用，不要固定绑定到FragmentScope
• 需要传参的Dialog：注入Dialog工厂类，由工厂统一处理参数传入和实例创建，比直接注入实例安全性更高

Intent、Navigation、ViewBinding 同类组件是否适用该逻辑？ #

不同组件特性不同，不能一概而论：

• Intent：不建议直接注入实例。Intent作为消息传递载体绝大多数场景需要动态设置Action、Extra、目标组件，注入固定实例实用价值极低，还容易因为复用实例导致参数错乱。如果是固定用途的通用Intent（比如打开系统设置、拨打电话的Intent），可以注入Provider<Intent>，每次使用生成新实例即可。
• Navigation组件：NavController本身支持注入，Hilt也提供了官方扩展可以直接绑定到Activity/Fragment Scope，不需要自己创建实例。其他动态生成的NavDestination等组件不建议注入。
• ViewBinding：绝对不建议直接注入实例。ViewBinding实例和View生命周期强绑定，必须在onCreateView之后创建、onDestroyView时手动置空，注入到FragmentScope会大概率出现内存泄漏，而且配置变更后布局重建，注入的旧Binding实例会导致布局错乱。如果要简化Binding创建，用Kotlin扩展或者视图委托的方案适配性远好于DI注入。

你给出的代码问题总结 #

@Module
@InstallIn(FragmentComponent::class)
object FragmentModule {
    @FragmentScoped
    @Provides
    fun provideDialog()=
     SampleDialog()
}

不符合设计原则的点：

• 硬编码返回具体实现类，没有面向抽象，DI的解耦优势完全没有体现
• 用@FragmentScoped绑定Dialog实例，容易出现实例状态残留、重复添加崩溃的问题
• 没有遵循DialogFragment官方创建规范，后续扩展参数时容易出现配置变更参数丢失的问题

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