小程序使用view標籤而不使用div的底層原因
- 2019 年 11 月 5 日
- 筆記
記一下為什麼小程序非要使用自己封裝的標籤
核心原因就是為了解決管控與安全問題
基於Web技術來渲染小程序存在一些問題
- 不可控因素
- 安全風險
Web技術是非常開放靈活的，我們可以利用JavaScript腳本隨意地跳轉網頁或者改變界面上的任意內容。
小程序原本定義了一套內置組件以提供統一的體驗，用戶進入小程序時，小程序代碼包會被拉到本地使得小程序可以離線瀏覽（只要小程序開發者把一些應用數據緩存到了本地），但要是開發者通過JavaScript 把渲染小程序的 WebView 跳轉到其他在線網頁，這個體驗就變得非常糟。
提供一種可以展示敏感數據的組件（這些數據只能被展示，開發者並不能拿到數據），若開發者可以通過JavaScript 操作界面（DOM樹），從而直接獲取這些敏感數據，那小程序毫無安全可言。
這就導致必須阻止開發者使用一些瀏覽器提供的，諸如跳轉頁面、操作DOM、動態執行腳本的開放性接口。一個一個禁止勢必會進入一個攻防戰，因為 JavaScript 的靈活性以及瀏覽器接口的豐富性，很容易遺漏一些危險的接口，而且就算被我們找到所有危險的接口，也許在下一次瀏覽器內核更新而新增了一個可能會在這套體系下產生漏洞的接口，這樣還是無法完全避免。
要徹底解決這個問題，我們必須提供一個沙箱環境來運行開發者的JavaScript 代碼。這個沙箱環境不能有任何瀏覽器相關接口，只提供純JavaScript 的解釋執行環境，那麼像HTML5中的ServiceWorker、WebWorker特性就符合這樣的條件，這兩者都是啟用另一線程來執行 JavaScript。但是考慮到小程序是一個多 WebView 的架構，每一個小程序頁面都是不同的WebView 渲染後顯示的，在這個架構下我們不好去用某個WebView中的ServiceWorker去管理所有的小程序頁面。
得益於客戶端系統有JavaScript 的解釋引擎（在iOS下是用內置的 JavaScriptCore框架，在安卓則是用騰訊x5內核提供的JsCore環境），我們可以創建一個單獨的線程去執行 JavaScript，在這個環境下執行的都是有關小程序業務邏輯的代碼，也就是我們前面一直提到的邏輯層。而界面渲染相關的任務全都在WebView線程里執行，通過邏輯層代碼去控制渲染哪些界面，那麼這一層當然就是所謂的渲染層。這就是小程序雙線程模型的由來。
