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

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

所以总结起来，就是两点问题：

业务组件无法动态更新；
现有的动态组件方案较重，影响性能和体验；
解决之道
对于上述问题，解决思路其实是比较通用的，要动态更新界面视图，就需要用界面模板描述视图，模板与数据分离。将动态下发的模板和数据在端上绑定渲染。要提升性能，也有三大着力点——减少视图层级与个数，结构尽量扁平化；异步布局渲染流程，解放主线程计算量；回收与复用组件，减少内存开销。

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

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

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