上一篇文章介紹了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旨在打造一個常規產品開發新模式，傳達一個以創造價值爲目的的開發理念，建設一個開發生態：
- 不爲了創新而創新，而爲了創造價值而創新，工程師要在有價值的方向上追求極致，而在僅僅能娛樂自己的方向上適可而止
- 讓前端和後端做應該做的事，做更有價值的事，不因某些壁壘而無法更好的創造價值