小程序里有幾個謎一樣的存在，微信的、支付寶的、百度的。

很多開發者都不明白為什么要造這種語言腳本的輪子出來，甚至很多開發者根本不知道它們的存在。

其實幾大小程序平臺創造它們，都是為了解決性能問題，但不得不吐槽下，設計的實在是很難用，文檔也語焉不詳。

uni-app支持將WXS、SJS、Filter編譯到這3家小程序平臺，同時還在App和H5實現了WXS的解析。為什么做這些事？也是為了性能。

uni-ui庫新版中的swiperaction組件，就是列表項向左滑動時拉出幾個擠壓式聯動的菜單按鈕，這種流暢的跟手動畫，正是借助于WXS機制實現的。

微信為何要創造WXS

WXS(WeiXin Script)是微信創造的一套腳本語言，它的官方說法是："WXS 與 JavaScript 是不同的語言，有自己的語法，并不和 JavaScript 一致"。

那微信為何要脫離 JavaScript ，單獨創造一套語言呢？這要從微信小程序的底層邏輯(運行環境)講起。

小程序的運行環境分為邏輯層和視圖層，分別由2個線程管理，其中：

· WXML 模板和 WXSS 樣式工作在視圖層，界面使用 WebView 進行渲染

· JavaScript代碼工作在邏輯層，運行在JsCore或v8里

小程序在視圖層與邏輯層兩個線程間提供了數據傳輸和事件系統。這樣的分離設計，帶來了顯而易見的好處：

· 邏輯和視圖分離，即使業務邏輯計算非常繁忙，也不會阻塞渲染和用戶在視圖層上的交互

但同時也帶來了明顯的壞處：

· 視圖層(webview)中不能運行JS，而邏輯層JS又無法直接修改頁面DOM，數據更新及事件系統只能靠線程間通訊，但跨線程通信的成本極高，特別是需要頻繁通信的場景

什么是需要頻繁通訊的場景？最典型的例子就是用戶持續交互的情況，比如觸摸、滾動等。我們以側滑菜單為例，假設在頁面上滑動A元素，要求B元素跟隨移動，一次滑動操作(touchmove)的響應過程如下：

1. touchmove 事件從視圖層(Webview)傳遞到邏輯層，中間會由微信客戶端(Native)做中轉

2. 邏輯層處理 touchmove 事件，計算需移動的位置，然后再通過 setData 傳遞到視圖層，中間同樣會由微信客戶端(Native)做中轉

一次 touchmove 的響應需要經過 視圖層、Native、邏輯層三者之間2個完整來回的通信，通信的耗時開銷較大，用戶的交互就會出現延時卡頓的情況。

除了滾動、拖動交互外，在for循環里對數據做格式修改，也會造成邏輯層和視圖層頻繁通訊。

其實這類通信損耗問題，在業內由來已久，react native和weex都有類似問題，weex提供了bindingx來解決。

但對于小程序來講，這類問題解決起來更容易。其實視圖層的webview，是有js環境的，只不過過去不給開發者開放。

如果在視圖層的js直接處理滾動或拖動交互、直接處理數據格式，就能避免大量通信損耗。

但對于小程序平臺而言，大量開放webview里的js編寫，違反了它的初衷，比如開發者會直接操作dom，影響性能體驗。所以小程序平臺提出一種新規范，限制webview里可運行的js的能力。這就是wxs、sjs、filter的由來。

從本質來講，wxs、sjs、filter是一種被限制過的、運行在視圖層webview里的js。它并不是真的發明了一種新語言。

WXS特征及適用場景

WXS具備如下特征：

· WXS是可以在視圖層(webview)中運行的JS

· WXS無法修改業務數據，僅能設置當前組件的class和style

· WXS是被限制過的JavaScript，可以進行一些簡單的邏輯運算

· WXS可以監聽touch事件，處理滾動、拖動交互

故可以得出WXS的適用場景，主要包括：

· 用戶交互頻繁、僅需改動組件樣式(比如布局位置)，無需改動數據內容的場景，比如側滑菜單、索引列表、滾動漸變等

· 純粹的邏輯計算，比如文本、日期格式化，通過WXS可以模擬實現Vue框架的,如下是一個通過wxs便捷實現首字母大寫的示例：

//首字母大寫var capitalize = function(value) { if (!value) return '' value = value.toString() return value.charAt(0).toUpperCase() + value.slice(1)}module.exports = { capitalize: capitalize}{{m1.capitalize(title)}}

uni-app如何支持WXS

uni-app遵循，組件/樣式/腳本是寫在一個.vue文件中的，但微信小程序是多文件分離(wxml/wxss/js/json)的，所以在微信端的主要工作是擴展vue-template-compiler，解析template/style/script節點，并正確生成到對應的wxml/wxss/js文件中，具體編譯工作如下圖：

Tips-1：關于標簽重構為

2. 在 wxs 文件中，處理 touch 事件邏輯，通過 translateX 移動元素位置

function touchstart(e, ins) { //記錄開始位置及動畫狀態var pageX = e.touches[0].pageX;....}?function touchmove(e, ownerInstance) {var instance = e.instance;var pageX = e.touches[0].pageX;//獲取當前移動位置//計算偏移位置var x = Math.max(-instance.getState().position[1].width, Math.min((value), 0));//設置左側元素移動位置instance.setStyle({transform: 'translateX(' + x + 'px)'}) //循環右側擠壓式聯動菜單var btnIns = ownerInstance.selectAllComponents('.button-hock');for (var i = 0; i < btnIns.length; i++) { ... //設置每個聯動菜單的移動位置 btnIns[i].setStyle({transform: 'translateX(' + (arr[i - 1] + value * (arr[i - 1] / position[1].width)) + 'px)'}) ...}}?function touchend(e, ownerInstance) {var instance = e.instance;var state = instance.getState()//根據當前移動位置，實現菜單項的自動展開或回彈move(state.left, -40, instance, ownerInstance)}

該示例的完整源碼參考github

更多平臺的兼容性

uni-app的App端也是一個小程序引擎，所以想要在App端實現流暢的跟手拖動，也需要實現類似wxs的機制。

其實H5平臺倒不存在邏輯層和視圖層通訊折損的問題，但為了平臺兼容性拉齊，uni-app在H5端也實現了wxs機制。

這樣編寫wxs代碼，在uni-app中可同時運行在App端、H5端、微信小程序端。

因百度小程序的、支付寶小程序的和微信小程序的在語法上差異較大，uni-app只支持單獨編寫百度小程序的Filter過濾器和支付寶小程序的SJS，這兩種腳本無法跨多端，僅支持自有平臺。開發者若需使用，可分別編寫wxs/filter/sjs腳本，然后依次通過script引用，uni-app編譯器會根據目標平臺，分別編譯發行，如下為示例代碼：

示例代碼要有條件編譯

后續

用運行在視圖層的js解決通訊阻塞，可能很多人都沒意識到。希望本文能給大家解惑，解開WXS之謎。

其實小程序的性能體驗優化，仍然有大量空間。DCloud團隊在這個領域研究了6年，清楚當前的優勢，也清楚當前的問題。我們會繼續分享這些問題及對應的解決方案，為小程序產業發展貢獻力量。

本文涉及的uni-ui的swiperaction組件，代碼開源在https://github.com/dcloudio/uni-ui，uni-app框架代碼開源在 https://github.com/dcloudio/uni-app，歡迎大家 star 或提交 pr。

總結

以上是生活随笔為你收集整理的移动app部分机型无法唤起h5支付宝支付_谜之wxs，uni-app如何用它大幅提升性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。