運行流程

運行流程

來源 https://zhuanlan.zhihu.com/p/36997098

 

一.微信小程序是啥

本質其實就是（混合）的app 介於web app與native 原生app之間，具有豐富的調用手機各類功能的接口，同時又具有靈活性，跨平臺

1. 運行環境差別

微信小程序運行在三端：iOS、Android 和 用於調試的開發者工具。
三端的腳本執行環境以及用於渲染非原生組件的環境是各不相同的：

• 在 iOS 上，小程序的 javascript 代碼是運行在 JavaScriptCore 中，是由 WKWebView 來渲染的，環境有 iOS八、iOS九、iOS10
• 在 Android 上，小程序的 javascript 代碼是經過 X5 JSCore來解析，是由 X5 基於 Mobile Chrome 53/57 內核來渲染的
• 在 開發工具上， 小程序的 javascript 代碼是運行在 nwjs 中，是由 Chrome Webview 來渲染的來自官方文檔說明

2.小程序目錄結

project
├── pages
| ├── index
| | ├── index.json index 頁面配置
| | ├── index.js index 頁面邏輯
| | ├── index.wxml index 頁面結構
| | └── index.wxss index 頁面樣式表
| └── log
| ├── log.json log 頁面配置
| ├── log.wxml log 頁面邏輯
| ├── log.js log 頁面結構
| └── log.wxss log 頁面樣式表
├── app.js 小程序邏輯
├── app.json 小程序公共設置
└── app.wxss 小程序公共樣式表

3.爲何小程序比較快

 

2、小程序架構

微信小程序的框架包含兩部分View視圖層(可能存在多個)、App Service邏輯層(一個)，View層用來渲染頁面結構，AppService層用來邏輯處理、數據請求、接口調用，它們在兩個線程裏運行。
視圖層使用WebView渲染，邏輯層使用JSCore運行。
視圖層和邏輯層經過系統層的WeixinJsBridage進行通訊，邏輯層把數據變化通知到視圖層，觸發視圖層頁面更新，視圖層把觸發的事件通知到邏輯層進行業務處理。

重點講一下wxs :
因爲view 與 App Service是不一樣線程,以前是傳遞數據,當遇到一些數據須要在view中處理時,就能夠用wxs來處理,以下所示定義 <wxs module="tools">,使用說明

index.js

//獲取應用實例
const app = getApp()
Page({
  data: {
    motto: 'Hello World',
    userInfo: {},
    hasUserInfo: false
  },
 //事件處理函數
  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>

3、小程序啓動加載

運行機制

小程序啓動會有兩種狀況，一種是「冷啓動」，一種是「熱啓動」。 假如用戶已經打開過某小程序，而後在必定時間內再次打開該小程序，此時無需從新啓動，只需將後臺態的小程序切換到前臺，這個過程就是熱啓動；冷啓動指的是用戶首次打開或小程序被微信主動銷燬後再次打開的狀況，此時小程序須要從新加載啓動。

更新機制

小程序冷啓動時若是發現有新版本，將會異步下載新版本的代碼包，並同時用客戶端本地的包進行啓動，即新版本的小程序須要等下一次冷啓動纔會應用上。 若是須要立刻應用最新版本，可使用wx.getUpdateManager API 進行處理。

運行機制

• 小程序沒有重啓的概念
• 當小程序進入後臺，客戶端會維持一段時間的運行狀態，超過必定時間後（目前是5分鐘）會被微信主動銷燬
• 當短期內（5s）連續收到兩次以上收到系統內存告警，會進行小程序的銷燬

 

4、View (頁面視圖)

視圖層由 WXML 與 WXSS 編寫，由組件來進行展現。
將邏輯層的數據反應成視圖，同時將視圖層的事件發送給邏輯層。

一、View - WXML
wxml編譯器：wcc 把wxml文件 轉爲 js 執行方式：wcc index.wxml

二、View - WXSS

• WXSS(WeiXin Style Sheets)
• wxss編譯器：wcsc 把wxss文件轉化爲 js 執行方式： wcsc index.wxss

三、View - Component

• 小程序的組件基於Web Component標準
• 使用Polymer框架實現Web Component

四、View - Native Component

• 目前Native實現的組件有 <canvas/> <video/> <map/> <textarea/>
• Native組件層在WebView層之上

 

5、WebView預加載

每次小程序進入除了當前頁面,Native預先額外加載一個WebView
當打開指定頁面時，用默認數據直接渲染，請求數據回來時局部更新
返回顯示歷史View
退出小程序，View狀態不銷燬

6、App Service(邏輯層)

邏輯層將數據進行處理後發送給視圖層，同時接受視圖層的事件反饋
一、App( ) 小程序的入口；Page( ) 頁面的入口
三、提供豐富的 API，如微信用戶數據，掃一掃，支付等微信特有能力。
四、每一個頁面有獨立的做用域，並提供模塊化能力。
五、數據綁定、事件分發、生命週期管理、路由管理

運行環境
IOS - JSCore
Android - X5 JS解析器
DevTool - nwjs Chrome 內核

一、App Service - Binding

• 數據綁定使用 Mustache 語法（雙大括號）將變量包起來，動態數據均來自對應 Page 的 data，能夠經過setData方法修改數據。
• 事件綁定的寫法同組件的屬性，以 key、value 的形式，key 以bind或catch開頭，而後跟上事件的類型，如bindtap, catchtouchstart，value 是一個字符串，須要在對應的 Page 中定義同名的函數。

二、App Service - Life Cylce

三、App Service - API
API經過WeixinJSBridge和Native 進行通訊

四、App Service - Router

• navigateTo(OBJECT)

保留當前頁面，跳轉到應用內的某個頁面，使用navigateBack能夠返回到原頁面。頁面路徑只能是五層

• redirectTo(OBJECT)

關閉當前頁面，跳轉到應用內的某個頁面。

• navigateBack(OBJECT)

關閉當前頁面，返回上一頁面或多級頁面。可經過 getCurrentPages()) 獲取當前的頁面棧，決定須要返回幾層。

5、小程序開發經驗

一、小程序存在的問題
小程序仍然使用WebView渲染，並不是原生渲染
須要獨立開發，不能在非微信環境運行 。
開發者不能夠擴展新組件。
依賴瀏覽器環境的js庫不能使用，由於是JSCore執行的，沒有window、document對象。
WXSS中沒法使用本地（圖片、字體等）。
WXSS轉化成js 而不是css。
WXSS不支持級聯選擇器。
小程序沒法打開頁面，沒法拉起APP。

二、小程序的優勢
提早新建WebView，準備新頁面渲染。
View層和邏輯層分離，經過數據驅動，不直接操做DOM。
使用Virtual DOM，進行局部更新。
所有使用https，確保傳輸中安全。
加入rpx單位，隔離設備尺寸，方便開發。

rpx（responsive pixel）:
能夠根據屏幕寬度進行自適應。規定屏幕寬爲750rpx。
如在 iPhone6 上，屏幕寬度爲375px，共有750個物理像素，則750rpx = 375px = 750物理像素，
1rpx = 0.5px = 1物理像素。
設備 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

 

7、代碼運行

運行時,外面包裹define,代碼做爲回到,當調用回調時,只傳入前面三個值,因爲後面的變量都是局部定義的變量,就屏蔽了(window,document等這些變量.

其中O就是上面define('app.js',callback),的回調,回調值傳入了三個參數,屏蔽了其餘屬性

8、優化建議(官方建議)

setData 工做原理
小程序的視圖層目前使用 WebView 做爲渲染載體，而邏輯層是由獨立的 JavascriptCore 做爲運行環境。在架構上，WebView 和 JavascriptCore 都是獨立的模塊，並不具有數據直接共享的通道。當前，視圖層和邏輯層的數據傳輸，實際上經過兩邊提供的 evaluateJavascript 所實現。即用戶傳輸的數據，須要將其轉換爲字符串形式傳遞，同時把轉換後的數據內容拼接成一份 JS 腳本，再經過執行 JS 腳本的形式傳遞到兩邊獨立環境。
而 evaluateJavascript 的執行會受不少方面的影響，數據到達視圖層並非實時的。

常見的 setData 操做錯誤
1. 頻繁的去 setData
在咱們分析過的一些案例裏，部分小程序會很是頻繁（毫秒級）的去 setData ，其致使了兩個後果：

• Android 下用戶在滑動時會感受到卡頓，操做反饋延遲嚴重，由於 JS 線程一直在編譯執行渲染，未能及時將用戶操做事件傳遞到邏輯層，邏輯層亦沒法及時將操做處理結果及時傳遞到視圖層；
• 渲染有出現延時，因爲 WebView 的 JS 線程一直處於忙碌狀態，邏輯層到頁面層的通訊耗時上升，視圖層收到的數據消息時距離發出時間已通過去了幾百毫秒，渲染的結果並不實時；

2. 每次 setData 都傳遞大量新數據
由 setData 的底層實現可知，咱們的數據傳輸實際是一次 evaluateJavascript 腳本過程，當數據量過大時會增長腳本的編譯執行時間，佔用 WebView JS 線程，
3. 後臺態頁面進行 setData
當頁面進入後臺態（用戶不可見），不該該繼續去進行 setData ，後臺態頁面的渲染用戶是沒法感覺的，另外後臺態頁面去 setData 也會搶佔前臺頁面的執行。
圖片資源

• 目前圖片資源的主要性能問題在於大圖片和長列表圖片上，這兩種狀況都有可能致使 iOS 客戶端內存佔用上升，從而觸發系統回收小程序頁面。
• 在 iOS 上，小程序的頁面是由多個 WKWebView 組成的，在系統內存緊張時，會回收掉一部分 WKWebView。從過去咱們分析的案例來看，大圖片和長列表圖片的使用會引發 WKWebView 的回收。

 

代碼包大小的優化

開發者在實現業務邏輯同時也有必要儘可能減小代碼包的大小，由於代碼包大小直接影響到下載速度，從而影響用戶的首次打開體驗。除了代碼自身的重構優化外，還能夠從這兩方面着手優化代碼大小：

1. 分包加載
   對小程序進行分包，能夠優化小程序首次啓動的下載時間
2. 清理沒有使用到的代碼和資源

目前小程序打包是會將工程下全部文件都打入代碼包內，也就是說，這些沒有被實際使用到的庫文件和資源也會被打入到代碼包裏，從而影響到總體代碼包的大小。
預先加載數據
原理
小程序在啓動時，會直接加載全部頁面邏輯代碼進內存，即使 page2 可能都不會被使用。在 page1 跳轉至 page2 時，page1 的邏輯代碼 Javascript 數據也不會從內存中消失。page2 甚至能夠直接訪問 page1 中的數據。
小程序的這種機制差別正好能夠更好的實現預加載。一般狀況下，咱們習慣將數據拉取寫在 onLoad 事件中。可是小程序的 page1 跳轉到 page2，到 page2 的 onLoad 是存在一個 300ms ~ 400ms 的延時的。以下圖：

由於小程序的特性，徹底能夠在 page1 中預先拿取數據，而後在 page2 中直接使用數據，這樣就能夠避開 redirecting 的 300ms ~ 400ms了。以下圖：

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

 

 

 

具體能夠參考這篇文檔( https://mp.weixin.qq.com/s/EvzQoSwWYUmShtI_MkrFuQ )
有錯誤的地方歡迎指出,共同進步
最後遇到相關問題開發者社區搜索問題
參考內容:

• 微信小程序架構解析
• 微信小程序weapp的底層實現原理
• Web Components 是個什麼樣的東西
• 微信小程序開發深刻解讀
• 雲+社區技術沙龍--WeGeek微信小程序敏捷開發實戰
• 理解微信小程序技術架構
• 微信小程序架構分析 (上)

 

============== End