小程序技術方案探討

微信小程序上線大半年，大部分技術原理也有文章介紹了，本文嘗試從需求出發探討微信小程序技術方案的來源，以及最近公測的支付寶小程序技術方案上的考量。

微信小程序

微信小程序的需求是讓第三方開發者能夠接入，能夠使用微信的提供的接口去開發應用嵌入在微信裏。對於這個需求，最簡單的實現方案是：讓外部開發者開發純H5應用，在微信的 H5 容器裏打開，容器提供微信 native 接口，就好了。在有小程序以前，已經有不少這樣的業務接入，像京東購物，錢包裏的各類友商大衆點評/滴滴出行等，均可以認爲是一個「小程序」，內嵌在微信裏，能調用微信 native 接口，是否是沿着這種模式下去，把相應的接口開放給第三方，再提供個入口就好了？

實際上這種簡單的方案不能知足需求，在產品上微信小程序有另外兩個很重要的需求：

1. 管控。做爲一個平臺必須對接入的應用有管控能力，必須能儘可能精確控制應用的內容和類型，畢竟若出現非法應用平臺是要承擔責任的，H5 的方式太過自由，開發者能夠隨時改變整個應用的內容，平臺難以檢測到這些改變，沒法管控。另外H5開發質量良莠不齊，平臺也沒法管控，這對於一貫有潔癖的微信來講沒法接受。
2. 體驗。做爲一個「小程序」須要讓體驗接近原生，而上述像京東購物這些普通 H5 頁面的體驗不太行，包括啓動速度/頁面切換流暢度都有問題，跟原生體驗無法比。

全部小程序的技術方案都是爲了這兩個需求服務。

管控

爲了知足管控的需求，技術上微信作了兩個事情：小程序框架和分離JS運行環境。

框架/DSL

H5太自由，首先要作的就是限制它的自由，怎樣限制？天然是作個框架套住，讓開發者只能按框架的規則去開發。那應該使用怎樣的框架？

在 PC SNS 時代，Facebook 作開放平臺時有相似的場景，爲了第三方開發者能在 Facebook 平臺上開發，同時又能限制住開發者的權限，Facebook 要求開發者使用自定義的一套 DSL(FBML)去開發，而這個 DSL 能怎麼寫，最終能轉成什麼，如何執行，都是平臺說了算，同時也能夠很方便作代碼掃描和審查。

小程序正好能借鑑這樣的設計思路，界面不使用 HTML 開發，而是自定義一套 DSL，這樣就能夠很容易配合審覈/代碼掃描/域名限制等系列措施去作管控，這就是小程序這一套框架的來源。這套框架經過 wxml 去描述界面，wxss 描述樣式，js 去處理邏輯和數據，再經過工具一系列處理把這些轉爲 HTML/CSS/JS 顯示在 webview 上，並處理界面交互和數據更新。

這樣用一套框架去限制開發方式，再造一層 DSL，除了管控外還有一個好處，就是容易進行鍼對性優化，DSL 最終轉成什麼，最終如何執行渲染都由框架決定，上層不感知，能夠作成由 webview 渲染，有條件也能夠用相似RN的方案本身實現渲染層。

JS 環境

經過框架限定開發方式後，管控上還有個問題，就是如何限制應用端類JS語言調用dom API？小程序跑在 webview 上，渲染時必然要經過 JS 操做 dom，若是小程序框架和應用 JS 代碼都有權限操做 dom，應用可能會經過各類方式在上線後繞過檢查，注入 JS 調用 dom 接口去修改頁面結構和內容，變成跟審覈時不同的應用。怎樣能限制應用的 JS 調用 dom 的權限？微信想了個比較創新的解決方案，就是：JS 運行環境與瀏覽器分離，運行在單獨的 JS 引擎上。

脫離了瀏覽器，JS 天然沒有 dom 的調用權限，任何跟 webview 界面相關的 API 都沒法拿到。而小程序框架核心JS運行在webview上，能夠自由操做dom，經過小程序框架定義的機制，應用端經過 wxml/wxss 定義固定的渲染樣式，JS 端只管數據綁定，數據能夠經過 native 橋樑從 JS 引擎傳遞到 webview，JS端沒法作任何渲染相關的操做，能夠對渲染的內容有完整的管控權。

獨立的 JS 運行環境除了知足管控需求外，也額外帶來一些好處和一些壞處，好處在於：

1. 多個頁面能夠共享一個 JS 運行環境，數據能夠很方便地共享，整個小程序生命週期裏共享同一個上下文，更接近 APP 的開發體驗。
2. JS 與頁面渲染分離並行執行，不會出現 JS 執行時卡住頁面渲染的狀況，提高渲染性能。

壞處在於：

1. 多了數據序列化傳輸的開銷，數據須要從 JS 傳到 webview 給視圖層渲染，須要序列化爲字符串格式再進行傳輸。
2. iOS 上 WKWebview 的 JS 引擎比 JavaScriptCore 多了 JIT 優化，執行速度快不少倍，小程序的 JS 運行在 JavaScriptCore 上沒法享受到這個優化。

因爲管控需求過於剛需，這個方案帶來壞處能夠接受。

體驗

小程序最主要的兩個技術點 — 框架和JS運行分離 都是源自管控需求，而體驗上的需求就是由各類細緻的性能優化組成了，不少文章也分析過，這裏簡單說下，包括：

1. 離線包：整個小程序打包下發，不須要打開每一個頁面都去請求，減小第二次打開時間以及頁面切換時間。
2. 預加載：預加載多一個wkwebview放後臺，用戶打開小程序時省去初始化wkwebview時間。另外對於一個小程序內的頁面切換，得益於框架的設計，能夠作到預渲染模板，切換時再填充數據，加快渲染速度。
3. 緩存：退出小程序後不會當即銷燬，會在後臺繼續跑5分鐘，在這期間用戶切回小程序時速度快。
4. 視覺：小程序首次加載經過loading和動畫的方式過渡，拒絕白屏，給人一種快的感受，同時提高了小程序的標識度。

剩下的就是圍繞小程序這個平臺的周邊建設了，像組件，native接口，IDE，後臺管理，版本管理，權限控制等基礎支持。