上一篇文章介绍了Tangram的开发思路和发展历程，本文将对Tangram 1.0的技术架构做一个概括性的说明。读者如果要了解更多的技术细节可以访问Tangram主页查看详细文档。

Tangram作为一个面向常规业务产品的解决方案由3个部分组成：

• Tangram SDK：目前Tangram 1.0开源了iOS和Android两个平台的SDK，负责端上的界面渲染。Tangram SDK基于两个自建的高效组件复用容器（VLayout-Android和 LazyScroll-iOS），开发的界面视图生成器。
• Tangram AC：Tangram App Container，是整个Tangram体系中的业务核心。负责把模板和数据按照业务逻辑进行组装，并输出给SDK。
• Tangram OP：Tangram Operator，是Tangram控制台，是业务人员调整界面结构、样式和数据源的控制台。

Tangram SDK

现在我们讨论的是Tangram 1.0架构，也就是正在服务手机天猫和其他几个App的版本。Tangram 2.0将在模型设计和核心技术上都有较大升级，暂不做讨论。

视图分层

Tangram以一棵深度为3的树形结构构建视图：

• 根节点是Tangram View。Tangram View是Tangram的最终产物，与使用者直接交互的接口，一个View实例。
• 第二层节点被定义为布局。布局是一个起到容器作用的View实例，被要求遵守Tangram布局接口规范。一般来说一个布局会独占Tangram View的一行，多个布局依次向下排列。此外还会有特殊布局，如：浮动布局，是漂浮在屏幕上的一个布局，可以被拖动到任何位置。（访问Tangram主页 - 内置布局支持，了解更多布局）
• 叶子节点是组件。组件就是要展示业务信息的View，是Tangram中的原子View。相比布局而言，开发一个组件的限制要小很多，只需要实现少数几个方法即可。把任意一个自定义的View转化为Tangram组件都非常方便，这也是Tangram所倡导的：把任意正在使用的视图组件快速转化为Tangram视图。

Tangram View

Tangram View作为整个体系的核心产物，是基于上文提到过的LazyScrollView（iOS）和VLayout（Android）开发的。其最主要的作用是在运行时处理上述三层结构中组件的回收和复用。

Tangram View的回收和复用基于一个双索引结构。在渲染准备期需要提前知晓界面中全部叶子节点的尺寸和相对根节点的相对位置，给予位置和尺寸信息构建两个索引：所有组件顶部相对位置顺序的倒排和底部相对位置的倒排。当整个界面中出现组件的增减或位置变化，都需要调用一次Reload操作重建索引，当然创建索引过程采用了效率较高的排序算法。

渲染初始状态或屏幕发生滚动后，Tangram View会拿到当前屏幕的可视范围相对根节点的坐标，并快速在上述双索引结构中找到处在可视范围内的组件集合。然后，可视组件集合与当前存活组件集合分别相减就可以得到需要构造的新组件和可以回收的旧组件。先把旧组件标记为可被回收（注意：这里除了标记，不做任何其他操作），加入复用池，再遍历新组件集合：看复用池里有没有同类型组件可以被复用，若没有则调用工厂构造一个新的。

Tangram Bus

Tangram Bus是Tangram提供的一个事件总线，主要为了避免各个模块为了需要相互通信而造成耦合。Tangram Bus的设计思想与常规的事件总线设计大同小异，使用方法也是采用监听模式：需要响应时间的模块注册一个监听方法到总线，而其他模块产生响应事件后会通知总线，总线则会调用监听方法。这里通过两个例子来说明Tangram Bus的作用：

• 跳转操作：界面的跳转逻辑是有Controller层负责的，而触发点击的一定是组件。为了避免组件和C层的耦合，C注册一个跳转的监听跳转事件的方法到总线，而组件发生需要跳转的操作时，会抛一个跳转事件到总线里，并在事件中带上跳转必需的信息。
• 索引重建：上文提到组件位置或尺寸发生变化需要触发索引重建，所以Tangram Core会注册一个方法监听位置或尺寸变更事件，当组件或布局发生变化则抛一个响应事件到总线。

Tangram AC

主要目的

Tangram AC是一个后端系统，是一个App容器，主要目的是通过规范化的开发模式打破后端开发在流程和环境上的壁垒，并通过容器本身的性能和稳定性保障绕过经验壁垒，给前端工程师一个直接开发后端逻辑的机会。

在传统的开发模式里，一个功能的开发流程至少要包括：接口约定、Mock数据和数据联调，三个需要前后端协作的过程，而且每个过程都会消耗大量资源，而且在我看来这样的消耗是完全没有意义的，不产生价值的。另一方面在现在的产品形态里对动态性要求越来越高，大量逻辑后移，客户端越来越薄。作为直接接触用户的前端开发，对整个产品逻辑的控制却越来越少，给技术驱动的产品创新造成了巨大障碍。

那么问题出在哪里？就是被上述提到过的流程、环境和经验的壁垒区分开来的前端和后端。所以打破这种壁垒，让听到炮火声的前端开发有更多的逻辑控制权，同时把后端开发从无聊的结构转换，数据拼装中解放出来就显得意义非凡。Tangram AC就是基于这样的想法诞生。

流程设计

TAC把每一个独立运行的逻辑称为一个服务，多个服务组成一个应用对外提供数据服务。

TAC的每一个服务有一个独立的源码仓库，开发者提交服务源码后在控制台针对特定分支提交打包请求，TAC将把制定源码打成一个可执行的服务包。开发者通过控制台把选定的服务包发布到日常或预发环境中进行测试和联调，通过TAC强制验证后，可以把这个包发布到生产环境直接对线上应用提供服务。

在TAC的运行时，有一套完整的质量监控设施，实时监控整体容器的和各个服务的状态，保证整体容器运行正常。此外，为了保障核心应用的稳定性，TAC还提供了独立部署的机制，也就是说部分核心应用所涉及到的服务允许被独立部署的一个物理集群上独占资源。如此既保证了核心服务的稳定性，不会被稳定性级别更低的应用影响，也保证了核心服务在大量占用资源时不会拖慢其他应用。

Tangram OP

Tangram OP是整个体系最重要的控制台，上文中提到过的布局排布方式等都可以通过OP GUI的方式配置完成，也就是说在部署了OP的体系中，可以直接通过配置生成一张页面结构。并通过OP提供的数据关联功能关联到AC的某个数据服务上，组成一个完整的产品。

关于OP的具体实现不涉及到Tangram的接入，更多是为了提升使用效率，所以在这里不做赘述，日后Tangram OP开源后将做更多介绍。

结语

Tangram旨在打造一个常规产品开发新模式，传达一个以创造价值为目的的开发理念，建设一个开发生态：

• 不为了创新而创新，而为了创造价值而创新，工程师要在有价值的方向上追求极致，而在仅仅能娱乐自己的方向上适可而止
• 让前端和后端做应该做的事，做更有价值的事，不因某些壁垒而无法更好的创造价值