Jetpack Compose是什么?
它是一个声明式的UI工具包(declarative UI toolkit for Android).
它的主要目的就是改变之前命令式地(imperatively)写UI的方法, 改成声明式(declarative)的.
Android之前的写法就叫命令式: view hierarchy是一个UI widgets构成的tree, 当app的状态改变时, UI需要更新. 通常的做法是通过findViewById()
等手段找到要更新的节点, 通过setText()
, addChild()
, setImageBitmap()
等方法更新控件的内部状态. 每个控件都有自己的内部状态, 并且暴露getter/setter, 允许程序逻辑和控件交互.
命令式为什么不好呢:
所以, 在过去的几年里, 业界一直在探索并且开始转向一种声明式的UI模型. 目的就是简化构建和更新UI.
Jetpack Compose是一个声明式的UI framework. 该技术的原理是从头开始重新生成整个屏幕, 然后仅应用必要的更改. 这种方法避免了手动更新stateful view的复杂度.
在Compose的声明式解决方案里, widgets相对来说是stateless的, 不暴露getter/setter.
实际上, widgets根本不是以对象的形式来暴露的.
当更新UI的时候, 实际上是传不同的参数调用了composable方法. 当数据改变时, composable负责把当前的应用状态转化为UI.
Compose的优势:
目前Google投入了大量的资源(学习资源, 社区挑战赛, IDE和编译器支持, 推出desktop版本等)来推广Compose, 我们有理由相信Google官方会继续发力, Compose会成为Android未来的UI标准开发形式.
Compose的声明式写法和Flutter, SwiftUI, React契合, 在支持多个平台的团队里, 有利于架构思想的统一.
声明式UI, 写起来更快, 不容易出错.
因为所有的代码都是Kotlin写的(真100%kotlin), 利用了Kotlin的强类型安全, 编译器会提示很多错误.
修复和更新了一些旧的API: (Buggy Android Views: Picker, Spinner, EditText, 有一些edge cases. 因为要更改旧的总是很难, 不如创建一个新的. )
基于组合的Composable, 比基于继承的View体系, 更加灵活, 易于复用. 比如可以通过组合来达到复用多个源, 不再受单继承限制.
以Button为例, 在传统的UI里, 它是单继承体系下的一个类: Button -> TextView -> View.
而在Compose的世界里, 它只是一个@Composable
的方法, 里面包含了其他composable, surface, row等.
举例: list->detail两个界面, 可以通过提取方法参数来达到两个界面的composable复用.
支持和View-based UI系统的互相调用. 这样有两个优点: 有利于已有项目app的混用和逐步迁移; 当Compose满足不了需求的时候可以用传统View作为第二选择.
和Jetpack系列的其他库都能完美结合. (ViewModel, Kotlin Flow, Coroutines, Paging, Hilt, Navigation…)
劣势:
Jetpack Compose的使用场景是取代原来的Android View写法(xml, 在代码里实例化View对象再添加到View hierarchy里等),
Jetpack Compose用全新的方式来写UI, 即将成为Google Android标准写法.
注意这里的改变除了UI写法的改变, 还是一种状态管理思想的转变.
声明式, 单向数据流, 单个数据源.
Android内部的模式近年来一直追求的无外乎就是数据和View的分离, View的无知与自动更新, 清晰的逻辑管理和分离, 可测试性等等.
除了与View强相关的这一层(ViewModel)外, 其他的业务逻辑, 数据交互等被影响不大, 所以即便app决定逐渐迁移到Compose, 也只用管View绘制以及和View相邻的这一层.
Jetpack compose的总体特点:
f(state)=UI
.Compose的使用方法:
定义一系列的composable functions: 接收数据, 发射UI元素.
@Composable
fun Greeting(names: String) {
Text("Hello $name")
}
Composable方法的特点:
@Composable
注解.还有一个小区别就是不同于普通的kotlin方法命名规范, composable方法名的首字母要大写, 因为它此时代表的是一种widget.
Compose framework会很机智地选出有变化, 需要重新绘制的部分.
在Compose中, 如果调用composable function, 传入了新数据, 会使得方法被recomposed: 这个方法发射的widgets会根据需要进行重新绘制.
因为重新绘制整个UI tree会花销比较大, 所以实际上composable function只有input改变的才会被重新绘制, 对于那些参数没有变化的方法和lambda, 其实是skip掉的, 这样才能提高recompose的效率.
所以, 永远不要依赖于执行composable function的side-effects, 因为recomposition有可能会被skip掉.
side-effects包括:
由于composable functions有可能会被逐帧执行(比如动画期间), 所以它应该足够的快, 如果需要耗时的操作, 可以考虑后台的coroutine.
Compose的几个特点:
关于Compose的底层原理, 目前还没找到一个官方的文档或者架构图.
因为可能大家都还在学习怎么使用, 这项技术的底层实现细节还没有被热烈讨论起来.
这里有个问题: https://stackoverflow.com/questions/58558163/how-does-jetpack-compose-work-under-the-hood
从使用者的角度揣测一下Compose的原理:
虽然Composable使用了注解@Composable
, 但是却没有添加注解处理器(kapt), 所以并不是依靠注解在编译期生成代码.
在添加依赖的时候需要在build.gradle
里添加:
composeOptions {
kotlinCompilerExtensionVersion compose_version
}
所以它和kotlin的编译器有关系.
这个视频: Understanding Compose (Android Dev Summit '19)在17:18开始讲实现原理.
@Composable
更像是一个语言的关键字. 可以类比suspend
, 有以下几个共同点:
用了定制化的Kotlin编译器插件, 数据改变时, 受数据影响的composable的方法会被重新调用.
Android View和Jetpack Compose的相似点:
Jetpack Compose改进了View系统的哪些地方:
Jetpack Compose和Flutter的相似点:
UI = f(state)
.Jetpack Compose比Flutter好的地方:
Flutter比Jetpack Compose好的地方:
Flutter还支持iOS.
Flutter相比Jetpack Compose稍微成熟一些(Flutter出来的早一些), 是经过一些app的实际上线验证的.
Flutter是有自己的图形引擎Skia的, 绘制会更有效率? (没有验证, 纯猜测)
Using Jetpack libraries in Compose | Session -> 这个讲状态管理和其他Jetpack库结合的视频很棒.
手机扫一扫
移动阅读更方便
你可能感兴趣的文章