UI状态

• 职责：负责UI自身的显示信息

• UI数据状态：需要显示到应用上的具体数据，如新闻列表及对应的新闻信息

• UI元素状态：如UI元素自身的可见性、大小、颜色等，属于UI元素自身属性

注：UI层的状态定义是不可变的，即想要修改只能通过重新创建，这样做的好处是，可以确保数据来源唯一，避免多个地方修改同样的引用和数据。

UI驱动

应用架构中的有个核心原则：数据驱动UI

• 业务逻辑：即具体驱动UI变化的业务逻辑，属于产品需求的实现，如当用户点击按钮收藏一篇文章时，将收藏状态保存到文件或数据库的逻辑就属于业务逻辑。

• UI自身逻辑：即UI自身逻辑驱动的UI变化，如在用户点击按钮时导航到不同屏幕

UI逻辑通常由UI本身处理

UI状态持有者

• 职责：存储和暴露状态供UI读取

• 优点：
• 简化UI：UI只需绑定其状态，无需关心复杂的逻辑。
• 可维护性：状态持有者中定义的逻辑可以独立迭代而无需修改UI。
• 可测试性：UI及其状态生产逻辑可以独立测试。
• 可读性：代码读者可以清晰区分UI展示代码和UI状态生产代码。

• 分类：根据UI逻辑和其与UI生命周期的关系
• 业务逻辑状态持有者（ViewModel）
• UI逻辑状态持有者（Plain Class）

业务逻辑状态持有者

• 推荐实现：ViewModel

• 职责：负责处理用户事件，并将data层或domain层的数据转换为屏幕界面状态。

• 建议：
• 避免传递ViewModel实例
• 避免多个地方修改状态，避免难以调试
• 不应持有任何与生命周期相关的引用

UI逻辑状态持有者

• 特点：
• 管理UI状态和UI元素状态
• 不跨活动重建保留状态：UI逻辑状态持有者通常依赖于UI自身的数据源，并且其生命周期与UI相同。例如，在Jetpack Compose中，通过remember函数创建的UI元素状态通常委托给rememberSaveable以在活动重建时保留状态
• 可在多个UI中复用：同一个UI逻辑状态持有者的不同实例可以在应用的不同部分中复用

• 建议：当UI逻辑变得足够复杂，需要从UI代码中分离出来以提高可读性时，就可以使用普通类作为状态持有者