簡介： 淘寶的開放技術目前主要有兩種形態，第一種是小程序，第二種是今天的主角小部件。它是基於小程序技術體系，面向標準化、輕量化、高性能的開放卡片場景。本文我們將通過技術設計策略、核心技術設施、業務場景接入、技術演進路線，這四個方面和大家分享它。
作者 | 千之
來源 | 阿里技術公衆號
私域，即品牌自運營的空間，可以幫助品牌持續運營自己的消費者。
淘寶也在快速調整私域的佈局：淘寶也有非常多的私域產品，譬如店鋪、客服、消息等。在這些場景中，品牌商家需要利用創意、內容和服務留住消費者羣體，併產生銷售轉化。但是做私域並不僅僅只是純銷售，更要用內容和服務把人留下來，讓場裏的人越留越多，這部分常駐人羣纔是「私域流量」。
商家和品牌通過持續穩定地提供優質內容，以及購買產品的後續服務，私域中的消費者比公域消費者能獲得更大的價值，也更容易產生復購和品牌忠誠度。
所以商家會迫切希望能夠深耕淘寶的私域場景，幫助自身更好地運營消費者。面對不同垂直行業不同屬性的大量商家，全量滿足商家的個性化訴求會是一個海量的工作，所以我們通過開放技術引入了三方生態來服務品牌和商家，幫助他們構建自己的淘系私域。
通過淘寶的開放技術，三方開發者可以爲品牌商家制作創意內容和服務，最後在私域被消費者所觸達。
那什麼是淘寶的開放技術？
一 開放技術形態
淘寶的開放技術目前主要有兩種形態，小程序是其一，淘寶基於小程序做了很多業務上的探索和技術上的實踐。小程序承載了大量商家的個性化訴求，通過小程序，商家可以持續釋放自身的創意並運營自身的消費者。小程序一定程度上解決了商家和消費者的連接問題。
再後來我們發現卡片形態更適合場景的開放訴求，在講究高效率的電商場，一塊前置並可以高度自定義的開放區域可以有效提升消費者的觸達率。我們也在積極探索一種適合電商場景並且足夠靈活、開放的卡片技術。
所以，今天給大家正式介紹一下淘寶開放技術的第二種形態。
基於小程序技術體系，面向標準化、輕量化、高性能的開放卡片場景，我們在業界首次推出了全新的開放卡片技術「小部件」。
本文將從以下四點分別進一步闡述我們的一些技術思考。
- 技術設計策略
- 核心技術設施
- 業務場景接入
- 技術演進路線
二 技術設計策略
開放業務場景，擁抱技術紅利，釋放商家創意，提升經營效率。
1 生產側
小部件爲開發者提供靈活、標準的技術選型。
小部件致力於解決場景卡片的開放問題，爲開發者提供靈活、標準的技術選型來支撐商家的個性化訴求，並帶來更具備體感的消費者體驗。
面向與研發強相關的小部件， 我們希望開發者在同一個 IDE 中可以完成小部件/小程序的研發、調試、預覽、上傳等功能，所以「淘寶開發者工具」作爲編輯工具與研發服務的結合平臺，提高工具、服務之間的串聯效率，一站式地幫助小部件的開發者提升整體效率。此外，在遊戲互動卡片這塊，開發者也可以直接使用遊戲引擎的 IDE 來提高自身的研發效率。
開發者可以基於「淘寶開發者工具」的生產環境來構建自己的小部件，小部件的整個生產流程也是對齊小程序的開發模式，小部件積極擁抱三方開放生態，開發者可以使用標準的小程序 DSL，小部件的上層技術生態對齊小程序 Web 生態，無縫支持小程序前端框架、遊戲引擎的運行接入。
此外面對錶單配置能力，我們還在「淘寶開發者工具」支持了 JsonSchema 能力，通過 JsonSchema 的開放，小部件的開發者可以完成與小部件配套的商家端表單配置能力的研發，配置表單幫助商家可以靈活控制小部件的前臺屬性和後臺接口。
2 投放側
卡片形態的小部件需要一套強大的投放系統來支撐。不同場景的小部件雲信息下發需要一箇中心化的平臺來支撐，基於這個中心化的平臺，小部件卡片可以被靈活投放到不同的業務場景下。
開發者入駐後，選擇自身需要研發投放的場景後，可以獲取不同場景的尺寸信息和視覺規範，通過這層約束得以保證場景的消費者體驗一致性。而對此，小部件的開發者通過我們的適配方案後僅需簡單適配即可完成產物交付，實現一套代碼多處運行的技術目標。
爲此，我們提供了一套完整的投放能力。當開發者完成小部件的交付並且審覈通過後，商家需要在商家端完成小部件的業務配置，並投放到線上環境。商家可以自主選擇投放的場景，譬如店鋪、會員、訂閱、直播等等。
前臺的業務場景服務端對接投放系統完成之後即可完成場景的小部件投放。
3 運行側
卡片本身的特殊性導致了對渲染、性能、體驗的要求極高。小部件容器提供了高效、穩定的環境來保證業務代碼的執行效率。
能力方面，通過基礎庫技術協議的對齊，所有的基礎/業務 API 能力我們都保證了對小程序容器的複用，並且和支付寶小程序容器保證了接口標準的一致性。這意味着開發者可以幾乎 0 成本地調用所有小程序開放出來的 API 能力並獲得和小程序完全一致的體驗。
渲染方面，傳統的 WebView 渲染方案在卡片形態下會比較厚重，多個卡片共存同一場景下的內存和體驗問題也無法得到很好解決。爲此，我們重新設計了一套更適合卡片場景的渲染方案，相對於小程序的 WebView 渲染引擎，我們在卡片場景中替換爲全新的渲染引擎，即 Weex2.0。
通過 Weex2.0 的跨平臺渲染能力，我們在 iOS 和 Android 上保持了極高的一致性。三方場景的特殊性會導致卡片本身的技術容錯率很低，所以，從性能和複雜度角度出發的角度考慮，我們也收斂了整體 CSS 樣式的支持度。整體樣式能力的規範的整體設計很大程度上兼容 W3C 標準，實現了一部分子集，在子集範圍內的功能都和標準一致。
此外，小部件的運行安全也是非常重要的，爲此我們引入了沙箱機制。通過沙箱機制我們得以保證不同的小部件環境之間是互相隔離並不互相影響的，通過底層技術的複用，我們也合併了多個 JavaScript 虛擬機的創建，保證性能和效率能夠最大化。
三 核心技術設施
接下來展開講講我們的核心技術設施，這裏包括腳本引擎、渲染引擎還有圖形引擎。
1 腳本引擎
小部件的技術產物是 JavaScript 源文件，小部件中我們使用了 QuickJS 虛擬機作爲腳本執行引擎。基於 QuickJS，我們可以獲取一個輕量並且高效的 JavaScript 執行環境。相較於龐大的 V8 引擎，QuickJS 虛擬機的啓動性能和包大小收益都遠遠超出我們的預期。
在卡片場景下，腳本引擎的快速啓動是一個非常重要並且迫切的任務，所以基於 QuickJS 虛擬機，我們做了大量的定製和優化工作。
在虛擬機層面的優化工作有助於我們使用新的技術特性來加速，基於「ByteCode」機制，我們已經考慮在小部件構建的時候把 JavaScript 源碼預編譯爲二進制來加速整體的渲染。此外，我們也在推進標準字節碼的設計工作，通過字節碼的優化，可以獲取加載速度與代碼體積的雙重優化。
同樣，在面向腳本引擎的接口這層，我們統一對接了集團標準「JSI」。通過 JSI 的幫助，我們可以實現不同 JavaScript 引擎之間的切換，並且可以幫助我們在異構容器下實現同構的標準編程。
2 渲染引擎
渲染引擎是小部件的核心， 我們使用了淘寶自研的渲染引擎「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 概念，更加貼合前端的技術棧。
3 圖形引擎
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 上的技術可行性較低，相對而言這樣會破壞小部件的技術一致性，消費者的前臺體驗也無法得到保證。
- 此外多場景的技術維護性成本會持續增長，開放業務的特殊性決定了三方開發者的忍受閾值相對很低，會引入大量額外排查成本。
由此，在不同的渲染方案下，我們都分別封裝了對應的組件，通過組件的調用，再實現小部件的嵌入。這種方式前期成本相對而言較高，但對於跨場景一致性會得到保證，開發者也可以避免關心場景的渲染，只需要專注於完成自身業務邏輯的開發即可。
五 技術演進路線
主要圍繞三個關鍵詞，性能、場景、效率來展開。
1 優化性能體驗
卡片場景對加載性能和運行性能會非常敏感，所以我們會持續優化技術性能，針對卡片場景進一步優化內存佔用並提升整體運行性能，充分釋放商家的創意和提升開發者的靈活度。
- 降低圖形內存佔用，通過 FCanvas 的資源整合和管線優化來降低內存佔用，此外我們會面向開發者提供最佳實踐的手段來幫助開發者合理使用。
- 提升首屏加載速度，腳本引擎的性能優化會涉及兩部分工作，一部分是預編譯能力的支持，一部分是運行時「JIT」能力支持；還有的就是渲染引擎的進一步瘦身，運行時優化加載任務隊列，支持低優先級和不必要的資源懶加載。
- 引入小程序插件能力，目前小程序的插件生態還是亟需支持，我們在考慮通過 API 的方式支撐插件生態的接入，可以幫助開發者直接使用會員、任務、人羣等插件能力。
2 覆蓋更多場景
小部件會繼續拓展接入更多場景，尤其是商品詳情頁這種高頻高轉化的場景，也會逐步開放公域部分場景。
- 對商家來說，可以滿足商家自身多元化的經營訴求，並有機會從公域收穫額外的流量，提升品牌經營的水位線。
- 對於場景來說，可以積極擁抱三方開放生態，通過小部件的通投能力，形成商業要素的結構化沉澱和利用。
- 對於開發者來說，可以幫助開發者在多賽道持續收穫商業收益，實現自身效益和效率最大化。
3 提升流通效率
在目前電商場流量逐步穩定的情況下，我們需要更好地幫助商家管理好營銷預算和收益，提升卡片本身的流轉效率至關重要，這樣能幫助商家提升整體的投入產出比。
幫助開發者降低研發成本並幫助商家提升效益，進一步提升卡片流通效率。使得卡片在不同場景的分發和流轉提升效率並建立相應的配套設施，最大化一個卡片的商業價值。
本文爲阿里雲原創內容，未經允許不得轉載。