一.微信小程序是啥
本質(zhì)其實就是(混合)的app 介于web app與native 原生app之間,具備豐富的調(diào)用手機各種功能的接口,同時又具備靈活性,跨平臺
1. 運行環(huán)境差異
微信小程序運行在三端:iOS、Android 和 用于調(diào)試的開發(fā)者工具。
三端的腳本執(zhí)行環(huán)境以及用于渲染非原生組件的環(huán)境是各不相同的:
- 在 iOS 上,小程序的 javascript 代碼是運行在 JavaScriptCore 中,是由 WKWebView 來渲染的,環(huán)境有 iOS8、iOS9、iOS10
- 在 Android 上,小程序的 javascript 代碼是通過 X5 JSCore來解析,是由 X5 基于 Mobile Chrome 53/57 內(nèi)核來渲染的
- 在 開發(fā)工具上, 小程序的 javascript 代碼是運行在 nwjs 中,是由 Chrome Webview 來渲染的來自官方文檔說明
2.小程序目錄結(jié)
project
├── pages
| ├── index
| | ├── index.json index 頁面配置
| | ├── index.js index 頁面邏輯
| | ├── index.wxml index 頁面結(jié)構(gòu)
| | └── index.wxss index 頁面樣式表
| └── log
| ├── log.json log 頁面配置
| ├── log.wxml log 頁面邏輯
| ├── log.js log 頁面結(jié)構(gòu)
| └── log.wxss log 頁面樣式表
├── app.js 小程序邏輯
├── app.json 小程序公共設(shè)置
└── app.wxss 小程序公共樣式表
3.為什么小程序比較快

二、小程序架構(gòu)
微信小程序的框架包含兩部分View視圖層(可能存在多個)、App Service邏輯層(一個),View層用來渲染頁面結(jié)構(gòu),AppService層用來邏輯處理、數(shù)據(jù)請求、接口調(diào)用,它們在兩個線程里運行。
視圖層使用WebView渲染,邏輯層使用JSCore運行。
視圖層和邏輯層通過系統(tǒng)層的WeixinJsBridage進行通信,邏輯層把數(shù)據(jù)變化通知到視圖層,觸發(fā)視圖層頁面更新,視圖層把觸發(fā)的事件通知到邏輯層進行業(yè)務(wù)處理。

重點講一下wxs :
由于view 與 App Service是不同線程,之前是傳遞數(shù)據(jù),當遇到一些數(shù)據(jù)需要在view中處理時,就可以用wxs來處理,如下所示定義 <wxs module="tools">,使用說明
index.js
//獲取應(yīng)用實例
const app = getApp()
Page({
data: {
motto: 'Hello World',
userInfo: {},
hasUserInfo: false
},
//事件處理函數(shù)
bindViewTap: function() {
},
onLoad: function() {
}
})
<!--index.wxml-->
<view class="container">
<view class="usermotto">
<text class="user-motto">{{tools.bar(motto)}}</text>
<text class="user-motto">{{tools.foo}}</text>
</view>
<wxs module="tools">
var foo = "'hello world' from comm.wxs";
var bar = function(d) {
return '啥子玩意'+d;
}
module.exports = {
foo: foo,
bar: bar
};
</wxs>
</view>
三、小程序啟動加載
運行機制
小程序啟動會有兩種情況,一種是「冷啟動」,一種是「熱啟動」。 假如用戶已經(jīng)打開過某小程序,然后在一定時間內(nèi)再次打開該小程序,此時無需重新啟動,只需將后臺態(tài)的小程序切換到前臺,這個過程就是熱啟動;冷啟動指的是用戶首次打開或小程序被微信主動銷毀后再次打開的情況,此時小程序需要重新加載啟動。
更新機制
小程序冷啟動時如果發(fā)現(xiàn)有新版本,將會異步下載新版本的代碼包,并同時用客戶端本地的包進行啟動,即新版本的小程序需要等下一次冷啟動才會應(yīng)用上。 如果需要馬上應(yīng)用最新版本,可以使用wx.getUpdateManager API 進行處理。
運行機制
- 小程序沒有重啟的概念
- 當小程序進入后臺,客戶端會維持一段時間的運行狀態(tài),超過一定時間后(目前是5分鐘)會被微信主動銷毀
- 當短時間內(nèi)(5s)連續(xù)收到兩次以上收到系統(tǒng)內(nèi)存告警,會進行小程序的銷毀

四、View (頁面視圖)
視圖層由 WXML 與 WXSS 編寫,由組件來進行展示。
將邏輯層的數(shù)據(jù)反應(yīng)成視圖,同時將視圖層的事件發(fā)送給邏輯層。
1、View - WXML
wxml編譯器:wcc 把wxml文件 轉(zhuǎn)為 js 執(zhí)行方式:wcc index.wxml

2、View - WXSS
- WXSS(WeiXin Style Sheets)
- wxss編譯器:wcsc 把wxss文件轉(zhuǎn)化為 js 執(zhí)行方式: wcsc index.wxss
3、View - Component
- 小程序的組件基于Web Component標準
- 使用Polymer框架實現(xiàn)Web Component

4、View - Native Component
- 目前Native實現(xiàn)的組件有 <canvas/> <video/> <map/> <textarea/>
- Native組件層在WebView層之上

五、WebView預(yù)加載
每次小程序進入除了當前頁面,Native預(yù)先額外加載一個WebView
當打開指定頁面時,用默認數(shù)據(jù)直接渲染,請求數(shù)據(jù)回來時局部更新
返回顯示歷史View
退出小程序,View狀態(tài)不銷毀
六、App Service(邏輯層)
邏輯層將數(shù)據(jù)進行處理后發(fā)送給視圖層,同時接受視圖層的事件反饋
1、App( ) 小程序的入口;Page( ) 頁面的入口
3、提供豐富的 API,如微信用戶數(shù)據(jù),掃一掃,支付等微信特有能力。
4、每個頁面有獨立的作用域,并提供模塊化能力。
5、數(shù)據(jù)綁定、事件分發(fā)、生命周期管理、路由管理
運行環(huán)境
IOS - JSCore
Android - X5 JS解析器
DevTool - nwjs Chrome 內(nèi)核
1、App Service - Binding
- 數(shù)據(jù)綁定使用 Mustache 語法(雙大括號)將變量包起來,動態(tài)數(shù)據(jù)均來自對應(yīng) Page 的 data,可以通過setData方法修改數(shù)據(jù)。
- 事件綁定的寫法同組件的屬性,以 key、value 的形式,key 以bind或catch開頭,然后跟上事件的類型,如bindtap, catchtouchstart,value 是一個字符串,需要在對應(yīng)的 Page 中定義同名的函數(shù)。

2、App Service - Life Cylce

3、App Service - API
API通過WeixinJSBridge和Native 進行通信

4、App Service - Router
- navigateTo(OBJECT)
保留當前頁面,跳轉(zhuǎn)到應(yīng)用內(nèi)的某個頁面,使用navigateBack可以返回到原頁面。頁面路徑只能是五層
- redirectTo(OBJECT)
關(guān)閉當前頁面,跳轉(zhuǎn)到應(yīng)用內(nèi)的某個頁面。
- navigateBack(OBJECT)
關(guān)閉當前頁面,返回上一頁面或多級頁面??赏ㄟ^ getCurrentPages()) 獲取當前的頁面棧,決定需要返回幾層。
五、小程序開發(fā)經(jīng)驗
1、小程序存在的問題
小程序仍然使用WebView渲染,并非原生渲染
需要獨立開發(fā),不能在非微信環(huán)境運行 。
開發(fā)者不可以擴展新組件。
依賴瀏覽器環(huán)境的js庫不能使用,因為是JSCore執(zhí)行的,沒有window、document對象。
WXSS中無法使用本地(圖片、字體等)。
WXSS轉(zhuǎn)化成js 而不是css。
WXSS不支持級聯(lián)選擇器。
小程序無法打開頁面,無法拉起APP。
2、小程序的優(yōu)點
提前新建WebView,準備新頁面渲染。
View層和邏輯層分離,通過數(shù)據(jù)驅(qū)動,不直接操作DOM。
使用Virtual DOM,進行局部更新。
全部使用https,確保傳輸中安全。
加入rpx單位,隔離設(shè)備尺寸,方便開發(fā)。
rpx(responsive pixel):
可以根據(jù)屏幕寬度進行自適應(yīng)。規(guī)定屏幕寬為750rpx。
如在 iPhone6 上,屏幕寬度為375px,共有750個物理像素,則750rpx = 375px = 750物理像素,
1rpx = 0.5px = 1物理像素。
設(shè)備 rpx換算px (屏幕寬度/750) px換算rpx (750/屏幕寬度)
iPhone5 1rpx = 0.42px 1px = 2.34rpx
iPhone6 1rpx = 0.5px 1px = 2rpx
iPhone6Plus 1rpx = 0.552px 1px = 1.81rpx
七、代碼運行
運行時,外面包裹define,代碼作為回到,當調(diào)用回調(diào)時,只傳入前面三個值,由于后面的變量都是局部定義的變量,就屏蔽了(window,document等這些變量.


其中O就是上面define('app.js',callback),的回調(diào),回調(diào)值傳入了三個參數(shù),屏蔽了其他屬性
八、優(yōu)化建議(官方建議)
setData 工作原理
小程序的視圖層目前使用 WebView 作為渲染載體,而邏輯層是由獨立的 JavascriptCore 作為運行環(huán)境。在架構(gòu)上,WebView 和 JavascriptCore 都是獨立的模塊,并不具備數(shù)據(jù)直接共享的通道。當前,視圖層和邏輯層的數(shù)據(jù)傳輸,實際上通過兩邊提供的 evaluateJavascript 所實現(xiàn)。即用戶傳輸?shù)臄?shù)據(jù),需要將其轉(zhuǎn)換為字符串形式傳遞,同時把轉(zhuǎn)換后的數(shù)據(jù)內(nèi)容拼接成一份 JS 腳本,再通過執(zhí)行 JS 腳本的形式傳遞到兩邊獨立環(huán)境。
而 evaluateJavascript 的執(zhí)行會受很多方面的影響,數(shù)據(jù)到達視圖層并不是實時的。
常見的 setData 操作錯誤
1. 頻繁的去 setData
在我們分析過的一些案例里,部分小程序會非常頻繁(毫秒級)的去 setData ,其導(dǎo)致了兩個后果:
- Android 下用戶在滑動時會感覺到卡頓,操作反饋延遲嚴重,因為 JS 線程一直在編譯執(zhí)行渲染,未能及時將用戶操作事件傳遞到邏輯層,邏輯層亦無法及時將操作處理結(jié)果及時傳遞到視圖層;
- 渲染有出現(xiàn)延時,由于 WebView 的 JS 線程一直處于忙碌狀態(tài),邏輯層到頁面層的通信耗時上升,視圖層收到的數(shù)據(jù)消息時距離發(fā)出時間已經(jīng)過去了幾百毫秒,渲染的結(jié)果并不實時;
2. 每次 setData 都傳遞大量新數(shù)據(jù)
由 setData 的底層實現(xiàn)可知,我們的數(shù)據(jù)傳輸實際是一次 evaluateJavascript 腳本過程,當數(shù)據(jù)量過大時會增加腳本的編譯執(zhí)行時間,占用 WebView JS 線程,
3. 后臺態(tài)頁面進行 setData
當頁面進入后臺態(tài)(用戶不可見),不應(yīng)該繼續(xù)去進行 setData ,后臺態(tài)頁面的渲染用戶是無法感受的,另外后臺態(tài)頁面去 setData 也會搶占前臺頁面的執(zhí)行。
圖片資源
- 目前圖片資源的主要性能問題在于大圖片和長列表圖片上,這兩種情況都有可能導(dǎo)致 iOS 客戶端內(nèi)存占用上升,從而觸發(fā)系統(tǒng)回收小程序頁面。
- 在 iOS 上,小程序的頁面是由多個 WKWebView 組成的,在系統(tǒng)內(nèi)存緊張時,會回收掉一部分 WKWebView。從過去我們分析的案例來看,大圖片和長列表圖片的使用會引起 WKWebView 的回收。
代碼包大小的優(yōu)化
開發(fā)者在實現(xiàn)業(yè)務(wù)邏輯同時也有必要盡量減少代碼包的大小,因為代碼包大小直接影響到下載速度,從而影響用戶的首次打開體驗。除了代碼自身的重構(gòu)優(yōu)化外,還可以從這兩方面著手優(yōu)化代碼大小:
-
分包加載
對小程序進行分包,可以優(yōu)化小程序首次啟動的下載時間 - 清理沒有使用到的代碼和資源
目前小程序打包是會將工程下所有文件都打入代碼包內(nèi),也就是說,這些沒有被實際使用到的庫文件和資源也會被打入到代碼包里,從而影響到整體代碼包的大小。
預(yù)先加載數(shù)據(jù)
原理
小程序在啟動時,會直接加載所有頁面邏輯代碼進內(nèi)存,即便 page2 可能都不會被使用。在 page1 跳轉(zhuǎn)至 page2 時,page1 的邏輯代碼 Javascript 數(shù)據(jù)也不會從內(nèi)存中消失。page2 甚至可以直接訪問 page1 中的數(shù)據(jù)。
小程序的這種機制差異正好可以更好的實現(xiàn)預(yù)加載。通常情況下,我們習慣將數(shù)據(jù)拉取寫在 onLoad 事件中。但是小程序的 page1 跳轉(zhuǎn)到 page2,到 page2 的 onLoad 是存在一個 300ms ~ 400ms 的延時的。如下圖:

因為小程序的特性,完全可以在 page1 中預(yù)先拿取數(shù)據(jù),然后在 page2 中直接使用數(shù)據(jù),這樣就可以避開 redirecting 的 300ms ~ 400ms了。如下圖:

渲染view線程和AppServcie是相互獨立的,對于AppServcie中js運行不會阻塞view的渲染
官方的示例也是采用這種方式: 先App中請求數(shù)據(jù),在index.js使用數(shù)據(jù)


具體可以參考這篇文檔( https://mp.weixin.qq.com/s/EvzQoSwWYUmShtI_MkrFuQ )
有錯誤的地方歡迎指出,共同進步
最后遇到相關(guān)問題開發(fā)者社區(qū)搜索問題
參考內(nèi)容:
- 微信小程序架構(gòu)解析
- 微信小程序weapp的底層實現(xiàn)原理
- Web Components 是個什么樣的東西
- 微信小程序開發(fā)深入解讀
- 云+社區(qū)技術(shù)沙龍--WeGeek微信小程序敏捷開發(fā)實戰(zhàn)
- 理解微信小程序技術(shù)架構(gòu)
- 微信小程序架構(gòu)分析 (上)
作者:litongqian
鏈接:微信小程序運行流程看這篇就夠了-教程-小程序社區(qū)-微信小程序-微信小程序開發(fā)社區(qū)-小程序開發(fā)論壇-微信小程序聯(lián)盟
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán),非商業(yè)轉(zhuǎn)載請注明出處。