​私域，即品牌自運營的空間，可以幫助品牌持續運營自己的消費者。

淘寶也在快速調整私域的佈局：淘寶也有非常多的私域產品，譬如店鋪、客服、訊息等。在這些場景中，品牌商家需要利用創意、內容和服務留住消費者群體，併產生銷售轉化。但是做私域並不僅僅只是純銷售，更要用內容和服務把人留下來，讓場裡的人越留越多，這部分常駐人群才是「私域流量」。

商家和品牌通過持續穩定地提供優質內容，以及購買產品的後續服務，私域中的消費者比公域消費者能獲得更大的價值，也更容易產生復購和品牌忠誠度。

所以商家會迫切希望能夠深耕淘寶的私域場景，幫助自身更好地運營消費者。面對不同垂直行業不同屬性的大量商家，全量滿足商家的個性化訴求會是一個海量的工作，所以我們通過開放技術引入了三方生態來服務品牌和商家，幫助他們構建自己的淘系私域。

通過淘寶的開放技術，三方開發者可以為品牌商家制作創意內容和服務，最後在私域被消費者所觸達。

那什麼是淘寶的開放技術？

開放技術形態

淘寶的開放技術目前主要有兩種形態，小程式是其一，淘寶基於小程式做了很多業務上的探索和技術上的實踐。小程式承載了大量商家的個性化訴求，通過小程式，商家可以持續釋放自身的創意並運營自身的消費者。小程式一定程度上解決了商家和消費者的連線問題。

再後來我們發現卡片形態更適合場景的開放訴求，在講究高效率的電商場，一塊前置並可以高度自定義的開放區域可以有效提升消費者的觸達率。我們也在積極探索一種適合電商場景並且足夠靈活、開放的卡片技術。

所以，今天給大家正式介紹一下淘寶開放技術的第二種形態。

基於小程式技術體系，面向標準化、輕量化、高效能的開放卡片場景，我們在業界首次推出了全新的開放卡片技術「小部件」。

本文將從以下四點分別進一步闡述我們的一些技術思考。

• 技術設計策略
• 核心技術設施
• 業務場景接入
• 技術演進路線

技術設計策略

開放業務場景，擁抱技術紅利，釋放商家創意，提升經營效率。

生產側

小部件為開發者提供靈活、標準的技術選型。

小部件致力於解決場景卡片的開放問題，為開發者提供靈活、標準的技術選型來支撐商家的個性化訴求，並帶來更具備體感的消費者體驗。

面向與研發強相關的小部件， 我們希望開發者在同一個 IDE 中可以完成小部件/小程式的研發、除錯、預覽、上傳等功能，所以「淘寶開發者工具」作為編輯工具與研發服務的結合平臺，提高工具、服務之間的串聯效率，一站式地幫助小部件的開發者提升整體效率。此外，在遊戲互動卡片這塊，開發者也可以直接使用遊戲引擎的 IDE 來提高自身的研發效率。

開發者可以基於「淘寶開發者工具」的生產環境來構建自己的小部件，小部件的整個生產流程也是對齊小程式的開發模式，小部件積極擁抱三方開放生態，開發者可以使用標準的小程式 DSL，小部件的上層技術生態對齊小程式 Web 生態，無縫支援小程式前端框架、遊戲引擎的執行接入。

此外面對錶單配置能力，我們還在「淘寶開發者工具」支援了 JsonSchema 能力，通過 JsonSchema 的開放，小部件的開發者可以完成與小部件配套的商家端表單配置能力的研發，配置表單幫助商家可以靈活控制小部件的前臺屬性和後臺介面。

投放側

卡片形態的小部件需要一套強大的投放系統來支撐。不同場景的小部件雲資訊下發需要一箇中心化的平臺來支撐，基於這個中心化的平臺，小部件卡片可以被靈活投放到不同的業務場景下。

開發者入駐後，選擇自身需要研發投放的場景後，可以獲取不同場景的尺寸資訊和視覺規範，通過這層約束得以保證場景的消費者體驗一致性。而對此，小部件的開發者通過我們的適配方案後僅需簡單適配即可完成產物交付，實現一套程式碼多處執行的技術目標。

為此，我們提供了一套完整的投放能力。當開發者完成小部件的交付並且稽核通過後，商家需要在商家端完成小部件的業務配置，並投放到線上環境。商家可以自主選擇投放的場景，譬如店鋪、會員、訂閱、直播等等。

前臺的業務場景服務端對接投放系統完成之後即可完成場景的小部件投放。

執行側

卡片本身的特殊性導致了對渲染、效能、體驗的要求極高。小部件容器提供了高效、穩定的環境來保證業務程式碼的執行效率。

能力方面，通過基礎庫技術協議的對齊，所有的基礎/業務 API 能力我們都保證了對小程式容器的複用，並且和支付寶小程式容器保證了介面標準的一致性。這意味著開發者可以幾乎 0 成本地呼叫所有小程式開放出來的 API 能力並獲得和小程式完全一致的體驗。

渲染方面，傳統的 WebView 渲染方案在卡片形態下會比較厚重，多個卡片共存同一場景下的記憶體和體驗問題也無法得到很好解決。為此，我們重新設計了一套更適合卡片場景的渲染方案，相對於小程式的 WebView 渲染引擎，我們在卡片場景中替換為全新的渲染引擎，即 Weex2.0。

通過 Weex2.0 的跨平臺渲染能力，我們在 iOS 和 Android 上保持了極高的一致性。三方場景的特殊性會導致卡片本身的技術容錯率很低，所以，從效能和複雜度角度出發的角度考慮，我們也收斂了整體 CSS 樣式的支援度。整體樣式能力的規範的整體設計很大程度上相容 W3C 標準，實現了一部分子集，在子集範圍內的功能都和標準一致。

此外，小部件的執行安全也是非常重要的，為此我們引入了沙箱機制。通過沙箱機制我們得以保證不同的小部件環境之間是互相隔離並不互相影響的，通過底層技術的複用，我們也合併了多個 JavaScript 虛擬機器的建立，保證效能和效率能夠最大化。

核心技術設施

接下來展開講講我們的核心技術設施，這裡包括指令碼引擎、渲染引擎還有圖形引擎。

指令碼引擎

小部件的技術產物是 JavaScript 原始檔，小部件中我們使用了 QuickJS 虛擬機器作為指令碼執行引擎。基於 QuickJS，我們可以獲取一個輕量並且高效的 JavaScript 執行環境。相較於龐大的 V8 引擎，QuickJS 虛擬機器的啟動效能和包大小收益都遠遠超出我們的預期。

在卡片場景下，指令碼引擎的快速啟動是一個非常重要並且迫切的任務，所以基於 QuickJS 虛擬機器，我們做了大量的定製和優化工作。

在虛擬機器層面的優化工作有助於我們使用新的技術特性來加速，基於「ByteCode」機制，我們已經考慮在小部件構建的時候把 JavaScript 原始碼預編譯為二進位制來加速整體的渲染。此外，我們也在推進標準位元組碼的設計工作，通過位元組碼的優化，可以獲取載入速度與程式碼體積的雙重優化。

同樣，在面向指令碼引擎的介面這層，我們統一對接了集團標準「JSI」。通過 JSI 的幫助，我們可以實現不同 JavaScript 引擎之間的切換，並且可以幫助我們在異構容器下實現同構的標準程式設計。

渲染引擎

渲染引擎是小部件的核心， 我們使用了淘寶自研的渲染引擎「Weex2.0」，Weex2.0 的前身是 Weex1.0，相對於1.0 的 系統 UI 渲染，2.0 上我們全面切換到了跨平臺 C++ 自繪方案。通過 C++ 的跨平臺開發，我們在原生層面使用 C++ 實現了元件化、MVVM、宣告式模板、響應式更新等複雜功能，也順便抹平了 iOS 和 Android 上平臺相關的元件差異。

介面註冊層面，我們通過 JS Binding 直接把原生渲染介面註冊繫結到 JavaScript 環境中，幾乎沒有序列化成本。C++ 框架下沉以後，可以更加細粒度的實現節點更新和回收複用。

渲染管線上，我們借鑑了 Flutter Engine 的執行緒模型及佈局演算法，最後會被提交到 Skia 本身的渲染流程上。這部分工作的複用有助於我們快速實現落地，此外由於我們的渲染管線是面向 Web 的技術特點設計，沒有 Flutter FrameWork 中的 Dart Widget 概念，更加貼合前端的技術棧。

圖形引擎

Canvas 是 Web 生態中非常重要的元件，適用於富互動並且注重互動體驗的業務場景，譬如遊戲互動、3D渲染、圖表繪製、AR渲染等圖形場景。

Canvas 能力在小部件中是一個獨立的元件，得益於 Weex2.0 的 Platform View 機制，我們在自繪的引擎中實現了同層渲染 Canvas 能力。Canvas 本質是一個 W3C 圖形渲染標準，面對這套標準淘寶同樣自研了一套圖形引擎實現「FCanvas」，FCanvas 支援 WebGL 和 Canvas2D 兩套標準，跨容器且高效能的 FCanvas 的圖形渲染能力我們對小部件也一併開放。同樣，Canvas2D 下和 Weex2.0 同樣直接對接了 Skia 圖形庫。

通過小程式標準的對齊和底層 SDK 的改造，我們完全相容並支援了小程式中的遊戲引擎生態。也就意味著，遊戲的開發者可以直接通過我們支援的遊戲引擎 IDE 自助生成小部件工程，卡片級別的互動遊戲非常適合前置在業務場景中做投放。

業務場景接入

小部件是卡片，那嵌入卡片的「場」自然很重要。

在淘寶內，目前有多個業務場景支援了小部件的投放，這裡麵包括店鋪、會員、直播、訂閱等等。因為場景業務的特殊性，目前多個場景的渲染方案不盡相同，這裡面涉及了 DX 渲染、H5 渲染、Weex 渲染、小程式渲染等多套技術方案。

面對紛雜的渲染環境，這裡面沒有捷徑。我們也思考過在不同的場景下使用對應的場景渲染方案的優劣，這樣會帶來兩個問題。

• 我們判斷不同的渲染方案對接到一套 DSL 上的技術可行性較低，相對而言這樣會破壞小部件的技術一致性，消費者的前臺體驗也無法得到保證。
• 此外多場景的技術維護性成本會持續增長，開放業務的特殊性決定了三方開發者的忍受閾值相對很低，會引入大量額外排查成本。

由此，在不同的渲染方案下，我們都分別封裝了對應的元件，通過元件的呼叫，再實現小部件的嵌入。這種方式前期成本相對而言較高，但對於跨場景一致性會得到保證，開發者也可以避免關心場景的渲染，只需要專注於完成自身業務邏輯的開發即可。

技術演進路線

主要圍繞三個關鍵詞，效能、場景、效率來展開。

優化效能體驗

卡片場景對載入效能和執行效能會非常敏感，所以我們會持續優化技術效能，針對卡片場景進一步優化記憶體佔用並提升整體執行效能，充分釋放商家的創意和提升開發者的靈活度。

• 降低圖形記憶體佔用，通過 FCanvas 的資源整合和管線優化來降低記憶體佔用，此外我們會面向開發者提供最佳實踐的手段來幫助開發者合理使用。
• 提升首屏載入速度，指令碼引擎的效能優化會涉及兩部分工作，一部分是預編譯能力的支援，一部分是執行時「JIT」能力支援；還有的就是渲染引擎的進一步瘦身，執行時優化載入任務佇列，支援低優先順序和不必要的資源懶載入。
• 引入小程式外掛能力，目前小程式的外掛生態還是亟需支援，我們在考慮通過 API 的方式支撐外掛生態的接入，可以幫助開發者直接使用會員、任務、人群等外掛能力。

覆蓋更多場景

小部件會繼續擴充接入更多場景，尤其是商品詳情頁這種高頻高轉化的場景，也會逐步開放公域部分場景。

• 對商家來說，可以滿足商家自身多元化的經營訴求，並有機會從公域收穫額外的流量，提升品牌經營的水位線。
• 對於場景來說，可以積極擁抱三方開放生態，通過小部件的通投能力，形成商業要素的結構化沉澱和利用。
• 對於開發者來說，可以幫助開發者在多賽道持續收穫商業收益，實現自身效益和效率最大化。

提升流通效率

在目前電商場流量逐步穩定的情況下，我們需要更好地幫助商家管理好營銷預算和收益，提升卡片本身的流轉效率至關重要，這樣能幫助商家提升整體的投入產出比。

幫助開發者降低研發成本並幫助商家提升效益，進一步提升卡片流通效率。使得卡片在不同場景的分發和流轉提升效率並建立相應的配套設施，最大化一個卡片的商業價值。

關注我們，每週 3 篇移動技術實踐&乾貨給你思考！