Android页面的事件(Event)和状态(State)学习

状态（State）

应用向用户显示的信息便是界面状态。比如一个新闻列表，列表的数据。界面是相对用户而言的，那么界面状态就是相对应用而言的。这就像同一枚硬币的两面，界面是界面状态的直观呈现。对界面状态所做的任何更改都会立即反映在界面中。

image.png

状态可以使用viewmodel作为容器去装载，使用单向数据流管理状态。

事件（Event）

界面与其 ViewModel 类之间的互动在很大程度上可以理解为事件输入及其随后的状态输出

image.png

状态向下流动、事件向上流动的这种模式称为单向数据流 (UDF)。这种模式对应用架构的影响如下：

ViewModel 会存储并公开界面要使用的状态。界面状态是经过 ViewModel 转换的应用数据。
界面会向 ViewModel 发送用户事件通知。
ViewModel 会处理用户操作并更新状态。
更新后的状态将反馈给界面以进行呈现。
系统会对导致状态更改的所有事件重复上述操作。

状态：
1 新状态会覆盖旧状态，如果短时间内发生多次状态更新，可以抛弃中间态只保留最新状态即可。这也是为什么 LiveData 连续 postValue 时会出现数据丢失。
2 最新状态是需要长久保持的，可以被时刻访问到，因此状态一般是“粘性的”，在新的订阅出现时为其发送最新状态。
3 状态是幂等的，唯一状态决定唯一UI，同样的状态无需响应多次。因此 StateFlow 在 setValue 时会对新旧数据进行比较，避免重复发送。

事件：
1 新事件不应该覆盖旧事件，订阅者按照发送顺序接收到所有事件，中间的事件不能遗漏。
2 事件只能被消费一次，消费后应该丢弃。因此事件一般不是“粘性”的，避免多次消费。
3 订阅者需要对发送的每个事件进行消费，即使是同一类事件发送多次。

image.png

UDF 有助于实现以下几点：

数据一致性。界面只有一个可信来源。
可测试性。状态来源是独立的，因此可独立于界面进行测试。
可维护性。状态的更改遵循明确定义的模式，即状态更改是用户事件及其数据拉取来源共同作用的结果。