为什么要推出Compose？解决的什么问题？切换的必要性？
- 声明式方式写UI
- 可以跟kotlin代码混在一起，数据实现自动绑定。
- 比如Text引用文本值是引用一个变量的，变量值变化了会自动更新，不需要重新获取View来修改View的值；
- 不需要手动获取View，再调用View的设置方法来更新了。
- 与Data Binding的区别：
- DataBinding只能绑定控件值
- 声明式UI还可以做逻辑控制，比如决定某些View是否展示，通过DataBinding实现比较复杂，而且DataBinding的逻辑控制写在xml中不利于调试和测试
- 可以跟kotlin代码混在一起，数据实现自动绑定。
- 去掉了xml，并且保持了简单的写法，比原来纯粹的代码写布局还要简单。这样布局和逻辑控制都是用Kotlin写，省了很多事。
那么基于这两点好处：声明式 UI、抛弃 xml 变成单一语言的写法，Compose 很明显是要比传统的 UI 写法要更好的。
这个所谓的好，解释开的话就是：写界面更简单更快速，并且我们能写出更复杂的界面。
kotlin-android-extensions插件解决了什么问题？
- 直接通过布局的id就可以获得对应的控件对象。
- 提供了 @Parcelize 注解帮助开发者快速实现 Parcelable。
这个插件优点就是用起来特别舒畅，直接用控件id就可以搞定了。
kotlin-android-extensions缺点?
- 不能提供可空信息，不同layout文件，id不一致，不能在编译时发现（但会提供警告），运行时容易崩溃。
- 仅支持kotlin。
- 污染全局命名空间。
ViewBinding
系统会为该模块中的每个 XML 布局文件生成一个绑定类。绑定类的实例包含对在相应布局中具有 ID 的所有视图的直接引用。
在大多数情况下，视图绑定会替代 findViewById。
与 findViewById 相比
- Null 安全：由于视图绑定会创建对视图的直接引用，因此不存在因视图 ID 无效而引发 Null 指针异常的风险。此外，如果视图仅出现在布局的某些配置中，则绑定类中包含其引用的字段会使用 @Nullable 标记。
- 类型安全：每个绑定类中的字段均具有与它们在 XML 文件中引用的视图相匹配的类型。这意味着不存在发生类转换异常的风险。
这些差异意味着布局和代码之间的不兼容将会导致构建在编译时（而非运行时）失败。
与kotlin-android-extensions相比
- Null 安全
- 支持Java和Kotlin
与DataBinding的对比
ViewBinding和DataBinding均会生成可用于直接引用视图的绑定类。但是，视图绑定旨在处理更简单的用例，与DataBinding相比，具有以下优势：
- 更快的编译速度：视图绑定不需要处理注释，因此编译时间更短。
- 易于使用：视图绑定不需要特别标记的 XML 布局文件，因此在应用中采用速度更快。在模块中启用视图绑定后，它会自动应用于该模块的所有布局。
反过来，与DataBinding相比，ViewBinding也具有以下限制：
- 视图绑定不支持布局变量或布局表达式，因此不能用于直接在 XML 布局文件中声明动态界面内容。
- 视图绑定不支持双向数据绑定。
考虑到这些因素，在某些情况下，最好在项目中同时使用ViewBinding和DataBinding。您可以在需要高级功能的布局中使用DataBinding，而在不需要高级功能的布局中使用ViewBinding。
ViewBinding缺点
Fragment生命周期比其视图生命周期长，需要在onDestoryView中手动清除ViewBinding引用，防止内存泄漏，这是冗余代码。这可以通过属性委托+反射+lifecycle回调来解决