一、背景
網(wǎng)頁開發(fā)，渲染線程和腳本是互斥的，這也是為什么長時間的腳本運行可能會導(dǎo)致頁面失去響應(yīng)的原因，本質(zhì)就是我們常說的 JS 是單線程的。
而在小程序中，選擇了 Hybrid 的渲染方式，將視圖層和邏輯層是分開的，雙線程同時運行，視圖層的界面使用 WebView 進行渲染，邏輯層運行在 JSCore 中。
1.渲染層：界面渲染相關(guān)的任務(wù)全都在 WebView 線程里執(zhí)行。一個小程序存在多個界面，所以渲染層存在多個 WebView 線程。
2.邏輯層：采用 JsCore 線程運行 JS 腳本，在這個環(huán)境下執(zhí)行的都是有關(guān)小程序業(yè)務(wù)邏輯的代碼。
二、通信
小程序在渲染層，宿主環(huán)境會把wxml轉(zhuǎn)化成對應(yīng)的JS對象。
在邏輯層發(fā)生數(shù)據(jù)變更的時候，通過宿主環(huán)境提供的setData方法把數(shù)據(jù)從邏輯層傳遞到渲染層，再經(jīng)過對比前后差異，把差異應(yīng)用在原來的Dom樹上，渲染出正確的視圖。
當(dāng)視圖存在交互的時候，例如用戶點擊你界面上某個按鈕，這類反饋應(yīng)該通知給開發(fā)者的邏輯層，需要將對應(yīng)的處理狀態(tài)呈現(xiàn)給用戶。
對于事件的分發(fā)處理，微信進行了特殊的處理，將所有的事件攔截后，丟到邏輯層交給JavaScript進行處理。
由于小程序是基于雙線程的，也就是任何在視圖層和邏輯層之間的數(shù)據(jù)傳遞都是線程間的通信，會有一定的延時，因此在小程序中，頁面更新成了異步操作。
異步會使得各部分的運行時序變得復(fù)雜一些，比如在渲染首屏的時候，邏輯層與渲染層會同時開始初始化工作，但是渲染層需要有邏輯層的數(shù)據(jù)才能把界面渲染出來。
如果渲染層初始化工作較快完成，就要等邏輯層的指令才能進行下一步工作。
因此邏輯層與渲染層需要有一定的機制保證時序正確，在每個小程序頁面的生命周期中，存在著若干次頁面數(shù)據(jù)通信。
三、運行機制
小程序啟動運行兩種情況：
1.冷啟動（重新開始）：用戶首次打開或者小程序被微信主動銷毀后再次打開的情況，此時小程序需要重新加載啟動，即為冷啟動。
2.熱啟動：用戶已經(jīng)打開過小程序，然后在一定時間內(nèi)再次打開該小程序，此時無需重新啟動，只需要將后臺態(tài)的小程序切換到前臺，這個過程就是熱啟動。
需要注意：
1.小程序沒有重啟的概念
2.當(dāng)小程序進入后臺，客戶端會維持一段時間的運行狀態(tài)，超過一定時間后會被微信主動銷毀
3.短時間內(nèi)收到系統(tǒng)兩次以上內(nèi)存警告，也會對小程序進行銷毀，這也就為什么一旦頁面內(nèi)存溢出，頁面會奔潰的本質(zhì)原因了
開發(fā)者在后臺發(fā)布新版本之后，無法立刻影響到所有現(xiàn)網(wǎng)用戶，但最差情況下，也在發(fā)布之后 24 小時之內(nèi)下發(fā)新版本信息到用戶。
每次冷啟動時，都會檢查是否有更新版本，如果發(fā)現(xiàn)有新版本，將會異步下載新版本的代碼包，并同時用客戶端本地的包進行啟動，即新版本的小程序需要等下一次冷啟動才會應(yīng)用上。
參考資料：微信公眾號：JS每日一題
這篇文章是轉(zhuǎn)載：JS每日一題
