命令式为什么不好呢:
- 这样手动地更新view会增加犯错的可能性. 如果某一数据在多个地方被渲染, 那么很可能就忘了更新其中的某个view.
- 很容易创建非法状态, 比如两个更新以不期望的方式冲突了. (比如: 一个要更新值, 另一个要移除节点.)
- 维护的复杂度随着需要更新的view个数而增加.
声明式
所以, 在过去的几年里, 业界一直在探索并且开始转向一种声明式的UI模型. 目的就是简化构建和更新UI.
Jetpack Compose是一个声明式的UI framework. 该技术的原理是从头开始重新生成整个屏幕, 然后仅应用必要的更改. 这种方法避免了手动更新stateful view的复杂度.
在Compose的声明式解决方案里, widgets相对来说是stateless的, 不暴露getter/setter. 实际上, widgets根本不是以对象的形式来暴露的. 当更新UI的时候, 实际上是传不同的参数调用了composable方法. 当数据改变时, composable负责把当前的应用状态转化为UI.
2.这个技术的优势和劣势分别是什么, 或者说, 这个技术的trade-off是什么.
Compose的优势:
- 目前Google投入了大量的资源(学习资源, 社区挑战赛, IDE和编译器支持, 推出desktop版本等)来推广Compose, 我们有理由相信Google官方会继续发力, Compose会成为Android未来的UI标准开发形式.
- Compose的声明式写法和Flutter, SwiftUI, React契合, 在支持多个平台的团队里, 有利于架构思想的统一.
- 声明式UI, 写起来更快, 不容易出错.
- 因为所有的代码都是Kotlin写的(真100%kotlin), 利用了Kotlin的强类型安全, 编译器会提示很多错误.
- 修复和更新了一些旧的API: (Buggy Android Views: P