在2017年1月12日
weex conf 2017上，來自手機淘寶移動平台weex團隊的凝砺結合淘寶實際業務分享了weex動态化方案和雙十一實踐，本文先介紹了weex的整體架構，接着重點分享了weex在雙十一會場上的實踐，最後談及了weex的業務支撐，包括aliweex等。
以下為精彩内容整理：
初始weex
weex是一套高性能跨平台移動開發架構，最大的優勢是解決了頻繁發版和和多端研發兩大移動開發痛點。一套代碼完美适配ios、android、html5和web等多端，極大的提升開發效率同時又保證了使用者體驗。
weex分為三層。最上層是dsl，早期類似于html、css、javascript這種語句的表達，讓前端熟悉表達方式建構頁面；中間層是virtual dom，virtual dom工作在framework的解析引擎上，自上而下驅動底層的三端實作；底層分别架構了ios、android、h5的renderengine，從整個效果來說，weex是三端一緻的解決方案，最終各個系統平台上的ui基本上保持一緻。
上圖為延伸的前後端協同圖，後端主要幫助我們如何從weex源檔案建構出js bundle，經過transformer進行轉移，js bundle針對的是業務代碼，js bundle會部署到後端伺服器上；前台同樣是三端，可以實施向後端伺服器請求js bundle，并運作在js framework上，底層的renderengine是架構在ios原生的jscore，engine上我們用了v8，它會有一個雙效通道，可以通過calljs、callnative來發出指令。
圖中紅色标記的是weexkernel，主要包含ui系統，ui系統中有很多重要的元件，比如list、scroller、slider、image等15種元件，後續我們會進一步擴充元件，同時可以看到，在每個components上還涵蓋生命周期、動畫和手勢，能夠讓頁面變得更加靈動；基于單個頁面有導航navigator，它能夠幫助我們進行頁面流轉；不同頁面之間需要進行互動，我們提供了全局事件的方式；同時我們結合了network功能，data store進行資料存儲。
應用級架構下面是module，功能的擴充。然後下面做的是整個性能的把控，右側部分為适配層，主要是網絡層圖檔庫的适配、本地的開發環境等。
雙十一會場實踐
2016年雙十一會場首次大規模啟用weex，總計淘寶+天貓共1754張會場頁面，weex占比99.6%，約為1747張；在流量最重要的天貓主會場入口，5個tab都是用weex進行實作的，同時，在天貓和淘寶的分會場，基本做到零降級。
當然，雙十一也并不是一帆風順，在用weex設計雙十一會場時也遇到了一些困難。大緻分為四個次元：頁面互動複雜、氛圍設定動态化、秒開與性能、容災機制。
<b>會場架構互動篇</b><b></b>
非push方式架構tab可以進行切換，滑動流暢，頂部有電梯幫助營運定位到每一個樓層，還有搜尋框，每個tab的浏覽曆史記錄要被儲存；主會場——分會場——主會場時，互動方式采用push方式，需要持續打開視窗。這樣互動方式的難點在于記憶體治理、前向加載實時性。
在這個基礎上，我們怎樣設計呢？對于主會場這樣一個特殊子產品，采用單執行個體，從左上角手淘首頁進入搜尋框主會場，跳轉到女裝，女裝再跳轉到男裝，男裝通過底部導航又可以切出主會場定位到必搶頁面，此處實際上共用一份執行個體；當從必搶進入女裝會場時，weex渲染容器數量不超過5個，保證記憶體開銷可控；前向跳轉實時更新，後向傳回儲存曆史記錄。
<b>會場架構氛圍篇</b><b></b>
雙十一分為主會場氛圍和分會場氛圍。主會場分為造勢期、預熱期、正式期，造勢期需要保證營運能夠實時配置效果，需要支援動态可配置性；分會場氛圍涉及各個行業，每個行業利益點不一樣，氛圍需要根據業務來定制。其中，動态性、實效性以及加載性能都是難點。
會場架構的本質是一個可以用來抽象化描述的架構，底部有tab，上面有導航，中間有可配置的取款，将模闆和與之關聯的互動邏輯通過預置的方式預置在本地，也就是從服務端去請求js bundle時，會略過網絡請求，僅僅需要本地渲染，架構模闆與資料分離，模闆預加載，資料走投放。
主會場氛圍是核心配置驅動（導航欄設定，獨⽴tab樣式以及url投放），分會場氛圍業務調用navigatormodule api，更加靈活。
<b>會場架構性能篇</b><b></b>
我們需要在會場架構中，同時加載5個200坑位的普通頁面，1個全景圖會場頁面，1個直播會場頁面。
通過壓測方案如下：
1. 主鍊路（首頁-店鋪-詳情-購物車）做一遍操作，讓記憶體緩存占滿，記錄記憶體值m0;
2. 進入weex頁面，待頁面全部加載完成，跳轉至下一個weex頁；
3. 重複步驟2，讓所有的測試場景頁進行壓棧；全景圖-p1p2p3p4-直播-p1p2p3p4。
得出結論：
控制單頁面坑位的個數（150）；
減少頁面元素的層級；
android低端機全景圖降級。
<b>會場架構保障篇</b><b></b>
在特定的場景下，weex需要提供降級的能力，來保障業務。
降級預案如下：
1. weex渲染容器降級；
2. weex頁面服務端配置降級。
現在在業務上應用比較多的是weex頁面根據作業系統、應用、weexsdk版本進行降級。依賴jsframework的降級能力，在容器渲染的過程中會經過jsframework的解析建構，在解析時會比對版本規則，如果命中規則即執行降級，反之正常渲染。
業務支撐
weex更多的服務于手淘等超大型用戶端，在未來的一年中，我們可以看到在集團内部有越來越多的業務對接weex。
業務支撐中心集中在五個方面：降低接入成本、優化開發體驗、更完善的性能監控體系、更好的頁面搭建平台和優化容災機制。
<b>業務接入</b><b></b>
aliweex通用子產品或邏輯聚合：包括環境初始化，weex子產品或元件的注冊，weex
渲染主流程，降級判定規則等；同時，aliweex實作了規範和标準化治理：适配層協定标準化定義，提供預設的接口實作。包括網絡庫、圖⽚庫、性能監控等。
<b>性能監控</b><b></b>
性能監控也很重要，需要通過資料進行不斷的調優，以及異常捕獲，具體包括以下兩點：
1. 性能資料的實時采樣:
• js framework加載時間
•
網絡傳輸加載時間
首屏渲染時間
2. 異常或渲染錯誤的捕獲:
資源請求失敗錯誤
• js 運作時異常
<b>搭建平台</b>
搭建平台步驟分為以下三步：
1. 從整體進行元件化分離；
2. 定義每個元件；
3. 把元件有機組合起來。
<b>開發體驗（</b><b>devtools</b><b>）</b><b></b>
devtools友善我們做兩件事：
1. 斷點調試；
2. inspector，不管native view
element，還是dom element，或者network和console log。
有了這些工具的輔佐，才有今天雙十一順利的排查問題，前端才能順利的定位頁面布局。