小程式使用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框架，在Android則是用騰訊x5內核提供的JsCore環境），我們可以創建一個單獨的執行緒去執行 JavaScript，在這個環境下執行的都是有關小程式業務邏輯的程式碼，也就是我們前面一直提到的邏輯層。而介面渲染相關的任務全都在WebView執行緒里執行，通過邏輯層程式碼去控制渲染哪些介面，那麼這一層當然就是所謂的渲染層。這就是小程式雙執行緒模型的由來。
