TextComponent。JSBridge

JS

Native

Module來完成

依托于Native，借助于前端，演變成大前端的架構，整體結構如下圖。我們希望App作為終端，提供容器的能力，做好底層服務，完美融合Weex、Web等跨平臺技術。

以下記錄了實踐中遇到的一些較為重要、常見的問題，及其解決方案，它們貫穿了Weex頁面的生命周期。

頁面間通信

路由

Weex自身提供的navigator只支持簡單的在線資源，而不支持本地文件的加載，同時無法滿足動態化的呈現方式和復雜參數傳遞，需要自行實現一套完整的頁面跳轉規則。

在大量使用了

Web、Weex

// 打開Web頁面
scheme:/web/open");

Weex中發起一次頁面跳轉的示例：

navigator.openUrl({
  url: "scheme://weex/open",
  params: {
    bundleUrl: "/dist/about.js",
    name: "這是下一個頁面所需的參數",
  },
})


// 備注： 而下一個頁面只需要在data中聲明一個與參數同名的屬性來接收具體的參數即可。

反向傳值

我們在考慮反向傳值的問題時，主要涉及兩種場景，一是Weex頁面反向傳值給Weex頁面，二是Native反向傳值給Weex頁面。我們可以使用Weex提供的基于W3C 規范的

BroadcastChannel

在頁面跳轉時將

WXModuleKeepAliveCallback

我們有嘗試借鑒

BroadcastChannel

我們最后選擇使用

fireGlobalEvent

1.Weex添加事件監聽
const globalEvent = weex.requireModule("globalEvent");
globalEvent.addEventListener("eventName", (e) => {
  // ...
});


2.原生頁面發送事件
weexInstance.fireGlobalEventCallback("eventName", params); // Android


[weexInstance fireGlobalEvent:seventName params:params]; // iOS

代碼中的weexInstance，可以理解為一個頁面的實例對象，該流程需要在發送監聽的頁面需要獲取上一個

Weex

weexInstance

----

navigator.openUrl({
  url: "scheme://weex/open",
  params: {
    bundleUrl: "/dist/about.js",
    needListen: true,
  },
})

2. 頁面配置文件

起初Weex頁面導航欄、跳轉方式等配置，均在自建Module中進行處理，例如一個頁面要設置導航欄，我們需要在mounted方法中加入如下代碼：

created () {
    navigator.setTitle("導航欄標題")
    navigator.setItems([{
      title: "按鈕",
    }])
}

這種不夠工程化、標準化的方式給后期的維護、跨項目移植、架構升級造成了極大的干擾。

我們參考小程序的設計思路進行了優化升級，為每一個需要特有化配置的Weex頁面添加一個json格式的配置文件，配置文件包括導航欄的配置、頁面級別的配置、跳轉的配置等，將配置工程化、標準化。

例如我為about頁面添加了配置文件，json文件的類容為：

{
    "navigationBarTitle": "導航欄標題",
    "navigationItems": [{
        "title": "按鈕"
    }]
}

打包后的資源文件目錄如下，about.js、about.json文件在同級目錄：

那么一個完整的頁面打開步驟如下：

經過擴展，配置文件變得更加豐富，先前麻煩的跳轉處理、彈框等都可以通過配置文件實現，下面是一些常用的屬性介紹：

針對于iOS客戶端存在頁面需要Present等情況，可以設置以下屬性：

transition中需定義動畫的表達式，Native則需要解析該表達式，并按照表達式執行動畫。

按鈕樣式說明：

{
     "type": "TEXT", // "TEXT", "IMG", "TEXT_IMG"，必傳




     "title": "標題", // 文字標題或者




     "image": "刷新", // 是圖片地址，圖片地址支持本地圖片和網絡圖片




     "textColor": "FFFFFF", // 16進制， 默認為白色，可不傳




     "backgroundColor": "", // 16進制， 默認透明色，可不傳




     "borderColor": "", // 16進制， 默認無邊框，可不傳




     "borderWidth": 1, // 默認無邊框，可不傳




     "cornerRadius": 1, // 默認無圓角，可不傳




     "font": 16, // 默認16號字體，可不傳
  
      "position": 0, // 默認0，可不傳, 0-左側顯示，1-右側顯示  
       
     "imagePosition": 0, // 0-圖片在左，文字在右，默認, 1- 圖片在右，文字在左,  2-圖片在上，文字在下,

4.自定義導航欄

例如滿足導航欄分段選擇的需求：

Weex對于iOS的支持比較友好，然而Android 端無法顯示陰影。 雖然文檔有明確指出此問題，但是Android sdk卻提供相關方法。也許是阿里的工程師嘗試解決，但效果并不理想。比較明顯的一點是，如果列表中的item使用陰影， 在列表滑動的時候會把陰影殘留在最初繪制的位置。Android的同學一直在嘗試解決此問題，最終也沒達到一個理想的效果。最后的降級方案是通過圖片來替代陰影，以下是Weex官方的注釋：

目前僅 iOS 支持 box-shadow 屬性，Android 暫不支持，可以使用圖片代替。

每個元素只支持設置一個陰影效果，不支持多個陰影同時作用于一個元素。

4. 網絡請求

Weex提供了

Stream

因此我們提供了自己的網絡請求模塊，Weex端調用Native提供的方法，并通過參數來決定請求，一些可選的參數：

請求示例：

// 1. 獲取原生Module
const nativeStream = weex.requireModule("nativeStream")


// 2. 設置基本參數
const options = {
  path："/...."，
  method: "POST",
  params: {
    id: "123"
  }
}


// 3. 發起請求
nativeStream.fetch(options, (res) => {
  if (res.code === 0) {
    succesCallback(res)
    return
  }
  failCallback(res)
}

5. 圖片加載

標簽圖片的加載需要客戶端提供handler，目前支持遠程鏈接和打包生成的Bundle資源，并不直接支持相冊圖片以及拍照生成的圖片。其對Base64的支持，為我們顯示相冊圖片提供了一種思路。下圖表明了Weex頁面中選擇相冊圖片、拍照并進行顯示的流程：

通過上圖我們可以知道，一個簡單的圖片顯示流程，其實并不簡單，其中最為關鍵的是在進行第5步時所選擇方案。先上傳圖片對于程序員而言是最為便捷的方案，但是比較影響用戶體驗，圖片本應該在需要上傳的時候進行上傳，而非因為技術隘口而干擾業務。

轉換為Base64可以提升用戶體驗，但是卻比較影響性能。在iOS端，將一張1M的圖片轉換為Base64所需要的時間≥45ms，第6、7步所消耗的時間則是30ms左右，這種時間消耗隨圖片大小以倍數增加。

綜上所述，我們設計了一種本地化方案，為每一個添加的圖片生成一個唯一性的ID，Native負責圖片的存儲、加載。

6. 刷新組件

由于Weex所提供的組件形式較單一，且存在交互Bug，我們自實現了一套刷新組件。通過屬性來確定刷新的顯示與否，并提供相應的接口實現Weex與Native之間的交互。

1.屬性

refresh 事件：當 、、 被下拉完成時觸發，該事件由原生回調到Weex。

loading 事件：當 、、 被上拉時觸發，該事件由原生回調到Weex。

"list"
      c
      :show-refresh="true"
      class="list"
      @refresh="refreshList"
      @loading="loadMoreList">
 

beginRefresh 事件：開始下拉刷新，由Weex調用。

beginLoading 事件：開始上拉刷新，由Weex調用。

endRefresh 事件：結束下拉刷新，由Weex調用。

endLoading 事件：結束上拉刷新，由Weex調用。

this.$refs.list.beginRefresh()
this.$refs.list.endRefresh()

如果不使用該屬性，則需要在created或者mounted函數中手動調用刷新的方法以觸發下拉刷新，然而在某些Android設備上面出現了白屏的情況。Weex對此做出了解釋：

和瀏覽器不同的是，Weex 的渲染流程是異步的，而且渲染出來的結果都是原生系統中的 View，這些數據都無法被 javascript 直接獲取到。因此在 Weex 上，Vue 的 mounted 生命周期在當前組件的 virtual-dom (Vue 里的 VNode) 構建完成后就會觸發，此時相應的原生視圖未必已經渲染完成。

7. 截屏

Weex中完成截屏，只需要獲取到對應的視圖層即可，Weex頁面在渲染時會為每一個組件生成一個唯一的ID，在JavaScript中更直觀的體現是ref，盡管Weex并不存在真正的DOM，但其依然支持ref的使用。具體的做法如下：

// 1. 標簽生命ref
"poster">


// 2. 獲取到該element，實際上是一個Map
const poster = this.$refs.poster


// 3. 獲取Map中對應的ref
saveViewShot({ ref: poster.ref })


// 4. 獲取Component
// iOS
WXComponent *component = [weexInstance componentForRef:ref];
// Android
WXComponent component = WXSDKManager.getInstance().getWXRenderManager().getWXComponent(mWXSDKInstance.getInstanceId(), ref);


// 5. 獲取View，進行

8. 優雅的彈窗

這是一個很簡單的彈框需求，視圖漸漸變大最后全屏展示。然而基于Weex現有的能力是無法實現的，第一點：Weex頁面默認的布局是從導航欄下面開始的，第二點：路由的跳轉方式并不能直接支持此種彈出方式，頁面默認是從右向左推出。

為了實現彈框的功能，我們需要四個步驟：

1. Native定義PopView組件

1. Weex搭建頁面，并以PopView為基礎進行布局

2. 全屏呈現頁面并隱藏導航欄

3. 執行動畫

原生定義好PopView組件后，Weex頁面可以這樣布局：

結合第三點所提出的配置文件，我們將2、3步驟的控制放在配置文件當中，最后寫出的配置文件為：

{
  navigationBarHidden: true, // 隱藏導航欄
  transition: {
    property:"scale", // popView的尺寸將由(0，0)變為顯示大小
    duration: 2, // 動畫時間，單位(秒)
  },// 轉場顯示，并規定popView的顯示動畫
}

這只是最為簡單的例子，更復雜的動畫需要客戶端支持即可。

五、To Be Continued

以上概括了Weex接入的心路歷程，以及在實踐中遇到的基本問題，表明了Weex在團隊中的運用已經暢通并日趨規范化，但是更深入的性能優化、熱更新等需要我們繼續前行，以下是下一期文章將涉及的知識點:

熱更新

資源預加載

配置文件動態化

Weex資源打包自動化，自動加入終端倉庫

加推科學院公眾號

mp.weixin.qq.com/s/LxdQ6Eq2R…