地保持了线程安全，使得后台渲染变得可⾏。
Android Threading Model
Litho Threading Model 1st
除此之外，现在我们已经节省了主线程的时间，还可以进⼀步进⾏优化。如果⼀帧有时间空余的话，可以提前 draw 下⼀帧的内容。这个是⽤DisplayList 实现的, DisplayList 在Android系统中⽤来保存 op
enGL commands ，提前创建和编译 Displaylists，需要显⽰这个组件的时候，只需要执⾏⾥⾯的命令就可，不需要再进⾏编译。（DisplayList is a group of openGL commands(已被保存，编译) for later execution）
Litho Threading Model 2nd
2. View Flattering 铺平View层次
好处：既减少了内存使⽤，也减少了GC的频率。
在不改变显⽰内容的基础上，铺平 View 结构可以减少 View 的个数
View Flatterning
a. 容器处理的优化：
Android ⾥⾯有很多容器，如果下图中的 Row 和 Column 不需要画背景的话，真正需要显⽰在屏幕上
的组件只有⼀个图⽚加上两个⽂本，那么就可以把 Row 和 Column 这两个容器删掉。Litho 会去检测容器是否影响组件的绘制，如果不影响就删掉。由于使⽤了 Yoga，因为 Litho 允许layout 过程中不使⽤ Android Views，可以提前得知在绘制组件的时候是否需要容器。
Container
b. View层⾯处理的优化：
如果 Row 和 Column 这两个容器消失了，那对于这个图⽚和两个⽂本要如何处理？
标准的Android系统，图⽚使⽤ ImageView，⽂本使⽤ TextView
Litho 中的实现使⽤ Drawables，轻量级，不会有 View 的内存和性能负担，使⽤ Drawables 让Litho进⼀步减少 View 的层数。
View
3. Incremental Recycling 增量复⽤
Android ReyclerView 的复⽤是基于 ViewType 的，假设有上百个ViewType，各种⽂章⽂本视频图⽚
组合在⼀起，每个 Type 分配⼀个Pool，那将会有上百个 pool ，会对内存造成负担。
RecylerView 多类型复⽤
Litho中的细粒度复⽤
每个Item都是由⼀些核⼼组件构成的，⽂本，图⽚，视频等，只是不同的 Item 只是对这些核⼼组件进⾏不同的组合。不把每个 Item 的内容看成⼀个整体，⽽是把 Item 拆分成各个核⼼组件。
当⼀个 Item 滚出屏幕，就把这个 Item 分解成各个核⼼组件，每种核⼼组件放到⼀个 Pool ，当显⽰⼀个新的 Item 的时候，再把这些组件进⾏重新组合。
更进⼀步的优化：
因为我们不把⼀个 Item 当成⼀个整体，所以当这个 Item 滚出屏幕的时候，也不⽤等整个 Item 滚出屏幕的时候再回收，只需要当每⼀个核⼼组件滚出屏幕就可以进⾏回收。
下⾯这个例⼦，当上⾯ Item 中的⼀部分移出屏幕，头像和标题部分已经被回收了，不需要整个 Item 滚出屏幕，这些组件可以更快地回收和复⽤，以减少核⼼组件的数量。
Incremental Recycling
参考
2017 Facebook F8
