回收

设备屏幕通常以每秒60帧的速度刷新。为了提供流畅的体验，应用程序需要能够每隔16ms连续渲染 UI 变更。如果不尊重这个时间限制，会导致帧丢失和用户体验不佳。随着用户界面变得越来越复杂，在这段时间内完成所有渲染工作变得越来越困难。随着新的 UI 片段不断涌入屏幕，这对于动态滚动页面的渲染来说尤其具有挑战性。

Android使用 RecyclerView 解决了这个问题，RecyclerView 是一个动态的 UI 容器，它能够通过创建足够的视图来填充屏幕，然后在UI滚动时回收和复用视图来显示大数据集的元素。

动态演示视频1

RecyclerView 支持显示多样内容。为此，它根据视图的类型将视图保存在不同的缓冲池中。虽然这个概念在简单的情况下工作得很好，但是对于具有许多不同视图类型的 UI 来说，它可能会出现问题。在包含许多视图类型的场景中，在滚动事件之后进入窗口的视图更有可能是 RecyclerView 第一次显示的视图。如果发生这种情况，RecyclerView 必须分配一个新的视图。发生分配的 16ms 时间槽内 RecyclerView 也必须同时对即将显示的视图执行绑定、测量和布局操作

动态演示视频2

Litho 中的增量回收利用

我们希望为 Litho 提供更具扩展性和高效率的回收系统，同时我们希望从 API 中消除视图类型的复杂性。 Litho 布局的表示与在屏幕上渲染布局的 View 和Drawable 完全脱节。这意味着，当我们需要在屏幕上放置一个新的 RecyclerView 视图时，我们已经知道该项目的内容以及它相对于其余 UI 的位置。 这使 Litho 完全摆脱 View 类型的概念。在 RecyclerView 滚动时，我们可以递增地使用文本或图像等构建块，而不是重新使用表示RecyclerView中项目的整个 View。 这对于传统的 Android 视图来说是不可能的，因为布局计算在完整的视图树上运行，并且当我们知道所有视图在一行中的位置时，所有视图都已经被实例化了。

动态演示视频3

能够回收像 Text 这样的单个的原始类型，可以大大提高应用程序的内存效率，现在可以将列表中的 text 回收用于其他的 text。 最重要的是，由于我们提前计算布局，所以我们确切地知道新项目需要在哪个点可见，这意味着比起在一个帧内绑定和画一棵大的视图树，我们可以每一帧在屏幕上引入更少数量的原始类型。