後 App 時代的輕應用技術
對於很多使用者來說,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 是嘗試在應用商店機制之外提供依然安全但又便利的折衷方案。但代價是比較複雜的技術機制。
有沒有公共標準或者工業標準可依託。使用建立在標準上的技術,對於開發者來說,風險低的多,首先所開發內容不用擔心被技術平臺鎖死,其次有標準工具可用。在一個技術標準的周圍,往往形成豐富的技術生態 - 開發工具、測試工具、外掛、文件、開源元件、開發者社群都形成積累。
如果基於上述的判斷條件,我們看好小程式這種技術形態是輕應用領域的良好選擇。因為:
-
便於在使用者之間、裝置之間的分享傳播
-
使用者之間的推薦,也是一種發現機制
-
基於 JavaScript、CSS、XML 而擴充套件/衍生,開發門檻相對低,能找到大量的的 Web 開發者勝任開發工作
-
程式碼執行在基於瀏覽器核心的容器中,往往與執行環境所在的裝置的其他軟硬體資源隔離,安全性得到保障,但複雜度較低(無需開發者深入瞭解內部原理)
-
向未來相容 - 正因為技術棧建立在 Web 技術基礎上,Web 上不斷出現的開源框架、工具往往都可以被利用
所以,接下來我們主要討論小程式作為未來主流的輕應用形態。
是時候重新理解小程式
小程式的出現,已經有五、六年以上時間。是不是就已經發展到高峰甚至過了它的鼎盛期?實際上,這是一個在繼續演進的領域,還有很大的創新空間,是時候重新檢視,並對小程式這個概念作出一些澄清,因為它負載了過多的含義在裡面,往往在不同的語境下說的是不同的意思,導致了交流過程說明清楚的困難。
從手機使用者的角度看,小程式是一種 應用,就是衣食住行、醫療健康、市政服務等等各種生活場景的服務互動方式,它們必定都是依託在某個網際網路大平臺的 App 裡面的。
但對於開發者來說,小程式首先是一種 技術載體,用什麼工具開發、基於什麼語言和規範、打包成什麼樣的格式、遵循什麼樣的要求才能申請上架到什麼網際網路平臺。
對於企業來說,往往要考慮自己的小程式投放到多個 小程式平臺,這些平臺各自擁有自己全權管控的 小程式內容生態。
此外,小程式是一種正在形成的 網際網路技術標準,W3C 的 Mini-App 工作組正在形成標準化的建議稿(上文提到的歐盟開源組織 OW2 所支援的快應用實現,也將遵循這個標準)。它不再是某個網際網路公司的“專利”,“小程式”這個名字也不代表是哪一家的技術。它是一種 輕應用形態,一種數字內容的表現方式,或者我們稱之為“ 小程式化的數字內容”。
標準形成後,小程式技術的底層實現方式,依然可以是各家廠商不同。這好比瀏覽器廠家有 Google、Microsoft、Apple、Mozilla、Opera... 它們各自的產品 Chrome、Edge、Safari、Firefox、Opera 等等也完全基於各自的技術而產生,但這不影響它們都能正確的在各種電腦、手機上解析、渲染和展現 HTML 的內容。
規範、既成事實標準、最終工業標準的形成,帶來了對企業應用軟體的重新解構。市場上出現新的技術門類,就是以小程式這種方式為載體實現的企業軟體平臺,目的是幫助企業以輕量、敏捷的方式,開發、運營、管理自己的“小程式化”的業務場景、應用服務、業務內容。
新生物種:以小程式為載體的企業輕應用方案
網際網路巨頭們自營的平臺,在其中上架的小程式內容,均由他們進行稽核、生殺予奪。所形成的數百萬計的小程式內容生態,也是由平臺掌握。當然,這些小程式也只能執行在他們提供的 App 中。
但這種連線能力強、數字化程度高、生態內容豐富的技術,能否為一般企業所掌握呢?這裡所謂的“掌握”,不是說企業有能力去開發小程式然後上架至某個網際網路平臺開展業務、成為別人生態的一部分,而是企業能否擁有類似的技術,搭建自己的小程式運營平臺、小程式商店、小程式開發者中心,自行掌握對其中內容的稽核、上下架管理,把小程式投放至自己的 App 中執行。
擁有這樣的工具,任何企業可以讓對內 IT 把業務內容小程式化、對外採購引入開發商提供的小程式化應用系統和工具,然後上架至自己的“小程式商店”,對自己的員工、客戶進行分發。
這種工具,我們稱之為小程式化輕應用 技術底座,它就是讓企業以小程式這種“格式”、“規範”、“標準”去開發軟體功能,並對這些功能單元進行生命週期管理、上下架釋出稽核以及傳播渠道的投放與監控。
FinClip:起源於金融業的輕應用技術
最早把小程式作為企業輕應用軟體技術載體的產品是 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 中執行輕應用,它更支援在各種桌面端、物聯網智慧裝置端的執行,逐漸發展成為一個在多終端、多裝置進行數字內容釋出與風控的平臺型技術工具。
作者:凡泰極客工程師 F1n0Geek
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70017183/viewspace-2910996/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 技術輕工行業內軟體應用發展崛起的時代行業
- 資料經濟時代的信仰,區塊鏈技術的應用區塊鏈
- 探索新零售時代背後的技術變革
- 以“技術應變”之道,角逐後疫情時代企業數字化轉型
- 資料加密新技術-實時雲渲染技術應用加密
- Embedding技術與應用(3):Embeddings技術的實踐應用
- 後疫情時代 Wi-Fi 6在高校中的應用
- 數實融合 數字孿生進入“技術+應用”雙驅動時代
- 機器視覺技術在現代倉儲物流的應用視覺
- 得物技術時間切片的實踐與應用
- 後疫情時代,應用RPA將成為CFO必做的事!
- 後臺開發 -- 核心技術與應用實踐
- 一個輕APP場景應用-外掛APP
- Apple App Clip(蘋果「輕應用」)詳解APP蘋果
- 《現代前端技術解析》讀後鬼扯前端
- 超級app+輕應用,移動應用崛起新契機APP
- 全日程釋出|Sora之後的影片生成技術與應用Sora
- LoadRunner關聯技術的應用
- 兩個半月的業餘時間用Flutter做了個app-技術篇FlutterAPP
- BERT時代與後時代的NLP(一)
- BERT時代與後時代的NLP(二)
- Redis_RDB持久化之寫時複製技術的應用Redis持久化
- 技術乾貨 | 解鎖Redis 時間序列資料的應用Redis
- 蘇寧技術研究院:後疫情時代的零售行業趨勢及技術前瞻(附下載)行業
- 創新奇智CTO 張發恩:後AI時代,應用為王AI
- 後深度學習時代,計算機視覺技術如何走向未來?深度學習計算機視覺
- 中電金信:數字經濟時代,AI+金融技術應用與未來發展AI
- 分析技術在PMP中的應用
- 分散式賬本技術的應用分散式
- 後臺開發:核心技術與應用實踐 -- C++C++
- 【Azure 應用服務】App Service For Linux 部署Java Spring Boot應用後,檢視日誌檔案時的疑惑APPLinuxJavaSpring Boot
- 第三代基因測序技術革新 雲端計算的應用
- 應用響應時延背後 深藏的網路時延
- 深度解讀後疫情時代下,零售行業的趨勢及技術前瞻行業
- 低延時音影片技術在OPPO雲渲染場景的應用
- 後門函式技術在二進位制對抗中的應用函式
- APP簽名後的應用分發是什麼APP
- APP 技術支援APP