TextComponent。JSBridge

JS

Native

Module來完成

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

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

頁面間通信

路由

Weex自身提供的navigator只支持簡單的在線資源，而不支持本地文件的加載，同時(shí)無法滿足動(dòng)態(tài)化的呈現(xiàn)方式和復(fù)雜參數(shù)傳遞，需要自行實(shí)現(xiàn)一套完整的頁面跳轉(zhuǎn)規(guī)則。

在大量使用了

Web、Weex

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

Weex中發(fā)起一次頁面跳轉(zhuǎn)的示例：

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


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

反向傳值

我們?cè)诳紤]反向傳值的問題時(shí)，主要涉及兩種場(chǎng)景，一是Weex頁面反向傳值給Weex頁面，二是Native反向傳值給Weex頁面。我們可以使用Weex提供的基于W3C 規(guī)范的

BroadcastChannel

在頁面跳轉(zhuǎn)時(shí)將

WXModuleKeepAliveCallback

我們有嘗試借鑒

BroadcastChannel

我們最后選擇使用

fireGlobalEvent

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


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


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

代碼中的weexInstance，可以理解為一個(gè)頁面的實(shí)例對(duì)象，該流程需要在發(fā)送監(jiān)聽的頁面需要獲取上一個(gè)

Weex

weexInstance

----

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

2. 頁面配置文件

起初Weex頁面導(dǎo)航欄、跳轉(zhuǎn)方式等配置，均在自建Module中進(jìn)行處理，例如一個(gè)頁面要設(shè)置導(dǎo)航欄，我們需要在mounted方法中加入如下代碼：

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

這種不夠工程化、標(biāo)準(zhǔn)化的方式給后期的維護(hù)、跨項(xiàng)目移植、架構(gòu)升級(jí)造成了極大的干擾。

我們參考小程序的設(shè)計(jì)思路進(jìn)行了優(yōu)化升級(jí)，為每一個(gè)需要特有化配置的Weex頁面添加一個(gè)json格式的配置文件，配置文件包括導(dǎo)航欄的配置、頁面級(jí)別的配置、跳轉(zhuǎn)的配置等，將配置工程化、標(biāo)準(zhǔn)化。

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

{
    "navigationBarTitle": "導(dǎo)航欄標(biāo)題",
    "navigationItems": [{
        "title": "按鈕"
    }]
}

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

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

經(jīng)過擴(kuò)展，配置文件變得更加豐富，先前麻煩的跳轉(zhuǎn)處理、彈框等都可以通過配置文件實(shí)現(xiàn)，下面是一些常用的屬性介紹：

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

transition中需定義動(dòng)畫的表達(dá)式，Native則需要解析該表達(dá)式，并按照表達(dá)式執(zhí)行動(dòng)畫。

按鈕樣式說明：

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




     "title": "標(biāo)題", // 文字標(biāo)題或者




     "image": "刷新", // 是圖片地址，圖片地址支持本地圖片和網(wǎng)絡(luò)圖片




     "textColor": "FFFFFF", // 16進(jìn)制， 默認(rèn)為白色，可不傳




     "backgroundColor": "", // 16進(jìn)制， 默認(rèn)透明色，可不傳




     "borderColor": "", // 16進(jìn)制， 默認(rèn)無邊框，可不傳




     "borderWidth": 1, // 默認(rèn)無邊框，可不傳




     "cornerRadius": 1, // 默認(rèn)無圓角，可不傳




     "font": 16, // 默認(rèn)16號(hào)字體，可不傳
  
      "position": 0, // 默認(rèn)0，可不傳, 0-左側(cè)顯示，1-右側(cè)顯示  
       
     "imagePosition": 0, // 0-圖片在左，文字在右，默認(rèn), 1- 圖片在右，文字在左,  2-圖片在上，文字在下,

4.自定義導(dǎo)航欄

例如滿足導(dǎo)航欄分段選擇的需求：

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

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

每個(gè)元素只支持設(shè)置一個(gè)陰影效果，不支持多個(gè)陰影同時(shí)作用于一個(gè)元素。

4. 網(wǎng)絡(luò)請(qǐng)求

Weex提供了

Stream

因此我們提供了自己的網(wǎng)絡(luò)請(qǐng)求模塊，Weex端調(diào)用Native提供的方法，并通過參數(shù)來決定請(qǐng)求，一些可選的參數(shù)：

請(qǐng)求示例：

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


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


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

5. 圖片加載

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

通過上圖我們可以知道，一個(gè)簡單的圖片顯示流程，其實(shí)并不簡單，其中最為關(guān)鍵的是在進(jìn)行第5步時(shí)所選擇方案。先上傳圖片對(duì)于程序員而言是最為便捷的方案，但是比較影響用戶體驗(yàn)，圖片本應(yīng)該在需要上傳的時(shí)候進(jìn)行上傳，而非因?yàn)榧夹g(shù)隘口而干擾業(yè)務(wù)。

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

綜上所述，我們?cè)O(shè)計(jì)了一種本地化方案，為每一個(gè)添加的圖片生成一個(gè)唯一性的ID，Native負(fù)責(zé)圖片的存儲(chǔ)、加載。

6. 刷新組件

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

1.屬性

refresh 事件：當(dāng) 、、 被下拉完成時(shí)觸發(fā)，該事件由原生回調(diào)到Weex。

loading 事件：當(dāng) 、、 被上拉時(shí)觸發(fā)，該事件由原生回調(diào)到Weex。

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

beginRefresh 事件：開始下拉刷新，由Weex調(diào)用。

beginLoading 事件：開始上拉刷新，由Weex調(diào)用。

endRefresh 事件：結(jié)束下拉刷新，由Weex調(diào)用。

endLoading 事件：結(jié)束上拉刷新，由Weex調(diào)用。

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

如果不使用該屬性，則需要在created或者mounted函數(shù)中手動(dòng)調(diào)用刷新的方法以觸發(fā)下拉刷新，然而在某些Android設(shè)備上面出現(xiàn)了白屏的情況。Weex對(duì)此做出了解釋：

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

7. 截屏

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

// 1. 標(biāo)簽生命ref
"poster">


// 2. 獲取到該element，實(shí)際上是一個(gè)Map
const poster = this.$refs.poster


// 3. 獲取Map中對(duì)應(yīng)的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，進(jìn)行

8. 優(yōu)雅的彈窗

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

為了實(shí)現(xiàn)彈框的功能，我們需要四個(gè)步驟：

1. Native定義PopView組件

1. Weex搭建頁面，并以PopView為基礎(chǔ)進(jìn)行布局

2. 全屏呈現(xiàn)頁面并隱藏導(dǎo)航欄

3. 執(zhí)行動(dòng)畫

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

結(jié)合第三點(diǎn)所提出的配置文件，我們將2、3步驟的控制放在配置文件當(dāng)中，最后寫出的配置文件為：

{
  navigationBarHidden: true, // 隱藏導(dǎo)航欄
  transition: {
    property:"scale", // popView的尺寸將由(0，0)變?yōu)轱@示大小
    duration: 2, // 動(dòng)畫時(shí)間，單位(秒)
  },// 轉(zhuǎn)場(chǎng)顯示，并規(guī)定popView的顯示動(dòng)畫
}

這只是最為簡單的例子，更復(fù)雜的動(dòng)畫需要客戶端支持即可。

五、To Be Continued

以上概括了Weex接入的心路歷程，以及在實(shí)踐中遇到的基本問題，表明了Weex在團(tuán)隊(duì)中的運(yùn)用已經(jīng)暢通并日趨規(guī)范化，但是更深入的性能優(yōu)化、熱更新等需要我們繼續(xù)前行，以下是下一期文章將涉及的知識(shí)點(diǎn):

熱更新

資源預(yù)加載

配置文件動(dòng)態(tài)化

Weex資源打包自動(dòng)化，自動(dòng)加入終端倉庫

加推科學(xué)院公眾號(hào)

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