Android声明式UI框架 Litho 初探——基础使用
初衷
Litho作为一个高性能的UI引擎,学习曲线还是比较高的,但是在国内能用的资料非常少(大部分都是相互复制的”Hello Word“教程),国外除了Litho自己的文档外,也没有太多教程。这几篇教程也是我边学边写。如果有那里理解不到位的地方,欢迎指正。
Litho 是什么
Litho是一个用于在Android上构建高效用户界面(UI)的声明性框架。但不同以往的UI框架,它的底层是Yoga,它通过将不需要交互的UI转换为Drawable来渲染视图,通过Yoga来完成组件布局的异步或同步(可根据场景定制)测量和计算,实现了布局的扁平化。加速了UI渲染速度
有一些小伙伴问和Google的Compose有什么区别:因为Compose目前还处于非常的早期的版本,所以我只能根据Google的介绍来说说,相同点:
两者都是声明式UI(如果你不知道什么是声明式UI那就看看Flutter)
两者都以Flexbox来创建布局(Column、Row),最终生成的布局层级更低,可以减少渲染时的递归调用。
感谢评论区的小伙伴指正,因为之前看到很多类似的代码(anko这种)。所以以为Compose又是Google早的一个轮子,其实它传统的View体系区别很大。
不同点:
Compose底层通过Canvas绘制,应该是参考了Flutter(盲猜可能是为了让Android开发人员更方便转到flutter开发)。Litho的底层是使用自家的Yoga
传统Android页面在UI非常复杂,视图层级较深时候,难免在Measure和Layout的时间会过长。而Litho使用异步布局,在异步线程中完成Measure、Layout,在UI线程中只需要完成绘制即可。由于是异步布局,因此在UI界面上FPS十分稳定。
对于没有交互的View会自动转成Drawable,因此布局更加扁平。
传统的RecyclerView按ItemType类型进行回收复用。也就是说有10种ItemType就会缓存10个ItemType。即是有的ItemType只使用过一次。而Litho中,在Compoent回收之前,会被拆分成text、iamge···不同的组件,在需要的时候再次组合。减少了内存占用。
下面是同样的UI用Android 传统方式 和 Litho 的布局边界对比: Litho:
传统方式:
可以看到,上图中的图片和TextView,Litho最终绘制成了一个Drawable。
在Litho中,使用组件(Component)来构建UI,而不是直接与传统的Android视图进行交互。组件本质上是一个函数,它接受不可变的输入(称为属性 props),并返回描述用户界面的组件层次结构。
如果有Flutter开发经验,那么Litho的开发方式有点类似
接下来的教程都将结合代码进行讲解
基础配置
gradle
apply plugin: 'kotlin-kapt'
dependencies 中加入
// Litho
implementation 'com.facebook.litho:litho-core:0.37.1'
implementation 'com.facebook.litho:litho-widget:0.37.1'
kapt 'com.facebook.litho:litho-processor:0.37.1'
// SoLoader
implementation 'com.facebook.soloader:soloader:0.9.0'
// For integration with Fresco
implementation 'com.facebook.litho:litho-fresco:0.37.1'
// Sections
implementation 'com.facebook.litho:litho-sections-core:0.37.1'
implementation 'com.facebook.litho:litho-sections-widget:0.37.1'
compileOnly 'com.facebook.litho:litho-sections-annotations:0.37.1'
kapt 'com.facebook.litho:litho-sections-processor:0.37.1'
初始化SoLoader.Litho依赖,SoLoader用于加载底层布局引擎Yoga
SoLoader.init(this, false);
使用基础Component
Component Specs
Litho中的视图单元叫做Component,可以直观的翻译为组件
组件分为两种类型 : Layout Spec:将其他组件组合到特定的布局中。这相当于 Android 上的 ViewGroup 。
Mount Spec:可以渲染 View 或 Drawable 组件。 现在,让我们来看看 Layout Spec 的整体结构:
Component的类名必须以Spec结尾,不然会报错
/**
* Component
* 组件 Spec 只是一个普通的java类,带有一些特殊的注解。
* 组件 Spec 是完全无状态的,没有任何类成员。
* 使用 @Prop 标注的参数将自动成为组件构建器的一部分。
*/
@LayoutSpec // 将其他组件组合到特定的布局中。这相当于 Android 上的 ViewGroup
class MainLithoViewSpec {
/**
* @OnCreateLayout 注解的方法必须具有 ComponentContext 作为其第一个参数
* 后跟使用 @Prop 标注的参数列表。注解处理器将在构建时对参数列表以及API中其他约束条件进行验证。
*/
@OnCreateLayout
fun onCreateLayout(
context: ComponentContext,
@Prop color: Int,
@Prop title: String
): Component {
return Column.create(context)
.paddingDip(YogaEdge.ALL, 16f)
.backgroundColor(Color.DKGRAY)
.child(
Text.create(context).text(title)
.textColor(color)
.textSizeDip(25f)
)
.child(
Text.create(context).text("这是小标题")
.textColor(Color.GREEN)
.textSizeDip(16f)
)
.build()
}
}
在Activity中使用
···
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val c = ComponentContext(this);
val component2 = MainLithoView.create(c).color(Color.WHITE).title("这是一个Title").build()
val component = MainLithoViewSpec.onCreateLayout(c, Color.WHITE, "这是一个Title")
// 这里不在使用xml,使用 Litho的Component
setContentView(LithoView.create(c, component));
}
···
运行效果:
组件 Spec 类在编译时期会生成与 Spec 名相同但没有 Spec 后缀的ComponentLifecycle 子类。例如,MainLithoViewSpec 类会生成一个 MainLithoView 类。
生成的类种暴露的唯一 API 是 create(...)方法,它为 spec 类中声明的 @Props 返回相应的Component.Builder。 在运行时,特定类型的所有组件实例共享相同的 ComponentLifecycle 引用。这意味着每个组件类型只有一个spec实例,而不是每个组件实例。
MountSpec相比于Layout Spec更复杂一些,它拥有自己的生命周期,在下篇文章中单独讲解。
目前我自己的理解是LayoutSpec中你可以使用官方提供的一些组件来构建UI,但是官方组件毕竟数量有限不可能全部实现UI设计。这时候MountSpec的作用就凸显出来了。MountSpec把Android上的View转化为一个符合Litho要求的Component。
作者:涂程
来源:CSDN