本文是2018年 Weex Conf 中議題《Weex + Ui》的內容文件整理，主要給大家介紹飛豬 Weex 技術體系從無到有的過程，包括 Weex Ui 元件庫的開發和發展，重點分享在 Weex Ui 層建設的一些經驗。
文章較長，首先放上 Weex Ui 的開源地址，歡迎大家提PR，同時也可以通過 Star 來表示你的喜歡。
Why Weex ?
Weex vs H5
我們為什麼選擇Weex作為我們首要的跨端開發技術呢？寫過H5的同學肯定會被它的簡單高效、釋出即更新、一條URL可適配多端等這些快所吸引，但寫過 Native 的同學肯定也會被 Native 的富互動、效能體驗、可呼叫原生能力、可管理記憶體等特性給我們的業務帶來更好的體驗。
快和體驗想同時兼得
但是很多時候，我們會想將H5的快和Native的體驗兼得，飛豬前幾年也一直在這個方向上面探索。
包括最開始的 Hybrid 開發，通過 Bridge 提供部分 Native 能⼒來提升 H5 體驗，譬如我們在H5裡面可以直接獲取App的定位資訊、使用相機、播放視訊、導航跳轉等能力，業界也有Cordova、Ionic、Meteor這些成熟的方案。
還有利用離線包體系通過提前將資源⽂件下載，訪問時路由攔截載入本地資源，讓我們的H5頁面可以達到秒出、動態更新、弱網可用效果，內部有手淘Zcache、飛豬信鴿、支付寶九州這些成熟的系統。
等到了16年左右，跨平臺開發技術逐漸火起來後，一種全新的開發思路吸引這我們，也即用JS來寫Native，⽤ Web 的開發體驗構建⾼效能、可擴充套件的 Native 應⽤，同時真正獲取上述所說的快和體驗。
業務對比分析
那麼為什麼會選擇 Weex 呢？其實和飛豬業務特點很有關係，同時又可以很好解決這些痛點。
飛豬業務迭代速度快，也需要快速上線；同時很多時候景點和海外弱網使用，同時要體驗良好；其中最重要的一點是多容器接入，適配飛豬、手淘、天貓、支付寶，也即我們一次重要業務的開發需要一個iOS、一個Android同學來開發兩端，同時由一個H5同學來開發相容手淘、支付寶、UC的 Web 版本，也即一次業務釋出涉及到多端同時開發、上線。
Weex 其實很好的解決了上述的一些問題，包括在飛豬、手淘、天貓 Weex環境下完全 Native體驗，同時Bundle 資源大小較 H5 小很多，加上富互動體驗、長列表效能好非常適合商品列表頁面和雙十一場景，最重要的是真正讓我們從3個人的開發減少到了1個人，其他2個人可以去做更多有意義的事情。
接下來我們可以從下面這個展示來看Weex和H5業務的一個展示、資料對比，詳細可看此錄製視訊>>>
這是一個業務邏輯複雜的頁面，包括篩選、排序、日曆選擇、收藏、長列表、業務邏輯也很複雜的頁面，重構成Weex以後，我們首屏可用時間降級68%、Bundle大小直接減少了73%，由於體驗變好變快、讓我們頁面轉化率居然提升了14.5%。
也上也就是我們為什麼選擇Weex作為我們跨端開發的一些重要原因，接下來介紹的是飛豬的weex 技術體系。
飛豬 Weex 技術體系
架構圖
可以從底層一直往上看，底層由我們APP的Framework / Libraries / OS Kernel等組成，我們在Weex的上下層和手淘、天貓一起設計出一套統一的Api設計，包括介面請求、資料埋點、路由跳轉、網路狀態、支付功能、導航欄定製等這一系列的通用服務，在 Weex 上面我們封裝了Weex Ui元件庫、業務元件庫、UPX搭建營銷模組、還有抹平多端差異的 Util 函式庫，這樣在我們上層可以長出我們眾多的業務。
由於 Weex 在我們這邊和 H5 一樣，都是當做頁面來發布、而不是一個 View 裡面寫很多子View來組織，同時也很不建議大家使用vue-router來管理，更多的使用多頁面來跳轉體驗會更好。
說到構建釋出流程，我們統一通過Clam來對我們專案進行初始化、構建、debug、預發、釋出等工作，同時在上線方面直接通過Awpp命令來直接釋出頁面到CND，同時可以通過信鴿將離線資源推送到APP，運營同學也可以直接通過搭建的方式將頁面釋出出去。
Weex 頁面如何在飛豬、手淘、支付寶進行多端投放 ?
那你可能會問 Weex 頁面如何在飛豬、手淘、支付寶進行多端投放呢 ? 這裡有兩種方式，第一種為通過前端 URL 引數決定渲染為 Weex 還是 H5
xxxx.html?_wx_tpl=xxxx.js：前面為降級時的 H5 地址， 後面 _wx_tpl 帶的引數代表 Weex JS 地址， 當容器發現 URL 帶有 _wx_tpl 引數時, 會下載後面的 JS 地址然後用 Weex 容器渲染。
還有一種為通過服務端返回內容決定渲染為 Weex 還是 H5：
xxxx?wh_weex=true：前面可以是 JS 地址也可以是 H5 地址，後面是固定的引數 wh_weex=true，當容器發現 URL 帶有 wh_weex=true 時, 會請求前面的 xxxx 地址， 如果發現響應的 mime type（HTTP header content-type）為 application/javascript，則使用 Weex 渲染返回的內容， 否則使用 WebView 渲染成 H5。
飛豬 Weex 業務大盤
Weex 並不是像外界某些人傳言說沒有什麼公司在使用Weex的，反而是超過你的想象，以上是我們這邊17年12月份前的一個相關weex頁面的一覽，大家可以在飛豬、手淘、支付寶裡面找到這些頁面，均是一份頁面同時投放到多端的。
什麼業務適合用 Weex ？
包括眾多的營銷業務、首頁、頻道、搜尋列表、正向流程、簡單詳情、富互動頁面都是很適合使用Weex來開發的，同時在我們這邊也有一個對應的原則包括 展示類專案優先使用 Weex、重構/新專案優先使用 Weex、深度垂直類目嘗試使用 Weex。
Weex 不適合複雜場景 ？
大家可以看下如下這幾個場景的視訊展示>>>
大家可能會覺得Weex不適合複雜的場景，其實也不一定，通過很多方式是可以做到複雜場景的支援，包括雙11超長列表滾動，30多屏資料，快速滾動很順滑。
同時包括邏輯異常複雜、多元件的國際機票列表頁，Weex 同樣也可以勝任；包括圖3富互動的使用場景，粘手效果的絲滑拖動，快速滑動，動態隱藏頭部等等功能都是可以做到的。
通過在我們這邊很多業務場景的使用 Weex 踩坑 最佳實踐的積累，其實有很多東西可以沉澱下來 通過封裝的方式給後續其他業務使用，這樣讓後面的業務可以達到快速生產，這也是我們建立Weex Ui 元件體系一個很大的原因。
Weex Ui 的發展和開源
為什麼要建立 Weex Ui 元件庫體系 ？
- 在引入 Weex 初期，通過 Weex Ui 讓未接觸 Weex 的同學對其編寫有借鑑作用
- 提煉業務中的公共元件，便於直接引用，提高大家開發效率
- 業務規範、視覺規範、最佳實踐的及時同步
- 將 Weex 業務中的疑難雜症通過元件封裝，對外只暴露簡單邏輯
Weex Ui 一覽
經過一年多的建設，我們一步一步將 Weex Ui 優化，整理，最終於20170930進行了開源，通過下圖可以看到 Weex Ui 是怎麼來的
目前 Weex Ui 元件庫包括7大類31個成熟的元件，同時並不是直接開源給大家使用，而是在內部已經使用了1年多後穩定後開源給大家使用，大家可以通過手淘、飛豬、任何瀏覽器掃碼進行預覽
同時一個開源庫的文件其實是後續發展中使用者是否能快速上手的一個很大因素，Weex UI 包括元件說明、使用規則、Demo展示、詳細使用API、升級文件等等，可以讓你快速使用。
Weex Ui 是不是隻適合電商體系呢？
近期我們隊 Weex Ui的使用者做過一次問卷調查，結果讓我們很驚喜，並不是只有電商在使用，還很很多其他的體系在使用，包括工具類、企業應用、文娛、自媒體、新聞這些其實都是有使用的。
元件化搭建你的 Weex 頁面
很多時候基礎建設，其實為了給業務開發來加速，譬如接下來這個飛豬專線的頁面就是通過我們的Weex Ui元件庫來搭建起來的
然而基礎基礎只能夠解決通用元件的問題，其實還包括業務元件這一塊，也即上圖中的your-item元件,也即我們下面要說的 Weex 業務元件化
除了基礎庫，在 Weex Ui 層還可以做什麼 ？
Weex 業務元件化
業務元件庫更多是前端、後端、設計師之間的一個“約定”，通過一定規範共同讓業務元件變得可複用。也即Weex程式碼中直接引入此元件，直接插入後端返回的原始資料，就可以生成設計師所設計出的商品卡片，最終可以做到支撐任意 Weex 業務模組 投放到 任意 Weex 頁面 中 任意位置 的能力。
那麼應該怎麼做呢？
可以自動化測試 Weex 嗎 ？
答案是可以的，之前通過macacajs測試框架和Weex結合來弄，通過自定義一連串的手勢、事件，最後通過用json來表明執行的順序，可以做到，詳細可見視訊地址>>>
1、安裝app 2、自動開啟native頁面 3、登入，自動輸入 4、自動測試飛豬度假首頁，包括點選、跳轉、滑動、下拉重新整理等操作 5、自動測試飛豬專線、包括左滑、右滑操作 6、自動測試Weex Ui，包括開啟元件、點選互動邏輯 7、自動各個頁面執行截圖，並將測試情況郵件給測試方
Weex 無障礙優化
Weex 其實也是支援無障礙的，也即讓盲人在最短的時間內通過最快的方式找到自己想要的資訊。
同時當盲人訪問我們Weex頁面時候，讓他們對 Weex 是可感知的、可操作的、可理解的、同時頁面也是魯棒的。譬如如下這個演示>>>：
無障礙在Weex實現起來是很簡單的，譬如如下實現：
飛豬 Weex 雙十一效能優化
每年的雙十一也就是我們Weex的一個戰場，幾乎所有會場頁面均由Weex實現，如何讓使用者絲滑的逛我們的頁面呢？期間我們也將之前很多經驗包括優化技巧放到了雙十一的會場頁面，包括一些經驗的整理。
回到開源
其實 Weex 可以在很多很多地方使用，包括各種應用場景，這也是我們開源Weex Ui 的一個很大原因，給大家更多 Weex 可實現功能的輸入，最佳實踐實現的參考。
同時外部開發者也急需要一套成熟元件庫來提高開發效率。
從20170930開始，我們一直在弄Weex Ui 的開源發展，包括共建 weex-toolkit 讓其更好支援Weex Ui、欠缺元件的補全 + 現有元件的增強、繼續擴充套件邊界 + 輕舟解決方案 UI 庫、引入更多富互動體驗 + 元件的無障礙優化、簡易的使用方式 + 詳細的中英文件等等工作。
其實更多的是想大家一起參與進來，共同促進我們 Weex 的發展。
說到共同促進，那麼你可以做什麼呢？ 其實可以做很多很多事情
晚上圓桌會議關於 Weex 元件方向討論總結
1. Weex 原生元件的封裝應該注意什麼？
- 通用性，只有多個業務同時在使用，同時具備可抽離性特性的元件，譬如Video/TabBar/TitleBar/ImageUpload 這些在 Native中成熟的元件
- 穩定性，Native 元件不像 weex 上層的元件可調節性大，所以需要注意好 Native 元件一定需要沒有Bug，防止修復和更新麻煩，同時 Native 元件一開始應該將大部分情況做成可配置化，防止頻繁更新，導致需要適配很多版本
- 原子性，不建議一個元件同時做很多事情，應該是單一的功能，然後通過搭配的方式來得到更多功能
2.weex 元件開發和實踐過程中的一些經驗？
- 811原則，預設80%的功能應該是不需要使用者配置很多引數，10%的地方使用者可以通過配置一些引數來達到目的，10%的稀有情況可以暫時不考慮，可能這裡會花費很多時間開發，所以可以等到有業務需要使用時候，再更新上去
- 統一收口原則，為了避免後續元件變成一個大雜燴，後續迭代視覺互動、新功能的增加需要將通用性考慮進去，這裡需要一個人統一來收口、開發維護此元件，可以避免很多“業務特性”來干擾元件的可用性
- 效能體驗的優化，Weex 元件比頁面的編寫更應該保證他的效能體驗
- 信任機制：很多時候別人使用你的元件一個很大原因是由於相信你的元件沒有問題，是穩定的，同時後續會常常維護的
3.大家認為Weex Ui元件還缺少什麼？
- 缺少一些彙集起來使用的場景，目前單個元件的使用文件已經詳細說明，但是對於多個元件的一些使用，或者頁面層面的開發缺少相關案例，後期需要逐步補上weex-ui-demo
- 主題配置靈活性上需要考慮進行，目前更多是通過引數配置的方式來更改主題顏色，其實是可以通過一個統一外部引數的配置來使它修改
4.未來跨端開發會是怎麼樣的？
- Native的佈局方式需要向H5的開發靈活性學習，逐步使用自動佈局來實現，同時引入彈性思路開發，避免絕對計算
- 資料繫結方面會越來越便捷，譬如和MVVM思路一樣，資料變化後，檢視立馬修改，而不是手動去觸發
More
大家可以通過用釘釘掃一掃如下二維碼，大家一起來討論交流：
- 本次分享PDF檔案: 《 Weex + Ui 》
- 官網地址：alibaba.github.io/weex-ui
- Github地址：github.com/alibaba/wee…
Please feel free to use and contribute to the development.