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

一、textarea 的高層級問題

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

癥狀（表現(xiàn)）

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

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

診斷（實驗）

模擬器中，針對 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;
}

模擬器中的表現(xiàn)：

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

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

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

<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;
}

結果在模擬器里不行

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

藥方（總結）

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

二、setData優(yōu)化

我們知道，與傳統(tǒng)的瀏覽器Web頁面最大區(qū)別在于，小程序的是基于 雙線程 模型的，在這種架構中，小程序的渲染層使用 WebView 作為渲染載體，而邏輯層則由獨立的 JsCore 線程運行 JS 腳本，雙方并不具備數(shù)據(jù)直接共享的通道，因此渲染層和邏輯層的通信要由 Native 的 JSBrigde 做中轉。

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

區(qū)分數(shù)據(jù)類別

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

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

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

合理利用局部更新

setData 是支持使用 數(shù)據(jù)路徑 的方式對對象的局部字段進行更新，我們可能會遇到這樣的場景： list 列表是從后臺獲取的數(shù)據(jù)，并展示在頁面上，當 list 列表的第一項數(shù)據(jù)的 src 字段需要更新時，一般情況下我們會從后臺獲取新的 list 列表，執(zhí)行 setData 更新整個 list 列表。

// 后臺獲取列表數(shù)據(jù)
const list = requestSync(); 
// 更新整個列表
this.setData({ list }); 

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

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

善用自定義組件

小程序自定義組件的實現(xiàn)是由小程序官方設計的 Exparser 框架所支持，框架實現(xiàn)的自定義組件的組件模型與 Web Components 標準的 Shadow DOM 相似：

在頁面引用自定義組件后，當初始化頁面時，Exparser 會在創(chuàng)建頁面實例的同時，也會根據(jù)自定義組件的注冊信息進行組件實例化，然后根據(jù)組件自帶的 data 數(shù)據(jù)和組件WXML，構造出獨立的 Shadow Tree ，并追加到頁面 Composed Tree 。創(chuàng)建出來的 Shadow Tree 擁有著自己獨立的邏輯空間、數(shù)據(jù)、樣式環(huán)境及setData調用，這是組件化帶來的好處。

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

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

在項目中，有一個預約模塊，字段忒多，保險業(yè)務嘛，需要用戶填寫各種數(shù)據(jù)的，為了用戶體驗拆成了多個步驟，如圖

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

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

后來改為 wx:if 來切換

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

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

對于這種大型表單，數(shù)據(jù)處理和邏輯交互的時候要非常注意，很容易出現(xiàn)性能問題。

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

參考文章：微信小程序渲染性能調優(yōu)

本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得，所有資料僅供用戶學習參考，本站不擁有所有權，如您認為本網頁中由涉嫌抄襲的內容，請及時與我們聯(lián)系，并提供相關證據(jù)，工作人員會在5工作日內聯(lián)系您，一經查實，本站立刻刪除侵權內容。本文鏈接:http://www.webpost.com.cn/25247.html