社区说｜Jetpack Compose 架构与原理
1.Composable 快速介绍
一段代码和运行结果示例
加上@Composable 注解后，Koltin 函数会变成一个可视化的 UI，函数体的执行顺序不变。可以看出：
Composable的本质是函数
复杂一些的例子👇，与 xml 的区别在于是代码级别的所见即所得。
2.Compose 编译器插件
Compose 架构图如下：
compose 编译器插件是架构最底层的部分，属于功能架构的基本能力，compose的很多核心能力都是基于编译器插件实现的。
编译器插件如何实现 compose 的能力呢？，一个案例代码：
在编译流程中，编译器插件对代码进行处理：
经过 compose 编译器插件处理后，函数参数会多出一个 Composer 参数：
类似 kotlin 中的挂起函数，suspend 关键字修饰的函数经过编译之后，会带有一个 continuation 参数。
为什么 compose 使用注解而不是关键字实现呢？因为 compose 是工程应用级别的，而非语言本身的特性。
compose 函数经过编译器转换之后的完整代码如下：
在初次执行时，会创建RestartGroup、Scope，调用 Text（）、结束RestartGroup、返回Scope、参数变化时触发重组。
3.Recompose 与性能优化
一个复杂的compose代码示例：
先定义一个state，延迟一秒更新 state 的值，greeting 函数使用到了state的值，运行日志如下：
可以看到，state的值变更导致了整个页面的重组。
优化
改变 state 参数的传值方式，greeting 不接收一个具体的值，而是接收函数参数：
改动后的执行流程日志如下：
可以看到，跟之前界面初始流程不变，但是state 值更新后，只有gretting 函数发生重组，main screen 没有触发重组。 -- 节省了资源消耗，这也是官方推荐的使用方式。
优化背后的原理：Laziness
实现laziness 比较简单，用 lambda 就可以实现：
重组作用域
和前文中编译后的scope概念是一致的
每个函数都有自己的scope 。state的读取发生在 main scope 中，当 state 值改变之后，就会触发 main screen 的 scope 的重新执行，从而触发 greeting 的重新执行
而代码优化之后，state的读取发生在 greeting 的 scope 中，因此state 值变更指挥触发 greeting 的scope的重新执行：
这就是通过 laziness 来最小化 读写 scope 的优化案例，也是官方推荐的优化方案。
Compose 生命周期
从 Composition 到 Layout 再到 Draw。Composition 就是我们的 compose 函数执行的过程，recompose 就是 recomposition
性能优化建议
- 1、Defer reads as long as possible 尽可能延迟读数据的时机（上文提到的 laziness 优化示例）
- 2、Use derivedStateOf to limit recomposition。使用 XtateOf 的子类限制重组
- 3、Avoid backwards writes。 避免在重组时写数据（否则可能会导致类似递归的恶性循环重组）
一个用 laziness 优化的官方案例。优化前：
优化后：
4.Compose 的架构设计
5.基于 Compose 的基础设施，我们还能做什么?
基于 runtime 和 snapshot ，可以自己实现 ui架构：
运行效果
使用 Moasic鞋 ui 界面：
Applier 是对ui进行操作的抽象。在Android 平台实现是LayoutNode，在Moasic 项目实现是MoasicNode。
UiApplier 的反省是 LayoutNode，是Android 的实现。
MoasicNodeApplier 是 Moasic 项目的实现：
底层抽象做的足够好，非常通用，上层才能随意定制实现。
6. Compose 与 Android
Compose 与 Android 有一个交互的节点，但最终还是会走 View的生命周期函数：
这个方法就是把compose的内存结构最终变成 ui结构的关键函数
7、扩展资料
- 极客时间《Kotlin编程第一课》
- 《两小时入门 Jetpack Compose（上）》
- 《两小时入门 Jetpack Compose（下）》
- 《Compose 原理与性能优化》
