對於很多使用者來說，App這個事物，似乎是人與機器打交道的最天經地義的方式，彷彿“自古以來”就是如此。00後的“後浪”們，使用App可以說是“與生俱來”了。而從未接觸過電腦的七八十歲老人，則可能是透過使用手機而首次接觸到“帶晶片的機器”，App也是他們這輩子首次接觸到的軟體。前些年裡，很多企業的“數字化”，也言必App。

但App這個東西，也就隨著智慧手機的大流行出現了不過十二三年，而移動網際網路發展的高峰期顯然已經過去了。App這種形態的軟體，早在幾年前，也已經遭遇到它的困境露出疲態。它對於使用者和開發者，都產生一定的侷限。

App類技術的疲態

App的軟體形態存在這些問題：

它們是使用者手機裡的一個又一個資訊孤島，明明在同一個裝置上，卻無法互相跳轉連通。尤其是和開放的Web連線互通不順暢平滑。甚至可以說，手機App之間的移動網際網路，和PC時代以來瀏覽器中的網際網路，是兩個平行世界。

對一個App的發現、安裝和執行，過程並不流暢。發現機制，一是透過網際網路搜尋引擎，或者透過一些媒體內容介紹，從而找到跳轉Google Play、Apple App Store、Huawei App Gallery等等的連結，然後再從這些應用商店裡下載;二是直接在應用商店裡搜尋下載。然後安裝使用。使用者之間的互相推薦分享，沒有什麼特別便利的機制 - 透過郵件、簡訊傳送連結，然後接收方重複上述過程，此過程中流失率高。

應用商店的存在，對於開發者和消費者，都有點雞肋。它隔斷了使用者在open Web直接透過連結下載App的可能，它裡面的內容通常也不能被網際網路搜尋引擎直接索引，所以使用者只能自己“逛店”，到裡面主動發起搜尋，或者看看當前的App排行榜，去發現有興趣的東西，但顯然現在越來越少人會去幹這種事情。對於開發者而言，所開發的App申請上架，稽核時間不可控，被駁回的理由不透明，發版週期長。發版後，想讓自己的產品在有數百萬App的應用商店中脫穎而出，營銷成本極高

對於任何企業來說，資訊化意味著養一個團隊同時支援iOS、Android以及Web。三者功能不易對齊、進度不易同步、體驗完全不同

時代召喚新軟體形態 - 輕應用

App的“重”，導致了一系列讓它們“變輕”的技術手段出現，包括了Apple App Clips、Google Instant Apps，也包括了中國市場發展起來的由手機廠商聯盟推動的“快應用”，當然也包括了最成功的“小程式”。這些技術載體標準、規格各異，採用的技術開發工具、開發方式以及所執行的環境也不同，但是它們無疑都是要達成“輕快”體驗的目標。

蘋果App Clips

Apple的App Clips，有說是Apple版的“小程式”。Apple官方稱之為「輕應用」，可以理解成是某個App的輕量級版本，它擁有該App(本體)的部分功能，可以把它看做已有App的某個功能碎片。App Clips體積相對小，壓縮前包體積最大不超過 10 M，關鍵是無需經 App Store 下載，因此它能保證及時性。從這個角度看確實有點像小程式。

App Clips的介面是一個卡片，使用者在iPhone上看到它顯示的時候，它背後的程式碼幾乎就已經安裝在了裝置上了，所以響應迅速。App Clips是使用者快速訪問和體驗一個App功能的便利方式，作為該App的一小部分，可以隨需隨用，而且使用時該Clips所屬的App並不需要被預先安裝存在於使用者裝置上 - 這也是App Clips的主要賣點：讓使用者快速體驗App的部分功能後，再決定是否下載完整的App本身。

App Clips提供了快速展示本體App價值的機會。要讓使用者更輕鬆地獲取完整App，開發者可以適時的在 App Clips中顯示下載選項。App Clips甚至可以保留使用者提供的任何資訊，並且無縫轉移到完整 App 中。

但是，它有一些比較大的侷限：

App Clips開發屬於 iOS 原生開發，開發過程幾乎和原生開發無異。所以，沒有iOS開發工程師的企業或者團隊，就別指望靠HTML5前端工程師去幹這活了

App Clips號稱無需經過App Store下載，但不要以為它就無需提交Apple經受比較痛苦的稽核過程，你並沒有這個自由。它既然是App的一部分，每次升級還是得提交稽核釋出

App Clips既然是iOS原生的程式碼實現，顯然它就無法在Android等其他平臺上存在。所以它不是一個跨平臺保障一致性體驗的機制。例如你很可能需要用Google Instant Apps的方式來重新實現一次類似功能(但使用者體驗無疑是很不一樣的)

因為上述技術原因，更因為小程式這種形態的應用已經在國內市場取得巨大成功，App Clips估計難以得到廣泛的應用。

Google Instant App

其主要目的是其針對本體App，提高被使用者發現的能力。例如使用者可以透過搜尋引擎和產品網站發現和直接開啟使用體驗一個Instant App，並因此被“引流”去下載安裝完整的本體App。其他方面與Apple的App Clips原理上有相似性。當然，具體技術實現手段從程式語言到工具都完全不同。它也是原生應用開發的一部分。

小程式

說到小程式，大部分的讀者第一反應，可能就是某些網際網路社交平臺、支付平臺上的小程式。確實，小程式的概念深入人心並且已經被約定俗成的繫結到某些網際網路公司的App上，導致大眾聽到這個概念時無法分清它指的是某家企業的小程式平臺、還是某個機構所開發的小程式應用、還是某種型別小程式軟體技術。

僅僅在小程式這個範疇下，又有多家網際網路巨頭的技術競品。除了上至80老翁下至8歲小兒都熟悉的“微信小程式”之外，尚有支付寶、百度、美團、京東、快手、頭條等等多家的平臺。

小程式之所以“輕”，是因為它基於HTML、CSS、JavaScript以及JavaScript基礎上一些DSL(Domain Specific Language，通常以XML形態出現)，以文字格式傳播，載入後由“宿主”App提供解析、渲染、執行的能力。也就是說它只是一些供解析的指令。它可以視為是HTML5基礎上的人機互動體驗最佳化，它輕量、利於傳播、能產生網路效應、發版敏捷、和Web內容可以無縫融合、跨裝置支援、繼承了HTML5的普適性又兼具了App的移動端體驗。

快應用

受到小程式類技術啟迪，由國內手機廠商和運營商共同發起的一種技術形態，因為與小程式的原理上有一定相似性，不在此贅述。值得一提的是，號稱是歐盟嫡系、歐盟基因的開源組織OW2，支援了快應用在歐洲的推動。

什麼是有生命力可持續發展的輕應用

雖然有Apple和Google這樣的巨頭在推動各自的“輕應用”技術，可是在此作為一家之言，我們並不看好這些技術形態能取得多大的成功。判斷標準是什麼呢?

能否解決跨裝置、全端支援問題。企業們都希望能夠讓自己的應用，開發一次、多處執行。硬體/作業系統廠商顯然不在解決這個問題的最佳位置上。當前即便有Flutter、RN等跨平臺技術去一定程度替代原生App的開發，但這些並非“輕應用”型別技術替代品。說到App Clips和Instant Apps，你依然需要採用iOS和Android的原生手段實現。

能否提供靈活多樣的發現機制。使用者不僅透過應用商店搜尋發現App，更可以透過網際網路搜尋引擎、網站傳播、朋友分享轉發，獲得相關應用資訊並在發現後即可“就地”使用。

是否對開發者也足夠輕。採用指令式的、解析型的語言程式設計，換句話說，基於指令碼型動態語言、標籤語言，應該是對大部分開發者而言門檻較低、開發較為敏捷。事實上也只有採用這種型別的技術，才能讓程式碼輕巧體積小和便於下載、轉發。

能否形成網路效應。數字化時代就是講使用者的網路效應，商業場景在人與人、裝置與裝置之間分享、傳播、借力，形成裂變。本質上這就是利用網路中的使用者節點去幫助做軟體分發。如果軟體體積大、接收者需要經歷明顯的下載安裝的階段，網路效應就無法達成。需要做到轉發者傳送方便，接收者則點開即用，就像開啟網頁連結馬上看到內容一樣。

傳播是否安全。原生的程式碼，因為對裝置端作業系統資源的訪問許可權較大，越過應用商店機制的“越獄式”隨意分發，導致的是病毒氾濫，對消費者資料安全、隱私保護造成極大傷害。App Clips和Instant Apps是嘗試在應用商店機制之外提供依然安全但又便利的折衷方案。但代價是比較複雜的技術機制。

有沒有公共標準或者工業標準可依託。使用建立在標準上的技術，對於開發者來說，風險低的多，首先所開發內容不用擔心被技術平臺鎖死，其次有標準工具可用。在一個技術標準的周圍，往往形成豐富的技術生態 - 開發工具、測試工具、外掛、文件、開源元件、開發者社群都形成積累。

是否建立在一個鬆散耦合的架構基礎上。輕應用往往都是一些功能單元、場景片段，如果它們之間的高度耦合、互相依賴、難分難解的，就無法獨立開發測試、互不影響的釋出。這好比伺服器端的服務，如果彼此緊密關聯，則最終它們形成一個事實上的單體應用，難以拆分和擴充套件，更遑論多團隊並行開發。Apple App Clips和Google Instant Apps，本質上是一個App的碎片，和App本體是一一對應、緊密耦合的關係。相較之下，小程式則是宿主應用與動態“外掛”的離散關係，外掛與宿主的關係是如此之鬆散，乃至外掛的開發者、擁有者數量可以無窮無盡，並且和宿主擁有者無需有任何前置商業關係。一個網際網路大平臺的App，動輒支援百萬級別的小程式。這種松耦合程度的技術架構，才可以支援高度敏捷性、高度可運營性、和高度的規模化。

如果基於上述的判斷條件，我們看好小程式這種技術形態是輕應用領域的良好選擇。因為：

• 便於在使用者之間、裝置之間的分享傳播

• 使用者之間的推薦，也是一種發現機制

• 基於JavaScript、CSS、XML而擴充套件/衍生，開發門檻相對低，能找到大量的Web開發者勝任開發工作

• 程式碼執行在基於瀏覽器核心的容器中，往往與執行環境所在的裝置的其他軟硬體資源隔離，安全性得到保障，但複雜度較低(無需開發者深入瞭解內部原理)

• 向未來相容 - 正因為技術棧建立在Web技術基礎上，Web上不斷出現的開源框架、工具往往都可以被利用

• 宿主應用與小程式之間極度鬆散耦合，讓敏捷輕量成為可能

所以，接下來我們主要討論小程式作為未來主流的輕應用形態。

是時候重新理解小程式

小程式的出現，已經有五、六年以上時間。是不是就已經發展到高峰甚至過了它的鼎盛期?實際上，這是一個在繼續演進的領域，還有很大的創新空間，是時候重新檢視，並對小程式這個概念作出一些澄清，因為它負載了過多的含義在裡面，往往在不同的語境下說的是不同的意思，導致了交流過程說明清楚的困難。

從手機使用者的角度看，小程式是一種應用，就是衣食住行、醫療健康、市政服務等等各種生活場景的服務互動方式，在終端使用者的印象裡它們似乎都是依附、歸屬在某個網際網路大平臺的App裡面的。

但對於開發者來說，小程式首先是一種技術載體，用什麼工具開發、基於什麼語言和規範、打包成什麼樣的格式、遵循什麼樣的要求才能申請上架到什麼網際網路平臺。

對於企業來說，往往要考慮自己的小程式投放到多個小程式平臺，這些平臺各自擁有其自己全權管控的小程式內容生態。企業不過是把自己的業務以小程式形態“進駐”到這些平臺上。

此外，小程式是一種正在形成的網際網路技術標準，W3C的Mini-App工作組正在形成標準化的建議稿(上文提到的歐盟開源組織OW2所支援的快應用實現，也將遵循這個標準)。它不再是某個網際網路公司的“專利”，“小程式”這個名字也不代表是哪一家的技術。它是一種輕應用形態，一種數字內容的表現方式，或者我們稱之為“小程式化的數字內容”。

標準形成後，小程式技術的底層實現方式，依然可以是各家廠商不同。這好比瀏覽器廠家有Google、Microsoft、Apple、Mozilla、Opera... 它們各自的產品Chrome、Edge、Safari、Firefox、Opera等等也完全基於各自的技術而產生，但這不影響它們都能正確的在各種電腦、手機上解析、渲染和展現HTML的內容。

規範、既成事實標準、最終工業標準的形成，帶來了對企業應用軟體的重新解構。市場上出現新的技術門類，就是讓企業以小程式這種形態為技術載體實現業務功能，並幫助企業以敏捷的方式，開發、運營、管理自己的“小程式化”的業務場景、應用服務、業務內容。小程式化，首先發生在企業內部的數字化程式中，它和網際網路上的平臺們，沒有必然的聯絡。企業裡開發的同一個小程式，它首先是供給給了自己的App，至於是否投放到第三方平臺，那是業務、法務、合規等等部門的聯合決策問題了。

新生物種：以小程式為載體的企業輕應用方案

網際網路巨頭們自營的平臺，在其中上架的小程式內容，均由他們進行稽核、生殺予奪。所形成的數百萬計的小程式內容生態，也是由平臺掌握。當然，這些小程式也只能執行在他們提供的App中。

但這種連線能力強、數字化程度高、生態內容豐富的技術，能否為一般企業所掌握呢?這裡所謂的“掌握”，不是說企業有能力去開發小程式然後上架至某個網際網路平臺開展業務、成為別人生態的一部分，而是企業能否擁有類似的技術，搭建自己的小程式運營平臺、小程式商店、小程式開發者中心，自行掌握對其中內容的稽核、上下架管理，把小程式投放至自己的App中執行，並讓別人成為自己的合作生態。

擁有這樣的技術，任何企業對內可以讓IT把業務內容小程式化、對外可以採購或引入開發商提供的小程式化應用系統，然後上架至自己的“小程式商店”，對自己的員工、客戶進行分發。

這種工具，我們稱之為小程式化輕應用技術底座，它就是讓企業以小程式這種“格式”、“規範”、“標準”去開發軟體功能，並對這些功能單元進行生命週期管理、上下架釋出稽核以及傳播渠道的投放與監控。

面向企業的小程式化輕應用技術，它的競品是誰呢?答案並非擁有小程式生態的網際網路平臺，而是傳統原生App開發模式、網頁應用開發模式、desktop軟體開發模式。這正如HTML、JavaScript首先盛行於網際網路的網站，後來它們逐漸被運用於企業應用，出現國內曾經風行一時的所謂“B/S架構” (Browser-Server架構)，從而與PC時代的C/S架構、基於Visual Basic/Visual C++的應用開發產生競爭並最終替代了後者。小程式化的輕應用技術，正處於從網際網路進入企業市場的時刻。

起源於金融業的輕應用技術底座

最早把小程式作為企業輕應用軟體技術載體的產品是FinClip - 凡泰極客自2019年前後即開始深耕這一領域。

FinClip的技術方案，目的就是要讓任何行業的任何企業，均可以擁有自主打造小程式生態、釋出管理小程式內容、在自己的App中執行小程式的能力。因為FinClip團隊相信：

• 小程式是促進數字化連線的最佳載體

• 連線是企業數字化轉型的核心關鍵

• 數字化內容資產的小程式化，最有利於敏捷釋出業務場景、實時風控、降本增效

FinClip 的命名本源，是 FinTech + Clip。因為這個技術起源於金融科技領域，原來的設計理念是，讓銀行、證券等金融機構把功能繁瑣複雜、合規要求嚴格、資料安全風險控制性強的數字化業務場景，以一種“輕應用”的技術形態開發，讓業務部門以“上下架”的機制自行進行功能碎片的釋出管理，讓消費者使用者以隨需隨用的方式載入至App中進行使用，並且每次的使用，總是自動獲得最新的版本。FinClip研發團隊基於金融業務場景的需求，經過對系列相關技術的深度研究，決定採用“小程式”格式，並把它稱之為“Clip”。

“Clip”這個詞，也被Apple在其App Clips技術中採用。它是一詞多義，濃縮了多箇中文翻譯的內涵，特別適合於技術命名：

【含義1】：別針、回形針。這可能也是大部分人所熟悉的第一反應。

【含義2】：報章、電影或電視的剪輯片段，例如“I watched a clip of the movie”。

【含義3】：快速、迅速。例如“We set off at a good clip, but we gradually slowed down”(我們出發時速度很快，但逐漸慢了下來)。

【含義4】：當作為動詞的時候，有“夾在”、“別在”什麼東西上面的意思。

因為小程式技術形態完全吻合這個單詞所包含的多重含義：作為程式碼“片段”，被“夾在”某個應用“宿主”上迅捷執行;並且程式碼是載入到一個嵌入在宿主中的“彈匣”(或者說“容器”)裡隨時射出;適合於像附件一樣轉發分享傳播的應用片段，啟動時間短、執行速度快。所以，FinClip的含義，就是“金融科技場景的敏捷輕應用”。

FinClip 讓金融機構能夠敏捷、動態的釋出業務場景，並能迅速對有任何潛在合規風險、資訊保安風險的場景實時下架，而無需重新發版App並經歷手機作業系統平臺的應用商店、應用市場長達數天的稽核甚至打回。畢竟金融業務風險處理有巨大的時間壓力，還有監管機構問責的壓力。風控永遠不嫌“實時”。

發展到今天，FinClip已經不再是金融業務場景的專用技術。事實證明，它能滿足強監管、強資訊保安與隱私保護規定、強風控要求的金融業訴求，也就能滿足其他各行各業的應用訴求。它也不再僅僅支援在手機App中執行輕應用，它更支援在各種桌面端、物聯網智慧裝置端的執行，逐漸發展成為一個在多終端、多裝置進行數字內容釋出與監測管控的平臺型技術工具。