Android声明式UI框架 Litho 初探——基础使用
初衷
Litho作为一个高性能的UI引擎，学习曲线还是比较高的，但是在国内能用的资料非常少（大部分都是相互复制的”Hello Word“教程），国外除了Litho自己的文档外，也没有太多教程。这几篇教程也是我边学边写。如果有那里理解不到位的地方，欢迎指正。
Litho 是什么
Litho是一个用于在Android上构建高效用户界面（UI）的声明性框架。但不同以往的UI框架，它的底层是Yoga,它通过将不需要交互的UI转换为Drawable来渲染视图，通过Yoga来完成组件布局的异步或同步（可根据场景定制）测量和计算，实现了布局的扁平化。加速了UI渲染速度
update：2020年09月09日16:17
有一些小伙伴问和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 上的 ViewGroupclass 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。
对于Litho我也是一个初学者，后面我会陆续跟新一些使用心得，在博客里基本上写的都是比较随意。掘金上一般会发一些自己整理过的。
更多相关文章
- 如何在代码中为组件设置dip，sp值
- 【Android API指南】App组件(1) - 应用程序基础
- 深入探索Android布局优化（上）
- android UI进阶之布局的优化（二）
- 01 Android应用的构成 四大组件 Activity， Intent Receiver ， Serv
- 【Android Studio快捷键】之导入相应包声明（import packages）
- 利用Android多进程机制来分割组件