小(xiǎo)程序技(jì )術演進史

1. 中(zhōng)國(guó)特色的移動互聯網時代

伴随着QQ小(xiǎo)程序面向用(yòng)戶開放，這個手機端月活7 億的巨無霸正式入場。小(xiǎo)程序，終于成為(wèi)了超級app的标配。

盤點下已經支持小(xiǎo)程序的超級app：

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

這些璀璨耀眼的名(míng)字，背後都是巨大的流量。

在這群超級app的支持下，中(zhōng)國(guó)的移動互聯網格局被徹底改變。

這個有(yǒu)中(zhōng)國(guó)特色的移動互聯網時代，被稱為(wèi)「小(xiǎo)程序時代」。

這是繼手機支付後，中(zhōng)國(guó)的移動互聯網領先世界的第二個代表事物(wù)。

中(zhōng)國(guó)的技(jì )術标準、開發者生态，第一次得到大規模的普及應用(yòng)，而且很(hěn)明顯，小(xiǎo)程序在功能(néng)和體(tǐ)驗上均超過了HTML5。

中(zhōng)國(guó)人能(néng)建立開發者生态嗎？這個命題曾一度讓人懷疑。

小(xiǎo)程序完成了這一步突破，這是一場值得歌頌的中(zhōng)國(guó)技(jì )術生态發展史。

讓我們來回顧下這場技(jì )術生态革命，是如何開始，又(yòu)将要去向何方。

2. 羅馬不是一天建成的，小(xiǎo)程序不是一天發明出來的

HTML5于 2007年在W3C立項，與iPhone發布同年。

喬布斯曾期待HTML5能(néng)幫助iPhone打造起應用(yòng)生态系統。

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

于是在iPhone站穩腳跟後，發布了自己的app Store，開啓了移動互聯網的原生應用(yòng)時代。

随後的Android，本來是基于Linux的 OS，與之同期的MeeGo等競争對手采用(yòng)C +HTML5的雙模應用(yòng)生态策略，然而C 的開發難度太大，HTML5體(tǐ)驗又(yòu)不行。Android依靠Java技(jì )術生态，在競争中(zhōng)脫穎而出。

于是在移動互聯網初期，應用(yòng)生态被定了基調——原生開發。

在那個時候，硬件不行，也沒有(yǒu)其他(tā)辦(bàn)法，原生開發才能(néng)在低配硬件上帶來商(shāng)用(yòng)體(tǐ)驗。

但大家都在懷念HTML，那種無需安(ān)裝(zhuāng)更新(xīn)、即點即用(yòng)，直達二級頁(yè)面的特點，一直讓人迷戀。

國(guó)内有(yǒu)一批做浏覽器的廠商(shāng)，嘗試去改進HTML5，他(tā)們提出了輕應用(yòng)的概念。

通過給WebView擴展原生能(néng)力，補充JS API，讓HTML5應用(yòng)可(kě)以實現更多(duō)功能(néng)。

不過這類業務(wù)沒有(yǒu)取得成功，HTML5的問題不止是功能(néng)不足，性能(néng)體(tǐ)驗是它更嚴重的問題，而體(tǐ)驗問題，不是簡單地擴展JS能(néng)力能(néng)搞定的。

這類業務(wù)發展的頂峰，是微信的JS SDK。

作(zuò)為(wèi)國(guó)内事實上最大的手機浏覽器，微信為(wèi)它的浏覽器内核擴充了大量JS API，讓開發者可(kě)以用(yòng)JS調用(yòng)微信支付、掃碼等衆多(duō)HTML5做不到的功能(néng)。

▲ 微信JS SDK說明文(wén)檔

但微信團隊對這套方案的體(tǐ)驗仍然不滿意，微信錢包欄目裏打車(chē)、理(lǐ)财等很(hěn)多(duō)應用(yòng)雖然嵌入了JS SDK，但每次點擊要等半天白屏，讓人用(yòng)着很(hěn)痛苦，他(tā)們在業内開始尋找新(xīn)的解決方案。

業内早有(yǒu)專業團隊看到了相同的問題。

與浏覽器不同，Hybrid應用(yòng)是另一個細分(fēn)領域。它們為(wèi)開發者提供使用(yòng)JS編寫跨平台應用(yòng)的工(gōng)具(jù)，為(wèi)了讓JS應用(yòng)更接近原生應用(yòng)的功能(néng)體(tǐ)驗，這個行業的從業者做出了很(hěn)多(duō)嘗試。

筆(bǐ)者所在的DCloud即是其中(zhōng)之一，我們提出了改進HTML5的「性工(gōng)能(néng)」障礙的解決方案 —— 通過工(gōng)具(jù)、引擎優化、開發模式調整，讓開發者可(kě)以通過JS寫出更接近原生app體(tǐ)驗的應用(yòng)。

多(duō)WebView模式，原生接管轉場動畫、下拉刷新(xīn)、Tab分(fēn)頁(yè)，預載WebView……各種優化技(jì )術不停叠代，終于讓Hybrid應用(yòng)取得了性能(néng)體(tǐ)驗的突破。

Hybrid應用(yòng)和普通的輕應用(yòng)相比，還有(yǒu)一個巨大的差别：一個是Client/Server，一個是Browser/Server。簡單來說，Hybrid應用(yòng)是JS編寫的需要安(ān)裝(zhuāng)的app，而輕應用(yòng)是在線(xiàn)網頁(yè)。

C/S的應用(yòng)在每次頁(yè)面加載時，僅需要聯網獲取JSON數據；而B/S應用(yòng)除了JSON數據外，還需要每次從服務(wù)器加載頁(yè)面DOM、樣式、邏輯代碼，所以B/S應用(yòng)的頁(yè)面加載很(hěn)慢，體(tǐ)驗很(hěn)差。

可(kě)是這樣的C/S應用(yòng)雖然體(tǐ)驗好，卻失去了HTML5的動态性，仍然需要安(ān)裝(zhuāng)、更新(xīn)，無法即點即用(yòng)、直達二級頁(yè)面。

那麽C/S應用(yòng)的動态性是否可(kě)以解決呢(ne)？對此，我們提出了流應用(yòng)概念，把之前Hybrid應用(yòng)裏的運行于客戶端的JS代碼，先打包發布到服務(wù)器，制定流式加載協議，手機端引擎動态下載這些JS代碼到本地，并且為(wèi)了第一次加載速度更快，實現了應用(yòng)的邊下載邊運行。

就像流媒體(tǐ)的邊下邊播一樣，應用(yòng)也可(kě)以實現邊用(yòng)邊下。

在這套方案的保障下，終于解決了之前的各種難題：讓JS應用(yòng)功能(néng)體(tǐ)驗達到原生，并且可(kě)即點即用(yòng)、可(kě)直達二級頁(yè)面。

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

這套技(jì )術，需要讓客戶端引擎提前預置在手機上，就像流媒體(tǐ)的普及，建立在Flash的裝(zhuāng)機量巨大的基礎上，那麽普及這個客戶端引擎就變得很(hěn)重要。

2015年，360和 DCloud合作(zuò)，在360手機助手裏内嵌了這個客戶端引擎，推出了業内第一個商(shāng)用(yòng)的小(xiǎo)程序，360稱之為(wèi)360微應用(yòng)。

微應用(yòng)實現了在360手機助手的應用(yòng)下載頁(yè)面，同時出現了「秒(miǎo)開」按鈕，點擊後直接使用(yòng)。

并且在360手機助手的掃碼裏，應用(yòng)的分(fēn)享裏，都實現了掃碼獲得一個應用(yòng)，點擊分(fēn)享消息獲得一個應用(yòng)。

為(wèi)了做大生态，DCloud把這套技(jì )術标準，捐獻給了HTML5中(zhōng)國(guó)産(chǎn)業聯盟，随後，聯盟開始推動更多(duō)的超級app和手機廠商(shāng)加入，共同推進動态app産(chǎn)業的發展。

然而事情并不順利，巨頭們有(yǒu)自己的利益訴求。雖然有(yǒu)一批廠商(shāng)同意加入聯盟共建生态，但最關鍵的角色，真正的國(guó)民(mín)應用(yòng)「微信」，最終決定自立标準、自研引擎，當然技(jì )術原理(lǐ)與流應用(yòng)是基本一緻的。

2016年 1月 11日，微信公(gōng)開課，張小(xiǎo)龍罕見露面，公(gōng)布了微信應用(yòng)号的計劃，為(wèi)這個大事件親自站台。

2016年 9月 21日，微信宣布更名(míng)應用(yòng)号為(wèi)小(xiǎo)程序，面向首批開發者内測。從此，這個詞被正式定了下來，「小(xiǎo)程序」，成為(wèi)後續一個時代的代名(míng)詞。而「流應用(yòng)」、「微應用(yòng)」則淹沒在曆史長(cháng)河中(zhōng)成為(wèi)一個令人唏噓的故事。

2017年 1月 9日，微信公(gōng)開課，小(xiǎo)程序面向用(yòng)戶正式推出。

從此後，阿裏巴巴、手機廠商(shāng)聯盟、百度、今日頭條，陸續推出了自己的小(xiǎo)程序平台，其中(zhōng)也有(yǒu)很(hěn)多(duō)波折與故事，在有(yǒu)偶然、有(yǒu)必然的過程中(zhōng)，形成了今天的局面。

小(xiǎo)程序大潮卷入了更多(duō)人，并形成了更大的浪潮，最終迎來了不可(kě)逆轉的小(xiǎo)程序時代。

3. 生态難，難于上青天

發明能(néng)解決功能(néng)體(tǐ)驗和動态性的技(jì )術方案，雖然難，但不是最難的事情。

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

最初HTML5中(zhōng)國(guó)産(chǎn)業聯盟的策略是在HTML5上擴展強化，複用(yòng)現有(yǒu)的HTML5生态。

當微信的标準完全自立重建時，業内人士都懸着一顆心。

在全球，基于Web的技(jì )術生态已經非常成熟，各種開發工(gōng)具(jù)、框架、組件、模闆...提升着開發者的效率。

小(xiǎo)程序丢棄了國(guó)際标準組織W3C的 DOM和 Window标準，僅僅采用(yòng)基礎JavaScript。這意味着HTML5生态的各種輪子無法複用(yòng)，要完全重造一個新(xīn)的小(xiǎo)程序開發生态。

當初微信推廣JS SDK時，是那麽地順其自然，開發者紛紛開始使用(yòng)，因為(wèi)對于開發者，隻是在他(tā)們的H5版本上補充一些API而已。

而小(xiǎo)程序初期，充滿了開發者的質(zhì)疑聲：我的業務(wù)叠代那麽久，讓我重新(xīn)做一個版本，你的生态到底能(néng)不能(néng)支撐我的投入？

微信用(yòng)持續而快速的版本升級、高管的站台，告訴大家微信做小(xiǎo)程序的決心，并最終通過2017年底的跳一跳，引爆了小(xiǎo)程序。

從此大家的問題不再是我要不要做小(xiǎo)程序了，而轉向了：既然要做，怎麽才能(néng)提升小(xiǎo)程序的開發效率、降低開發成本？

任何一種技(jì )術，或者開發模式的演進，在不斷成熟的過程中(zhōng)，都遵循着類似的成熟規律：

技(jì )術标準 -> 基礎平台 -> 開發工(gōng)具(jù) -> 培訓市場 -> 框架誕生 -> 周邊生态逐步完善 -> 輪子之上的輪子

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

多(duō)層輪子代表着生态的繁榮，也意味着開發者的開發效率更高。

可(kě)微信的全新(xīn)标準出現時，它把開發者推回了原始社會，一切都要重來。

這在當時看來，并不是一個必然會成功的事情（其實直到現在，比如圖表類輪子，小(xiǎo)程序仍然比不過HTML5）。

時至今日，讨論這個标準的選擇對錯已經沒有(yǒu)意義。當支付寶、百度、今日頭條都開始參考這個标準做小(xiǎo)程序時，時代已經不可(kě)阻擋。

所幸，最終的結果是，中(zhōng)國(guó)人做成了。在國(guó)際标準之外，在中(zhōng)國(guó)，終于建立起了自己的技(jì )術生态。

并且這個生态，給用(yòng)戶帶來了更好的體(tǐ)驗，給開發者帶來了更多(duō)流量和變現效率的提升，這是一個比HTML5更優秀的生态。

4. 野蠻的技(jì )術生态成長(cháng)速度

兩年時間，中(zhōng)國(guó)的小(xiǎo)程序開發者如何從原始社會進階到現代文(wén)明？這也是一段有(yǒu)趣的曆史。

我們來看看小(xiǎo)程序技(jì )術生态是如何快速成長(cháng)，走完上面所說的這套技(jì )術成熟路線(xiàn)，也就是從技(jì )術标準到輪子之上的輪子的。

在Web世界裏，已經成熟到了原生JS用(yòng)量很(hěn)少的時代了，開發人員大量使用(yòng)Vue等框架，并且在Vue的基礎之上，又(yòu)有(yǒu)更多(duō)輪子。

當中(zhōng)國(guó)的開發人員面臨重頭開始時，他(tā)們感受到效率對比的差距，既然時代已不可(kě)阻擋，那就擁抱它。勤勞的中(zhōng)國(guó)技(jì )術人開始蓬勃地建設起了小(xiǎo)程序各種周邊技(jì )術生态。

其中(zhōng)比較重要的是開發框架的叠代，我們看看每個小(xiǎo)程序開發框架為(wèi)什麽會誕生、流行和衰落。

最初的微信小(xiǎo)程序，一片荒蠻，一份文(wén)檔 + 一個難用(yòng)的IDE，很(hěn)多(duō)效率工(gōng)具(jù)比如npm、預處理(lǐ)器這些都不支持，而這些已經是大型項目離不開的工(gōng)具(jù)。

于是，第一個标志(zhì)性的框架出現了 ——WePY。

WePY緊随微信小(xiǎo)程序在2017年發布，原本是騰訊其他(tā)部門的一個個人工(gōng)程師的作(zuò)品。在那個年代，WePY有(yǒu)效地解決了小(xiǎo)程序不支持npm、預處理(lǐ)器的痛點，被引爆後，騰訊官方才把這個框架收編到官方的GitHub下。

不過WePY也面臨很(hěn)多(duō)問題，它使用(yòng)了私有(yǒu)語法，這讓它在生态建設上面臨很(hěn)大難度，IDE着色、語法提示、語法校驗、格式化、人員招聘培訓等各方面問題制約着它的流行和普及。

面對這些問題，人們開始思考，有(yǒu)什麽更好的方式，可(kě)以複用(yòng)現有(yǒu)技(jì )術生态來快速完善小(xiǎo)程序生态？

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

MPVue采用(yòng)Vue語法來開發小(xiǎo)程序，通過對Vue.js的底層改造，實現了編譯到微信小(xiǎo)程序。

MPVue良好地借助了Vue的技(jì )術生态，周邊工(gōng)具(jù)如IDE、校驗器、格式化等支持直接複用(yòng)、人員招聘培訓等生态建設壓力大幅下降，受到了大量開發者的歡迎。

看着熟悉Vue的開發者終于有(yǒu)了趁手的輪子，那熟悉React的開發者怎會無動于衷？

京東團隊是React的重度用(yòng)戶，還自研了JDreact，于是他(tā)們開發了Taro框架，一款基于React語法編寫小(xiǎo)程序的框架。

但Taro并不是想簡單做一個MPVue在 React世界裏的翻版，Taro相比MPVue，想要解決更多(duō)重要問題。

Taro面世較晚，此時微信、支付寶、百度、頭條都已發布或宣傳了自己的小(xiǎo)程序，開發者面臨一個多(duō)端開發和适配的問題。

于是Taro率先支持多(duō)端開發，它甚至還能(néng)發布到H5和 app。

當時小(xiǎo)程序領域還有(yǒu)一個重要變化，微信開始支持小(xiǎo)程序自定義組件。

組件是一個成熟框架不可(kě)缺的東西，不管是Vue還是React都有(yǒu)豐富的組件生态。

在過去，MPVue時代，是把Vue組件也編譯成頁(yè)面模闆，這帶來一個很(hěn)大的性能(néng)問題，在複雜頁(yè)面裏（比如長(cháng)列表）使用(yòng)組件，更新(xīn)組件狀态會導緻整個頁(yè)面的數據全部從JS邏輯層向視圖層通訊一次，大量數據通訊會非常卡頓。

注意：小(xiǎo)程序的邏輯層運行在V8或 JSCore下，和視圖層是分(fēn)離的，通訊阻塞很(hěn)容易引發性能(néng)問題。

于是Taro把 React組件編譯為(wèi)新(xīn)出的微信小(xiǎo)程序自定義組件，這種組件在數據更新(xīn)時，隻會更新(xīn)組件内部的數據，而不是整個頁(yè)面更新(xīn)數據，從而大幅減少了數據通信量。

這一輪的後浪推前浪很(hěn)猛，Taro在性能(néng)和多(duō)端支持上，都超越了MPVue。

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

我們基于Vue開發了uni-app，它實現了自定義組件編譯模式，并在算法上做了很(hěn)多(duō)優化。另外，之前MPVue對 Vue的語法支持度不太完善，比如過濾器等不支持，在uni-app中(zhōng)我們進行了解決。

同樣，uni-app也看到了前浪的其他(tā)問題：Taro雖然邁出了多(duō)端的第一步，但多(duō)端支持能(néng)力比較弱，每個平台仍然各自開發大量代碼。核心原因，是Taro在 H5端和app端，并不是一個完整的小(xiǎo)程序技(jì )術架構，無法保持最大程度的統一。

于是uni-app在 app端，使用(yòng)了一個技(jì )術架構相同的小(xiǎo)程序引擎，本身就可(kě)以直接運行小(xiǎo)程序應用(yòng)，這個引擎搭配小(xiǎo)程序代碼打包為(wèi)app，開發者一行代碼不用(yòng)改，可(kě)以同時發布小(xiǎo)程序和app。

當然，其app引擎從Hybrid應用(yòng)起家，它提供的API要比小(xiǎo)程序多(duō)很(hěn)多(duō)，因為(wèi)app的需求會比小(xiǎo)程序豐富，它還支持把WebView渲染引擎替換為(wèi)Weex渲染引擎。

之後uni-app又(yòu)發布了H5版的小(xiǎo)程序引擎，原理(lǐ)與小(xiǎo)程序的PC模拟器相同，實現了良好的跨H5版的發布。于是uni-app比較完美地實現了開發一次，7個平台發布。

第一層輪子就這樣迅速發展了起來，Web世界裏最成熟的Vue、React技(jì )術生态被導入了小(xiǎo)程序開發生态中(zhōng)。然後輪子之上的輪子開始如火如荼的建設。

以UI庫為(wèi)例，之前的UI庫，有(yǒu)Vue庫、React庫，有(yǒu)PC庫、H5庫和小(xiǎo)程序庫，種類繁多(duō)，甚至說混亂。

比如在Vue陣營中(zhōng)，Vant和 iView這兩個UI庫，都是同時維護兩個版本，它們即有(yǒu)H5版，又(yòu)有(yǒu)小(xiǎo)程序版。

不止框架作(zuò)者麻煩，開發者想在多(duō)端使用(yòng)這些UI庫時，會發現在不同端還需要引入不同的UI庫，寫法都不一樣，這讓開發者很(hěn)崩潰。

既然已經可(kě)以多(duō)端開發應用(yòng)，于是在多(duō)端開發的領域裏，開始出現輪子之上的輪子，多(duō)端UI庫。

首先是Taro推出了Taro UI，實現了H5和小(xiǎo)程序UI庫的統一，不過可(kě)惜Taro UI不支持app端。

然後uni-app推出了uni UI，這個UI庫同時支持多(duō)家小(xiǎo)程序、H5、app。

由于uni-app和 MPVue同屬Vue陣營，它們的組件是互通的。于是這兩家聯合舉辦(bàn)了一場插件大賽，建立了插件市場。

在中(zhōng)國(guó)的前端開發者領域，有(yǒu)很(hěn)多(duō)和國(guó)外不一樣的地方：一個是國(guó)内有(yǒu)小(xiǎo)程序，第二個是國(guó)内Vue的開發者體(tǐ)量遠(yuǎn)超過React和 Angular。這裏面很(hěn)大的原因，是Vue.js的作(zuò)者尤雨溪，是中(zhōng)國(guó)人。

在龐大的Vue用(yòng)戶體(tǐ)量支持下，uni-app和 MPVue的周邊生态迅速發展起來，開發工(gōng)具(jù)、周邊輪子、教育培訓等生态快速完善。目前在Vue陣營下，開發者在Web生态下所需的輪子，在多(duō)端開發下基本也都有(yǒu)了。

短短兩年時間，小(xiǎo)程序開發生态裏幾撥叠代，輪子之上的輪子不斷湧現，快速進入了成熟期。

5. 結語

産(chǎn)業還在繼續發展，每當底層有(yǒu)重大技(jì )術變更時，上層框架世界就會發生新(xīn)機會。

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

我們不知道未來還會有(yǒu)什麽新(xīn)的框架出世，但我們知道方向：

對于開發者而言，總是會向着更高的開發效率、更高的性能(néng)、更高的投入産(chǎn)出比前進。

對于開發商(shāng)，目前的小(xiǎo)程序，雖然發展了2 年，但流量增長(cháng)空間仍然巨大，微信之外，很(hěn)多(duō)超級app的勢能(néng)将逐漸釋放，整個小(xiǎo)程序産(chǎn)業的日活總量有(yǒu)數億的提升空間。

如果開發商(shāng)能(néng)追上這撥紅利，就能(néng)獲得更多(duō)增長(cháng)。而多(duō)端框架的出現，可(kě)以幫助開發商(shāng)更好的把握這撥紅利。