私域，即品牌自營運的空間，可以幫助品牌持續營運自己的消費者。
淘寶也在快速調整私域的布局：淘寶也有非常多的私域産品，譬如店鋪、客服、消息等。在這些場景中，品牌商家需要利用創意、内容和服務留住消費者群體，并産生銷售轉化。但是做私域并不僅僅隻是純銷售，更要用内容和服務把人留下來，讓場裡的人越留越多，這部分常駐人群才是「私域流量」。
商家和品牌通過持續穩定地提供優質内容，以及購買産品的後續服務，私域中的消費者比公域消費者能獲得更大的價值，也更容易産生複購和品牌忠誠度。
是以商家會迫切希望能夠深耕淘寶的私域場景，幫助自身更好地營運消費者。面對不同垂直行業不同屬性的大量商家，全量滿足商家的個性化訴求會是一個海量的工作，是以我們通過開放技術引入了三方生态來服務品牌和商家，幫助他們建構自己的淘系私域。
通過淘寶的開放技術，三方開發者可以為品牌商家制作創意内容和服務，最後在私域被消費者所觸達。
那什麼是淘寶的開放技術？
開放技術形态
淘寶的開放技術目前主要有兩種形态，小程式是其一，淘寶基于小程式做了很多業務上的探索和技術上的實踐。小程式承載了大量商家的個性化訴求，通過小程式，商家可以持續釋放自身的創意并營運自身的消費者。小程式一定程度上解決了商家和消費者的連接配接問題。
再後來我們發現卡片形态更适合場景的開放訴求，在講究高效率的電商場，一塊前置并可以高度自定義的開放區域可以有效提升消費者的觸達率。我們也在積極探索一種适合電商場景并且足夠靈活、開放的卡片技術。
是以，今天給大家正式介紹一下淘寶開放技術的第二種形态。
基于小程式技術體系，面向标準化、輕量化、高性能的開放卡片場景，我們在業界首次推出了全新的開放卡片技術「小部件」。
- 技術設計政策
- 核心技術設施
- 業務場景接入
- 技術演進路線
開放業務場景，擁抱技術紅利，釋放商家創意，提升經營效率。
▐ 生産側
小部件為開發者提供靈活、标準的技術選型。
小部件緻力于解決場景卡片的開放問題，為開發者提供靈活、标準的技術選型來支撐商家的個性化訴求，并帶來更具備體感的消費者體驗。
面向與研發強相關的小部件， 我們希望開發者在同一個 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 的方式支撐插件生态的接入，可以幫助開發者直接使用會員、任務、人群等插件能力。
▐ 覆寫更多場景
小部件會繼續拓展接入更多場景，尤其是商品詳情頁這種高頻高轉化的場景，也會逐漸開放公域部分場景。
- 對商家來說，可以滿足商家自身多元化的經營訴求，并有機會從公域收獲額外的流量，提升品牌經營的水位線。
- 對于場景來說，可以積極擁抱三方開放生态，通過小部件的通投能力，形成商業要素的結構化沉澱和利用。
- 對于開發者來說，可以幫助開發者在多賽道持續收獲商業收益，實作自身效益和效率最大化。
▐ 提升流通效率
在目前電商場流量逐漸穩定的情況下，我們需要更好地幫助商家管理好營銷預算和收益，提升卡片本身的流轉效率至關重要，這樣能幫助商家提升整體的投入産出比。
幫助開發者降低研發成本并幫助商家提升效益，進一步提升卡片流通效率。使得卡片在不同場景的分發和流轉提升效率并建立相應的配套設施，最大化一個卡片的商業價值。