正常來說，微信小程序是依賴於微信客戶端上運行的，並且跟小程序基礎庫（包括了小程序的整個運行環境以及基礎能力，跟具體小程序無關）版本有重大關聯關係。
我們可以把微信客戶端以及小程序基礎庫簡稱爲宿主環境（就算去開發類似於百度小程序、字節跳動小程序、京東小程序，它們的概念都是想通的）。
小程序可以調用宿主環境提供的微信客戶端的能力，這就使得小程序比普通網頁擁有更多的能力。小程序會運行在不同版本（不同的微信客戶端+不同基礎庫）的宿主環境下，因此針對各個版本的宿主環境做程序上的兼容也是在所難免的。
渲染層和邏輯層
小程序的運行環境分成渲染層和邏輯層，分工明確。
WXML模板和WXSS樣式工作在渲染層，負責展示數據JS腳本工作在邏輯層，負責產生、處理數據，通過Page 實例或者Component實例的 setData 方法傳遞數據到渲染層。
WXML模板可以使用 view等 標籤，其節點用 {{ }} 的語法綁定一個 數據變量；
WXSS 樣式負責整體展示效果，類似於位置、寬高、字體顏色等等；
JS 腳本使用 this.setData 方法來修改數據變量達到動態修改 WXML顯示內容；
通信模型
小程序的渲染層和邏輯層分別由2個線程管理：渲染層的界面使用了WebView 進行渲染；邏輯層採用JsCore線程運行JS腳本。
一個小程序存在多個界面，所以渲染層存在多個WebView線程，這兩個線程的通信會經由微信客戶端（下文中也會採用Native來代指微信客戶端）做中轉，邏輯層發送網絡請求也經由Native轉發，小程序的通信模型如圖3-1所示。
從這個圖，理解出以下內容：
- 整個圖有點類似於Android
MVP的設計概念，渲染層負責渲染繪製相關內容，也就是View層，邏輯層處理網絡請求，產生處理數據，也就是Model層，Native類似於Presenter層，負責協調邏輯層（Model）和渲染層（View）之間的操作關係，邏輯層和渲染層不直接進行交互。三者職責分離。 - 邏輯層運行在一個單獨線程，負責執行JsCore，也就是我們小程序代碼中的那一堆JS代碼，而渲染層運行於另一個UI單獨線程，負責繪製內容，並且維護了一個頁面棧（android開發工程師應該對頁面棧很熟悉，特別是Activity生命週期），每一個Page對應一個Webview，由於有多個頁面，也就意味着有多個Webview。
- 所有的網絡請求都是通過Native去調用，也就是JsCore的網絡請求最終都會經過Native去執行，也就是通過微信客戶端本身的網絡庫去執行。
數據驅動
在開發UI界面過程中，程序需要維護很多變量狀態，同時要操作對應的UI元素。隨着界面越來越複雜，我們需要維護很多變量狀態，同時要處理很多界面上的交互事件，整個程序變得越來越複雜。通常界面視圖和變量狀態是相關聯的，如果有某種“方法”可以讓狀態和視圖綁定在一起（狀態變更時，視圖也能自動變更，MVVM），那我們就可以省去手動修改視圖的工作。
這個方法就是“數據驅動。
WXML結構實際上等價於一棵Dom樹（但是小程序中沒有支持直接操作DOM），通過一個JS對象也可以來表達Dom樹的結構。
WXML可以先轉成JS對象，然後再渲染出真正的Dom樹。
通過setData把msg數據從“Hello World”變成“Goodbye”，產生的JS對象對應的節點就會發生變化，此時可以對比前後兩個JS對象得到變化的部分，然後把這個差異應用到原來的Dom樹上，從而達到更新UI的目的，這就是“數據驅動”的原理。
快速對比出修改點，再把修改點體現在Dom樹上（那麼，思考點，如果數據點很多或者多次調用setData會怎麼樣？）。
雙線程下的界面渲染
小程序的邏輯層和渲染層是分開的兩個線程。在渲染層，宿主環境會把WXML轉化成對應的JS對象，在邏輯層發生數據變更的時候，我們需要通過宿主環境提供的setData方法把數據從邏輯層傳遞到渲染層，再經過對比前後差異，把差異應用在原來的Dom樹上，渲染出正確的UI界面。
