重磅！W3C首次發佈小程序標準化白皮書，小程序要實現統一了嗎？

重磅！W3C首次發佈小程序標準化白皮書，小程序要實現統一了嗎？

源自 | W3C 官網 譯者 | 王強編輯 | Yonie2019 年 9 月 12 日，W3C 首次公開發布了小程序標準化白皮書，該文檔介紹了這種很是流行的混合解決方案，既依賴 Web 技術，也集成了原生應用的功能。此標準一出，各家小程序未來有望實現統一嗎？文檔狀態

本節介紹本文檔發佈時的狀態。本文檔可能會被其餘文檔取代。能夠在W3C 技術報告索引中找到 W3C 當前發佈列表和本技術報告的最新版本: https://www.w3.org/TR/

目前這項工做仍在推動中。該提案正在W3C 中文 Web 興趣小組中孵化。本文檔由中文 Web 興趣小組做爲首次公開的工做草案發布。

GitHub 問題列表是討論本規範的首選場所: https://github.com/w3c/mini-app-white-paper/issues/。或者你能夠向咱們的郵件列表發送評論。請將它們發送至 public-chinese-web@w3.org。

發佈第一個公共工做草案並不意味着得到 W3C 成員的承認。這是一份草案文檔，可能隨時被其餘文檔更新、替換或廢棄。引用這份文檔時應當指出它尚在推動中。

製做本文檔的小組是基於 W3C 專利政策運營的。該小組沒有預期該文檔會成爲 W3C 推薦標準。W3C 維護一份全部專利披露的公開名單，與該小組的交付相關；該頁面還包括披露專利的說明。若是我的擁有關於一項專利的實際知識，而且他認爲這些知識包含 「基本要求」 的內容，那麼他必須根據 W3C 專利政策的第 6 節披露該信息: https://www.w3.org/Consortium/Patent-Policy/#sec-Disclosure

本文檔受 2019 年 3 月 1 日 W3C 流程文檔的約束: https://www.w3.org/2019/Process-20190301/

   介紹   問題原生應用程序在咱們的平常生活中頗受歡迎，但它們在不少層面上也有改善的空間。

• 在用戶從原生應用程序獲取服務以前，他 / 她每每要先下載 - >安裝 - >註冊應用程序才行。因爲存儲能力的限制，用戶只能在設備上保留數量有限的原生應用。在不一樣的原生應用程序之間共享數據並不容易。

• 要開發原生應用時，開發人員可能須要學習一些新的編程語言。爲了向各個平臺的原生應用程序提供相同的服務，開發人員可能須要爲不一樣的平臺維護重複的產品。

Web 是可以避免這些問題的一個理想平臺，但到目前爲止，它仍然不夠完美。

• 與原生應用相比，Web 應用很難利用系統提供的功能。此外 Web 應用程序的性能很難媲美或超過功能相似的原生應用程序。

• 在移動設備上，用戶常常要獲取瀏覽器以外的服務或內容；顯然，他們但願系統中的全部應用程序在用戶賬戶、登陸狀態和用戶交互上保持一致。此外，有時用戶可能但願與應用程序共享某些數據（若是他們真的信任它），可是一些常常請求的信息（例如當前設備的我的移動電話號碼或聯繫人列表）很難在 Web 應用上提供許可。

小程序是什麼？

小程序是一種新的移動應用程序格式，是一種依賴 Web 技術（尤爲是 CSS 和 Javascript），但也集成了原生應用程序功能的混合解決方案。

小程序受到了一些超級應用程序的歡迎，由於它的一些特性有助於填補 Web 和原平生臺之間的鴻溝。

• 它不須要安裝。
• 具有多個 Web 視圖以提升性能。
• 它提供了一些經過原生路徑訪問操做系統功能或數據的機制。
• 它的內容一般更值得信賴，由於應用程序須要由平臺驗證。

• 小程序能夠分發到多個小程序平臺（Web、原生應用，甚至是 OS）。這些平臺還爲小程序提供了入口，幫助用戶輕鬆找到所需的應用。

咱們簡單地使用 PWA 不行嗎？小程序並非要取代 PWA、Web 或原生應用的。

• 目標
  • PWA：漸進式 Web 應用程序提供的用戶體驗與原生應用程序類似，對離線和推送 API 有更好的支持。
  • 小程序：小程序經過在原生應用、Web 應用和 OS 中共享數據和功能來提供無縫服務。
• 宿主環境
  • PWA：瀏覽器。

  • 小程序：小程序平臺有一些原生應用、Web 應用和 OS 沒有的功能。在此平臺上實現新 API 更容易。

案例研究 案例 1：共享單車服務

小程序的普及幫助共享單車成爲一項無縫服務，無需繁瑣的應用程序。

小程序的共享單車服務

• 用戶進入移動設備上的某個小程序平臺，通常來講是他 / 她已經登陸的某個超級應用程序；
• 用戶在超級應用內掃描共享單車上的二維碼標籤；
• 平臺應用將自動跳轉到共享單車小程序並當即解鎖自行車；
• 抵達目的地後，用戶在小程序上鎖定自行車；

• 交易完成後，系統將向用戶發送付款詳細信息。

對於用戶來講，小程序的便利體如今如下幾個方面： 

案例 2：AR 動物園

小程序開發人員只需使用 HTML/CSS/Javascript 做爲編程語言便可，但小程序比傳統應用更靈活，所以團隊能夠在平常開發流程中快速開發複雜的功能。

這款小程序構建了一個採用 AI 技術的 AR 動物園來識別這些動物。開發人員能夠添加一些組件或 API 來輕鬆實現這一需求，這些組件或 API 提供對原生功能或高級功能的訪問，諸如圖像識別、AR 3D 動物模型渲染、用於語音合成的語音 API、由地圖 SDK 提供的 AR 導航等。

小程序能夠經過搜索引擎、宿主應用程序中的小程序商店或二維碼來獲取。

AR 動物園小程序

對於開發人員來講，小程序的好處顯而易見。

 案例 3：用於物聯網的小程序

小程序的一個目標是在不一樣平臺上鍊接信息和服務，所以它是智能汽車、語音控制揚聲器和智能電視等物聯網應用的理想選擇。

爲車輛屏幕和系統適配小程序是可行的；爲此，一些小程序供應商已經構建了專門爲車輛系統設計的小程序平臺，以幫助應用程序在多種車型上分發和升級。這使數百萬 Web 開發人員進入了汽車應用程序生態系統。

這些汽車小程序能夠服務於許多用戶場景，包括加油、洗車、電子收費、保險、餐廳預訂或娛樂等。例如，當系統檢測到剩餘燃料低於 20％時，它能夠向車主推薦 Gas Pumping 小程序。用戶能夠獲取最近的加油站信息並前往那裏加油，包括付款流程在內都在小程序中完成，實現「不下車加油」。

用於智能汽車的小程序（加油應用）

小程序概述

核心功能以下：

分離視圖層與邏輯層

在小程序中，視圖層一般與邏輯層分離。

小程序的通常架構

視圖層負責渲染小程序頁面，包括 Web 組件和原生組件渲染，能夠將其視爲混合渲染。例如，Web 組件渲染能夠由 WebView 處理，但 WebView 不支持某些 Web 組件渲染，或者是性能受限；小程序還依賴於某些原生組件，例如地圖、視頻等。

邏輯層是用 JS Worker 實現的。Worker 負責小程序的事件處理、API 調用和生命週期管理。

擴展的原生功能一般來自宿主原生應用程序或操做系統，這些功能包括支付、文件處理、掃描、電話等。它們經過某些 API 調用。當小程序調用原生 API 時，它會將 API 調用傳遞給擴展的原生功能，以便經過 JS Bridge 進一步處理，並經過 JS Bridge 從擴展的原生功能獲取結果。

調用 API 時小程序的數據流

Worker 爲每一個 Render 創建鏈接，傳輸須要渲染的數據以進一步處理。

若是事件由小程序頁面中的組件觸發，則此頁面的 Render 將向 Worker 發送事件以進一步處理。同時，Render 將等待 Worker 發送的數據來從新渲染小程序頁面。

渲染過程可被視爲無狀態，而且全部狀態都將存儲在 Worker 中。

視圖層和邏輯層分離有不少好處：

• 方便多個小程序頁面之間的數據共享和交互。
• 在小程序的生命週期中具備相同的上下文能夠爲具有原生應用程序開發背景的開發人員提供熟悉的編碼體驗。

• Render 和 JS worker 的分離和並行實現能夠防止 JS 執行影響或減慢頁面渲染，這有助於提升渲染性能。

 豐富的 API 和組件

小程序平臺提供了許多組件來幫助開發人員構建精美的 UI，包括 View、Form、Image 等基本組件以及 Maps 等高級組件。

小程序供應商還爲開發人員提供了許多 API，以便訪問 Web 和原生功能；這些 API 既有 UI 顯示 API 和圖像 API 這樣的基礎選項，也有帳戶 API、地圖 API、支付 API 等高級選項。

API 一般與組件一塊兒使用。當用戶單擊小程序頁面上的某個組件時，它將調用相關的 API 來完成用戶的交互，並在須要時刷新當前的小程序頁面。

 小程序構造

爲了得到與原生應用程序類似的用戶體驗，小程序資源一般打包在一塊兒。下載並安裝小程序軟件包後，用來顯示應用程序頁面所需的全部靜態頁面模板 /CSS/JavaScript 文件都已經在用戶的設備上就緒了。在下次更新以前，這些資源始終可用，無需任何額外下載內容。

小程序包是壓縮格式（例如 zip）存檔，包括：

• 一個配置文檔，位於包的根目錄下。配置文件應包括：
  • 整個小程序的概述。
  • 頁面描述及其對應路徑，用於頁面定位和開啓。
• 一個包含 JavaScript 代碼的應用級邏輯文件，處理應用級生命週期回調。
• 一個或多個頁面文件，包含頁面結構的模板代碼、頁面樣式的 CSS 代碼和頁面邏輯的 JavaScript 代碼。

• 支持數字簽名驗證。

爲了在搜索和執行時定位特定的小程序，小程序必須在平臺上具備包名或 ID。還須要一個小程序圖標幫助用戶識別。

 小程序小部件

除了以小程序頁面的形式渲染以外，小程序還能以信息片斷的形式顯示，亦即小程序小部件。在這種形式下，開發人員能夠將他們的服務和 / 或內容放到各類宿主場景（稱爲宿主環境）中，內容能夠是助手、搜索頁面等。此功能將小程序的服務與場景關聯起來，爲用戶提供更多便利。

例如，當用戶購買火車票時，智能助手上的小程序小部件當即顯示列車的最新狀態。用戶能夠單擊這個小部件並跳轉到全屏小程序頁面以獲取更多詳細信息。

從主屏幕到小程序的小部件

與小程序頁面相同，小部件也由 URI scheme 描述。宿主環境指定小程序包和對應的小部件經過 URI 路徑加載，並經過 URI 查詢參數將數據傳遞給小部件。小部件加載後，它將在宿主環境中顯示和渲染。來自宿主和小部件的數據以及來自其餘小部件的數據會被隔離，以確保安全性和獨立性。

在許多狀況下，小部件能夠打開小程序頁面以執行更復雜的操做。在這種狀況下，小部件一般須要與其對應的小程序共享數據，例如保持一致的登陸狀態。所以小部件和小程序的數據能夠互通。換句話說，小程序小部件和頁面具備相同的數據訪問權限。

小程序小部件交互

小部件的一個目標是讓用戶忘記傳統的應用程序概念，並以服務的形式真正知足用戶的需求。所以，除了全部傳統的應用程序調用路徑以外，小部件還能夠在各類場景下由多種方法觸發，例如文本關鍵字、語音分析、圖片識別、掃描代碼、事件意圖等。

 單實例，多入口

用來發現、打開和訪問小程序的入口衆多。與多 WebView 的 Web 應用不一樣，同一個小程序只會建立一個實例，所以小程序以全局一致的方式保持其狀態和數據。例如，在一個用戶經過二維碼入口第一次打開並登陸小程序後，當用戶從小程序商店等另外一個入口返回應用時仍將保持登陸狀態。

小程序的入口包括但不限於：

• 小程序商店

• 搜索引擎

• 智能助手

• 二維碼

• 短信 / 文本

• 物理對象（經過 AI）

• 瀏覽器

• 日曆條目

• 語音留言（經過 AI）

 性能和用戶體驗

小程序試圖經過一些已被實踐證實有效的機制來改善其性能和用戶體驗。

打包

使用小程序的構造器，用戶只需在首次打開小程序時下載軟件包便可，以後無需再次下載小程序中的靜態資源（頁面 /JavaScript/CSS），這樣加載和跳轉頁面就會更快。此功能可改善用戶操做體驗並節省網絡流量。

同時，小程序有一個預下載機制，能夠提早下載小程序軟件包，或者單獨預載第一頁，並在下載過程當中並行執行流解壓，以最大限度地減小小程序啓動階段和耗時，提高初次打開首頁的性能表現。

多重渲染環境

小程序在渲染環境之間使用原生頁面堆棧管理，頁面切換由原生代碼驅動。所以，在頁面中的手勢操做和頁面之間的切換能夠實現與原生應用徹底相同的流暢體驗。

因爲視圖層和邏輯層的隔離，視圖層能夠獨立渲染。不受 JavaScript 邏輯代碼的阻礙，能夠大大提升頁面的渲染速度。

預構建和複用運行時環境

小程序的運行時環境一般在啓動應用程序以前預先構建，從而縮短了啓動時間。預構建的內容包括渲染環境、靜態資源、開發人員定義的預取請求和小程序運行時容器。小程序激活後，它將接管預構建的渲染環境，而後咱們繼續爲緩存池預構建新的渲染環境以備下一次使用。渲染環境數量有一個限制，當任何渲染環境關閉或超出數量限制時，最先打開的渲染環境將被銷燬。當小程序退出時其運行時將被銷燬，而應用程序環境和資源能夠複用。

預約義的組件和 API

小程序平臺提供了很是豐富的組件和 API，這些組件和 API 大都設計出色，可以幫助開發人員保證工做效率。

JavaScript 框架預設和熱更新

小程序的運行時環境包含兩大部分，其一是原生代碼提供的基本功能，其二是一個框架，包括開發人員 API 和一些由 JavaScript 實現的組件。JavaScript 框架內置於原生應用程序中，並將在執行小程序以前提早加載到小程序運行時環境中。JavaScript 框架能夠熱更新（在使用期間從新加載），帶來了不少性能提高的潛力。

 小程序概覽

本節介紹了目前主流的一些小程序或相關平臺。

支付寶小程序

支付寶小程序運行在支付寶原生應用之上，這是 Web 和原生的混合解決方案。支付寶小程序依賴 CSS 和 JavaScript 等 Web 技術。同時，它還集成了支付寶原生應用的功能，如支付、信用服務、面部認證等。

如今，已有超過 1,000,000 個小程序運行在支付寶原生應用上，DAU（每日活動用戶）達 2.3 億。用戶場景包括零售、運輸、醫療服務等。

百度智能小程序

百度智能小程序是指基於百度應用和其餘合做夥伴平臺，智能地將人們與信息和服務聯繫起來的開放式生態產品。經過百度的 AI 能力和對智能小程序中內容的理解，咱們能夠準確地將智能小程序和用戶對接起來。藉助百度的搜索和信息流雙引擎，用戶能夠在智能小程序中實現相似 APP 的體驗。截至 2019 年 7 月，咱們擁有 150,000 多個智能小程序，MAU 達 2.7 億。

百度智能小程序是在咱們的開源聯盟內開源的，該聯盟擁有超過 30 個合做夥伴，涵蓋超級 APP、移動操做系統、車載操做系統、語音控制揚聲器和電視等領域。

快應用（包括小米和華爲在內的快應用聯盟）

快應用是由快應用聯盟的 12 家頂級手機制造商開發的小程序標準，覆蓋超過 2 億 MAU。開發人員能夠一次開發就在全部硬件供應商的平臺上運行應用。快應用深度集成在操做系統內，在智能手機系統的衆多應用場景中只需輕點一次便可獲取。快應用引入了原生渲染路徑，有效融合了前端開發和原生性能體驗。

快應用可以以兩種形式運行：相似原生應用頁面的快應用頁面形式，和用來在場景中顯示信息的小部件形式。這二者適應不一樣的用戶需求，將系統和小程序以多種形式鏈接成一個總體。

360 PC 小程序

PC 上的小程序仍處於早期探索階段。360 PC 小程序是一款在 PC 瀏覽器中運行的輕量級應用程序。與傳統網頁相比，它具備更多功能，更易於與 PC 操做系統交互。

PC 小程序僅適用於通過驗證的企業賬戶，大多數功能都受到嚴格的約束，所以能夠將它們視爲高度可信的 Web 內容。

PWA

PWA 是現代 Web 應用程序的最新統稱術語。做爲原生應用程序的對應物，PWA 應用程序看起來和用起來都像原生應用，能夠安裝到主屏幕 / 啓動器 / 開始菜單；它能夠發送推送通知以重獲用戶關注；它能夠離線使用，或在網絡情況不佳的狀況下運行；它支持具備衆多功能的設備，而且仍在不斷髮展，以及時利用開放式 Web 標準定義的新功能；用戶能夠在 PWA 應用程序內付款；PWA 應用程序是搜索引擎友好的，並與超連接配合完美。PWA 在技術和業務層面都很成功（被許多網站普遍採用，特別是面向消費者的網站）。

與 Web 配合

本節選擇了一些典型的用例，並提出了一些讓小程序得到 Web 支持的 API 提案。

應用程序生命週期 混合渲染

小程序是 Web 渲染和原生渲染的混合解決方案。最好有一種很好的方法來組合 Web 和原生的渲染結果。

渲染來自 Web 和原生的結果

提案：小程序須要標準化的 API 幫助來將原生渲染結果集成到 Web 渲染結果中。

 過渡動畫

小程序但願在頁面切換期間提供過渡動畫，以便用戶能夠得到與使用原生應用時類似的體驗，但如今幾乎不可能這樣作。

提案：小程序須要一個 API 調用來在頁面切換期間添加過渡動畫。

 標準化小程序的構建包

小程序能夠經過標準化的分發格式爲多個小程序宿主平臺制定一個統一的打包和解析約定。目前，每一個小程序宿主平臺都提供不一樣的開發工具（不一樣的打包方法），不一樣宿主環境中的解析方法也不同。

提案：小程序其實是分發過程當中所用文件的打包（壓縮）集合。咱們能夠用統一的文件後綴描述小程序（.ma），並指定如何建立和解析.ma 文件。

 標準化跳轉到小程序頁面的流程

能夠在一個小程序中引用另外一個小程序的熱頁面，並在用戶訪問時準確引用它。

提案：定義一套標準化協議（URI scheme）以訪問小程序。

 小程序小部件

與 Android 小部件或蘋果 dashboard 同樣，用戶能夠經過小程序小部件直接獲取信息和 / 或完成任務，而無需打開任何 Web 或應用程序頁面。小程序小部件能夠在 Web 瀏覽器以外的環境（如桌面或 dashboard）中顯示。

提案：

• 小程序小部件能夠在宿主環境中顯示，後者能夠是 Webview 或原生應用程序頁面。宿主環境使用其對應的 URI 路徑加載小部件，該路徑描述程序包和小部件頁面。
• 小程序小部件能夠訪問從服務器或本地數據。同時，小程序小部件能夠訪問同一個包中的小程序。

• 小程序小部件應該是交互式的，這意味着它應該響應任何用戶行爲 / 交互。小程序小部件應該可以打開 Web 或應用程序頁面。

性能和調優 在小程序中定義時間事件來交互

小程序須要知道小程序頁面的交互時間（TTI）什麼時候完成。

提案：一個標準化事件，用於通知小程序頁面交互時間已完成。

圖形和媒體 模型元素擁有豐富細節的 3D 模型越發流行，它與 AR 結合將提供比 2D 更好的用戶體驗。其商業案例可能涉及網上購物、廣告】教育等。然而，當前的 Web 平臺缺少處理 3D 模型的標準和便捷方式。在本文檔中，咱們建議定義一個 HTML 標籤來直接處理 3D 模型，相似於咱們使用相應 HTML 標籤處理音頻、視頻和圖像的方式：

• 360 度視圖

用戶能夠經過手勢從不一樣角度查看 3D 模型。3D 模型也能夠放大 / 縮小。它能夠全屏查看，也能夠嵌入 HTML 頁面，與其餘 HTML 內容一塊兒顯示。

• 用 AR 查看

用戶可使用相機將 3D 模型放置在真實世界環境中。用戶能夠指定放置模型的不一樣位置。

提案：元素，用於在 Web 上指定 3D 模型並使用 AR 爲交互式 3D 內容提供支持。

面部跟蹤

面部跟蹤可用於許多 3D 場景。

實時視頻中的面部效果

在實時視頻中添加面部效果。這些效果包括全屏濾鏡、面部重塑和化妝、2D 貼紙、3D 頭飾等。大部分效果都高度依賴對視頻源的實時面部追蹤。

遊戲

遊戲開發者能夠根據跟蹤到的面部數據設計遊戲策略。好比在眨眼時觸發特定的遊戲邏輯，或者檢查水果是否掉進了嘴裏。

虛擬化妝

讓用戶在產品頁面上嘗試口紅、眼影、眼鏡和帽子，幫助他們作出決定。

提案：一個面部追蹤 API，使用視頻元素做爲輸入並在每幀圖像更新面部跟蹤輸出，其中包括：

• 每張臉的邊框。

• 每張臉的 4x4 姿式矩陣。

• 歸一化（x，y）地標點。

• ace 幾何數據，包括頂點、法線和紋理座標。

 手勢跟蹤和識別

手勢可用於視頻效果和 AR/VR 遊戲場景，可使應用程序更加互動、更吸引人。

提案：用於跟蹤手部動做的高級 API，獲取手部輪廓。

 基於 ARCore 和 ARKit 的底層 AR API

咱們將在小程序中把一些 AR API 遷移到 Web 上，由於它們有助於在遊戲、3D 模型預覽和交互式廣告中提供更好的 AR 體驗。

提案：提供基於 ARCore 和 ARKit 的底層 AR API，其中包括：

用於世界跟蹤的相機視圖矩陣

提供移動電話空間位置和方向的 4x4 視圖矩陣，可由開發人員用來實時更新其 3D 虛擬世界中的攝像機矩陣。這樣一來，現實世界的位置就能夠與虛擬世界中對象的位置相關聯。

平面檢測和跟蹤

檢測並實時跟蹤現實世界中的平面。提供 4x4 變換矩陣，表示每一個平面的中心位置和方向。可用它將 3D 虛擬對象放置在地面 / 桌面上。

錨點

錨點定義了現實世界中固定的位置和方向。開發人員能夠從 4x4 變換矩陣建立錨點，前者能夠經過命中測試獲取。該矩陣將在每幀中更新，以確保對應於矩陣的虛擬對象能夠在真實場景中固定在一個位置和方向上。

命中測試

得到 4x4 變換矩陣，表示與屏幕位置對應的真實世界空間中的位置和方向，以實現諸如點擊和放置虛擬對象之類的功能。

更好地支持 AR 的 API

安全和隱私考慮

小程序利用 HTTPS 來支持安全鏈接。同一宿主環境中的多個小程序彼此獨立。

小程序中的用戶交互須要不一樣級別的用戶權限：

權限許可	用戶交互
默認（無需額外操做）	頁面分享、剪貼板、震動、羅盤、運動感應、地圖、屏幕亮度、屏幕捕獲、電池狀態
初次使用時許可	地理信息、相機（二維碼）、網絡狀態、藍牙、NFC
每次使用時許可	聯繫人、文件 API、添加到主屏幕、相片拾取、電話
須要密碼	支付
使用密鑰驗證	推送
回調 / 消息	無需密碼的支付

W3C 前景展望爲了知足小程序的使用場景和要求，並使 Web 標準更好地支持小程序，咱們但願在 W3C 中加入如下工做事項：

• 創建一個小組來協調 W3C 中與小程序相關的標準化工做，並與其餘相關的 W3C 小組協做。

• 探索用戶代理的創新，豐富 Web 內容。

• 橫向審查（安全、隱私、i18n 和 a11y）。

具體來講，咱們討論瞭如下技術工做：

• 進一步檢查現有小程序 API 與 Web API 之間的差別，完成差別分析。
• 根據小組選擇的用例和要求起草小程序標準的路線圖。
• 制定當前供應商的功能規範。目標功能包括但不限於：

  • 包構造器

  • 小程序 URI scheme

  • 混合渲染 API

  • 3D 模型標籤

  • 面部跟蹤 API

  • 小部件

• 設計針對將來，適用於 Web 和小程序環境的 Web API。

詞彙表

英文原文:
https://www.w3.org/TR/2019/WD-mini-app-white-paper-20190912/ 活動推薦

小程序正在以難以想象的速度實現對中國移動互聯網羣體的全面覆蓋，入局小程序，正是移動互聯網業務的下一個方向。9 月 21 日週六下午，小程序·雲開發技術沙龍走進北京，現場將從小程序雲開發後臺架構、實時數據推送實踐、雲開發 AI 智能客服等多個方面，解析日活過 2.5 億的微信小程序背後的技術演進歷程。掃描下圖二維碼或者點擊閱讀原文免費報名參加。