小程式開發中的一些實踐和踩坑

2019 年 12 月 27 日
筆記

在公司小程式也開發了一段時間了，中間遇到過很多問題，特此記錄幾個比較典型的問題和解決方案。

一、textarea 的高層級問題

此問題提供源碼demo，可導入微信開發者工具查看。

癥狀（表現）

textarea 是小程式的原生組件，它的一個表現就是優先順序很高，這導致了一些困擾，比如我們有一個表單頁面，最下面就是一個textarea和一個保存按鈕，這會導致textarea的文字會浮現在按鈕上。如下圖：

它最大的問題時會導致保存按鈕可能點擊無效或者會彈出鍵盤，並且開發者工具模擬器和真機表現不一樣，這真是個坑！

診斷（實驗）

模擬器中，針對 position:fixed 定位的按鈕，我們加一個 z-index:10 即可， z-index 等於多少合適不清楚，試了等於1是不行的，10就可以，其餘的值沒試過。

.submit-cls {    position: fixed;    left: 30px;    right: 30px;    bottom: 300px;    text-align: center;    background-color: green;    color: #fff;    z-index: 10;  }

模擬器中的表現：

然兒，真機上（Android）依然無效！如下圖：

於是我想到了 cover-view 標籤，cover-view 是微信提供的一個原生組件，它是覆蓋在原生組件之上的文本視圖，可覆蓋的原生組件包括 map、video、canvas、camera、live-player、live-pusher之上，只支援嵌套 cover-view、cover-image，可在 cover-view 中使用 button。

用 cover-view 標籤包裹 button 如何呢？鬱悶的事情發生了，真機上按鈕不見了！。。。這方法貌似不行。。

<cover-view>    <button class="submit-cls" id='button' bindtap="onClick"> Button z-index: 10 </button>  </cover-view>

那我直接用 cover-view 標籤作為按鈕呢？

  <cover-view class="cover-view-clas" id='cover-view' bindtap="onClick"> cover-view z-index: 10 </cover-view>

 .cover-view-clas {    position: fixed;    height: 40px;    line-height: 40px;    left: 30px;    right: 30px;    bottom: 250px;    text-align: center;    background-color: orangered;    color: #fff;  }

結果在模擬器里不行

但是真機上表現很好。於是我也加了一個 z-index: 10 ，這樣模擬器和真機表現就一致。

藥方（總結）

綜上所述，要解決這個問題似乎只有一個辦法，那就是用 cover-view + z-index:10 ，然兒這樣會導致一個的副作用，沒法使用微信的開放能力比如 open-type。

二、setData優化

我們知道，與傳統的瀏覽器Web頁面最大區別在於，小程式的是基於雙執行緒模型的，在這種架構中，小程式的渲染層使用 WebView 作為渲染載體，而邏輯層則由獨立的 JsCore 執行緒運行 JS 腳本，雙方並不具備數據直接共享的通道，因此渲染層和邏輯層的通訊要由 Native 的 JSBrigde 做中轉。

每當小程式視圖數據需要更新時，邏輯層會調用小程式宿主環境提供的 setData 方法將數據從邏輯層傳遞到視圖層，經過一系列渲染步驟之後完成UI視圖更新。然而當 setData 傳遞大量的新數據、頻繁的執行 setData 操作、過多的頁面節點數時會影響渲染性能。

區分數據類別

意思是， setData 只用來通知頁面更新，只有需要通知頁面更新的時候，頁面引用了某個 data 欄位時才使用，其它欄位數據我們有時候可能只是為了讓 js 方便使用。比如如下數據

data: {      form: {          name: 'xxxx',          ... ...      },      index: 0  }

假如頁面上根本沒用到 index 來展示，只是我們的邏輯變數，那麼我們在賦值的時候就直接 this.data.index = xxx 即可，不要用 setData 去賦值了。

合理利用局部更新

setData 是支援使用數據路徑的方式對對象的局部欄位進行更新，我們可能會遇到這樣的場景： list 列表是從後台獲取的數據，並展示在頁面上，當 list 列表的第一項數據的 src 欄位需要更新時，一般情況下我們會從後台獲取新的 list 列表，執行 setData 更新整個 list 列表。

// 後台獲取列表數據  const list = requestSync();  // 更新整個列表  this.setData({ list });

實際上，只有個別欄位需要更新時，我們可以這麼寫來避免整個 list 列表更新:

// 後台獲取列表數據  const list = requestSync();  // 局部更新列表  this.setData({    'list[0].src': list[0].src  });

善用自定義組件

小程式自定義組件的實現是由小程式官方設計的 Exparser 框架所支援，框架實現的自定義組件的組件模型與 Web Components 標準的 Shadow DOM 相似：

Shadow-DOM.png

在頁面引用自定義組件後，當初始化頁面時，Exparser 會在創建頁面實例的同時，也會根據自定義組件的註冊資訊進行組件實例化，然後根據組件自帶的 data 數據和組件WXML，構造出獨立的 Shadow Tree ，並追加到頁面 Composed Tree 。創建出來的 Shadow Tree 擁有著自己獨立的邏輯空間、數據、樣式環境及setData調用，這是組件化帶來的好處。

小程式組件渲染.jpg

基於自定義組件的 Shadow DOM 模型設計，我們可以將頁面中一些需要高頻執行 setData 更新的功能模組（如倒計時、進度條等）封裝成自定義組件嵌入到頁面中。當這些自定義組件視圖需要更新時，執行的是組件自己的 setData ，新舊節點樹的對比計算和渲染樹的更新都只限於組件內有限的節點數量，有效降低渲染時間開銷。

三、大表單交互的一點實踐經驗

在項目中，有一個預約模組，欄位忒多，保險業務嘛，需要用戶填寫各種數據的，為了用戶體驗拆成了多個步驟，如圖

一開始，業務上要求切換tab的時候數據要快取，跟Vue的 keep-alive 一樣，但是小程式沒有這樣的機制，所以利用小程式的 hidden 屬性，也就是 Vue 中的 v-show，組件始終會被渲染，只是簡單的控制顯示與隱藏。關於wx:if 和 hidden。

這樣的導致頁面節點太多，在低性能手機上會出現卡死的現象，直接無法渲染或者渲染太慢。

後來改為 wx:if 來切換

<view wx:if="{{current === 0}}">......</view>  <view wx:if="{{current === 1}}">......</view>  <view wx:if="{{current === 2}}">......</view>  ... ...

這樣以來一次渲染節點太多的問題解決了，但是怎麼實現tab切換的時候輸入的內容杯快取呢？其實我們的笨辦法就是切換的時候把前一個表單內容保存到 localStorage 或 gloabData 中，切換回去的時候再取出來填充，這中間會有一個明顯的渲染過程，肉眼可見，沒辦法，目前只能犧牲一點點體驗了。

對於這種大型表單，數據處理和邏輯交互的時候要非常注意，很容易出現性能問題。

這次就說這麼多吧，文章如有什麼錯誤，或有什麼想法，請留言，不吝賜教！

全文完。

本文代表個人觀點，內容僅供參考。若有不恰當之處，望不吝賜教！

本文鏈接：https://zhangbing.site/2019/10/01/小程式開發中的一些實踐和踩坑/。