Tangram，七巧板，几块简单的积木就能拼出大千世界。我们用Tangram来命名这套界面方案，也是希望他能像七巧板一样可以通过几块积木就搭出丰富多彩的界面。

号外：Tangram开源了！通过http://tangram.pingguohe.net可以了解更多技术细节，直接去GitHub查看iOS(https://github.com/alibaba/tangram-ios)和Android(https://github.com/alibaba/tangram-android)源码。

什么是Tangram

Tangram不仅仅是一个Native（iOS & Android）的界面开发框架，而是我们从日常工作中沉淀出的一套界面解决方案，涵盖了Native SDK，GUI操作台，后端逻辑容器，组件库机制的一整套方案。

Tangram从手机天猫 - 首页方案抽象而来，是面向组件的界面方案，是我们不断权衡性能、稳定性、开发效率、灵活性和动态性多方面表现的结果。除了手机天猫首页外，还支撑了天猫App中的天猫直播，我的天猫，猜你喜欢等多个业务，并且在阿里星球等多个阿里系App中有所应用。

就如Tangram主页所说，我们重点关注方案的多平台一致性，高性能和业务支撑能力。

Tangram怎么来的

从2013年天猫在移动平台发力开始，我们一直在探索界面动态化方案。先后经历了WebView+HTML方案，动态Native方案，直至Tangram的原型——组件化方案。

最初我们看重动态性，在HTML框架和发布工具上做了大量的文章。我们可以快速开发出一张HTML页面，并推送到端上，而且通过Hybrid接口还能与Native进行交互。然而在大规模（双11）应用的过程中我们很快发现了问题——性能。当时我们认为WebView的性能是HTML页面的瓶颈，现在还不是大规模推广HTML的时候，我们需要一套替代方案。

很快我们提出了Dynative方案，框架内置基础组件（文本，图片，Button等）和函数（数学运算，字符串，网络等），以JSON为模板描述页面。Dynative方案兼具HTML方案的动态性和Native方案的高性能，看似完美。但很快在下一次的双11我们再次跌倒——效率。由于基于JSON定义的模板不具备通用性，写一张有逻辑的会场页面就需要数千行JSON，而且里边还有各种潜规则。能搞定这份模板的人，不超过5个。

痛定思痛，作为业务团队我们开始从业务的角度审视技术方案。带界面的业务基本分三种：

1. 临时性业务——比如活动，几张页面生命周期可能2周，1周，甚至一两天。数量多，需求频繁，有可沉淀的东西，但变化更多。对极致性能不敏感。
2. 常规业务——比如频道，生命周期长，需要长期维护。数量有限，需求稳定，沉淀性好。对极致性能相当敏感。
3. 基础业务——跟常规业务相比需求稳定性更高，对性能和稳定性有极高的要求。

对于第1型，我们认为未来一定属于HTML，随着WebView性能的提升和Mobile开发框架与开发技能日趋成熟，现阶段HTML体现出的劣势终将荡然无存。而第2型和第3型是值得我们去思考的，结合我们团队所负责的业务形态，我们结合多年在业务上的经验制定了以粗粒度组件化+灵活布局容器为基本理念的界面解决方案。

整体上，Tangram View作为根节点，具备滚动能力；页面的子节点为布局容器，每行一个容器，向下单行排列；布局容器中按照各自的布局规则，在其内对任意组件进行排列。

至此，Tangram的基础模型已经确定，放弃了第1型和第3型，重点关注第2型。从改造手机天猫首页的实现方案开始，通过几个月的时间证明这套模型和方案在业务上完全可行。进一步对方案进行抽象，并且开始周边建设。

Tangram关注的重点

正如Tangram主页上所述的，Tangram关注三个重点：面向业务、多端一致性和高性能。

面向业务

正如第一部分所讲的，Tangram来源于多次试错和方向的调整，最终站在业务角度出发，权衡多项技术指标的结果。所以面向业务是出发点，是整个Tangram体系的最基本原则。

基于这个原则，在端上Tangram始终坚持粗粒度组件。粗粒度意味着通用性和灵活性的下降，某种程度上还会对动态性造成影响，但在第2型业务中通用性、灵活性和动态性的需求是有节制的，在粗粒度上完全可以满足业务需求。而且，粗粒度还会带给我们使用成本低，性能更好等优势。在端上重点精力则投入到提升组件库复用度，布局容器和组件的丰富性，从而推动业务发展。

除了端上的工作，另一部分重点工作在控制台和服务网关的建设上。作为一个面向业务的方案，控制台是业务方和产品的接口，控制台的主要目标是让业务方可以直接控制基于Tangram建设的产品——调整页面布局，切换页面数据，等。服务网关的建设目标是最大程度的降低业务创建Tangram页面的压力和成本。

多端一致性

在多年的业务开发经历中，我们屡次被多端表现不一致的问题困扰。为了实现业务诉求，不得不通过复杂的网关逻辑来兼容多端逻辑不一致情况，以实现表现一致。因此我们早早的制定了两个Tangram端开发原则：

1. 任意新功能的提出都是不区分平台，在功能设计中必须同时考虑多端功能，具体的实现方案和逻辑必须多端统一Review以保证多端表现一致。
2. 任意一端的变更都必须在改动前把方案同步给其他端，而且变更必须多端同步发布。

高性能

在面向业务的原则之下，已经给高性能打下了一个良好的基础。而在高性能的思考上我们重点基于页面渲染效率和组件回收复用两方面。

1. 页面渲染——为了提升渲染效率，Tangram将在视图渲染之前把大量的计算工作在VM中完成，并缓存在VM组成的树形结构里。
2. 回收和复用——Tangram在Android和iOS平台上分别开发了VLayout和LazyScroll两个基础组件，通过一个双索引可见区域组件发现算法，实现了跨父节点组件的高效回收和复用。

总结

以上是对目前已经开源的Tangram 1.0的介绍，而目前我们已经完成了Tangram 2.0的讨论，开始执行2.0版本的重构工作。在Tangram 2.0中出于适应业务形态的变化，对Tangram 1.0中基于布局和组件的二维结构进行进一步的抽象，用于支撑更复杂的流式布局。并且对于控制台和服务网关也将进一步升级，大幅提升新业务开发效率。在性能层面，对组件开发模型和渲染模式进行一次较大的升级，在渲染和滚动效率上将得到巨大提升。