Cube 技术解读 | Cube 渲染设计的前世今生

阿里是个重运营的公司，前端开发者居多，2016-2017年，在Weex还是1.0时代，React Native开源还没多久，Flutter还没诞生的时候，如何在贴合前端开发环境的前提下，快速铺到android/iOS双平台是个大热点，支付宝内部孵化一个动态化跨平台方案顺势而生。

前面三篇文章分别介绍了Cube当前架构，Cube卡片和Cube小程序技术产品形态。这篇文章主要讨论Cube的渲染设计，帮助大家了解Cube卡片渲染技术的前世今生。

Native原生渲染的问题

我们都知道一个原生view渲染上屏需要几个步骤，以android举例：create、measure、layout、draw，这些需要在主线程完成，当实现原生列表时，即使完美复用item，对不同数据渲染时，也需要measure、layout、draw几步缺一不可，而且随着view嵌套层级越深，对主线程资源消耗越大，当列表fly起来以后，帧率快速下降，造成页面卡顿，基于这个问题，cube在调研期间，如何解决渲染效率是重要的一part。

通常来说优化列表滚动帧率，也就是view层级、布局复杂度、去掉不必要背景色，解决过度绘制，图片懒加载、item复用等方面下手，但根本还是绕不过measure、layout、draw。彼时的weex和RN，也都还是将html中的标签映射到平台层view，在某些场景下，开发者又不能像原生开发一样自行优化，在渲染性能上饱受诟病。因此cube调研期间渲染目标是：优化渲染效率+跨平台。

跨平台异步渲染方案

异步渲染

基于上面提到的背景和需求，那么我们就想，能否有一种方式，把关键步骤移除出线程呢，即异步渲染。在列表滚动时基本只有系统手势和列表本身滚动算法、动画需要占用主线程，将大大提高帧率。视图内元素绘制的产物是一个像素缓存（Cube采用的设计是Bitmap），回到主线程给视图进行刷新显示。

跨平台架构

另一个目标跨平台，是要做到可以快速扩展其他平台，cube将涉及平台的部分分离出来，形成platform 层。

platform

这里提供了各平台通用的标准c++原子接口，在不同平台用平台语言实现，初步只实现了android、iOS两个平台，android通过jni调用java方法，iOS在实现文件中c++、OC混编。如果未来需要扩展其他平台例如macOS，只需实现platform层定义的接口即可，可以达到快速扩展其他平台的目标。

core

library是基于platform原子接口用c++实现的是基础库，例如文件IO、UI控件、图片下载、消息通讯等，供上层引擎使用。library之上，就是cube渲染的核心实现，渲染部分包括数据模型和渲染逻辑，组件库指cube内部支持的一些系统实体控件，或者开发者可外接的实体组件。

下图是第一版cube渲染架构图。

cube渲染架构图

异步渲染技术选型

前面提到了，异步渲染方案里异步绘制的“产物”是一张bitmap交给“容器”View，为什么是bitmap呢，看起