阿里Tangram框架

image.png

什么是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平台上分别开发了VLayoutLazyScroll两个基础组件,通过一个双索引可见区域组件发现算法,实现了跨父节点组件的高效回收和复用。

参考资料
http://tangram.pingguohe.net/
http://tangram.pingguohe.net/docs/basic-concept/history

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 195,898评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,401评论 2 373
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 143,058评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,539评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,382评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,319评论 1 273
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,706评论 3 386
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,370评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,664评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,715评论 2 312
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,476评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,326评论 3 313
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,730评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,003评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,275评论 1 251
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,683评论 2 342
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,877评论 2 335

推荐阅读更多精彩内容