微信小程序的原生框架和taro對比

微信小程序的原生框架和taro對比

小程序歷史（爲何會出現？）

2007年 iPhone H5

你們知道如今手機端主要是iOS、Android兩大系統，實際上在早期有3大系統競爭，還有一個就是諾基亞的Meego系統，MeeGo 採用 C + HTML5 的雙模應用生態策略，然而 C 的開發難度太大，HTML5 體驗又不行，因此後來 MeeGo就掉隊了；與之對應，Android 依靠 Java 技術生態，在競爭中脫穎而出。

因而在移動互聯網初期，應用生態被定了基調 —— 原生開發。

在那個時候，硬件不行，也沒有其餘辦法，原生開發才能在低配硬件上帶來商用體驗。

可是 ：你們都在懷念 HTML

- HTML 優勢：無需安裝更新、即點即用，直達二級頁面的特色，一直讓人迷戀

- HTML缺點：不止是功能不足，性能體驗是它更嚴重的問題，而體驗問題，不是簡單地擴展 JS 能力能搞定的。

2013 百度輕應用

方式是經過給 WebView 擴展原生能力，補充 JS API，讓 HTML5 應用能夠實現更多功能

2015 微信 JS SDK

國內事實上最大的手機瀏覽器，微信爲它的瀏覽器內核擴充了大量 JS API，讓開發者能夠用 JS 調用微信支付、掃碼等衆多 HTML5 作不到的功能。
但每次點擊要等半天白屏,讓人用着很痛苦

Hybrid 應用

經過工具、引擎優化、開發模式調整，讓開發者能夠經過 JS 寫出更接近原生 App 體驗的應用。

Hybrid 應用和普通的輕應用相比，還有一個巨大的差異：一個是 Client/Server，一個是 **Browser/Server。**簡單來講，Hybrid 應用是 JS 編寫的須要安裝的 App，而輕應用是在線網頁。

C/S 的應用在每次頁面加載時，僅須要聯網獲取 JSON 數據；而 B/S 應用除了 JSON 數據外，還須要每次從服務器加載頁面 DOM、樣式、邏輯代碼，因此 B/S 應用的頁面加載很慢，體驗不好。

但是這樣的 C/S 應用雖然體驗好，卻失去了 HTML5 的動態性，仍然須要安裝、更新，沒法即點即用、直達二級頁面。

那麼 C/S 應用的動態性是否能夠解決呢？

流應用概念，把以前 Hybrid 應用裏的運行於客戶端的 JS 代碼，先打包發佈到服務器，制定流式加載協議，手機端引擎動態下載這些 JS 代碼到本地，而且爲了第一次加載速度更快，實現了應用的邊下載邊運行。

就像流媒體的邊下邊播同樣，應用也能夠實現邊用邊下。

2015 第一個小程序 360 稱之爲 360 微應用

2016 微信小程序，最初的名字其實是微信應用號，以後更名爲小程序

再以後阿里巴巴、手機廠商聯盟、百度、今日頭條，陸續推出了本身的小程序平臺，小程序時代滾滾而來

2018年9月，微信率先推出雲開發

小程序架構

這是一個比較通用的小程序架構，目前幾家小程序架構設計大體都是這樣的（快應用的區別是視圖層只有原生渲染）

你們知道小程序是一個邏輯、視圖層分離的架構。

網頁開發渲染線程和腳本線程是互斥的，這也是爲何長時間的腳本運行可能會致使頁面失去響應，而在小程序中，兩者是分開的，分別運行在不一樣的線程中。

架構引起的性能坑點

小程序這種架構，最大的好處是新頁面加載能夠並行，讓頁面加載更快，且不卡轉場動畫；但同時也引起了部分性能坑點，今天主要介紹 3 點：

邏輯 視圖層 通信阻塞

數據 、組件 的差量更新

同層渲染 和 混合渲染

邏輯層/視圖層通信阻塞

咱們從swipeaction這個例子講起，需求是用戶在列表項上向左滑動，右側隱藏的菜單跟隨用戶手勢平滑移動

若想在小程序架構上實現流暢的跟手滑動，是很困難的，爲何？

咱們再回顧一下上面的小程序架構，小程序的運行環境分爲邏輯層和視圖層，分別由2個線程管理，小程序在視圖層與邏輯層兩個線程間提供了數據傳輸和事件系統。這樣的分離設計，帶來了顯而易見的好處：

環境隔離，既保證了安全性，同時也是一種性能提高的手段，邏輯和視圖分離，即便業務邏輯計算很是繁忙，也不會阻塞渲染和用戶在視圖層上的交互

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

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

基於這樣的架構設計，咱們回到swipeaction，分析一次touchmove的操做，小程序內部的響應過程：

• 用戶拖動列表項，視圖層觸發touchmove 事件，經Native層中轉通知邏輯層（邏輯層、視圖層不是直接通信的，需Native中轉），即下圖中的⓵、⓶兩步

• 邏輯層計算需移動的位置，而後再經過 setData 傳遞位置數據到視圖層，中間一樣會由微信客戶端（Native）作中轉，即下圖中的⓷、⓸兩步

實際上，用戶滑動過程當中，touchmove的回調觸發是很是頻繁的，每次回調都須要4個步驟的通信過程，高頻率回調致使通信成本大幅增長，極有可能致使頁面卡頓或抖動。爲何會卡頓，由於通信太過頻繁，視圖層沒法在16毫秒內完成UI更新。

爲解決這種通信阻塞的問題，各家小程序都在逐步提供對應的解決方案，好比微信的WXS、支付寶的SJS、百度的Filter，但每家小程序支持狀況不一樣，詳細見下表。

另外，微信的關鍵幀動畫、百度的animation-view Lottie動畫，也是爲減小頻繁通信的一種變動方式。

小程序代碼構成

• JSON 配置
• WXML 模板
• WXSS 樣式
• JS 邏輯交互

目前各小程序都有對主包的大小進行限制，微信小程序限制爲 2M。這是由於初次進入的速度對於用戶的體驗很是地關鍵，而主包體積越大下載的時間就最長。所以小程序框架的大小也成爲了開發前框架選型的重要參考指標之一，假若框架體積過大，就會壓縮業務邏輯的可用空間。

數據/組件差量更新

小程序架構存在通信阻塞問題，廠商爲解決這個問題，創造了wxs腳本語言及關鍵幀動畫等方式，但這些都是廠商維度的優化方案。咱們做爲小程序開發者，在性能優化方面，又能作哪些工做呢？

小程序開發性能優化，核心就是setData的調用，你能作只有兩件事情：

• 儘可能少調用setData
• 每次調用setData，傳遞儘量少的數據量，即數據差量更新

減小setData調用次數

假設咱們有更改多個變量值的需求，示例以下：

change:function(){
    this.setData({a:1});
    ... //其它業務邏輯
    this.setData({b:2});
    ... //其它業務邏輯
    this.setData({c:3});
    ... //其它業務邏輯
    this.setData({d:4});
}
​
複製代碼

如上4次調用setData，會引起4次邏輯層、視圖層數據通信。這種場景，開發者需意識到setData有極高的調用代價，本身需手動調整代碼，合併數據，減小數據通信次數。

部分小程序三方框架已內置數據合併的能力，開發者無需關注setData的調用代價，可放心編寫以下代碼：

change:function(){
    this.a = 1;
    ... //其它業務邏輯
    this.b = 2;
    ... //其它業務邏輯
    this.c = 3;
    ... //其它業務邏輯
    this.d = 4;
}
複製代碼
複製代碼

如上4次賦值，uni-app運行時會自動合併成{"a":1,"b":2,"c":3,"d":4}一條記錄，調用一次setData完成全部數據傳遞，大幅下降setData的調用頻次，結果以下圖：

減小setData調用次數，還有個注意點：後臺頁面（用戶不可見的頁面）應避免調用setData。

組件差量更新

下圖是一個微博列表截圖：

假設當前有200條微博，用戶對某條微博點贊，需實時變動其點贊數據（狀態）；在傳統模式下，一條微博的點贊狀態變動，會將整個頁面(Page)的數據所有經過setData傳遞過去，這個消耗是很是高的；而即便經過以前介紹，經過差量計算的方式獲取變動數據，這個 Diff 遍歷範圍也很大，計算效率極低。

如何實現更高性能的微博點贊？這其實就是組件更新的典型場景。

合適的方式應該是，將每條微博封裝成一個組件，用戶點贊後，僅在當前組件範圍內計算差量數據（可理解爲Diff範圍縮小爲原來的1/200），這樣效率纔是最高的。

提醒你們注意，並非全部小程序三方框架都已實現自定義組件，只有在基於自定義組件模式封裝的框架，性能纔會大幅提高；若是三方框架是基於老的template模板封裝的組件開發，則性能並不會有明顯改善，其 Diff 對比範圍依然是Page頁面級的。

框架性能 PK (平均值)

包大小：

原生 < Wepy < Taro < Mpvue < Uni-app < Chameleon

微信小程序的性能：

Taro > Mpvue > Uni-app > Wepy > Chamelon > 未優化過的原生代碼

框架使用後比原生的性能更好，這簡直逆天了，後來研究發現：

微信原生框架耗時主要在 setData 調用上，開發者若不單獨優化，則每次都會傳遞大量數據；而 Uni-app、Taro 等都在調用 setData 以前自動作 diff 計算，每次僅傳遞變更的數據。

生態

小程序

小程序的邏輯層和渲染層是分開的，邏輯層運行在 JSCore 中，並無一個完整瀏覽器對象，於是缺乏相關的DOM API和BOM API。這一區別致使了前端開發很是熟悉的一些庫，例如 jQuery、 Zepto 等，在小程序中是沒法運行的。同時 JSCore 的環境同 NodeJS 環境也是不盡相同，因此一些 NPM 的包在小程序中也是沒法運行的。

Taro

中不但能自由引用 npm 包，並且還大量支持 React 社區中沉澱的優秀工具和庫，如 react-redux、mobx-react 等。

到這裏你們可能會問，Taro 性能真的優於原生嗎？其實並否則，針對每一個場景，咱們均可以用原生寫出性能最佳的代碼。可是這樣作工做量太大，實際項目開發中須要掌握效率與優化之間的平衡。Taro 的優點在於能讓咱們在書寫更有效率的代碼、擁有更豐富的生態的同時，還帶來了不錯的性能。