compose 编程思想

前言

compose已经熟悉了几周了，跟着google sample进行理解时，对可组合函数参数列表如何声明，事件向上，数据向下传递理解还是有偏差。重新理解了下compose编程思想

1.早期基于View 微件数：

更新界面：多个需要同时更新View，会遗漏。复杂的View微件更新会更新前面已经移除过微件的状态

2.声明性范式：

tips：mvvm 为数据驱动界面ui更新。界面（Fragment，Activity）订阅ViewModel中的LiveData,数据发生变化时通知界面进行刷新。而lifecycle系列避免发生订阅内存泄露而引入的辅助管理类。

compose：一个声明性界面框架，【完全重新生成一个屏幕】

声明性范式转变

View微件数：在许多面向对象的命令式界面工具包中，您可以通过实例化微件树来初始化界面。您通常通过Inflate XML 布局文件来实现此目的。每个微件都维护自己的内部状态，并且提供 getter 和 setter 方法，允许应用逻辑与微件进行交互。

Compose 的声明性方法中：微件相对无状态，并且不提供 setter 或 getter 函数，微件不会以对象形式提供，您可以通过调用带有不同参数的同一可组合函数来更新界面

界面描述：自上而下

应用逻辑为顶级可组合函数提供数据,该函数(顶级可组合函数)通过调用其他可组合函数来使用这些数据描述界面，将适当的数据传递给这些可组合函数，并沿层次结构向下传递数据

事件响应：自下而上

例如：触发onclick事件，这些事件应通知应用逻辑，应用逻辑随后可以改变应用的状态。当状态发生变化时，系统会使用新数据再次调用可组合函数。这会导致重新绘制界面元素，此过程称为“重组”。

单选按钮点击，应用逻辑将单选按钮状态由check变为checked。状态变化导致compose函数重组

可组合函数内不建议缓存临时变量，包含匿名函数，除非特别简单。建议将状态和数据提取到可组合函数外面使可组合函数幂等

重组

1.切勿依赖于执行可组合函数所产生的附带效应，因为可能会跳过函数的重组

附带效应：对应用的其余部分可见的任何更改

写入共享对象的属性
更新 ViewModel 中的可观察项
更新共享偏好设置

可组合函数可能会像每一帧一样频繁地重新执行，如果您需要执行成本高昂的操作（例如从共享偏好设置读取数据），请在[后台协程]中执行，并将值结果作为参数传递给可组合函数。

本文档讨论了您在 Compose 中编程时需要注意的事项：

可组合函数可以按任何顺序执行：

可组合函数均应该是幂等的，不应该依赖声明函数顺序，臆想程序执行顺序是序列化

可组合函数可以并行执行。

如果您看一下可组合函数的代码，可能会认为这些代码按其出现的顺序运行。但其实未必是这样。如果某个可组合函数包含对其他可组合函数的调用，这些函数可以按任何顺序运行。Compose 可以选择识别出某些界面元素的优先级高于其他界面元素，因而首先绘制这些元素。

例如，假设您有如下代码，用于在标签页布局中绘制三个屏幕：

@Composable
fun ButtonRow() {MyFancyNavigation {StartScreen()MiddleScreen()EndScreen()}
}

对 StartScreen、MiddleScreen 和 EndScreen 的调用可以按任何顺序进行。这意味着，举例来说，您不能让 StartScreen() 设置某个全局变量（附带效应）并让 MiddleScreen() 利用这项更改。相反，其中每个函数都需要保持独立。

可组合函数可以并行运行

Compose 可以通过并行运行可组合函数来优化重组。这样一来，Compose 就可以利用多个核心，并以较低的优先级运行可组合函数（不在屏幕上）。

这种优化意味着，可组合函数可能会在后台线程池中执行。如果某个可组合函数对 ViewModel 调用一个函数，则 Compose 可能会同时从多个线程调用该函数。

为了确保应用正常运行，所有可组合函数都不应有附带效应，而应通过始终在界面线程上执行的 onClick 等回调触发附带效应。

调用某个可组合函数时，调用可能发生在与调用方不同的线程上。这意味着，应避免使用修改可组合 lambda 中的变量的代码，既因为此类代码并非线程安全代码，又因为它是可组合 lambda 不允许的附带效应。

以下示例展示了一个可组合项，它显示一个列表及其项数：

@Composable
fun ListComposable(myList: List<String>) {Row(horizontalArrangement = Arrangement.SpaceBetween) {Column {for (item in myList) {Text("Item: $item")}}Text("Count: ${myList.size}")}
}

此代码没有附带效应，它会将输入列表转换为界面。此代码非常适合显示小列表。不过，如果函数写入局部变量，则这并非线程安全或正确的代码：

@Composable
@Deprecated("Example with bug")
fun ListWithBug(myList: List<String>) {var items = 0Row(horizontalArrangement = Arrangement.SpaceBetween) {Column {for (item in myList) {Text("Item: $item")items++ // Avoid! Side-effect of the column recomposing.}}Text("Count: $items")}
}

在本例中，每次重组时，都会修改 items。这可以是动画的每一帧，或是在列表更新时。但不管怎样，界面都会显示错误的项数。因此，Compose 不支持这样的写入操作；通过禁止此类写入操作，我们允许框架更改线程以执行可组合 lambda。

重组会跳过尽可能多的可组合函数和 lambda。

重组是乐观的操作，可能会被取消:

只要 Compose 认为某个可组合项的参数可能已更改，就会开始重组。重组是乐观的操作，也就是说，Compose 预计会在参数再次更改之前完成重组。如果某个参数在重组完成之前发生更改，Compose 可能会取消重组，并使用新参数重新开始。

取消重组后，Compose 会从重组中舍弃界面树。如有任何附带效应依赖于显示的界面，则即使取消了组成操作，也会应用该附带效应。这可能会导致应用状态不一致。

确保所有可组合函数和 lambda 都幂等且没有附带效应，以处理乐观的重组。

可组合函数可能会像动画的每一帧一样非常频繁地运行

最佳做法都是使可组合函数保持快速、幂等且没有附带效应。

compose编程思想 https://developer.android.com/jetpack/compose/mental-model