整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
TML5課件
玩微信的朋友對HTML5都不陌生，它就像一個絕世大美女，一出場就受到了各方的強烈關注，自然也受到了移動學習平臺（m-learning）的青睞。HTML5的資本在于它支持跨平臺，在于它可以實現文字、圖片、表格、音頻、視頻的有機結合，在于它良好的交互性。
支持跨平臺學習
相對于傳統的HTML技術，HTML5針對終端設備增加了許多新特性，只需一個版本即可實現跨平臺、跨分辨率、終端自適應等。不需要再考慮是得用電腦還是手機，得用蘋果還是安卓。不管什么設備，只需要一個支持HTML5的瀏覽器，統統搞定。
HTML5的這個特性對于移動學習來說無疑是個特大好消息，簡直就是為了移動學習量身定做的。如此一來，HTML5課件可以跨平臺，并實現終端自適應，既節省了培訓課件開發者的時間，又能讓學員獲得良好一致的學習體驗。
文字、圖片、音頻、視頻等多種呈現方式
Web剛出現的時候，我們都在網上看些基礎文檔學習，隨著互聯網技術的發展，純靜態頁面已經難以吸引用戶的眼球，而HTML5課件的出現，讓人眼前一亮，音頻、視頻等多媒體元素的支持，讓學習內容變得更加豐富多彩，極大地提升了學員的學習興趣，這在課件形式上也是一場質的飛躍。
良好的交互性
上學的時候，老師都比較喜歡積極發言的同學，因為互動。同樣，在開發設計網頁課件時，教學設計人員也希望可以與用戶互動。HTML5的特性，正可以讓教學設計人員設計一些學習交互點，提升學員的學習參與度。
正因為HTML5課件有如此多特性，使得企業在培訓的微課形式上，更喜歡HTML5課件。思創擁有16年e-learning綜合服務經驗，為客戶提供課程定制開發服務，課件形式包括：快速開發、圖文類、綜合動畫、HTML5交互。
更多資訊關注微信公眾號：思創云學習
著各大平臺小程序的快速放量，開發者遇到越來越多的平臺適配問題。各平臺小程序的性能優化方法也各不相同，我們該如何應對？DCloud CTO 崔紅保在 GMTC 深圳 2019（全球大前端技術大會）分享了《小程序的未來方向》，介紹了小程序技術架構、性能卡點以及各平臺優化方案，對于小程序未來的技術更迭，提出了小程序在未來可能的發展方向。本文根據演講內容整理而成。
簡單介紹一下我自己，中年碼農，跨平臺開發領域的老兵。在那個翻蓋摩托羅拉手機代表著先進和時髦的年代，我就開始參與 “window mobile/j2me/symbain” 等系統的跨平臺研發管理工作，可能很多同學都沒見過那些手機。到后來的移動互聯網時代及當下的小程序時代，我也一直在深度參與其中，持續輸出“Hybrid App”引擎、前端 UI 庫（mui）及小程序跨端開發框架（uni-app）。目前在 DCloud 任職 CTO，同時兼 “uni-app” 產品負責人。
羅馬不是一天建成的，小程序也不是一天發明的。小程序這種介于 H5 和 Native App 之間的特殊應用形態，從探索到成熟，經歷了哪些過程？我們首先帶大家回顧梳理一下。然后，從現有技術架構出發，分析小程序當下幾個主要性能坑點。各家小程序引擎為解決這些坑點，做了哪些完善工作。比如，大家知道小程序是以 Web 渲染為主、原生渲染為輔，那引入原生渲染后，引發了哪些新的問題？為解決這些問題，微信提出了同層渲染的方案，同層渲染在技術層面上又是如何實現的？最后從當前已知問題出發，對于小程序未來的技術更迭，拋出一些我們認為的可能方向，供大家參考。
HTML5 于 2007 年在 W3C 立項，與 iPhone 發布同年。
喬布斯曾期待 HTML5 能幫助 iPhone 打造起應用生態系統。但 HTML5 的發展速度并不如預期，雖然它成功地打破了 IE+Flash 壟斷的局面，卻沒有達到承載優秀的移動互聯網體驗的地步。
蘋果公司在 iPhone 站穩腳跟后，緊接著發布了自己的 App Store，開啟了移動互聯網的原生應用時代。
大家知道現在手機端主要是 iOS、Android 兩大系統，實際上在早期有 3 大系統競爭，還有一個就是諾基亞的 MeeGo 系統，MeeGo 采用 C + HTML5 的雙模應用生態策略。然而，C 的開發難度太大，HTML5 體驗又不行，所以后來 MeeGo 就掉隊了；與之對應，Android 依靠 Java 技術生態，在競爭中脫穎而出。
于是在移動互聯網初期，應用生態被定了基調 —— 原生開發。
國內有一批做瀏覽器的廠商，嘗試去改進 HTML5。比如，百度在 2013 年的百度世界大會上發布了輕應用，通過給 WebView 擴展原生能力，補充 JS API，讓 HTML5 應用可以實現更多功能。
這類業務發展的頂峰，是微信在 2015 年初發布的微信 JS SDK，作為國內事實上最大的手機瀏覽器，微信為它的瀏覽器內核擴充了大量 JS API，讓開發者可以用 JS 調用微信支付、掃碼等眾多 HTML5 做不到的功能。
不過這類業務沒有取得成功，HTML5 的問題不止是功能不足，性能體驗是更嚴重的問題。而體驗問題，不是簡單地擴展 JS 能力能搞定的。
與瀏覽器不同，Hybrid 應用是另一個細分領域，開發者使用 JS 編寫應用，為了讓 JS 應用更接近原生應用的功能體驗，這個行業的從業者做出了很多嘗試。我們 DCloud 公司是業內主流 Hybrid App 引擎提供方之一，我們提出了改進 HTML5 的“性能功能”障礙的解決方案 —— 通過工具、引擎優化、開發模式調整，讓開發者可以通過 JS 寫出更接近原生 App 體驗的應用。
多 WebView 模式，原生接管轉場動畫、下拉刷新、Tab 分頁，預載 WebView……各種優化技術不停迭代，終于讓 Hybrid 應用取得了性能體驗的突破。
Hybrid 應用和輕應用、微信 JS SDK 等基于瀏覽器增加方案相比，還有一個巨大的差別：一個是 Client/Server，一個是 Browser/Server。簡單來說，Hybrid 應用是 JS 編寫的需要安裝的 App，而輕應用是在線網頁。
C/S 的應用在每次頁面加載時，僅需要聯網獲取 JSON 數據；而 B/S 應用除了 JSON 數據外，還需要每次從服務器加載頁面 DOM、樣式、邏輯代碼，所以 B/S 應用的頁面加載很慢，體驗很差。
可是這樣的 C/S 應用雖然體驗好，卻失去了 HTML5 的動態性，仍然需要安裝、更新，無法即點即用、直達二級頁面。
那么 C/S 應用的動態性是否可以解決呢？對此， DCloud 率先提出了“流應用”概念，把之前 Hybrid 應用里的運行于客戶端的 JS 代碼，先打包發布到服務器，制定流式加載協議，手機端引擎動態下載這些 JS 代碼到本地，并且為了第一次加載速度更快，實現了應用的邊下載邊運行。
就像流媒體的邊下邊播一樣，應用也可以實現邊用邊下。
在這套方案的保障下，終于解決了之前的各種難題：讓 JS 應用功能體驗達到原生，并且可即點即用、直達二級頁面。
接著就是微信小程序，最初的名字實際上是微信應用號，之后改名為小程序，2016 年 9 月份內測，2017 年 1 月正式發行，再之后阿里巴巴、手機廠商聯盟、百度、，陸續推出了自己的小程序平臺，小程序時代滾滾而來。
2018 年 9 月，微信推出云開發，這個功能我們認為是小程序發展歷史上的一個重要節點，它可以讓前端工程師從前到后將所有業務閉環實現，減少前后端的溝通成本、人力成本、運維成本，屬于開發模式的重大升級。與之前的前端同學既可通過 JS/CSS 編寫前端 UI，又可通過 “Node.js” 寫后端業務，這種所謂全棧開發模式相比，云開發有更好的優勢，因為前端同學對于 DB 優化、彈性擴容、攻擊防護、災備處理等方面還是有經驗欠缺的，但云開發將這些都封裝好了，真正做到僅專注業務實現，其它都委托云廠商服務。
這是一個比較通用的小程序架構，目前幾家小程序架構設計大致都是這樣的（快應用的區別是視圖層只有原生渲染）。
大家知道小程序是一個邏輯、視圖層分離的架構。
邏輯層就是上圖左上角這塊，小程序中開發的所有頁面 JS 代碼，最后都會打包合并到邏輯層，邏輯層除了執行開發者的業務 JS 代碼外，還需處理小程序框架的內置邏輯，比如 App 生命周期管理。
視圖層就是上圖右上角這塊，用戶可見的 UI 效果、可觸發的交互事件在視圖層完成，視圖層包含 Web 組件、原生組件兩種，也就是小程序是原生 +Web 混合渲染的模式，這塊后面會詳細講。
邏輯層最后運行在 JS CORE 或 V8 環境中；JS CORE 既不是 DOM 環境，也不是 Node 環境，你是無法使用 JS 中的 DOM 或 BOM 對象的，你能調用的僅僅是 ECMAScript 標準規范中所給出的方法。
那如果你要發送網絡請求怎么辦？window.XMLHttpRequest 是無法使用的（當然即使可以調用，在 iOS 的 WKWebView 中也存在更嚴格的跨域限制，會有問題）。這時候，網絡請求就需要通過原生的網絡模塊來發送，JS CORE 和原生之間呢，就需要這個 JS Bridge 來通訊。
小程序這種架構，最大的好處是新頁面加載可以并行，讓頁面加載更快，且不卡轉場動畫；但同時也引發了部分性能坑點，今天主要介紹 3 點：
我們從“swipeaction”這個例子講起，需求是用戶在列表項上向左滑動，右側隱藏的菜單跟隨用戶手勢平滑移動。
若想在小程序架構上實現流暢的跟手滑動，是很困難的，為什么？
回顧一下小程序架構，小程序的運行環境分為邏輯層和視圖層，分別由 2 個線程管理，小程序在視圖層與邏輯層兩個線程間提供了數據傳輸和事件系統。這樣的分離設計，帶來了顯而易見的好處：
環境隔離，既保證了安全性，同時也是一種性能提升的手段，邏輯和視圖分離，即使業務邏輯計算非常繁忙，也不會阻塞渲染和用戶在視圖層上的交互。
但同時也帶來了明顯的壞處：
視圖層（WebView）中不能運行 JS，而邏輯層 JS 又無法直接修改頁面 DOM，數據更新及事件系統只能靠線程間通訊，但跨線程通信的成本極高，特別是需要頻繁通信的場景。
基于這樣的架構設計，我們回到“swipeaction”，分析一次 touchmove 的操作，小程序內部的響應過程：
（1）用戶拖動列表項，視圖層觸發 touchmove 事件，經 Native 層中轉通知邏輯層（邏輯層、視圖層不是直接通訊的，需 Native 中轉），即下圖中的?、?兩步；
（2）邏輯層計算需移動的位置，然后再通過 setData 傳遞位置數據到視圖層，中間同樣會由微信客戶端（Native）做中轉，即下圖中的?、?兩步。
實際上，用戶滑動過程中，touchmove 的回調觸發是非常頻繁的，每次回調都需要 4 個步驟的通訊過程，高頻率回調導致通訊成本大幅增加，極有可能導致頁面卡頓或抖動。為什么會卡頓，因為通訊太過頻繁，視圖層無法在 16ms 內完成 UI 更新。
為解決這種通訊阻塞的問題，各家小程序都在逐步提供對應的解決方案，比如微信的 WXS、支付寶的 SJS、百度的 Filter，但每家小程序支持情況不同，詳細見下表。
另外，微信的“關鍵幀動畫”、百度的“animation-view” Lottie 動畫，也是為減少頻繁通訊的一種變更方式。
其實，通訊阻塞是業界普遍存在的一個問題，不止小程序，“React Native”“Weex”等同樣存在通訊阻塞的問題。只不過“React Native”“Weex”的視圖層是原生渲染，而小程序是 Web 渲染。我們下面以“Weex”為例來說明。
大家知道，“Weex”底層使用的 JS-Native Bridge，這個 Bridge 使得 JS 和 Native 之間的通信會有固定的性能損耗。
繼續以上述“swipeaction”為例，要實現列表項菜單的跟手滑動，大致需經如下流程：
（1）在 UI 視圖上綁定 touch 事件（或 pan 事件）;
（2）當手勢觸發時， Native UI 層將手勢事件通過 Bridge 傳遞給 JS 邏輯層 , 這產生了一次 Native UI 到 JS 邏輯的通信，即下圖中的?、?兩步 ;
（3）JS 邏輯在接收到事件后，根據手指移動的偏移量驅動界面變化，這又會產生一次 JS 到 Native UI 的通信，即下圖中的?、?兩步。
同樣，手勢回調事件觸發的頻率是非常高的，頻繁的的通信帶來的時間成本很可能導致界面無法在 16ms 中完成繪制，卡頓也就產生了。
“Weex”為解決通訊阻塞，提供了“BindingX”解決方案，這是一種稱之為“Expression Binding”的機制，簡要介紹一下：
（1）接收手勢事件的視圖，在移動過程中的偏移量以“x，y”兩個變量表示；
（2）期望改變（跟隨移動）的視圖，變化的屬性為“translateX”和“translateY”，對應變化的偏移量以“f(x)，f(y)”表達式表示；
（3）將”交互行為 " 以表達式的方式描述，并提前預置到 Native UI 層；
（4）交互觸發時，Native UI 根據其內置的表達式解析引擎，去執行表達式，并根據表達式執行的結果驅動視圖變換，這個過程無需和 JS 邏輯通訊。
偽代碼 - 摘錄自 Weex 官網
復制代碼
{ anchor: foo_view.ref // ----> 這是 " 產生手勢的視圖 " 的引用 props: [ { element: foo_view.ref, // ----> 這是 " 期望改變的視圖 " 的引用 expression: f(x) = x, // ----> 這是具體的表達式 property: translateX // ----> 這是期望改變的屬性 }, { element: foo_view.ref, expression: f(y) = y, // ----> y 屬性 property: translateY } ]}“React Native”同樣存在類似問題，為避免頻繁的通信，“React Native”生態也有對應方案，比如“Animated”組件及 Lottie 動畫支持。以 “Animated”組件為例，為實現流暢的動畫效果，該組件采用了聲明式的 API，在 JS 端僅定義了輸入與輸出以及具體的 transform 行為，而真正的動畫是通過 Native Driver 在 Native 層執行，這樣就避免了頻繁的通信。然而，聲明式的方式能夠定義的行為有限，無法勝任交互場景。
“uni-app”在 App 端同樣面臨通訊阻塞的問題，我們目前的方案是采用類似微信 WXS 的機制（內部叫“renderjs”），但放開了 WXS 中無法獲取頁面 DOM 元素的限制，比如下圖中多個小球同時移動的 canvas 動畫，“uni-app”在 App 端的實現方案是：
（1）renderjs 中獲取 canvas 對象；
（2）基于 web 的 canvas 繪制動畫，而非原生 canvas 繪制。
Tips：大家需要注意，并不是所有場景都是原生性能更好，小程序架構下，如上多球同時移動的動畫，原生 canvas 并不如在 WXS（renderjs）中直接調用 Web canvas
下表總結了跨端框架在通訊阻塞方面的解決方案：
小程序架構存在通訊阻塞問題，廠商為解決這個問題，創造了“WXS”腳本語言及關鍵幀動畫等方式，但這些都是廠商維度的優化方案。我們作為小程序開發者，在性能優化方面，又能做哪些工作呢？
小程序開發性能優化，核心就是“setData”的調用，你能做只有兩件事情：
（1）減少 setData 調用次數
假設我們有更改多個變量值的需求，示例如下：
change:function(){
? ? this.setData({a:1});
? ? ... // 其它業務邏輯
? ? this.setData({b:2});
? ? ... // 其它業務邏輯
? ? this.setData({c:3});
? ? ... // 其它業務邏輯
? ? this.setData({d:4});
}如上，4 次調用“setData”，會引發 4 次邏輯層、視圖層數據通訊。這種場景，開發者需意識到“setData”有極高的調用代價，自己需手動調整代碼，合并數據，減少數據通訊次數。
部分小程序三方框架已內置數據合并的能力，比如“uni-app”在 Vue runtime 上進行了深度定制，開發者無需關注“setData”的調用代價，可放心編寫如下代碼：
change:function(){
? ? this.a = 1;
? ? ... // 其它業務邏輯
? ? this.b = 2;
? ? ... // 其它業務邏輯
? ? this.c = 3;
? ? ... // 其它業務邏輯
? ? this.d = 4;
}
如上 4 次賦值，uni-app 運行時會自動合并成“{“a”:1,“b”:2,“c”:3,“d”:4}”一條記錄，調用一次“setData”完成所有數據傳遞，大幅降低 setData 的調用頻次，結果如下圖：
減少“setData”調用次數，還有個注意點：后臺頁面（用戶不可見的頁面）應避免調用“setData”。
（2）數據差量更新
假設我們有一個 “列表頁 + 上拉加載” 的場景，初始化列表項為 “item1 ~ item4”，用戶上拉后要向列表追加 4 條新記錄 “item5 ~ item8”，小程序代碼如下：
page({
? ? data:{
? ? ? ? list:['item1','item2','item3','item4']
? ? },
? ? change:function(){
? ? ? ? let newData = ['item5','item6','item7','item8'];
? ? ? ? this.data.list.push(...newData); // 列表項新增記錄
? ? ? ? this.setData({
? ? ? ? ? ? list:this.data.list
? ? ? ? })
? ? }
})
如上代碼，change 方法執行時，會將 list 中的 “item1 ~ item8”8 個列表項通過“setData”全部傳輸過去，而實際上變化的數據只有“item5 ~ item8”。
開發者在這種場景下，應通過差量計算，僅通過“setData”傳遞變化的數據，如下是一個示例代碼：
page({
? ? data:{
? ? ? ? list:['item1','item2','item3','item4']
? ? },
? ? change:function(){
? ? ? ? // 通過長度獲取下一次渲染的索引
? ? ? ? let index = this.data.list.length;
? ? ? ? let newData = ['item5','item6','item7','item8'];
? ? ? ? let newDataObj = {};// 變化的數據
? ? ? ? newData.forEach((item) => {
? ? ? ? ? ? newDataObj['list[' + (index++) + ']'] = item;// 通過 list 下標精確控制變更內容
? ? ? ? });
? ? ? ? this.setData(newDataObj) // 設置差量數據
? ? }
})
每次都手動計算差量變更數據是繁瑣的，新手不理解小程序原理的話，也容易忽略這些性能點，給 App 埋下性能坑點。
此處，建議開發者選擇成熟的第三方小程序框架，這些框架已經自動封裝差量數據計算，對開發者更友好。比如，“uni-app”借鑒了 “westore JSON Diff”庫，在調用 setData 之前，會先比對歷史數據，精確高效計算出有變化的差量數據，然后再調用 setData，僅傳輸變化的數據，這樣可實現傳遞數據量的最小化，提升通訊性能。如下，是一個示例代碼：
export default{
? ? data(){
? ? ? ? return {
? ? ? ? ? ? list:['item1','item2','item3','item4']
? ? ? ? }
? ? },
? ? methods:{
? ? ? ? change:function(){
? ? ? ? ? ? let newData = ['item5','item6','item7','item8'];
? ? ? ? ? ? this.list.push(...newData) // 直接賦值，框架會自動計算差量數據
? ? ? ? }
? ? }
}
Tips：如上 change 方法執行時，僅會將 list 中的 “item5 ~ item8”4 個新增列表項傳輸過去，實現了 setData 傳輸量的極簡化。
（3）組件差量更新
下圖是一個微博列表截圖：
假設當前有 200 條微博，用戶對某條微博點贊，需實時變更其點贊數據（狀態）；在傳統模式下，一條微博的點贊狀態變更，會將整個頁面 (Page) 的數據全部通過 setData 傳遞過去，這個消耗是非常高的；而即使通過之前介紹，通過差量計算的方式獲取變更數據，這個 Diff 遍歷范圍也很大，計算效率極低。
如何實現更高性能的微博點贊？這其實就是組件更新的典型場景。
合適的方式應該是，將每條微博封裝成一個組件，用戶點贊后，僅在當前組件范圍內計算差量數據（可理解為 Diff 范圍縮小為原來的 1/200），這樣效率才是最高的。
提醒大家注意，并不是所有小程序三方框架都已實現自定義組件，只有在基于自定義組件模式封裝的框架中，性能才會大幅提升；如果三方框架是基于老的“template”模板封裝的組件開發，則性能并不會有明顯改善，其 Diff 對比范圍依然是 Page 頁面級的。
大家知道，小程序當中有一類特殊的內置組件——原生組件，這類組件有別于 WebView 渲染的內置組件，他們是由原生客戶端渲染的。
小程序中的原生組件，從使用方式上來說，主要分為三類：
除了上面提到的這些之外，其它基本都是 Web 渲染。所以說，小程序是混合渲染模式，Web 渲染為主，原生渲染為輔。
（1）為什么要引入混合渲染
接下來的問題，為什么要引入原生渲染？以及為什么僅針對這幾個組件提供了原生增強？其他組件為什么沒有做原生實現？
這就需要我們針對每個組件單獨進行分析思考，這里舉了幾個例子：
提到“input”控件的原生化，可以稍微發散一下。
小程序中原生 input 控件的通用做法是，未獲取焦點時以 Web 控件顯示，但在獲取焦點時，繪制一個原生 input，蓋在 Web input 上方，此時，用戶看見的鍵盤即為原生 input 所對應的鍵盤，原生彈出鍵盤是可自定義按鈕（如上圖中下一步、send 按鈕）。這種做法存在一個缺陷： Web 和原生，畢竟不同渲染引擎，在鍵盤彈出和關閉時，對應 input 的“placeholder”會閃爍。
在 Android 平臺，還有一種做法是基于 WebKit 改造，定制彈出鍵盤樣式；這種方案，在鍵盤彈出和關閉時，input 控件都是 Web 實現的，故不存在“placeholder”閃爍的問題。
（2）混合渲染引發的問題
原生組件雖然帶來了更豐富的特性及更好的性能，但同時也引入了一些新的問題，比如：
當然，并不是所有小程序都存在這種問題，部分小程序通過修改自帶的 WebView 內核，實現了 WebView 也可以使用 rom 主題字體，比如微信、QQ、支付寶；其他小程序（百度、頭條），WebView 仍然無法渲染為 rom 主題字體。
（3） 混合渲染改進方案
既然混合渲染有這些問題，對應就會有解決方案，目前已有的方案如下。
既然其它組件無法覆蓋到原生組件上，那就創造出一種新的組件，讓這個新組件可以覆蓋到 video 或 map 上。“cover-view/cover-image”就是基于這種需求創造出來的新組件；其實它們也是原生組件，只不過層級略高，可以覆蓋在 map、video、canvas、camera 等原生組件上。
目前除了字節跳動外，其它幾家小程序均已支持“cover-view/cover-image”。
cover-view/cover-image 在一定程度上緩解了分層覆蓋的問題，但也有部分限制，比如嚴格的嵌套順序。
既然分層有問題，那就消除分層，從 2 層變成 1 層，所有組件都在一個層中，“z-index”豈不就可生效了？
這個小目標說起來簡單，具體實現還是很復雜的。
拋開小程序當前架構實現，解決混合渲染最直接的方案，應該更換渲染引擎，全部基于原生渲染，video/map 和 image/view 均為原生控件，層級相同，層級遮蓋問題自然消失。這正是“uni-app”在 App 端的推薦方案。
當前 Web 渲染為主、原生渲染為輔的主流小程序現狀，如何實現同層渲染？
基于我們的分析研究，這里簡單講解一下同層渲染實現的方案，和微信真實實現可能會有出入（目前僅微信一家實現了同層渲染）。
（1） iOS 平臺
小程序在 iOS 端使用 WKWebView 進行渲染，WKWebView 在內部采用的是分層渲染，一般會將多個 DOM 節點，合并到一個層上進行渲染。因此，DOM 節點和層之間不存在一一對應關系。但是，一旦將一個 DOM 節點的 CSS 屬性設置為 “overflow: scroll” 后，WKWebView 便會為其生成一個 WKChildScrollView，且 WebKit 內核已經處理了 WKChildScrollView 與其他 DOM 節點之間的層級關系，這時 DOM 節點就和層之間有一一對應關系了。
小程序 iOS 端的同層渲染可基于 WKChildScrollView 實現，主要流程如下：
（2）Android 平臺
小程序在 Android 端采用 Chromium 作為 WebView 渲染層，和 iOS 的 WKWebView 不同，是統一渲染的，不會分層渲染。但 Chromium 支持 WebPlugin 機制，WebPlugin 是瀏覽器內核的一個插件機制，可用來解析“< embed >”。Android 端的同層渲染可基于 “< embed >”加 Chromium 內核擴展來實現，大致流程如下：
這個流程相當于給 WebView 添加了一個外置插件，且“< embed >”節點是真正的 DOM 節點，可將更多的樣式作用于該節點上。
如果要探討小程序接下來的技術升級方向，我們認為應該在用戶體驗、開發效率兩個方向上努力。
先說用戶體驗的問題，主要也是兩個方面：
如果你也想快速搭建的自己的小程序引擎，并更優的解決如上體驗問題，該怎么辦？
uni-app 發行到 App 端，實際上就是一個完整的小程序引擎，DCloud 會在近期將這個引擎完整開源，歡迎大家基于 uni-app 小程序 SDK 快速打造自己的小程序平臺。
uni-app 小程序 SDK 具備如下幾個特征：
開發效率應該從跨端、跨云兩個維度進行分析。
目前的小程序都帶有明顯的廠家屬性，每個廠家各不相同。比如，阿里內部有多套小程序（支付寶、淘寶、釘釘等），幸好阿里內部目前已基本統一。但騰訊體系下，微信和 QQ 小程序依然是兩隊人馬，兩套規范。
小程序之前是手機端的，2019 年 360 出了 PC 端小程序。
接下來，會不會還有其它廠家推出自己的小程序？會不會有新的端的出現？比如，面向電視的小程序、面向車載的小程序？
一切皆有可能。
逐水草而居是人類的本能，追求流量依然是互聯網的制勝法寶。當前的小程序宿主，都是億級流量入口，且各家流量政策不同。比如，微信的流量雖然很大，但有各種限制；百度和頭條是支持廣告投放的，通過廣告投放，可以快速獲得大量較為精準的用戶；百度小程序還有個 Web 化的功能，可以將 Web 的搜索流量，轉化成小程序的流量。
面對眾多小程序平臺及各自巨大的入口流量，開發者如何應對？
等待 W3C 的小程序標準統一，短期不太現實。當下，若想將業務快速觸達多家小程序，借助跨端框架應該是唯一可行的方案。
開發商借助“uni-app”或其它跨端框架，雖然已可以開發所有前端應用。但仍然需要雇傭 PHP 或 Java 等后臺開發人員，既有后端人員成本，又有前 / 后端溝通成本。
騰訊、阿里、百度小程序雖陸續上線了云開發，但它們均只支持自己的小程序，無法跨端，分散的服務器對開發商更不可取。
故我們認為跨廠商的 Serverless 是接下來的一個重點需求，開發者在一個云端存儲所有業務數據及后端邏輯，然后將前端小程序發行到各家小程序平臺，也就是“一云多端”模式。
基于小程序的現狀，我們也許可以總結一下小程序技術上的可能方向：
作者介紹：
崔紅保，DCloud CTO，Uni-App 團隊負責人，開發了 2 個 Github Star 上萬的流行項目。有 10 年以上研發管理經驗，在跨平臺引擎、前端 UI、小程序性能優化等方面有豐富的實踐經驗。
著小程序正式對外發布之即，微信團隊近日北京舉辦了一場線下公開課，筆者也應邀參加了這次公開課的分享，微信團隊在公開課里透漏的，有很多細節筆者在之前的一篇文章《小程序來了，這些細節你必須注意！》都有提及過，但是通過這次與微信團隊的直接接觸，我把內容整理出來，讓吃瓜群眾對小程序有一個更加清晰的認識，本篇文章圖片較多，建議在WIFI環境下閱讀。
第一部分：小程序接入流程，吃瓜群眾務必知曉
第二部分：運營規范，設計人員必須了解
第三部分：框架解析，技術黨務必理解
第四部分：實戰分享，開發者最渴望的實戰經驗
第五部分：小程序不是HTML5
微信團隊在本次公開課中明確提出“小程序不是HTML5”，其實說到這里我們可以這樣分別定義小程序和HTML5，以小程序為代表的 hybrid app 和以 HTML 5 為代表的 web app。“小程序”在騰訊內部被統一稱為 web+，Web+ 是什么？可以簡單理解為一種“混搭”的開發方式或是具備 Native 能力的 web 應用框架。它既不是純粹的 web 開發，也不是 ios 或是 Android 開發，它是 MIX 的，雖然像 web 一樣更輕，但也像 Native 應用開發一樣更加重視用戶體驗本身。
關于小程序更多的開發、運營、設計的解讀，大家可以查閱筆者早前發表的一篇文章《小程序來了，這些細節你必須注意！》 去詳細學習。
第六部分：小程序經典案例解讀
本次公開課微信團隊除了分享有關開發層面的實戰分享之外，還特例拿出了1-2個小程序作為經典案例進行分享。
在本次小程序公開課后的分享中，微信團隊特別提到到了一個標桿性的小程序—自選股，筆者在課后也了解到了這只開發團隊的相關情況，根據了解，這只團隊是騰訊內部最早進入微信小程序內測的6個團隊的其中之一。
自選股團隊負責人強調它們的小程序是一款基于微信體系小而美額度產品，去掉了APP里像研報、投資評級、機構評級以及公司財報等功能，同時結合微信的社交屬性，在用戶與微信好友在聊天時，就能夠通過自選股小程序了解當前的股市行情，這類產品就很好的響應了小程序"更小、更輕"的理念。
從效率上來說，小程序產品在微信Web+框架下的開發速度是遠比原生應用更快，跨平臺的適配性更高，開發成本更低。以騰訊自選股小程序為例，3個人的團隊在5天內就開發完成了整個小程序。
同時，微信自選股團隊負責人還透漏了一個細節，小程序能夠支持股票移動的動態顯示，讓股民能夠更直觀的看到股票的變化，微信小程序已經支持整個 CSS3 的動畫，而這在 Native 的股票 App 中，也不是所有的都能做到這一點。
這是一個典型的符合小程序設計理念的產品，正如微信團隊在官方設計規范中所提及的“產品設計遵循重點突出”。
開發速度加快，必然的帶來了開發成本的降低，效率因此獲得提高。不過，開發者當對市場情況和用戶需求并不十分確定的情況下，它讓快速、低成本的試錯成為可能。
第七部分：微信公開課給了我們更明確的信號
小程序的設計完全可以對標第三方服務里的小應用
在小程序推出之前，我們大家所熟知的微信第三方服務所包含的應用其實都可以看做是小程序的縮影，筆者對比了幾個典型的應用，我們完全可以看出小程序所有細節，統一的Title標題和Background背景，統一的Tab格局，統一的按鈕尺寸和色塊，這些細節和小程序定義的規范極其接近。
小程序就是要突出重點，快速直達用戶的需求
小程序“自選股”把AP的重點功能“實時行情”放到了小程序里，并且做到了用戶極致體驗；同城旅游把重點功能票務預訂放到了小程序里；藝龍旅行網把重點功能“酒店預訂”放到了小程序里；大眾點評把重點功能外賣放到了小程序里，通過以上案例我們不難看出，這些開發者只是把AP的其中一項功能或者單個頁面搬到了小程序上，拋棄了除主需求之外所有的陪襯功能，以最直接的方式滿足用戶的需求。如果我們把APP定位成一頓滿足胃口的大餐，那小程序就是快速解決溫飽問題一頓快餐了。但是人在餓的時候，一頓快餐的解決問題的快感顯然要比一頓大餐好的多。
第八部分、微信團隊正在逐步推進小程序的進程
我在小程序公測之后的一篇文章《小程序來了，這些細節你必須注意！》里有提到過這樣一個觀點，小程序箭在弦上卻不能發布是因為微信團隊剛剛公布公測消息，市場的反饋需要一定的時間，微信團隊還沒有給市場一個可以借鑒的標桿。通過微信團隊這次的公開課和前段時間張小龍爆出的手機截圖顯示，僅僅過去20多天，微信團隊似乎已經找到了不下20個可以稱得上標桿的小程序。微信團隊通過這次公開課就是想再次給市場傳遞一個信號：什么可以做，什么不能做，應該怎么做。看到市場上這么多想擁抱小程序的開發者，筆者想說的是，其實最急的不是你們，而是微信團隊。它們迫切的希望您們去擁抱，最樂意看到的現狀就是，它們所制定的生態規則能夠在最短的時間內被市場所接受，并且開發者上手的速度越快越好，從而幫助微信團隊更好的打造這個偉大的生態系統。
【作者：春曉。公眾號：wsbang520。個人ID：cxfdaiyi001，歡迎經驗交流。】
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
