再談位元組小程式
作者:位元組小程式基礎技術團隊-楊德立
前言
如今,全網小程式數量已超700w+個,細分行業200+個,開發者數量超500w個,作為移動網際網路的重要新基建小程式網際網路已成型,使用者習慣已經養成。
位元組小程式身處大的生態之中,基於位元組APP而建。圍繞開放場景、開放介面、開放信任關係搭建的一套以小程式為最終落地的技術載體連線外部企業主體所提供服務的全鏈路生態解決方案。方案在主要提供和具備多頁應用級形態的開發和執行模式同時,還提供了單頁、卡片等的開發和執行模式,可支援多形態和執行模式間的執行時打通和聯動。目前已經覆蓋位元組內部抖音、抖音火山版、西瓜、頭條等20+個APP,並支援對外賦能,已上線外部APP 50+個。
讓宿主有執行小程式的能力是可打破應用孤島、連線更多服務的第一步。不同宿主基於各自發展的願景和使命,整合小程式框架所賦予開發者的玩法空間,承載的業務場景各有不同。基於一套小程式框架,可多種延展,以最輕量的方式實現同外部服務的快速連線,拓展能力邊界,構建業務生態能力。
1.方案價值
-
可規模化連結外部內容和服務:
-
方案安全性高,可規模化引入外部服務和內容 :平臺統一處理的沙盒隔離、平臺管控(鑑權、稽核、版控)、語法限定、能力封裝、包編譯和載入等策略在讓使用者可以較流暢和方便的使用小程式同時,穩定性和安全性做到統一、可控和有保障
-
小程式生態完善,行業滲透率高
-
-
提效開發:
-
基於成型的標準去開發
-
跨平臺相容成本低:平臺統一的對跨端碎片化差異相容
-
坑少:安全穩定性有保障,框架已經過大量小程式線上多業務場景的使用和驗證,配套質量保障工具、策略完善
-
上手成本低:與業界小程式方案統一,有任意小程式經驗可無成本接入開發
-
-
效能&體驗貼近原生:
-
邏輯 & 渲染分離:雙執行緒執行,避免存在因邏輯長時間執行導致頁面卡死的問題
-
更靈活多樣的原生元件和原生能力: 像video、map、textarea、live-player、Canvas等原生元件;AR、VR等能力支援
-
離線性好: 在弱網路&間歇性網路下,可開啟本地包,保障使用者體驗,從而避免了傳統H5無網路情況下使用者體驗差的問題
-
效能上限高: 在載入效率、通訊效率、渲染效率等多方面有更多的可探索和優化空間,在同一套小程式開發體系下,可探索和建設原生渲染和原生+原生混合的小程式渲染方案及編譯與載入策略
-
-
突破傳統 web 界限:
-
渲染優化打破瀏覽器限制: 容器預熱、預載入、預請求等優化手段有效提升首屏展現速度
-
多容器頁面管理脫胎換骨: 避免瀏覽器多 tab 頁跳頁白屏、回退重載入等問題,預渲染機制與跳轉動畫讓 web 體驗無限貼近純端實現
-
高度可控的資源包離線快取與更新手段:在規避瀏覽器快取策略不穩定的同時,也從根本上解決內容載入優化與內容更新的矛盾
-
2.價值出口
2.1價值主賽道-賦能位元組宿主:
支援位元組小程式平臺面向企業開發者和服務商開發者,關注其 入駐->開發->場景分發->使用者復訪 以及 場景安全保障的路徑。
對於連線外部的開發者,小程式開放平臺所提供的生態框架希望外部的開發者整合其能提供的服務,滿足抖音內使用者、創作者的需求獲得健康的收益,在這個生態下,讓企業本身成就一番「事業」而不僅僅是在和位元組APP做「生意」。
2.2價值子賽道-賦能業務:
2.2.1 充當核心業務開發的方案,讓業務低成本高效率開發和迭代
-
一套業務程式碼多端執行
- 小程式生來被賦予“一處程式碼、多處執行”的屬性和光環,一套程式碼可以跑在多端多平臺。使用小程式方案開發業務功能,可以較穩地做到降本提效,快速支撐業務的開發、上線和迭代。用統一的一波研發人力做到多端多平臺支撐。
-
提供通用和豐富的元件庫、模板,甚至支援基於低程式碼平臺生成小程式
- 平臺所提供的元件庫、模板及同低程式碼平臺的打通可支撐平臺所扶持的內部業務和合作業務同時, 也可以支援對外輸出。
2.2.2 國內多家超級APP基於小程式打造的平臺生態,為各行業和機構提供了在移動端運營自身生態和運營多渠道的可能性
-
賦能 那些有要“走出去” , 將自身內容或服務,嵌入到更多的應用場景當中去的業務, 早期更多是通過開放API、SDK等形式,如今小程式成為了更佳的載體。可控性強,可承載更多更強的內容和玩法,迭代和運營管理更方便。
-
走出去-到多生態平臺,打通多生態體系:
- 以貓眼電影為例,全景流量佈局強化宣發服務能力,通過貓眼小程式的生態佈局接入了更多支點,變得立體多元,實現從社交向搜尋、短視訊、直播等更為廣泛的渠道拓展,2021年春節期間,覆蓋抖音、微信、百度等多個平臺的貓眼小程式生態總使用者規模突破了4.5億,為影片宣發能力和使用者服務能力上開闢了新路徑。
-
走出去-玩轉一個生態體系 :
- 像懂車帝、幸福裡、西瓜小程式在位元組系多個產品線的上線,包括頭條,抖音,自身APP內等
- 像星巴克小程式在阿里系多個產品線的上線,包括支付寶,手淘,盒馬,餓了麼等
-
2.3價值子賽道-賦能更多APP:
越來越多的行業(業務)匹配有“走出去”的訴求同時, 也有著“引進來”的強需。將外部供應商、客戶等的資源和服務吸引到自己的生態內。
那些頭部的超級平臺,通過超級APP為使用者提供連線一切服務所帶動整個小程式生態不斷髮展背後,多行業供應商和客戶使用小程式的佔比變得越來越高,促進行業滲透效率越來越高。客戶和供應商對更多開放平臺也可支援小程式載體方式開放的呼聲越來越高,促進越來越多開放平臺將小程式為載體納為首選。
2.3.1 典型行業-金融行業
金融行業對小程式技術框架的應用背景:
銀行數字化轉型、開放金融生態是既符合監管要求又符合銀行發展路徑的明確方向。
銀行 App 作為數字化轉型的重要抓手,產品能力升級與相關科技投入將持續提升。
小程式作為銀行 App 生態開放的重要一環,將會在金融領域得到長足的發展。
- 開放銀行的大趨勢背景
開放銀行起源於英國和歐盟關於銀行業的資料共享和開放資料的探索,近年尤其是從 19 年開始在國內持續升溫。開放銀行的核心在於“銀行服務再也不是基於銀行實體,虛擬化的銀行本身即可提供”。它促進金融業務更加場景化。在手機銀行中引入場景化的服務,就是其中的一種形式。
- 國家政策及監管趨勢
從當前的監管趨勢來看,銀行持續數字化程序,建設自有線上流量經營金融產品將是大勢所趨。金融街論壇年會上,多位監管部門人士和專家強調了金融機構 數字化轉型的必要性,肯定了金融科技在數字化轉型中起到的重要作用。還談到必須高度重視網路安全、資料隱私、寡頭壟斷等風險挑戰,確保市場公平和金融穩定。
- 小程式建設是銀行 App 生態建設的實際需求
通常銀行尤其是大行不缺使用者,在銀行線上化程序中,絕大部分銀行客戶下載了銀行 App。但在實際運營 App 過程中,銀行業 App 活躍度普遍偏低。金融行業慣用的提升 App 活躍度方式為引入生活服務、政務服務等非金融場景服務。而隨著引入的服務越來越多,如何快速、高效引入外部服務場景就成為銀行需要考慮的問題。
Tips:金融行業對小程式技術框架的需求將會呈現由大到小,由少到多的趨勢,並且筆者判斷這種趨勢發展的速度將會很快。由大到小指的是將會由大行向中腰部銀行輻射,由少到多指的是隨著有需求的銀行將逐漸下沉需求量將會逐漸變多。
2.3.2 典型行業-電商行業
電商行業對小程式技術框架的應用背景:
有平臺自身要走出去的強訴求,線上流量有限,借力更龐大的流量渠道,更豐富的營銷推廣工具,提高運營效率、擴大銷量
有平臺自身對已有的商家開放平臺要突破生態規模的強需
有來自頭部KA和供應商希望通過小程式方式入駐的強訴求
- 平臺要走出去
電商平臺行業痛點: 線上流量有限,新平臺難以開啟市場空間;獲客成本日益增加,新客轉化低;客戶易流失,復購訂單少;低價文化,平臺補貼似流水;
通過小程式走出去: 借力超級平臺所提供的龐大流量渠道和豐富的營銷推廣工具
- 商家開放平臺要升級成支援商家小程式方式接入
賦能商家引流、留存、轉化、配置等整套入駐和運營玩法,幫助商家在平臺上有更大的發揮空間和品牌建設,讓更多商家願意入駐同時,讓平臺生態更加豐富,獲利環節更多。
- 響應頭部商家實際需要:一套小程式玩法在多電商平臺售賣和運營
通過小程式方式入駐到電商平臺, 小程式作為商家一個獨立的店鋪,顧客進入小程式只能在這一家店鋪瀏覽挑選,較好避免其他店鋪品牌的干擾,強化了店鋪的品牌形象,提升品牌忠誠度,沉澱顧客更輕鬆。同時還有更重要的一點: 商家如果在多個電商平臺均是通過小程式方式投放,可以在各電商平臺安全管控下,低成本的結合庫存和各平臺銷售情況,高效的調整價格及匹配多樣的運營活動。
Tips:金融行業、電商行業只是諸多行業裡的冰山一角,有部分企業已經行動起來,並嚐到其中甜頭,有要開放、要走出去同時引進來的 行業和領域都適用於此方案。在平臺具備較強的管控同時,可以給到更豐富和靈活的開放方式和空間。
3.位元組小程式框架包含內容
3.1 涉及內容
包含專案 | 功能描述 |
---|---|
IDE開發者工具 | 小程式開發者工具是面向小程式開發者推出的 PC 端開發者工具,支援小程式開發、除錯、預覽、上傳等基本功能,並且整合開發者服務(包含智慧客服等),支援在 Windows、Mac 多平臺上執行,核心目標是為了幫助開發者更高效地開發小程式。 |
小程式程式碼轉換工具 | 小程式程式碼轉換工具可以幫助開發者快速從其他小程式轉換為位元組小程式或自家小程式。 |
文件站 | 管理員使用markdown在後臺編輯文件,將小程式的相關API特性、工具用法展示給廣大開發者。 |
小程式截圖工具 | 通過爬蟲工具獲取小程式路徑/引數,並對線上/待上線小程式進行截圖,幫助稽核同學快速完成稽核工作,核心目標是提升開發者提審速度。 |
小程式SDK | 對小程式容器封裝,支撐小程式執行時及API、元件能力的封裝,內部採用多層級設計,包含通用基礎層、業務基礎層、應用層、接入層。 整合小程式SDK是讓你的APP可以執行小程式的前提 |
管理平臺 | 提供小程式上下線管理、配置管理、運營管理等 |
平臺服務 | 提供登入、包管理、編譯、稽核、預覽等服務, 對外可使用公有云服務,也可支援私有化部署 |
3.2 位元組小程式方案Show
在主流的小程式方案支撐和承載上,並無較大差異。匹配多業務場景提供了更多開發模式支援和更多渲染方案的支援。
3.2.1方案本身
Tips:一句話:常規認知裡的小程式方案優點我們都有,缺點我們可以沒有,一套開發標準下可以滿足市面所有對解決方案的期待
3.2.2方案Show- 普通小程式
Tips:開發標準適用性較廣,已大規模對外開放,一處開發,多處執行,可低成本支援跨BAT小程式互轉;
採用雙執行緒架構、多程序模式(Android)、hybrid渲染等優化技術。支援全屏、X分屏展示、支援同進程多小程式例項執行。
3.2.3方案Show- 原生渲染小程式
Tips:開發標準適用性偏弱,目前底層基於Lynx渲染,API可和普通小程式拉齊,但僅支援有限的CSS和元件,尚不適合規模化開放;
適用於開放和覆蓋到頁面簡單,對效能高的合作方和模板化場景內;
較適用於通過低程式碼平臺生成小程式的場景,把低程式碼平臺支援的元件和模板支援用純原生渲染。
3.2.4方案Show- 混合渲染小程式
Tips:使用WebView渲染頁面和使用Oryx/LynxView渲染的頁面共享同一個執行時 ,讓高標準要求的頁面可以使用webview渲染同時, 可通過Oryx/LynxView滿足高效能和體驗要求的場景
3.2.5方案Show- OneCard卡片
Tips:基於小程式技術體系,面向標準化、輕量化、高效能的開放卡片場景,提供給開發者的View級別解決方案,可跟小程式執行時打通,可跟原生頁面更好聯動。
4.合作&加入
筆者來自位元組小程式基礎技術團隊。團隊聚焦和致力於讓位元組小程式框架成為業內方案效果更優,能力更強,影響力和覆蓋面更大的小程式框架。 我們負責位元組小程式框架建設並向位元組內及外部應用賦能。如果你有要進一步瞭解和使用這套框架的需要,歡迎進一步交流。如果你也熱衷於這個生態和方案的建設,歡迎加入我們。合作&加入聯絡:[email protected]
此文提到的小程式框架後續將在位元組跳動應用開發套件 MARS 上線,MARS 是位元組跳動終端技術團隊過去九年在抖音、今日頭條、西瓜視訊、飛書、懂車帝等 App 的研發實踐成果,面向移動研發、前端開發、QA、 運維、產品經理、專案經理以及運營角色,提供一站式整體研發解決方案,助力企業研發模式升級,降低企業研發綜合成本。歡迎大家持續關注和接入使用。