在 2021 年的時候，小程式已經成為了我們在日常生活中極其普遍的應用，每一天的生活與辦公場景中，「小程式」都在扮演著不同的角色。但不妨先讓我們把時間迴轉到 5 年之前，看看它是怎麼誕生的。

一、什麼是小程式

在 2016 年的「微信公開課 Pro」演講中，微信事業群總裁張小龍這樣描述了小程式的前景與未來：

“小程式是一種不需要下載安裝即可使用的應用，它實現了應用“觸手可及”的夢想，使用者掃一掃或者搜一下即可開啟應用。也體現了“用完即走”的理念，使用者不用關心是否安裝太多應用的問題。應用將無處不在，隨時可用，但又無須安裝解除安裝”。

蘋果官方對「輕應用」的介紹頁面

而在 2020年的「WWDC 蘋果全球開發者大會」中，輕應用則被作為 iOS 14 的主要功能進行強調與推介：

“ App Clip 就是一種無需使用者在 iPhone 或 iPad 上安裝完整的應用程式，就可以訪問使用該應用程式的部分功能的輕量級應用，它們專注於處理簡單快速的任務”。

不論是張小龍對「微信小程式」略帶文藝的描述，還是在 WWDC 上對於「輕應用」在 iOS 生態中的地位描述，我們都能大抵能理解小程式誕生的初衷。而如果我們把時間從這兩場釋出會的轉至今日，卻會發現小程式早已不再侷限於「用完即走」與「快速開啟」，各式各樣的小程式已呈現百花齊放的狀態，不論是工具小程式，內容小程式，交易小程式，直播小程式，各種型別應有盡有。

不妨讓我嘗試用自己的工作日常舉例，早上出門上班，我會開啟「天府健康通」掃描地鐵場所碼，並把健康碼給地鐵安檢檢視，臨近中午11點 30分，我會用「美團」或「餓了麼」為自己訂一份工作餐，吃完午飯後我會開啟「動物餐廳」看看小貓咪又賺了多少小魚乾，下午會議時使用「騰訊文件」檢視會議紀要，快下班的時候用「叮咚買菜」購置晚飯所需的食材，晚上回家做飯時，用「懶飯 App」看看想吃的番茄肥牛飯怎麼做。

各種型別小程式的使用截圖

時至今日，當我們說到小程式時，也不僅僅在特指微信小程式，各式各樣的平臺都紛紛推出了自己專屬的小程式平臺，不論支付寶、位元組跳動、美團還是百度等其他網際網路大廠，都紛紛推出了自己專屬的小程式平臺，且都基於自己的生態業務，為小程式提供流量進行支援，希望使用者與開發者能夠選擇自有平臺中的小程式進行開發。

隨著小程式業務的愈演愈烈，越來越多的流量都被引入了網際網路巨頭的小程式戰場中，但在這個過程中，對於戰場中「封閉，不透明」的吐槽與爭議也逐漸出現，無數企業都希望自己的應用中也能具備執行小程式的能力，希望能夠藉此抗爭小程式被引入寡頭所控制的戰場，但「知易行難」，快速完成對小程式的底層與容器的研發，所需要花費的精力與時間並不是短時間就能夠完成的。

事實上，小程式可以被理解為是「移動應用 App」的一個細分子集，如果按照「平等透明」的設想，小程式不應該僅僅存在於微信之中，那些我們並不經常使用的應用都可以通過小程式進行重新優化，我們可以通過各式各樣的專門應用開啟相關的小程式，從而對那些「太重的應用」進行減負操作。

當然了，小程式還會有這樣一些特性需要我們注意：

小程式不具備「被關注」的能力，獲取流量留存使用者的操作需要由獨立應用或其他渠道完成；
小程式不具備「推送訊息與群發訊息」的能力，對使用者的資訊觸達與訊息傳遞的操作需要由其他渠道完成；
小程式不具備「跨 App 分享」的能力，因此對於小程式的分享與開啟路徑，需要在設計產品時提前思考，而不是把雞蛋放在一個籃子裡；

二、哪種應用適合用小程式開發？

很多朋友在瞭解到 FinClip 的小程式容器時，都會想請我們看看對方的業務場景是否適合使用小程式進行開發，雖然小程式市場時至今日依然是一片藍海，但我想也不是所有應用「都可以，都應該」使用小程式開發的。

基於我們的經驗與積累來說，符合「邏輯簡單，使用低頻，對效能要求不極致」的應用場景，更加適合使用小程式進行研發。

「邏輯簡單」是指應用的操作邏輯並不十分複雜，各類生活服務（如叫車，訂餐，查地圖與導航等等）都需要給使用者提供簡單清晰的操作邏輯，而這一類也天然的符合起初小程式「用完即走」的定義，因此十分符合使用小程式研發。一些邏輯複雜的應用場景想要通過小程式進行適配，就可能會面臨更多的設計與研發困難，同時在效能和體驗也可能會面對更多需要解決的問題。

「使用低頻」是指小程式的使用頻率不應該太高，比如社交類的釘釘或飛書，金融類的掌上生活或浦大喜奔，媒體類的網易雲音樂或鬥魚都不太適合使用小程式進行重新設計。對於使用者使用的頻率較高的應用來說，直接開啟應用進行體驗的步驟肯定最快的，此外由於某些行業的特殊性質（比如具備交易，支付等能力）要求，對於安全性與保密性的首選風險判斷原則，也不宜使用常見的小程式進行設計。

「對效能要求不極致」是指由於小程式始終存在於某個獨立應用（也被稱為宿主應用）中，考慮到目前的效能與研發所限制，暫時不太適合開發對於這兩者有更高要求的移動應用。比如把原神，王者榮耀這樣的遊戲應用通過小程式進行重新設計，在目前來說肯定是不現實的。

FinClip 客戶案例

當然，隨著相關研發實力的增強與產業生態的逐漸補充，也有越來越多的「不可能」變為了「可能」，比如華西證券的「華彩人生」，浦發銀行的「浦大喜奔」，某省的移動警務平臺等客戶，都紛紛選擇使用 FinClip 的小程式容器方案進行落地實現。

三、小程式與 H5，原生應用的對比

很多朋友在瞭解小程式技術的時候，都會有這樣的疑惑“到底與 H5，原生應用”這些技術相比，小程式具有哪些優勢與劣勢呢？

H5 移動應用

我們常說的 H5 其實也通常可以被視為一種 Web App，相比於我們在桌面端瀏覽器中開啟的網頁，主要是增加了一些響應式的設計與互動優化，從而使得這些網頁更適合在移動端的瀏覽器中顯示執行。既然是網頁應用，那依然是基於 JavaScript，CSS 和 HTML 進行實現的，由於是基於各類前端技術棧進行實現，最大的好處就是快速、簡單、方便，且有各種技術資料可以參考。

同樣，H5 的缺點與優點也是並存的，比如由於技術已經很成熟了，對於前端經驗欠缺的新人來說，面對各式各樣的框架，模組、任務管理工具，UI 庫可能會出現無從下手的問題；此外相比於原生應用，對於系統許可權的獲取（比如資料快取能力，網路通訊狀態等）都顯得比較雞肋，當低效能的裝置載入包含複雜邏輯的頁面時，會出現明顯的卡頓與延遲問題。

原生應用

原生應用也被叫做 Native App，相比於 H5 應用通過前端三大件進行實現不同，原生應用主要會採用 iOS 與 Android 的專有語言 Object-C（或 Swift），Java（或 Kotlin）進行實現，大多我們所常見的國民應用，比如微信，支付寶等都屬於這種原生應用。

既然被叫做「原生應用」，就像作業系統的親兒子一樣，天然在效能與體驗上具備優秀的潛質，也有元件庫豐富，介面支援完善等各種優勢特點。但原生應用最大的缺陷就是不能跨平臺研發，以目前的主流市場為例，必須要支援 iOS 與 Android 兩個主流平臺。

混合應用

混合應用一般被稱為 Hybrid App。簡單來說，混合應用就是將原生功能封裝成對應的 JS 介面，在前端使用 H5 來開發對應的 App （即 H5 作為內容+原生應用作為殼），看上去雖然是一個移動原生應用整體，但實際的頁面還是網頁，一套程式碼可以生成 iOS 與 Android 兩種安裝包，開發成本較低。

我們常見的淘寶，京東等應用由於更新與優化節奏都十分快速，為了更好的響應「貼近使用者」的目標，應用中有的功能通過原生 Native 實現，有的功能則通過 H5 頁面進行實現，這種應用就屬於我們所說的混合應用。

小程式

嚴格意義上來說，小程式並不屬於以上 3 種應用的任何一種。小程式主要通過 JavaScript 與 CSS 這種常見的前端技術進行開發，但又沒有完全使用 HTML 進行實現，在不同的作業系統中，JavaScript 程式碼分別執行在 iOS 的 JavaScriptCore 與 Android 的 X5 JSCore 中，各家小程式平臺或多或少都有一部分自研的核心，因此渲染檢視層的元件也有所不同。

與原生應用、混合應用相比，小程式的優勢

相比「 H5 移動應用」與「移動原生應用」，小程式具備如下優勢：

具備跨平臺的能力，一套程式碼可以在 iOS 與 Android 兩個平臺中執行；
遠超過 H5 的體驗（支援本地快取，Webview，有豐富的元件與支援庫）；
能獲取更多系統許可權，完成更加豐富的產品設計；
可以避免 DOM 洩露（不使用常用的 window 物件與 document 物件）；
開發簡單，上手成本低（比如 FinClip 提供了 FIDE 與開發文件）；

此外，小程式還具有這樣一些特有優勢（以下內容以 FinClip 為例）：

目錄結構清晰，程式碼結構簡單，便於初學者更好的學習與探索；
開發環境簡單，不需要配置各種各樣的腳手架與框架，開發成本極低；
釋出與部署流程簡單，不需要運維與服務端的相關支援，幾乎可以只通過「點選」完成小程式的提審與上架；
支援自定義元件，通過將元件的業務邏輯寫在元件模組之中，用元件化的程式設計思維設計業務；
具備 Windows SDK，在桌面系統中也能夠提供對應的支援與支撐，並不侷限在移動業務與應用中；

FinClip 小程式的接入步驟十分簡單

四、有哪些常見的小程式開發框架？

以主要的小程式開發框架舉例，騰訊雲社群的「極樂君」將不同平臺下小程式支援的力度整理在一張表中：

框架	技術棧	案例	微信小程式	支付寶小程式	百度小程式	頭條小程式	H5	App
Taro	React	豐富	⭕	⭕	⭕	⭕	⭕	⭕
Nanachi娜娜奇	React	少	⭕	⭕️	⭕️	⭕️	⭕️	❌
wepy	Vue	豐富	⭕	❌	❌	❌	❌	❌
mpvue	Vue	豐富	⭕	❌	❌	❌	⭕️	❌
uni-app	Vue	豐富	⭕	⭕️	⭕️	⭕	⭕️	⭕
megalo	Vue	少	⭕	⭕️	⭕️	❌	❌	❌
OKAM	Vue	少	⭕	⭕	⭕	⭕	❌	❌
Mpx	Vue	少	⭕	❌	❌	❌	❌	❌

截止目前，FinClip相容性較好的第三方框架包括：

小程式開發框架

（僅支援通過 uni-app 生成的小程式）

UI 框架

基於以往的研發經驗，我們建議大家使用 Taro 或 Uni-App 完成小程式的研發。Taro 在執行效能上的優化優於 Uni-App，而 Uni-App 則可以更好的支援跨端小程式的研發（通過其匯出的微信小程式也可以無縫在 FinClip 中編譯執行）。

由於各框架的倉庫與支援文件，社群都較為豐富，本文將不再贅述對其效能與使用的內容。

五、FinClip 是什麼？

至此，我們應該大概瞭解了小程式的前世今生，以及常見的框架。但文章寫到這裡，可能你內心一直有一個疑惑「FinClip 是什麼？」，我們將在這裡大抵進行描述，希望能夠幫助你快速瞭解 FinClip。

FinClip 產品官網

通俗來說，FinClip 小程式開放平臺是基於我們自研的小程式容器技術，幫助任何企業中的 App 具備執行小程式能力的一套技術。任何 App 都可以通過引入 FinClip 小程式 SDK 來獲得執行小程式的能力，也能夠在 FinClip.com 的後臺中完成小程式的更新，上架能力，與微信、頭條或支付寶小程式不同，FinClip 同時提供 SaaS 與私有化版本的小程式管理平臺，最大程度幫助開發者打造自己的業務開放生態，同時構建企業的專屬小程式開放平臺。

與 Taro 或 Uni-App 不同，FinClip 是一套小程式生態，開發者可以通過整合的 SDK 幫助 App 輕而易舉獲得開啟小程式的能力，此外 FinClip 也支援微信等其他平臺的小程式語法，支援平滑上架，如經過 Uni-App 所編譯的微信小程式可以直接被上傳至 FinClip 中，並在移動應用中開啟使用，為了儘可能為開發者與使用者提供良好的體驗，FinClip 不僅提供完善的開發、測試、上下架等全生命流程，引入 FinClip SDK 的應用安裝包體積僅會增加 2M 左右。

此外，FinClip 還具備灰度釋出，資料統計等偏向於業務側的能力，便於業務人員直接在管理後臺中編輯灰度釋出計劃，檢視小程式統計資料。

FinClip 擴充架構圖

截止目前，FinClip 小程式開放平臺已經與上百家知名券商，股份制銀行，航空公司，車載裝置服務商，省級移動警務平臺進行合作，並完成小程式及小程式沙箱的落地實踐，部署。

我們希望藉助 FinClip 的力量，不僅能夠降低企業內部 IT 研發的高昂成本，提升敏捷研發速率，也能夠幫助商務應用設計者，降低小程式研發門檻，並通過結合低程式碼技術，直接或間接地支援「更加平民化」的程式碼生成技術，讓小程式技術成為數字化基建的聯結器，促進行業內外互聯互通。

網際網路巨頭們為什麼偏愛小程式業務