Weex Ui - Weex Conf 2018 乾貨分享_ZenDei技術網路在線

本文是2018年 Weex Conf 中議題《Weex + Ui》的內容文檔整理，主要給大家介紹飛豬 Weex 技術體系從無到有的過程，包括 Weex Ui 組件庫的開發和發展，重點分享在 Weex Ui 層建設的一些經驗。 ...

　　本文是2018年 Weex Conf 中議題《Weex + Ui》的內容文檔整理，主要給大家介紹飛豬 Weex 技術體系從無到有的過程，包括 Weex Ui 組件庫的開發和發展，重點分享在 Weex Ui 層建設的一些經驗。文章較長，首先放上 Weex Ui 的開源地址：https://github.com/alibaba/weex-ui

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 技術體系。

可以從底層一直往上看，底層由我們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 可實現功能的輸入，最佳實踐實現的參考。

同時外部開發者也急需要一套成熟組件庫來提高開發效率。

https://github.com/alibaba/weex-ui

從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 組件比頁面的編寫更應該保證他的性能體驗
信任機制：很多時候別人使用你的組件一個很大原因是由於相信你的組件沒有問題，是穩定的，同時後續會常常維護的