Weex + Ui - Weex Conf 2018

時間 2019-11-16

標籤 weex conf 简体版

原文原文鏈接

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

文章較長，首先放上 Weex Ui 的開源地址，歡迎你們提PR，同時也能夠經過 Star 來表示你的喜歡。html

github.com/alibaba/wee…前端

Why Weex ?

Weex vs H5

咱們爲何選擇Weex做爲咱們首要的跨端開發技術呢？寫過H5的同窗確定會被它的簡單高效、發佈即更新、一條URL可適配多端等這些快所吸引，但寫過 Native 的同窗確定也會被 Native 的富交互、性能體驗、可調用原生能力、可管理內存等特性給咱們的業務帶來更好的體驗。vue

快和體驗想同時兼得

可是不少時候，咱們會想將H5的快和Native的體驗兼得，飛豬前幾年也一直在這個方向上面探索。java

包括最開始的 Hybrid 開發，經過 Bridge 提供部分 Native 能⼒來提高 H5 體驗，譬如咱們在H5裏面能夠直接獲取App的定位信息、使用相機、播放視頻、導航跳轉等能力，業界也有Cordova、Ionic、Meteor這些成熟的方案。git

還有利用離線包體系經過提早將資源⽂件下載，訪問時路由攔截加載本地資源，讓咱們的H5頁面能夠達到秒出、動態更新、弱網可用效果，內部有手淘Zcache、飛豬信鴿、支付寶九州這些成熟的系統。github

等到了16年左右，跨平臺開發技術逐漸火起來後，一種全新的開發思路吸引這咱們，也即用JS來寫Native，⽤ Web 的開發體驗構建⾼性能、可擴展的 Native 應⽤，同時真正獲取上述所說的快和體驗。vue-router

業務對比分析

那麼爲何會選擇 Weex 呢？其實和飛豬業務特色頗有關係，同時又能夠很好解決這些痛點。json

飛豬業務迭代速度快，也須要快速上線；同時不少時候景點和海外弱網使用，同時要體驗良好；其中最重要的一點是多容器接入，適配飛豬、手淘、天貓、支付寶，也即咱們一次重要業務的開發須要一個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來代表執行的順序，能夠作到，詳細可見視頻地址>>>

一、安裝app 二、自動打開native頁面三、登陸，自動輸入四、自動測試飛豬度假首頁，包括點擊、跳轉、滑動、下拉刷新等操做五、自動測試飛豬專線、包括左滑、右滑操做六、自動測試Weex Ui，包括打開組件、點擊交互邏輯七、自動各個頁面運行截圖，並將測試狀況郵件給測試方

Weex 無障礙優化

Weex 其實也是支持無障礙的，也即讓盲人在最短的時間內經過最快的方式找到本身想要的信息。同時當盲人訪問咱們Weex頁面時候，讓他們對 Weex 是可感知的、可操做的、可理解的、同時頁面也是魯棒的。譬如以下這個演示>>>：

無障礙在Weex實現起來是很簡單的，譬如以下實現：

飛豬 Weex 雙十一性能優化

每一年的雙十一也就是咱們Weex的一個戰場，幾乎全部會場頁面均由Weex實現，如何讓用戶絲滑的逛咱們的頁面呢？期間咱們也將以前不少經驗包括優化技巧放到了雙十一的會場頁面，包括一些經驗的整理。

回到開源

其實 Weex 能夠在不少不少地方使用，包括各類應用場景，這也是咱們開源Weex Ui 的一個很大緣由，給你們更多 Weex 可實現功能的輸入，最佳實踐實現的參考。

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

github.com/alibaba/wee…

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