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

1. 運行環境差異

微信小程序運行在三端：iOS、Android 和 用于調試的開發者工具。

三端的腳本執行環境以及用于渲染非原生組件的環境是各不相同的：

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

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            小程序公共樣式表

微信小程序的框架包含兩部分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>

三、小程序啟動加載

運行機制

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

更新機制

小程序冷啟動時如果發現有新版本，將會異步下載新版本的代碼包，并同時用客戶端本地的包進行啟動，即新版本的小程序需要等下一次冷啟動才會應用上。 如果需要馬上應用最新版本，可以使用wx.getUpdateManager API 進行處理。

運行機制

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

四、View (頁面視圖)

視圖層由 WXML 與 WXSS 編寫，由組件來進行展示。

將邏輯層的數據反應成視圖，同時將視圖層的事件發送給邏輯層。

1、View - WXML

wxml編譯器：wcc 把wxml文件 轉為 js 執行方式：wcc index.wxml

2、View - WXSS

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

3、View - Component

• 小程序的組件基于Web Component標準

• 使用Polymer框架實現Web Component

4、View - Native Component

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

五、WebView預加載

每次小程序進入除了當前頁面,Native預先額外加載一個WebView

當打開指定頁面時，用默認數據直接渲染，請求數據回來時局部更新

返回顯示歷史View

退出小程序，View狀態不銷毀

六、App Service(邏輯層)

邏輯層將數據進行處理后發送給視圖層，同時接受視圖層的事件反饋

1、App( ) 小程序的入口；Page( ) 頁面的入口

3、提供豐富的 API，如微信用戶數據，掃一掃，支付等微信特有能力。

4、每個頁面有獨立的作用域，并提供模塊化能力。

5、數據綁定、事件分發、生命周期管理、路由管理

運行環境

IOS - JSCore

Android - X5 JS解析器

DevTool - nwjs Chrome 內核

1、App Service - Binding

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

2、App Service - Life Cylce

3、App Service - API

API通過WeixinJSBridge和Native 進行通信

4、App Service - Router

• navigateTo(OBJECT)

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

• redirectTo(OBJECT)

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

• navigateBack(OBJECT)

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

五、小程序開發經驗

1、小程序存在的問題

小程序仍然使用WebView渲染，并非原生渲染

需要獨立開發，不能在非微信環境運行 。

開發者不可以擴展新組件。

依賴瀏覽器環境的js庫不能使用，因為是JSCore執行的，沒有window、document對象。

WXSS中無法使用本地（圖片、字體等）。

WXSS轉化成js 而不是css。

WXSS不支持級聯選擇器。

小程序無法打開頁面，無法拉起APP。

2、小程序的優點

提前新建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

七、代碼運行

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

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

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

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 ) 

有錯誤的地方歡迎指出,共同進步

最后遇到相關問題開發者社區搜索問題