Hippy/docs/architecture/render/android/native-render.md

Android Native Renderer

---

Flatten UI

Flatten UI是一种终端视图层级优化的方法，在Hippy 2.0的基础上实现这种优化方案，并不是简单的改造渲染逻辑就可以实现的，这里还依赖整体UI结构调整，缓存池改造，以及细粒度复用等重构完成后才能支持Flatten UI最终优化的实现，所以Flatten UI在3.0可以理解为一整套解决方案的升级，而不是单一的局部优化。

层级优化对比

在2.0中通过针对只参与排版的节点不创建实体view的方法来减少终端UI层级，在此基础上，3.0 Flatten UI采用子元素直接在父view上完成渲染的方法将UI层级进一步打平，通过下面这个demo我们可以看到不同阶段优化效果对比：

      <View onClick={...}>
         <View style={{margin: 10}}> 
               <Image {...} />
               <Text {...}>hello world</Text>
         </View>
      </View>

• 无层级优化情况下dom -> render -> view 一一对应
• 2.0将只参与排版的节点在render中被优化，render节点和view一一对应
• 3.0在2.0的基础上进一步优化view层级，部分子节点直接渲染在父节点的view上

UI 主体结构的改造

2.0 UI主体结构

• HippyViewGroup是我们页面中最常见的元素，但绝大部分view是不需要展示图片与处理图片属性的，从imageview派生出来让view组件变得异常臃肿;
• AsyncImageView是HippyViewGroup的基类，也是属于Support-ui里面的一个基础组件，这个基类里面包括图片拉取管理，drawable的管理与渲染诸多逻辑，让组件渲染与view强耦合在一起，除了设计不合理以外代码实现质量也较差。
• Support-ui目录下的所有组件逻辑未来会全部废弃。

3.0 UI主体结构

• 废弃 suppor-ui AsyncImageView，使用轻量化FlatViewGroup替代，FlatViewGroup只负责子节点渲染顺序的管理;
• 通过新增Component体系实现view属性与渲染属性处理逻辑的分离；
• Component由Render Node持有，负责Drawable的管理，可以在不依赖view的情况下完成独立渲染；
• Image Component extends Component，主要包括image相关属性处理以及image loader对接逻辑。

缓存池改造

在2.0中只针对预创建view，base64与本地图片的数据做了缓存，既没有抽象出统一的缓存访问接口，也无法做很好的扩展来支持其它流程的缓存优化，所以在3.0定义了一套标准的缓存访问接口，重构了所有缓存相关的代码实现结构，并扩展了基于view的复用池与常用object的复用池。

• PreCreateViewPool

  预创建view缓存池，当在dom线程接收到create node指令时，会创建对应的create render node task并放入队列中，等batch的时候把队列中的task放到UI线程批量执行，在此之前还需要执行排版相关的逻辑，为了让UI线程能提前处理一部分任务，当接收到create node指令时，就直接在UI线程创建对应的view并放到缓存池，等到UI 线程执行batch的时候就可以直接从缓存池取出使用，这样可以最大化UI线程和dom线程task的并行执行，减少整个流程的耗时该缓存池对于开发者来说是透明的，每次batch执行结束后就会清空，内部使用SparseArray的数据结构进行存储，直接使用view id做key

• RecycleViewPool

  基于view type的view缓存池，主要使用在Recycler view滚动时候，recycler view item子view的回收，具体回收机制可以参考下一节细粒度复用的介绍该缓存池内部使用Map<String, SimplePool>进行存储，view的class name作为key值，每个类型的view pool default pool size为8

• ImageDataPool

  Image data缓存池，该缓存池内部使用LruCache<Integer,ImageDataSupplier>进行存储，key值由image uri后32位做hashcode计算得出，当前设置的default pool size为24

• RecycleObjectPool

  常用频繁创建对象的缓存池，类似于系统Message的使用，使用完成后做recycle，获取的时候直接obtain from pool，避免临时对象的频繁创建和销毁带来GC问题，该缓存池内部使用Map<CustomObjectType, SimplePool