猫客页面内组件的动态化方案-Tangram

Tangram 2.0 库

Android

• Tangram-Android
• Virtualview-Android

iOS

• Tangram-iOS
• Virtualview-iOS

背景

技术背景

一直以来，无线应用都在不断寻求动态化页面的解决方案，在阿里巴巴集团内，除了风风火火地 Weex 项目外，各个团队都有大大小小的解决方案。咱们猫客一直持续基于 Tangram 方案来解决页面动态化的问题，然而在面对持续升级的业务需求时，原有的开发模式也慢慢变得没法胜任，本年度以来，咱们 Tangram 体系在各个层面都进行了大跨度的技术升级（可参考文章天猫APP改版之首页架构&开发模式全面升级），本文再详细介绍一下页面内组件体系升级方案。

老组件体系的问题

在原有的 Tangram 体系里，主要解决了页面内布局结构的动态化能力，经过 json 数据描述能够组合出经常使用的页面结构。然而页面内具体的坑位样式，咱们称之为业务组件，是采用常规的 native 代码开发的，除非内置了足够多的逻辑，不然组件的样式调整或者新组件的开发都要发布版本，没法知足业务节奏；固然咱们也尝试过使用 Weex 开发业务组件贴到页面上，可是在体验和性能上仍是有较大的缺陷。

因此总结起来，就是两点问题：

1. 业务组件没法动态更新；
2. 现有的动态组件方案较重，影响性能和体验；

解决之道

对于上述问题，解决思路实际上是比较通用的，要动态更新界面视图，就须要用界面模板描述视图，模板与数据分离。将动态下发的模板和数据在端上绑定渲染。要提高性能，也有三大着力点——减小视图层级与个数，结构尽可能扁平化；异步布局渲染流程，解放主线程计算量；回收与复用组件，减小内存开销。

新的组件体系就是在模板化描述视图，动态更新视图，减小视图层级几个方面作文章，至于组件的回收复用，则是在页面级别统一完成；而异步布局渲染流程，则是后续的优化方向。

新的组件方案称之为 VirtualView，简称 VV，也称为2.0组件，它的设计遵循如下几个思路：

1. 以了一种虚拟化开发基础组件的技术，使用方只要按照指定协议实现一个基础组件的尺寸计算、绘制逻辑、布局逻辑，即能实如今宿主容器的 canvas 里实现直接绘制 UI 内容的，让最终渲染出来的视图结构呈现扁平化，提高组件渲染性能。同时为了解决虚拟化 View 带来的原生 View 的能力损失的问题，它支持加载和渲染原生基础组件，二者组合产生协力，既能减小开销，又能知足特殊场景下的业务需求。
2. 内置实现了一系列基础组件，可让使用方直接上手尝试；而搭建业务组件的方式采用 XML 模板来编写，配套 XML 模板更新 sdk，这使得业务组件动态更新成为了可能。XML 模板里还支持写数据绑定的表达式，在样式动态化、数据动态化的场景下能很是方便地实现业务需求。
3. XML 模板里涉及到的基础节点、属性、字符串资源等都被提早编译成二进制资源，客户端加载经过加载编译后的模板数据来建立视图。

设计方案

总体架构

先从总体上预览一下整个方案的大致结构：

自下往上，自左往右的顺序介绍各个模块：

• 基础模板加载器负责加载编译后的模板数据，好比从文件加载、从二进制数组加载、从网络加载，将编译后的二进制模板数据加载到内存里，经过组件加载器、字符串资源加载器、表达式资源加载器等提取出其中的资源。
• 框架还内置了基础组件，包括原子的基础组件如文本、图片、线条，还包括布局类型的基础组件，好比线性布局、帧布局、网格布局等；每一种类型的基础组件提供了原生 Native 版本的实现和虚拟化的实现，用户也能够自定义本身的基础组件注册到框架内部，组件构造器经过加载好的组件数据，来构造出整个业务组件树，并添加到宿主容器里，对于虚拟组件，会在渲染阶段绘制到宿主容器的 canvas 上，而原生组件会做为子 View 添加到宿主容器里。
• 框架内部也提供了基础的表达式能力，主要分两种，一种是简单的数据绑定表达式，一种是简单的逻辑表达式；前者用于在模板里写表达式绑定数据到基础组件的属性上，然后者提供了一种轻量级的逻辑运算能力，能够访问基础组件的属性并更新，实现一些联动效果。
• 事件管理，本方案聚焦于界面的动态化建立，但对业务逻辑的处理主要仍是靠原生的代码实现，所以处理组件的一些经常使用交互事件，好比组件的点击、长按、触摸、曝光事件等。事件管理模块负责将外部的各个类型的事件处理模块注册进来，当组件发生特定的事件时，找到对应类型的处理模块来调用处理。
• 宿主容器管理负责对虚拟组件的宿主容器进行构建和回收复用的管理。当原有的组件滑出屏幕后，能够回收到统一的池子里，以便后续复用。
• 组件管理负责对基础组件进行构建和回收复用管理。当原有的组件滑出屏幕后，除了宿主容器能够回收复用，内部的基础组件对象也能够回收到统一的池子里。若是组件的池子是空的，则在须要的时候构造新的组件。
• 扩展模块管理则用于注册外部功能扩展模块，当内置的基础能力没法知足业务场景的时候，经过扩展模块注册特定的功能模块，而后编写自定义基础组件来实现特定功能。
• 模板存储、模板校验、模板更新、模板注册则分别负责模板数据的存储、安全性校验、版本校验、与更新检查与新模板下载、注册模板数据到框架，总体协同来完成业务组件的动态更新，它并不与整个渲染组件的核心框架耦合，能够做为独立模块存在。
• 配套的工具和服务主要包括模板编写工具、模板编译工具、模板更新服务.模板编写工具用于 XML 的模板的编辑，并调用编译模块编译模板，模板里涉及到的组件资源、字符串资源、表达式资源会分别用对应的模块处理。编译后端模板数据能够上传到模板更新服务里，客户端调用相应的接口检查是否有更新。

运行流程

有了上述基础，当咱们要开发新的业务组件的时候，除了有新增 Native 逻辑的需求场景（好比新增视频功能），大部分需求均可以告别原生代码的编写，转而编写组件模板。

1. 先编写业务组件的模板。
2. 经过工具将模板数据编译成二进制数据。
3. 客户端加载二进制数据能够有两种路径，一是直接打包到客户端里，写代码加载，另外一种是发布到模板管理后台，客户端在线更新到模板数据。
4. 不论哪一种方式加载二进制数据，客户端接下来的工做是解析二进制数据里，好比校验版本号，合法性，读取头信息等等。
5. 等要真正建立组件的时候，根据组件名称找到二进制数据，从中解析并建立出真正的组件模型数据。
6. 从模板里建立在组件每每不含有业务数据，由于业务数据是动态性的，用户须要获取到业务数据绑定到组件上，组件的属性里能够写表达式来指定使用哪个数据字段。

值得注意的是，在上述架构及流程里，描述了一个完整的实践经验，但对于本方案来讲，核心点在于提供了对组件从编写到展现流程的实现，其周边的配套设施，并无内置在框架里，包括客户端上的模板管理、更新、注册模块，以及后端的模板发布服务，由于这些模块每每涉及业务逻辑，且与各个应用的基础设施相关，内置在框架里反而限制了使用方的接入。这里提供一些可供参考的经验：

1. 模板管理后台要能对模板的进行发布、更新，而且按照客户端版本、平台、组件版本、生效优先级等几个维度来管理模板；
2. 模板文件能够存放到 CDN 上供客户端下载，管理平台只是对比下发远信息；下载文件要作足够的校验；
3. 客户端要内置一份打底的模板数据，这样不至于由于模板不存在而出现空窗；
4. 客户端可提供一个统一的模板管理模块，面向全应用提供服务，在合适的时候请求管理平台检查有没有更新，好比启动、用户刷新、推送指令的到达，而且负责下载、文件校验、通知页面刷新等功能；页面刷新能够作优先级区分，好比高优先级的模板更新主动去刷新下页面，而低优先级的能够等二次进入页面或者刷新页面的时候生效；

几个核心设计

组件的基础模型

对于组件，咱们作了以下定义，每个基础的原子组件或者容器组件都会有如下属性，自定义的基础组件应当继承自基础定义并作扩展。

名称	类型	默认值	描述
id	int	0	组件id
layoutWidth	int/float/enum(match_parent/wrap_content)	0	组件的布局宽度，与Android里的概念相似，写绝对值的时候表示绝对宽高，match_parent表示尽量撑满父容器提供的宽高，wrap_content表示根据自身内容的宽高来布局
layoutHeight	int/float/enum(match_parent/wrap_content)	0	组件的布局宽度，与Android里的概念相似，写绝对值的时候表示绝对宽高，match_parent表示尽量撑满父容器提供的宽高，wrap_content表示根据自身内容的宽高来布局
layoutGravity	enum(left/right/top/bottom/v_center/h_center)	left|top	描述组件在容器中的对齐方式，left：靠左，right：靠右，top：靠上，bottom：靠底，v_center：垂直方向居中，h_center：水平方向居中，可用或组合描述
autoDimX	int/float	1	组件宽高比计算的横向值
autoDimY	int/float	1	组件宽高比计算的竖向值
autoDimDirection	enum(X/Y/NONE)	NONE	组件在布局中的基准方向，用于计算组件的宽高比，与autoDimX、autoDimY配合使用，设置了这三个属性时，在计算组件尺寸时具备更高的优先级。当autoDimDirection=X时，组件的宽度由layoutWidth和父容器决策决定，但高度 = width * (autoDimY / autoDimX)，当autoDimDirection=Y时，组件的高度由layoutHeight和父容器决策决定，但宽度 = height * (autoDimX / autoDimY)
minWidth	int/float	0	最小宽度
minHeight	int/float	0	最小高度
paddingLeft	int/float	0	左内边距
paddingRight	int/float	0	右内边距
paddingTop	int/float	0	上内边距
paddingBottom	int/float	0	下内边距
layoutMarginLeft	int/float	0	左外边距
layoutMarginRight	int/float	0	右外边距
layoutMarginTop	int/float	0	上外边距
layoutMarginBottom	int/float	0	下外边距
background	int	0	背景色
backgroundImage	string	null	背景图地址
borderWidth	int	0	边框宽度
borderColor	int	0	边框颜色
visibility	enum(visible/invisible/gone)	visible	可见性，与Android里的概念相似，visible：可见，invisible：不可见，但占位，gone：不可见也不占位
gravity	enum(left/right/top/bottom/v_center/h_center)	left|top	描述内容的对齐，好比文字在文本组件里的位置、原子组件在容器里的位置，left：靠左，right：靠右，top：靠上，bottom：靠底，v_center：垂直方向居中，h_center：水平方向居中，可用或组合描述

方案内内置了一系列基础组件，完整的组件列表以下：

• 虚拟文本组件
• 原生文本组件
• 虚拟图片组件
• 原生图片组件
• 虚拟线条组件
• 原生线条组件
• 虚拟进度条组件
• 虚拟图形组件
• 原生翻页布局容器组件
• 原生滚动布局容器组件
• 虚拟帧布局容器组件
• 虚拟比例布局容器组件
• 虚拟网格布局容器组件
• 原生网格布局容器组件
• 虚拟线性布局容器组件
• 原生线性布局容器组件

虚拟组件

上文提到虚拟化开发的组件的技术，简称虚拟组件。不少作性能优化的方案、建议都会提到采用 Canvas 直接绘制的方式来减小 View 的个数，虚拟将这个开发流程作了抽象与规范，可让开发人员像定义原生组件同样定义虚拟组件。

具体来说，基础组件须要遵循一个接口的规范，这个口定义了渲染过程当中须要的三个流程：计算尺寸阶段、布局阶段、绘制阶段；定义这个三个阶段是为了更好的与系统平台特别是 Android 平台对接，由于在 Android 原平生台下也会有这个三个阶段，在 iOS 平台下则也须要按照本方案里要求的规范去处理。计算尺寸阶段定义要触发一次尺寸计算，须要对其包含的子组件进行计算调用；布局阶段定义了要触发一次布局，将子元素按照计算好的位置尺寸排布，也要对包含的子组件进行布局调用；绘制阶段定义要进行视图绘制，固然也要对起包含的子组件进行绘制的调用；对于虚拟组件，就在这些接口里实现相关逻辑，而对于原生组件，在这些接口实现里调用原生组件的对应逻辑。

不管是虚拟化组件仍是原生组件，都采用上述相同的模型来定义，再加上相同的尺寸计算接口、布局接口、绘制接口，这样对于宿主容器来讲，包装在内部的组件就不分虚拟化仍是原生，一视同仁，暴露给外面的接口也是同样的，只要将宿主容器像普通的 View 同样添加到的视图界面上，就能够在后续的渲染过程当中显示出来。若是虚拟组件使用的越多，View 的个数就越少，对于系统来讲层级越扁平。如下图示例的组件来讲，最终呈现的 View 只有宿主容器和两个图片组件，若是将图片也用虚拟化的方式实现，最终 View 只有一个宿主容器，而界面仍然保持不变。

二进制文件的格式

经过 XML 编写的业务组件，并不直接在客户端里运行使用，而是先进行一次二进制序列化操做，原始的 XML 模板文件保存成文件的时候，就是以纯文本的形式存在，会包含不少冗余信息，好比空格、换行、还有重复出现的字符串等，文件体积比较大，以xml解析器去解析的时候，也会须要大量字符串操做，效率和性能不能达到最优。而将它编译成二进制格式，会避免这些问题，好比文件重复出现的字符串只保留一份，经过字符串索引去引用它，全部的组件类型也都会被转换成一个数字索引，在客户端内经过数字索引反过来找到对应的类实例化。这样文件格式会很是紧凑，体积更小。整个设计也借鉴了 Android 系统编译模板文件的思路。它的具体格式说明以下：

按照图中从左往右、从上往下的顺序分别说明每一个段的做用：

• 开始5个字节固定为 ALIVV；至关于咱们的文件格式的一个标记。
• 版本号分三个，分别为主版本号，次版本号和修订版本号，均为 2 个字节；在无重大重构更新时，前两位通常不变，第三位用于组件的业务级别变动升级；
• 组件区的起始位置和长度，均为 4 个字节；表示这份文件里组件区数据从第几个字节开始，它总共有多少个字节，这样解析这份数据的时候能直接将文件指针定位到特定位置来读取数据。
• 字符串区的起始位置和长度，均为 4 个字节；表示这份文件里字符串数据从第几个字节开始，它总共有多少个字节。
• 表达式区的起始位置和长度，均为 4 个字节；表示这份文件里字符串数据从第几个字节开始，它总共有多少个字节。
• 数据区的起始位置和长度，均为 4 个字节；表示这份文件里附加数据从第几个字节开始，它总共有多少个字节。目前这一区块是做为一种保留区，实际还未使用到。
• 当前文件所属页编码，2 个字节，惟一标识一个页（保留使用）
• 当前文件依赖页的个数为 2 个字节，后面为依赖页的 Id，依赖页个数大于 0 表示该页用到了其余页的资源或者代码，在该页加载以前须要确保依赖页必须已经加载；（保留使用）
• 组件区开始，前 4 个字节表示文件里业务组件个数，目前一个 XML 模板编译成一个二进制文件，故其值固定为 1。每一个业务组件前 2 个字节表示业务组件名称字符串的长度，后面为指定长度的字符串字节数据；紧接着是 2 个字节的编译后组件二进制流长度，后面为二进制代码；
• 字符串区开始，前4个字节表示字符串个数，在咱们的框架里，会内置一些系统级别的字符串资源，好比上文5.2开端表格里提到的那些属性名，这些字符串不用序列化到二进制文件里，而模板文件里出现的非系统字符串才会做为资源序列化到二进制文件。每一个字符串资源前 4 个字节字符串索引 Id 即它的 hashCode，后面 2 个本身为字符串的长度，再后面为对应的字符串；
• 逻辑表达式代码表。前 4 个字节表示逻辑表达式资源个数，每一个表达式资源前4个本身表示表达式的索引，它是表达式原始字符串的hashCode，后面两个2 个字节表示表达式的长度，后面为对应的表达式内容，它是表达式按照关键字切割后的字符串结构；
• 扩展数据段是保留为第三方扩展使用；

绑定数据的表达式

开发业务组件的时候，基础属性或者样式每每不能在模板里直接写死，而是须要从数据里获取，因此引入了用户数据绑定的表达式，语法和实现上目前比较简单，参考了不少同类的设计，尽量符合开发人员的直觉。

• 访问数据属性的表达式

语法上以 ${ 开头，以 } 结束。对于Map，经过 . 操做符进行访问，对于 Array 或者 List 经过 [] 操做符进行访问。

好比：

${benefitImgUrl}
${data[0].benefitImgUrl}
复制代码

• 条件表达式

用来给那些须要根据数据中某个字段来设置值的属性，语法上以 @{ 开头，以 } 结束，中间部分为表达式的具体内容。

条件表达式 ? 结果表达式[1] : 结果表达式[2]
复制代码

当条件表达式成立的时候，使用结果表达式[1]，不然使用结果表达式[2]。 其中： 条件表达式支持布尔类型、字符串类型、JSONObject、JSONArray。 如下场景均为 false：

• 布尔类型值为 false
• 字符串为 null 或者 "" 或者 "null"
• 字符串 "false" 或者 "FALSE"
• JSONObject 为空或 JSONObject.NULL
• JSONArray 长度为 0
• 字段不存在

好比：

@{${logoUrl} ? visible : invisible }
复制代码

考虑到篇幅限制，不能将上述架构和流程中的每一细节彻底展开，详情能够参考苹果核这里的文档。

效果

与 Tangram 及 TAC 结合

VirtualView 方案是 Tangram 的极大补充，能够解决80%场景下的动态化需求，而 Tangram 依赖的数据则经过 TAC 提供解决，三者结合能够造成一个闭环，让一个开发从端到端地解决整块业务的开发。

组件动态下发

以双十一期间为例，90%的双十一业务组件都是动态下发的，且随时可根据业务节奏调整。

展望

尽管在功能流程上已经逐步稳定，能承载起平常及大促的需求变动，咱们的方案仍是有不少不足之处的，好比咱们指望更高的运行效率、更加扁平化的UI结构、更加方便的开发体验，对此也作了更进一步的规划建设：

功能	计划
提供更加完善的文档和教程、Demo，内外版本同步，创建以 github 为中心的迭代开发机制	17年12月
组件建立、布局计算、数据绑定机制优化，提高性能	18年1月
重构模板编译工具，提高编译开发体验	18年1月
提供预览服务，提高开发效率	18年3月
提供配套的后端数据服务与基础设施，即 TAC 平台开放	18年3月

附录

Tangram 2.0 主要更新说明

1. 组件模型的概念升级，从原来的『卡片』+『组件』升级成『布局』+『组件』，即原来的『卡片』认为是一种具备布局能力的组件，具有嵌套另外一组件的能力；
2. 页面结构优化，页面下能够直接挂载组件，不须要嵌套一层布局；
3. 组件类型的语义化，从原来的 一、二、三、4...等数字枚举类型定义，升级成字符串类型的定义，兼容解析原有的数字枚举定义；
4. 更好的嵌套布局实现，流式布局在模型描述上支持多层次的嵌套，并优化了 Android 端上的实现方式；
5. margin 去重的实现，同一层级的容器组件或原子组件直接，支持外边距 margin 的去重，使得动态数据下控制间距更方便；
6. 支持 zIndex，不管是容器组件仍是原子组件，支持在其样式上配置 zIndex，zIndex 值越大，绘制层次越高；
7. 升级组件开发方式，引入动态化组件开发技术，提高组件动态性，实现组件样式的高效渲染与动态更新；

其余相关的 Tangram 库

Android

• vlayout
• UltraViewPager

iOS

• LazyScrollView

工具

• virtualview_tools