簡單說說微信小程序的底層原理

小程序選擇了 Hybrid 的渲染方式，將UI渲染跟 JavaScript 的腳本執行分在了兩個線程。

雙線程模型

小程序的渲染層和邏輯層分別由兩個線程管理：

• 渲染層：界面渲染相關的任務全都在 WebView 線程裏執行。一個小程序存在多個界面，因此渲染層存在多個WebView 線程。
• 邏輯層：採用JsCore 線程運行JS腳本，在這個環境下執行的都是有關小程序業務邏輯的代碼。

雙線程之間的通訊

咱們都知道小程序是避免DOM操做，而是採用數據驅動來渲染頁面的，那麼他究竟是怎麼經過更改數據來更新DOM呢。

邏輯層和渲染層的通訊會由 Native （微信客戶端）作中轉，邏輯層發送網絡請求也經由 Native 轉發。經過把 WXML 轉化爲數據，經過 Native 進行轉發，來實現邏輯層和渲染層的交互和通訊。

1. 在渲染層會把WNML轉化成Js對象，Js對象會模擬DOM樹
2. 邏輯層更新數據的時候，經過setData方法將數據從邏輯層轉發到Native,Native再轉發到渲染層
3. 這時候，比較兩虛擬DOM樹的差別，最後將差別應用到真實DOM樹上，更新頁面。

Virtual DOM 相信你們都已有了解，大概是這麼個過程：用JS對象模擬DOM樹 -> 比較兩棵虛擬DOM樹的差別 -> 把差別應用到真正的DOM樹上。

小程序的生命週期

小程序的生命週期借鑑了Android的生命週期，若是你瞭解過Android的APP開發，那麼理解小程序的就會很簡單。

界面線程有四大狀態：

• 初始化狀態：初始化界面線程所須要的工做，包括工做機制，基本和咱們開發者沒有關係，等初始化完畢就向「服務線程」發送初始化完畢信號，而後進入等待傳回初始化數據狀態。

• 首次渲染狀態：收到「服務線程」發來的初始化數據後（就是 json和js中的data數據），就開始渲染小程序界面，渲染完畢後，發送「首次渲染完畢信號」給服務線程，並將頁面展現給用戶。

• 持續渲染狀態：此時界面線程繼續一直等待「服務線程」經過this.setdata（）函數發送來的界面數據，只要收到就從新局部渲染，也所以只要更新數據併發送信號，界面就自動更新。

• 結束狀態：結束渲染。

服務線程五大狀態：

• 初始化狀態：無需和其餘模塊交流，跟小程序開發也沒多大關聯，此階段就是啓動服務線程所需的基本功能，好比信號發送模塊。系統的初始化工做完畢，就調用自定義的onload和onshow， 而後等待界面線程的「界面線程初始化完成」信號。

onload是隻會首次渲染的時候執行一次，onshow是每次界面切換都會執行，簡單理解，這就是惟一差異。

• 等待激活狀態：接收到「界面線程初始化完成」信號後，將初始化數據發送給「界面線程」，等待界面線程完成初次渲染。

• 激活狀態：收到界面線程發送來的「首次渲染完成」信號後，就進入激活狀態既程序的正常運行狀態，並調用自定義的onReady()函數。

此狀態下就能夠經過 this.setData 函數發送界面數據給界面線程進行局部渲染，更新頁面。

• 後臺運行狀態：若是界面進入後臺，服務線程就進入後臺運行狀態，從目前的官方解讀來講，這個狀態挺奇怪的，和激活狀態是相同的，也能夠經過setdata函數更新界面的。畢竟小程序的框架剛推出，應該後續會有很大不一樣吧。

運行機制

啓動

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

銷燬

只有當小程序進入後臺必定時間，或者系統資源佔用太高，纔會被真正的銷燬。

更新機制

開發者在後臺發佈新版本以後，沒法馬上影響到全部現網用戶，但最差狀況下，也在發佈以後 24 小時以內下發新版本信息到用戶。

小程序每次冷啓動時，都會檢查是否有更新版本，若是發現有新版本，將會異步下載新版本的代碼包，並同時用客戶端本地的包進行啓動，即新版本的小程序須要等下一次冷啓動纔會應用上。

因此若是想讓用戶使用最新版本的小程序，能夠利用 wx.getUpdateManager 作個檢查更新的功能