基於weex的有贊無線開發框架

出於對開發效率和動態化的要求，無線端的開發框架也一直在更新，從 Hybrid、結構化 Native View、React Native、Weex，再到如今正在大受關注的 Flutter。什麼樣的框架纔是適合本身的團隊？不只要有技術追求，並且要考慮實際業務須要。最近，有贊移動選擇了 weex 做爲無線開發框架，搭建了從開發、Debug、構建、發佈、數據一個閉環的流程。本文將對此進行分享。

1、什麼是 weex

Weex 是阿里巴巴開源的一套構建高性能、可擴展的原生應用跨平臺開發方案。首先總結一下 weex 的特色：

1. 頁面的開發目前支持Rax和Vue

   Weex 也不是隻支持 Vue 和 Rax，你也能夠把本身喜歡的前端框架集成到 Weex 中，有一個文檔擴展前端框架描述瞭如何實現，可是這個過程仍然很是複雜和棘手，你須要瞭解關於 js-native 之間通訊和原生渲染引擎的許多底層細節。

2. 一次編寫，三端（Android、iOS、前端）運行

   前提是都集成了 weex sdk，另外視覺表現作不到徹底同樣，有的會有一些差別，須要作一下適配。因此寫 weex 頁面的時候，若是支持三端，便須要在三端都進行自測。

3. UI 的繪製經過 native 的組件，JavaScript 邏輯在 JS 引擎裏運行，二者經過 JavaScriptCore 通訊

   weex 裏使用組件都須要在 native 端註冊，這樣 weex 裏纔可使用，運行的時候經過註冊時記錄的 map 進行查找。weex sdk 內置註冊了一些基礎的組件，包括 list、text、input 等。WXJSCoreBridge 封裝了 JavaScriptCore 實現 native 和 js 之間的通訊。

4. 支持 Native 擴展

   能夠將 native 的 UI 組件封裝成 component，將 native 的邏輯代碼封裝成 module。從而在 weex 裏能夠進行使用。這裏的 natiev UI 組件包括 modal、webview、image 等，這裏的 native 邏輯代碼包括 storage、network 等。

5. 每一個 weex 頁面會被打包成一個 js 文件，weex sdk 將 js 文件渲染成一個 view
   weex 的打包經過 webpack，將每一個頁面打包成獨立的一個 js 文件，weex sdk 會將 js 進行解析，將 UI 部分繪製成一個 view, 再綁定 view 的事件與 js 代碼綁定。

2、爲何要使用weex進行無線開發

1. 效率問題

1）開發的人力成本

若是不算 web 端，一個頁面原本須要 Android 和 iOS 2 我的開發；使用 weex 後只須要 1 個開發頁面。

2）開發的編譯速度

隨着項目漸漸變得龐大，Android 項目一次編譯須要 2-3 分鐘，機器很差的還須要 10 分鐘，iOS 可能會快一點，也須要 1-2 分鐘。使用 weex 後，界面修改，只須要十幾秒。

3）測試效率

提測以後，發現 bug，修復完成，測試總須要從新下載一個包進行安裝；使用 weex 後，跟原生無關的 bug，只要測試重啓 App 就能夠進行驗證。

2. 動態化

weex 頁面最後打包完是一個 js 文件，只要能作到動態下發 JavaScript，那即可以實現動態化，能夠熱修復，甚至能夠熱部署，徹底替換或者新增頁面。

3. 成熟度

在 2016 年阿里雙十一中，Weex 在阿里雙十一會場中的覆蓋率接近 99%，頁面數量接近 2000，覆蓋了包括主會場、分會場、分分會場、人羣會場在內幾乎全部的阿里雙十一會場業務。阿里雙十一主會場秒開率97%，所有會場頁面達到 93%。
2016 年 12 月 15 日，阿里巴巴宣佈將移動開源項目 Weex 捐贈給 Apache 基金會開始孵化。
2017 年，weex 在阿里業務裏增加以下圖，來自 WeexConf 2018。

4. 接入成本

通過實踐，一個移動端開發，一週時間就能夠開始進行使用 weex 進行業務開發。

3、如何使用 weex 進行無線開發

weex 實際上是一套方案，各個流程不少東西須要本身建設，把它建設得讓小夥伴能夠以較小成本開始使用 weex，把它建設得融入已有的系統。這方面，咱們目前作了下面這幾個方面，還任重道遠。

1. 開發工具 zweex-toolkit

這是一個腳手架工具，基於 weex 官方的 weex-toolkit，用於新建 weex 工程，目前只支持 vue。

隨着頁面的增多，業務的複雜，工程會慢慢變得龐大，每次運行的時候若是所有頁面都運行起來比較慢。爲了解決這個問題，使用 zweex-toolkit 建立建的工程模板支持運行的時候，支持只運行指定目錄下的頁面，只要在 npm start 後加上參數便可，如：

npm run start hi,helloworld

這樣就表示只運行 hi 目錄下和 helloworld 下的頁面。
另外，咱們支持：

• 新增頁面zweex page
• 開啓調試zweex debug

2. ZanWeex SDK 的實現

官方 weex sdk 作的事情，就是輸入一個 js 文件，而後返回一個view。考慮到每一個應用的路由和個性化的須要，這一點，ZanWeex SDK 沒有作其餘工做，也仍是返回了一個view，業務方能夠根據本身的須要將view添加到本身想要展現的地方。ZanWeex SDK 作的事情主要有以下幾方面：

1）支持下發配置，支持動態化，能夠完成整個頁面的替換

weex 頁面打包後的結果是一個 js 文件，因此能夠進行下發進行動態更新，那麼就須要有一份配置，來關聯頁面路由和 js 文件的關係，因而咱們設計了這樣的數據結構：

h5：頁面路由地址，能夠直接使用發佈平臺生成的 h5 地址

js：打包後的 js 文件地址

version：支持的最低 App 版本，由於新頁面若是須要 native 擴展，那就須要發佈新版本進行支持

md5：爲了校驗完整性，咱們在配置裏添加每一個 js 文件的 md5。

2）支持多模塊獨立配置，互不影響
一個App裏會有多個模塊，每一個模塊可能由獨立的團隊進行負責，因此爲了減小耦合，咱們將配置獨立，每一個模塊能夠獨立管理本身的配置，獨立接入weex，不依賴於宿主App。

3）預加載頁面模板，支持頁面模板緩存和配置緩存

• 若是沒有緩存，每次都從服務端拉取頁面模板，那麼是不可能達到秒開的，跟沒有作緩存的H5頁面就區別不大了。咱們SDK會預加載頁面模板到本地，打開過的頁面會緩存到內存。這樣渲染的時間就更接近原生的渲染時間了。

4）支持開發時的hot reloading，前端開發般的體驗

• 若是沒有hot reloading，那麼每次修改完頁面，都得退出頁面從新進入。爲了省去這個操做，hot reloading是必須的。
• weex 工程裏本地開發時候，經過webpack-dev-server來啓動一個websocket，zan weex sdk 打開一個weex頁面後，去與它創建鏈接。webpack-dev-server將工程的編譯狀態發送給ZanWeex SDK，當接收到渲染完成的指令時，就從新渲染頁面，從而達到 hot reloading的目的。

5）支持頁面的適配，提供環境變量
ZanWeex SDK 會提供如下四個變量共 weex 頁面使用，方便完成頁面配置。

• 容器的高度：weex.config.yzenv.viewHeight
• 容器的寬度：weex.config.yzenv.viewWidth
• 狀態欄高度：weex.config.yzenv.statusBarHeight
• 底部欄高度（針對iPhone X，其餘爲0)：weex.config.yzenv.bottomHeight

6）開發階段日誌的查看
在開發階段，weex sdk 源碼裏輸出的日誌以及 js 裏經過 console.log 輸出的日誌，還有 js 運行的報錯，都只能經過 XCode 和 Android Studio 進行查看。這對於一個只瞭解一端的開發人員是很是不方便的。因而咱們作了一個入口，在打開 weex 頁面的時候，會顯示該入口，點擊便可查看所輸出的日誌。

7）參數傳遞
正向傳參：從 A 頁面跳轉到 B 頁面，參數傳遞是開發過程確定會碰見的一個場景。SDK 對外提供的渲染接口 renderByH5 的參數包括 url，params，data。業務方進行渲染的時候，能夠將參數直接跟在 url 後面，或者經過 params、data 傳入，不一樣方式，取的方式也不同：

• url 後面的參數，會傳入 data，weex 頁面裏直接在 data 裏定義參數就會自動賦值；
• params的參數，在 weex 頁面裏能夠經過 weex.config.name 來獲取；
• data 傳入的參數，獲取方式同第一種。
• 反向傳參：從 B 頁面返回到 A 頁面的時候，攜帶參數返回也是很常見的一個場景。SDK 提供了統一的存儲類 ZParamStorage 來臨時存儲參數。頁面 B 要返回的時候先把數據存入存儲區，A 頁面顯示的時候再從存儲區獲取，而後清空存儲區。
• 非跳轉的參數傳遞：weex 頁面之間，能夠採用 BroadcastChannel 進行傳參，weex 與 native 之間的傳遞能夠經過本身封裝 Module 進行實現。

3. 頁面的開發

前面有提到，weex 的頁面目前能夠採用 vue 或者 Rax 編寫。對於 Vue 和 Rax 的語法這裏不作陳述。這裏主要總結了容易在實際開發中卡住小夥伴的幾個問題。

1）如何判斷一個頁面是否用 weex 來實現？

能夠認爲全部的新頁面均可以採起 weex 來開發，區別在於這個頁面使用的 native 能力有多少。能夠經過自定義 Module 來調用 native 的能力，經過自定義 component 來使用 native 的組件；

2）何時須要自定義 Module？

• 須要原生的能力的時候，好比：

  • 要調用系統選擇圖片的接口
  • 調用打電話、發短信的功能
  • 打開其餘應用

• 調用已有的業務邏輯，好比：

  • 加密、解密邏輯
  • 登陸邏輯

3）何時須要自定義 component？

• 若是一個組件已經使用 native 實現，爲了保持統一一致，那麼能夠將原有的組件封裝成 component
• 若是一個組件不能使用 weex 實現，好比地圖組件、超長圖顯示等

4）多個彈層的佈局如何實現？

weex 頁面渲染的層級，是從上而下的，越在下面的佈局，顯示越上層。因此要做爲彈層的佈局，就把它放到最下面。

5）頁面的動畫如何實現？

官方 weex sdk 已經封裝了 animation 的 module 能夠直接使用，複雜的動畫可使用 BindingX 實現。

6）weex 的代碼如何複用？

代碼均可以抽離出組件。

• 做爲一個 UI 組件，抽離成一個組件，向外暴露屬性參數和事件接口；
• 做爲獨立的 js 函數，抽離成一個 js 供其餘頁面引入；
• css 樣式也能夠抽離成一個 css 文件，供其餘頁面引入；
• 若是包含多個組件形式，能夠經過 mixins 來引入。

4. 構建和打包平臺

咱們開發了以項目爲單位的構建平臺：

• 每一個項目能夠添加多個分支，能夠是不一樣倉庫的分支。由於一個項目有多是跨團隊跨模塊的，可是須要一塊兒發佈。
• 構建經過 webpack 構建，構建以後，支持發佈線下存儲和線上 cdn

咱們還開發了以應用爲單位的 weex 發佈平臺：

• 這裏的應用是一個抽象概念，不是傳統的「應用」，能夠理解成模塊
• 業務方能夠在構建平臺構建完成後，一鍵跳轉到發佈平臺進行發佈，除了須要第一次填寫最低支持的版本號，其餘均無需操做。
• 發佈平臺支持灰度發佈、全量發佈和回滾。
• 發佈平臺會展現 weex 在端上的使用狀況，渲染時間、渲染錯誤、下載時間等

4、遇到的問題以及解決方案

在開發過程當中，不少問題，能夠經過閱讀源碼來解決，好比：

• 使用 iconfont 的時候，是否已支持緩存?

  答：已支持，包括內存緩存和文件緩存，內存緩存使用 familyname 來作 key，文件緩存使用 md5(url) 來作本地文件名

• module實現的函數能不能返回參數？

  答：module 的函數氛圍 UIThread 和 JSThread，JSThread 對於 js 線程來講是同步的，支持直接返回參數；UIThread 對於 JS 線程來講是異步的，不支持直接返回參數，只能使用 callback

另外，不少常見的問題，咱們已經在 ZanWeexSDK 進行了解決，包括實現動態化、多模塊的支持、緩存管理、Hot Reloading、日誌查看、頁面適配、參數傳遞等。

此外，還會有一些常見的問題，在此羅列一下：

1. 配置的更新機制是怎樣的？更新失敗，如何打開 weex 頁面？

   答： 配置的更新接口開放給業務方調用，由業務方決定何時調用更新接口；SDK 裏作了三種處理，來儘可能保證配置能夠更新成功：

   1）配置接口拉取失敗後，會有三次重試；

   2）網絡從無網變成有網時，sdk 會檢查配置是否已拉取，若是未拉取就主動拉取

   3）容許業務方內置配置和 js 文件，當拉取失敗後，SDK裏會從內置配置裏讀取

2. 配置的版本管理是怎樣的？

   答：配置每次發佈的時候，都會指定該發佈支持的 App 最低版本號。每次請求，會攜帶 App 版本號，服務端只會返回符合該版本號的最新配置。

3. 支持不支持屏幕旋轉？

   答：答案是支持的。旋轉以後，屏幕變成了橫屏，weex 就按照橫屏的尺寸來渲染，問題是隻要你寫的頁面符合這種變化就能夠了，跟 native 來實現頁面沒有什麼區別。

5、將來還要繼續作的事情

1. 組件庫的建設
2. 性能統計，好比幀率、內存、CPU
3. 配置和js文件的增量更新、推送更新
4. 降級處理