小程序技術始於微信？來看看移動端小程序技術的前世此生！

本文由DCloud 公司創始人王安原創發佈於CSDN，原題《小程序技術演進史》，即時通信網收錄時有改動，感謝原做者。

一、引言

微信的成功，並不是特定於某個具體的功能，微信的成功其實是一大批創新技術和體驗的成功合集，這也是它爲什麼如此難此被超越的根本緣由。

做爲微信這個超級社交應用中最爲亮眼的技術之一——微信小程序，儼然已成歷移動端小程序的代名詞，不少人一提起「小程序」3個字就條件反射式地認爲是微信小程序。事實是，小程序技術並不是微信首創，它的出現和演進，實際上包含了一大批各種公司、各產品技術先驅們的努力。

實際上，早在微信小程序以前，有力推輕應用的百度，有來自 HTML5 中國產業聯盟的 DCloud 所主張的流應用，但最終卻都已經淹沒在了移動互聯網的歷史長河之中。惟有微信小程序風生水起，更是帶動了巨頭們的爭相入場。

小程序迎來了專屬於中國移動互聯網的羣雄逐鹿的時代。

本文做者王安便是流應用的創造者，做爲移動領域的老兵，他依然在矢志不移地構建移動開發工具框架及生態，從原生應用到 HTML5 再到現在的小程序，他是這段歷史的見證者、參與者。

本篇文章，將爲你盤點移動端小程序技術的前世此生。經過本文，咱們可以鮮活地看到小程序的技術演進歷程，以及對於全部開發者來講，終將去往何處。

（本文同步發佈於：http://www.52im.net/thread-26...）

二、關於做者

王安：DCloud 公司創始人，HTML5 中國產業聯盟祕書長。2003 年開始從事移動互聯網工做，十幾年編程和商業經驗，連續創業者。曾任北京市學聯主席，畢業後創辦 DCloud 公司。興趣愛好：編程、顛覆式創新。

三、相關文章

《最火移動端跨平臺方案盤點：React Native、weex、Flutter》
《盤點主流移動端跨平臺UI技術：實現原理、技術優劣、橫向對比等》

四、中國特點的移動互聯網時代

伴隨着 QQ 小程序 面向用戶開放，這個手機端月活 7 億的巨無霸正式入場。小程序，終於成爲了超級 App 的標配。

盤點下已經支持小程序的超級 App：

微信、企業微信、QQ、支付寶、高德地圖、手機淘寶、百度、百度貼吧、百度地圖、今日頭條、抖音……

這些璀璨耀眼的名字，背後都是巨大的流量。

在這羣超級 App 的支持下，中國的移動互聯網格局被完全改變。

這個有中國特點的移動互聯網時代，被稱爲「小程序時代」。

這是繼手機支付後，中國的移動互聯網領先世界的第二個表明事物。

中國的技術標準、開發者生態，第一次獲得大規模的普及應用，並且很明顯，小程序在功能和體驗上均超過了 HTML5。

中國人能創建開發者生態嗎？這個命題曾一度讓人懷疑。

小程序完成了這一步突破，這是一場值得歌頌的中國技術生態發展史。

讓咱們來回顧下這場技術生態革命，是如何開始，又將要去向何方。

五、羅馬不是一天建成的，小程序也不是一天發明出來的

HTML5 於 2007 年在 W3C 立項，與 iPhone 發佈同年。

喬布斯曾期待 HTML5 能幫助 iPhone 打造起應用生態系統。

但 HTML5 的發展速度並不如預期，它雖然成功地實現了打破 IE+Flash 壟斷局面的目標，卻沒有達到承載優秀的移動互聯網體驗的地步。

因而在 iPhone 站穩腳跟後，發佈了本身的 App Store，開啓了移動互聯網的原生應用時代。

隨後的 Android，原本是基於 Linux 的 OS，與之同期的 MeeGo 等競爭對手採用 C + HTML5 的雙模應用生態策略，然而 C 的開發難度太大，HTML5 體驗又不行。Android 依靠 Java 技術生態，在競爭中脫穎而出。

因而：在移動互聯網初期，應用生態被定了基調 —— 原生開發。

在那個時候，硬件不行，也沒有其餘辦法，原生開發才能在低配硬件上帶來商用體驗。

但你們都在懷念 HTML，那種無需安裝更新、即點即用，直達二級頁面的特色，一直讓人迷戀。

國內有一批作瀏覽器的廠商，嘗試去改進 HTML5，他們提出了輕應用的概念。

經過給 WebView 擴展原生能力，補充 JS API，讓 HTML5 應用能夠實現更多功能。

不過這類業務沒有取得成功，HTML5 的問題不止是功能不足，性能體驗是它更嚴重的問題，而體驗問題，不是簡單地擴展 JS 能力能搞定的。

這類業務發展的頂峯，是微信的 JS SDK。

做爲國內事實上最大的手機瀏覽器，微信爲它的瀏覽器內核擴充了大量 JS API，讓開發者能夠用 JS 調用微信支付、掃碼等衆多 HTML5 作不到的功能。

▲ 微信 JS SDK 說明文檔

但微信團隊對這套方案的體驗仍然不滿意，微信錢包欄目裏打車、理財等不少應用雖然嵌入了 JS SDK，但每次點擊要等半天白屏，讓人用着很痛苦，他們在業內開始尋找新的解決方案。

業內早有專業團隊看到了相同的問題。

與瀏覽器不一樣，Hybrid 應用是另外一個細分領域。它們爲開發者提供使用 JS 編寫跨平臺應用的工具，爲了讓 JS 應用更接近原生應用的功能體驗，這個行業的從業者作出了不少嘗試。

筆者所在的 DCloud 便是其中之一，咱們提出了改進 HTML5 的「性工能」障礙的解決方案 —— 經過工具、引擎優化、開發模式調整，讓開發者能夠經過 JS 寫出更接近原生 App 體驗的應用。

多 WebView 模式，原生接管轉場動畫、下拉刷新、Tab 分頁，預載 WebView……各類優化技術不停迭代，終於讓 Hybrid 應用取得了性能體驗的突破。

Hybrid 應用和普通的輕應用相比，還有一個巨大的差異：一個是 Client/Server，一個是 Browser/Server。簡單來講，Hybrid 應用是 JS 編寫的須要安裝的 App，而輕應用是在線網頁。

C/S 的應用在每次頁面加載時，僅須要聯網獲取 JSON 數據；而 B/S 應用除了 JSON 數據外，還須要每次從服務器加載頁面 DOM、樣式、邏輯代碼，因此 B/S 應用的頁面加載很慢，體驗不好。

但是這樣的 C/S 應用雖然體驗好，卻失去了 HTML5 的動態性，仍然須要安裝、更新，沒法即點即用、直達二級頁面。

那麼 C/S 應用的動態性是否能夠解決呢？對此，咱們提出了流應用概念，把以前 Hybrid 應用裏的運行於客戶端的 JS 代碼，先打包發佈到服務器，制定流式加載協議，手機端引擎動態下載這些 JS 代碼到本地，而且爲了第一次加載速度更快，實現了應用的邊下載邊運行。

就像流媒體的邊下邊播同樣，應用也能夠實現邊用邊下。

在這套方案的保障下，終於解決了以前的各類難題：讓 JS 應用功能體驗達到原生，而且可即點即用、可直達二級頁面。

現在看來，這已經變成了常識。但在當年，先驅們作了無數艱辛探索。

這套技術，須要讓客戶端引擎提早預置在手機上，就像流媒體的普及，創建在 Flash 的裝機量巨大的基礎上，那麼普及這個客戶端引擎就變得很重要。

2015 年，360 和 DCloud 合做，在 360 手機助手裏內嵌了這個客戶端引擎，推出了業內第一個商用的小程序，360 稱之爲 360 微應用。

微應用實現了在 360 手機助手的應用下載頁面，同時出現了「秒開」按鈕，點擊後直接使用。

而且在 360 手機助手的掃碼裏，應用的分享裏，都實現了掃碼得到一個應用，點擊分享消息得到一個應用。

▲ 在 360 手機助手 3.4 版本中上線的中國第一個小程序

爲了作大生態，DCloud 把這套技術標準，捐獻給了 HTML5 中國產業聯盟，隨後，聯盟開始推進更多的超級 App 和手機廠商加入，共同推動動態 App 產業的發展。

然而事情並不順利，巨頭們有本身的利益訴求。雖然有一批廠商贊成加入聯盟共建生態，但最關鍵的角色，真正的國民應用「微信」，最終決定自立標準、自研引擎，固然技術原理與流應用是基本一致的。

2016 年 1 月 11 日，微信公開課，張小龍罕見露面，公佈了微信應用號的計劃，爲這個大事件親自站臺。

2016 年 9 月 21 日，微信宣佈改名應用號爲小程序，面向首批開發者內測。今後，這個詞被正式定了下來，「小程序」，成爲後續一個時代的代名詞。而「流應用」、「微應用」則淹沒在歷史長河中成爲一個使人唏噓的故事。

2017 年 1 月 9 日，微信公開課，小程序面向用戶正式推出。

今後後，阿里巴巴、手機廠商聯盟、百度、今日頭條，陸續推出了本身的小程序平臺，其中也有不少波折與故事，在有偶然、有必然的過程當中，造成了今天的局面。

小程序大潮捲入了更多人，並造成了更大的浪潮，最終迎來了不可逆轉的小程序時代。

六、生態難，難於上青天

發明能解決功能體驗和動態性的技術方案，雖然難，但不是最難的事情。

最難的是開發者生態的建設。

最初 HTML5 中國產業聯盟的策略是在 HTML5 上擴展強化，複用現有的 HTML5 生態。

當微信的標準徹底自立重建時，業內人士都懸着一顆心。

在全球，基於 Web 的技術生態已經很是成熟，各類開發工具、框架、組件、模板...提高着開發者的效率。

小程序丟棄了國際標準組織 W3C 的 DOM 和 Window 標準，僅僅採用基礎 JavaScript。這意味着 HTML5 生態的各類輪子沒法複用，要徹底重造一個新的小程序開發生態。

當初微信推廣 JS SDK 時，是那麼地順其天然，開發者紛紛開始使用，由於對於開發者，只是在他們的 H5 版本上補充一些 API 而已。

而小程序初期，充滿了開發者的質疑聲：個人業務迭代那麼久，讓我從新作一個版本，你的生態到底能不能支撐個人投入？

微信用持續而快速的版本升級、高管的站臺，告訴你們微信作小程序的決心，並最終經過 2017 年末的跳一跳，引爆了小程序。

今後你們的問題再也不是我要不要作小程序了，而轉向了：既然要作，怎麼才能提高小程序的開發效率、下降開發成本？

任何一種技術，或者開發模式的演進，在不斷成熟的過程當中，都遵循着相似的成熟規律：

技術標準 -> 基礎平臺 -> 開發工具 -> 培訓市場 -> 框架誕生 -> 周邊生態逐步完善 -> 輪子之上的輪子

在 HTML5 生態裏，已經發展到最終極的形態，好比 Vue 是一個重要框架，而基於 Vue 的各類豐富的 UI 庫、測試框架，則是輪子之上的輪子。

多層輪子表明着生態的繁榮，也意味着開發者的開發效率更高。

可微信的全新標準出現時，它把開發者推回了原始社會，一切都要重來。

這在當時看來，並非一個必然會成功的事情（其實直到如今，好比圖表類輪子，小程序仍然比不過 HTML5）。

時至今日，討論這個標準的選擇對錯已經沒有意義。當支付寶、百度、今日頭條都開始參考這個標準作小程序時，時代已經不可阻擋。

所幸，最終的結果是，中國人作成了。在國際標準以外，在中國，終於創建起了本身的技術生態。

而且這個生態，給用戶帶來了更好的體驗，給開發者帶來了更多流量和變現效率的提高，這是一個比 HTML5 更優秀的生態。

七、野蠻的技術生態成長速度

兩年時間，中國的小程序開發者如何從原始社會進階到現代文明？這也是一段有趣的歷史。

咱們來看看小程序技術生態是如何快速成長，走完上面所說的這套技術成熟路線，也就是從技術標準到輪子之上的輪子的。

在 Web 世界裏，已經成熟到了原生 JS 用量不多的時代了，開發人員大量使用 Vue 等框架，而且在 Vue 的基礎之上，又有更多輪子。

當中國的開發人員面臨重頭開始時，他們感覺到效率對比的差距，既然時代已不可阻擋，那就擁抱它。勤勞的中國技術人開始蓬勃地建設起了小程序各類周邊技術生態。

其中比較重要的是開發框架的迭代，咱們看看每一個小程序開發框架爲何會誕生、流行和衰落。

最初的微信小程序，一片荒蠻，一份文檔 + 一個難用的 IDE，不少效率工具好比 npm、預處理器這些都不支持，而這些已是大型項目離不開的工具。

因而，第一個標誌性的框架出現了 —— WePY。

WePY 緊隨微信小程序在 2017 年發佈，本來是騰訊其餘部門的一個我的工程師的做品。在那個年代，WePY 有效地解決了小程序不支持 npm、預處理器的痛點，被引爆後，騰訊官方纔把這個框架收編到官方的 GitHub 下。

不過 WePY 也面臨不少問題，它使用了私有語法，這讓它在生態建設上面臨很大難度，IDE 着色、語法提示、語法校驗、格式化、人員招聘培訓等各方面問題制約着它的流行和普及。

面對這些問題，人們開始思考，有什麼更好的方式，能夠複用現有技術生態來快速完善小程序生態？

這時候下一個重要框架借勢誕生，美團前端在 2018 年初開源了 MPVue。

MPVue 採用 Vue 語法來開發小程序，經過對 Vue.js 的底層改造，實現了編譯到微信小程序。

MPVue 良好地藉助了 Vue 的技術生態，周邊工具如 IDE、校驗器、格式化等支持直接複用、人員招聘培訓等生態建設壓力大幅降低，受到了大量開發者的歡迎。

看着熟悉 Vue 的開發者終於有了趁手的輪子，那熟悉 React 的開發者怎會無動於衷？

京東團隊是 React 的重度用戶，還自研了 JDreact，因而他們開發了 Taro 框架，一款基於 React 語法編寫小程序的框架。

但 Taro 並非想簡單作一個 MPVue 在 React 世界裏的翻版，Taro 相比 MPVue，想要解決更多重要問題。

Taro 面世較晚，此時微信、支付寶、百度、頭條都已發佈或宣傳了本身的小程序，開發者面臨一個多端開發和適配的問題。

因而 Taro 率先支持多端開發，它甚至還能發佈到 H5 和 App。

▲ 京東凹凸實驗室

當時小程序領域還有一個重要變化，微信開始支持小程序自定義組件。

組件是一個成熟框架不可缺的東西，無論是 Vue 仍是 React 都有豐富的組件生態。

在過去，MPVue 時代，是把 Vue 組件也編譯成頁面模板，這帶來一個很大的性能問題，在複雜頁面裏（好比長列表）使用組件，更新組件狀態會致使整個頁面的數據所有從 JS 邏輯層向視圖層通信一次，大量數據通信會很是卡頓。

注意：小程序的邏輯層運行在 V8 或 JSCore 下，和視圖層是分離的，通信阻塞很容易引起性能問題。

因而 Taro 把 React 組件編譯爲新出的微信小程序自定義組件，這種組件在數據更新時，只會更新組件內部的數據，而不是整個頁面更新數據，從而大幅減小了數據通訊量。

這一輪的後浪推前浪很猛，Taro 在性能和多端支持上，都超越了 MPVue。

看着 React 陣營取得如此成績，Vue 陣營天然會繼續追擊。

咱們基於 Vue 開發了 uni-app，它實現了自定義組件編譯模式，並在算法上作了不少優化。另外，以前 MPVue 對 Vue 的語法支持度不太完善，好比過濾器等不支持，在 uni-app 中咱們進行了解決。

一樣，uni-app 也看到了前浪的其餘問題：Taro 雖然邁出了多端的第一步，但多端支持能力比較弱，每一個平臺仍然各自開發大量代碼。核心緣由，是Taro 在 H5 端和 App 端，並非一個完整的小程序技術架構，沒法保持最大程度的統一。

因而 uni-app 在 App 端，使用了一個技術架構相同的小程序引擎，自己就能夠直接運行小程序應用，這個引擎搭配小程序代碼打包爲 App，開發者一行代碼不用改，能夠同時發佈小程序和 App。

固然，其 App 引擎從 Hybrid 應用起家，它提供的 API 要比小程序多不少，由於 App 的需求會比小程序豐富，它還支持把 WebView 渲染引擎替換爲 Weex 渲染引擎。

以後 uni-app 又發佈了 H5 版的小程序引擎，原理與小程序的 PC 模擬器相同，實現了良好的跨 H5 版的發佈。因而 uni-app 比較完美地實現了開發一次，7 個平臺發佈。

第一層輪子就這樣迅速發展了起來，Web 世界裏最成熟的 Vue、React 技術生態被導入了小程序開發生態中。而後輪子之上的輪子開始如火如荼的建設。

以 UI 庫爲例，以前的 UI 庫，有 Vue 庫、React 庫，有 PC 庫、H5 庫和小程序庫，種類繁多，甚至說混亂。

好比在 Vue 陣營中，Vant 和 iView 這兩個 UI 庫，都是同時維護兩個版本，它們即有 H5 版，又有小程序版。

不止框架做者麻煩，開發者想在多端使用這些 UI 庫時，會發如今不一樣端還須要引入不一樣的 UI 庫，寫法都不同，這讓開發者很崩潰。

既然已經能夠多端開發應用，因而在多端開發的領域裏，開始出現輪子之上的輪子，多端 UI 庫。

首先是 Taro 推出了 Taro UI，實現了 H5 和小程序 UI 庫的統一，不過惋惜 Taro UI 不支持 App 端。

而後 uni-app 推出了 uni UI，這個 UI 庫同時支持多家小程序、H五、App。

因爲 uni-app 和 MPVue 同屬 Vue 陣營，它們的組件是互通的。因而這兩家聯合舉辦了一場插件大賽，創建了插件市場。

在中國的前端開發者領域，有不少和國外不同的地方：一個是國內有小程序，第二個是國內 Vue 的開發者體量遠超過 React 和 Angular。這裏面很大的緣由，是 Vue.js 的做者尤雨溪，是中國人。

▲ Vue 和 React 百度指數對比

在龐大的 Vue 用戶體量支持下，uni-app 和 MPVue 的周邊生態迅速發展起來，開發工具、周邊輪子、教育培訓等生態快速完善。目前在 Vue 陣營下，開發者在 Web 生態下所需的輪子，在多端開發下基本也都有了。

短短兩年時間，小程序開發生態裏幾撥迭代，輪子之上的輪子不斷涌現，快速進入了成熟期。

八、本文小結

產業還在繼續發展，每當底層有重大技術變動時，上層框架世界就會發生新機會。

當年 HTML5 標準不統一，瀏覽器兼容性問題嚴重，誕生了 jQurey 的機會。而在移動互聯網下半場，瀏覽器兼容已經再也不是核心問題，jQurey 的地位被更適合移動互聯網的 Vue 替代。

咱們不知道將來還會有什麼新的框架出世，但咱們知道方向：

對於開發者而言，老是會向着更高的開發效率、更高的性能、更高的投入產出比前進。

對於開發商，目前的小程序，雖然發展了 2 年，但流量增加空間仍然巨大，微信以外，不少超級 App 的勢能將逐漸釋放，整個小程序產業的日活總量有數億的提高空間。

若是開發商能追上這撥紅利，就能得到更多增加。而多端框架的出現，能夠幫助開發商更好的把握這撥紅利。

中國的技術發展，此刻正在經歷一個分水嶺，從全面的技術進口，到開始建設本身的標準和開發者生態。早晚，會開始向外輸出，引領世界的進步。

無論中美是否開打貿易戰，這一轉變都是必須作的事情。

中國的移動支付、小程序、5G，不少領域已經走在了全球前面。中國人發明的 Vue 已經在影響全球。

雖然還有不少困難仍需克服，但咱們每一個開發者，都是新時代的見證者，更是新生態的建設者！

附錄：更多移動端開發精華文章

《全面瞭解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》

《美圖App的移動端DNS優化實踐：HTTPS請求耗時減少近半》

《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數據傳輸更省更快(原理篇)》

《金蝶隨手記團隊分享：還在用JSON? Protobuf讓數據傳輸更省更快(實戰篇)》

《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》

《通俗易懂：基於集羣的移動端IM接入層負載均衡方案分享》

《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》

《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》

《騰訊原創分享(一)：如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》

《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》

《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》

《基於社交網絡的Yelp是如何實現海量用戶圖片的無損壓縮的？》

《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(圖片壓縮篇)》

《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(音視頻技術篇)》

《最火移動端跨平臺方案盤點：React Native、weex、Flutter》

《盤點主流移動端跨平臺UI技術：實現原理、技術優劣、橫向對比等》

《小程序技術始於微信？來看看移動端小程序技術的前世此生！》

《iPhone X 的 UI界面適配官方指南！》

《新浪微博技術分享：微博短視頻服務的優化實踐之路》

《全面掌握移動端主流圖片格式的特色、性能、調優等》

《邁向高階：優秀Android程序員必知必會的網絡基礎》

《HTTPS時代已來，打算更新你的HTTP服務了嗎？》

《移動端APP的日誌上報機制的優化實踐》

《移動端網絡優化之HTTP請求的DNS優化》

《僞即時通信：分享滴滴出行iOS客戶端的演進過程》

《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》

《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》

《Android程序員的痛你永遠不懂(一)：Bitmap到底佔用多大內存？》

《Android程序員的痛你永遠不懂(二)：如何減小Bitmap內存佔用？》

《Android反編譯利器APKDB：沒有美工的日子裏繼續堅強的擼》

《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》

《全面總結iOS版微信升級iOS9遇到的各類「坑」》

《微信團隊原創資源混淆工具：讓你的APK立減1M》

《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》

《Android版微信安裝包「減肥」實戰記錄》

《iOS版微信安裝包「減肥」實戰記錄》

《移動端IM實踐：iOS版微信界面卡頓監測方案》

《iOS端移動網絡調優的8條建議》

《微信「紅包照片」背後的技術難題》

《移動端IM實踐：iOS版微信小視頻功能技術方案實錄》

《移動端IM實踐：Android版微信如何大幅提高交互性能（一）》

《移動端IM實踐：Android版微信如何大幅提高交互性能（二）》

《移動端IM實踐：iOS版微信的多設備字體適配方案探討》

《愛奇藝技術分享：愛奇藝Android客戶端啓動速度優化實踐總結》

更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-26...）