Kotlin Clean Architecture与MVVM基础架构问题咨询

问题1：应该使用AndroidViewModel还是通过Hilt注入@ApplicationContext？ #

优先使用AndroidViewModel。它是Android官方为ViewModel层提供的封装，自带Application上下文，无需额外注入，且生命周期与ViewModel绑定，能有效避免内存泄漏。ViewModel属于表现层，本就可以依赖Android框架的封装，完全符合Clean Architecture的依赖规则。如果用Hilt注入@ApplicationContext虽然可行，但不如AndroidViewModel直接简洁。

问题2：我为Repository采用接口/实现模式，是否需要为ViewModel、DataSource和UseCase也使用该模式？会不会过度设计？我习惯在领域层为Repository定义接口，在数据层实现，但不为数据层的DataSource、领域层的UseCase和表现层的ViewModel定义接口，这样做是否正确？ #

这种做法是合理且符合常规实践的：

• Repository的接口/实现是必要的：领域层依赖抽象接口，数据层提供具体实现，遵循依赖倒置原则，同时方便单元测试时用Mock实现替换真实数据源。
• DataSource：如果数据源类型固定（比如仅用Room和Retrofit），不用接口完全没问题；若未来有替换数据源的需求（比如从Room切换到Realm），添加接口会更灵活，但多数中小项目属于过度设计。
• UseCase：除非需要为同一个业务逻辑提供多种实现（比如不同环境下的逻辑切换），否则无需接口。UseCase本身就是领域层的具体逻辑封装，直接写实现类足够，加接口只会增加冗余。
• ViewModel：完全没必要抽象接口。ViewModel是与UI紧密绑定的表现层组件，抽象它没有实际意义，反而会增加维护成本。

问题3：若同时存在本地数据源和远程数据源，当第一个数据源不可用时，应该由Repository还是UseCase来处理切换到第二个数据源的逻辑？ #

交给Repository处理是正确的选择。Repository的核心职责就是封装多数据源的切换、合并逻辑，对外提供统一的数据访问入口。UseCase只负责处理业务逻辑，不应该关心数据的来源细节。比如Repository可以实现“先查本地缓存，无数据或过期则请求远程，失败则 fallback 到本地备份”的逻辑，UseCase只需调用Repository的方法获取数据即可。

问题4：若要实时显示电池电量，轮询的职责应归属Repository（应用后台运行时可能对电池不友好）、UseCase还是ViewModel？ #

轮询（更推荐用广播接收器替代轮询，更高效）的逻辑放在Repository，但要配合ViewModel做生命周期控制：

• Repository负责封装获取电池电量的逻辑，包括注册广播接收器、处理权限、异常捕获，同时提供开启/停止监听的方法。
• ViewModel根据UI生命周期触发监听的启停，比如在onStart时开启，onStop时停止，避免后台不必要的耗电。
• UseCase只负责处理电量数据的业务逻辑（比如格式转换、阈值过滤），不参与监听的控制逻辑。

问题5：针对电池电量，应该使用Flow（冷流，由收集者触发）还是StateFlow（热流，共享型）？ #

推荐使用StateFlow：

• 电池电量是持续变化的状态，需要多个UI组件共享最新值，StateFlow天生支持多订阅，且会保留最新状态，新订阅者能立刻获取当前值。
• Flow作为冷流，每次订阅都会重新触发收集逻辑（比如重新注册广播），会造成资源浪费。StateFlow作为热流，仅需一个数据源，所有订阅者共享数据，更高效。

问题6：我需要展示大量系统信息，主要使用Android原生包，是否需要将这些操作代理到DataSource或Repository实现中？还是可以直接在UseCase中调用，因为这些都是“基础”操作？ #

必须封装到Repository或DataSource中。即使是系统API调用，也需要将Android框架相关代码隔离到数据层，原因如下：

• 领域层（UseCase）完全脱离Android框架依赖，方便进行单元测试（无需依赖Android测试环境）。
• 统一管理系统API的调用逻辑，比如权限处理、异常捕获，避免重复代码。
• 未来若系统API发生变化，仅需修改Repository的实现，无需改动领域层和表现层。

问题7：若要实时显示已安装应用列表，应该在Repository中使用逐个发射应用包的冷流？还是发射List<>的冷流？或是Repository中的热流？还是Repository仅提供获取应用列表的方法，由UseCase/ViewModel中的广播接收器触发轮询？ #

推荐Repository提供返回List<AppInfo>的StateFlow，结合广播接收器监听应用安装/卸载事件：

• 首次获取时返回完整应用列表，当有应用安装/卸载时，重新获取完整列表并发射新的StateFlow值。
• 不要逐个发射应用包，UI通常需要完整列表来展示，逐个发射会增加UI更新的复杂度。
• 使用StateFlow是因为多个UI组件可能需要订阅，且需要保留最新的应用列表状态。
• 广播接收器封装在Repository内部，对外仅暴露StateFlow，UseCase和ViewModel无需关心底层的监听实现。

问题8：假设我调用一个耗时数秒的Repository方法，该方法应返回什么类型（普通方法、Flow、StateFlow）？如何处理UI需要展示的三种常见状态：加载中、错误、成功（我使用密封类）？是将Flow转换为Flow<State/Result>，还是让T包装在State/Result中？ #

• 返回类型：使用**Flow<Result<T>>**，其中Result是你定义的密封类（包含Loading、Success、Error状态）。
• 处理逻辑：
  1. Repository方法内部先发射Loading状态，再执行耗时操作，成功则发射Success(data)，失败则发射Error(throwable)。
  2. 不要用普通方法，因为耗时操作不能在主线程执行，Flow天然支持异步处理。
  3. 不用StateFlow，因为这是一次性的请求操作，并非持续变化的状态，StateFlow更适合持久状态的管理，而Flow更适配单次异步任务的状态流转。
  4. 直接让Flow发射Result密封类，ViewModel收集时可直接处理三种状态，无需额外转换。

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