全鏈路技術揭秘｜我在1688修煉小程式

一、前言

本文主要講述1688小程式隨著業務加快節奏，技術上在做什麼支撐業務的迭代、互動玩法的多樣性；以及面向未來的能力佈局。

二、做了什麼

2.1 整體架構

2.2 研發工程

2.1.1 渲染架構

雙執行緒執行環境

小程式是在應用內的一個嵌入式應用，所以給予到具體的業務應用上有諸多限制：比如更少的記憶體，更多的執行限制等。為了使得應用在這種捉襟見肘的計算資源下還能接近原生的體驗，小程式提出了邏輯層/渲染層雙執行緒分離的方案。

渲染層基於系統的webview實現（微信類小程式還最新提供了skyline渲染引擎，使得體驗更接近native），邏輯層基於傳統的js實現，這兩個執行緒的通訊會經由native客戶端做中轉，邏輯層傳送網路請求也經由native轉發。這種實現相比於傳統web類應用最大的好處就是使得邏輯層進行復雜運算時不會阻塞渲染層的渲染，大大增加了應用執行的流暢度；缺陷兩個執行緒間的通訊全部是非同步的，這就導致UI重新整理存在部分延時，所以需要透過一些手段儘量減少通訊次數、解決重新整理的時序問題。

小程式渲染原理

由於小程式特殊的雙執行緒架構以及極小的記憶體使用空間，小程式很難像傳統react應用一樣使用類似虛擬dom的方案（一個是因為虛擬dom記憶體佔用較大，一個是因為虛擬dom不論是放在哪一層都存在較多的非同步同步）。

小程式後續也支援了類似vue的MVVM雙向繫結方案（以微信小程式為例，使用<input model:value="{{value}}" />的寫法將值繫結起來，不過相容性較差用得不多），圖為小程式的雙執行緒架構天然適合MVC架構方案

2.1.2 體驗工程

在1688微信小程式起步的這一年裡，我們從開始刀耕火種、一切以業務迭代速度為先，到逐步發掘核心體驗問題並最佳化，沉澱了很多基於小程式的獨特體驗最佳化方案。下面將從搜推、商詳、旺旺等核心鏈路進行闡述。

2.1.2.1搜尋推薦

在微信支付鏈路打通後，由於我們急需快速產生可用的小程式能力，並使其體驗達到高可用的水平，第一版搜尋推薦誕生了。但是隨著業務DAU的緩慢增長，我們發現我們的使用者中低端機的佔有量仍比較高，並且這版本的搜推列表在下拉載入超過200個商品時就會出現無法忍受的卡頓（甚至無法滾動下去），於是乎從針對列表的效能最佳化引入，我們進行了一波關於首頁的重構（核心還是feeds列表，也順帶修改了其它內容）。

最佳化前

最佳化後

最先做的就是規劃邏輯的分離。我們首先將一個列表的組成分為了以下幾個部分：卡片資料獲取層、結果資料對映層、純列表渲染器、分頁重新整理控制器、滾動動畫控制器；在逐步擊破。

資料獲取層&對映層

由於我們想要做到之後feeds流的複用，我們為不同場景的feeds流定義了不同的scene，其中不同的scene也對映到了不同的mtop介面和結果轉換邏輯，最終產出渲染層可用的統一資料結構。並且這份對映邏輯也會複用在其它模組。經過這份邏輯抽離，我們成功將其應用在所有介面規範不同的feeds模組上，並且可以快速拓展諸多業務邏輯。

列表渲染器

最傳統的解決無限滾動feeds流卡頓問題的方案是基於絕對位置計算的虛擬滾動方案。但這種方案無法在小程式中直接使用，因為小程式直接計算高度並使dom發生變化的開銷是非常大的，並且feeds的卡片高度也不是確定的。為了在有限次的dom變化中使得在屏dom節點數量可控，這裡針對傳統的虛擬滾動方案升級最佳化。

分頁重新整理控制器、滾動動畫控制器

我們將下拉重新整理、上拉載入等通用化的邏輯抽離為一個元件，使得後續所有小程式內需要滾動的地方均可直接複用。滾動動畫我們從原本的js邏輯控制改為了使用微信提供的animationAPI，這是微信提供的在邏輯層生成指令、在渲染層執行的方法，可以避免動畫邏輯需要通訊，達到接近原生的效果。

其他邏輯最佳化

比如將feeds列表的介面做快取（加快二次載入首屏速度）、載入中骨架屏、元件載入前元素佔位等。

最佳化效果

整體最佳化前：346個商品節點總數為4388個，且出現長耗時

整體最佳化後：630個商品wxml節點僅1238個，頁面無長耗時、無卡頓

程式碼部分經過此次邏輯修改，首頁的程式碼量減少了1000行，並將多份邏輯解耦到多個檔案中，為後續不同業務同樣功能的接入做鋪墊，後續的旺鋪、採購車等業務均使用了首頁拆分的能力進行最佳化。

2.1.2.2商品詳情

商品詳情是電商應用最核心的頁面，其載入速度和使用體驗直接影響了其轉化到訂單的比率，所以針對od頁的載入最佳化是一個比較關鍵的命題。下面將分別闡述我們針對od的載入速度和使用體驗的最佳化。

最佳化前

最佳化後

介面效能

a. 耗時分析

透過OD程式碼分析、Arthas抓包的方式，進行耗時排查

三個耗時瓶頸中，“請求獲取領域資料來源” 和 “天搭渲染” 為呼叫上游HSF介面，OD側最佳化效果有限。
因此，把最佳化重點放在 “模型上下文填充” 的邏輯裡。

b. 最佳化前邏輯

Builder列表序列升級改造為並行執行

c. 非同步pipeline改造

然而，隨著OD元件的不斷堆積，目前已有四五十個執行不同功能的 Builder，依賴關係錯綜複雜，無法實現完全並行。新的思路：梳理 Builder 依賴關係，非同步 pipeline 改造，根據拓撲排序，實現儘可能的並行

首先找到圖中所有入度為0的頂點，這些頂點相互之間沒有依賴關係，可以併發執行
刪除相關頂點及所有邊，形成一個新的圖結構
重複前序操作
每次單獨記錄當前層無相互依賴的builder列表
最終得到串+並執行任務列表

d. Builder依賴關係梳理

以下是梳理得到的數十個Builder的依賴關係DAG圖

最終介面效能整體服務介面最佳化使原有RT降低了50%；

預載方案

od加載出完整資料的步驟比較簡單：介面獲取到資料，然後將其經過邏輯處理後渲染出來，完事了。只要資料成功獲取到，邏輯處理和渲染都不是什麼難題，所以od載入的核心卡點在資料獲取上。

前端上使用了介面預讀方案。目前商品詳情是在od頁載入完成後才進行介面讀取，從點選推薦頁的商品後，到商品頁首屏載入完成中間的這個時間，網路層什麼都沒有做（跳轉？跳轉也算時間哦）。所以最佳化的根本原理是利用起來前端路由跳轉的這段時間，在發起跳轉命令的時刻就進行介面請求。這裡使用了小程式的getOpenerEventChannel API，這是一個建立在當前頁面和上一頁面的事件通道，正是透過這種方式將頁面跳轉前獲取到的資料傳遞給了當前頁。透過這種最佳化方案我們將od首屏載入時長平均下降了200ms；

動畫

在頁面內容相同的基礎上，最能使得體感更加流暢的方式就是動畫。與搜推列表類似，我們從js邏輯動畫修改為了使用wxs方案（wxs即為可以在渲染層上直接進行程式設計的方案，無需通訊即可控制元素css狀態）。我們修改瞭如下元件，使其像🍫（廣告位招租）一樣絲滑

header欄，根據滾動進度控制透明度和高度
主圖，根據滾動進度控制高度，實現快速檢視到頁面詳情
左上角後退按鈕，根據滾動進度控制透明度
右下角回到頂部按鈕，根據滾動進度控制透明度
輪播圖影片到圖片的tab滑動動畫

後續最佳化

其實od載入最佳化的終極方案就是在進入od前就獲取到od的各種核心資料（如商品標題、商品主圖等），之後在od頁面漸進式地逐步渲染；後續將結合各業務邏輯逐步改造（以推薦列表為例，每一項均需要提前獲取到od的一些關鍵資訊優先渲染類似主圖、標題、詳描等。

2.1.2.3旺旺訊息

不論是售前的詢盤，還是售後的服務，均需要與商家溝通這份橋樑。所以我們也針對旺旺的鏈路進行了最佳化。這次最佳化分為兩部分，旺旺的訊息列表和旺旺的訊息詳情

訊息列表

最早我們小程式的訊息列表是h5的版本。但是由於h5只有在曝光後才會開始載入，所以在進入訊息列表頁時需要進行漫長的等待（足足2s），並且也沒有辦法及時獲取到有多少未讀訊息，於是乎我們考慮將其升級為原生化的列表。

思路是將訊息列表改造為原生化後，我們就可以在應用進入時在後臺直接初始化訊息列表sdk，這樣就可以省去列表獲取的時間，也可以在後臺即時獲取到未讀訊息數，渲染到訊息欄。訊息列表的sdk是基於釘釘imsdk實現的，淘天在web上基於imsdk做出過一版封裝，於是我們就將其clone了下來，針對小程式做了魔改：比如將基於web的websocket修改為基於小程式的CustomWebSocket、將預設介面的鑑權token獲取修改為了基於小程式鑑權改造的mtop介面獲取等等。

當然，坑遠遠不止這些，由於小程式只識別es5語法，所以我們將一些不支援es5（也無法透過babel編譯到es5）的邏輯幹掉了（此處感謝釘釘imsdk的龍允、閒魚的前端大佬灼升提供的技術支援），並將其打包為一份es5的imsdk.js檔案供小程式使用（為什麼不借助小程式的編譯打包生成，因為我們是基於原生開發）。雖然經過這次修改訊息列表做到了秒開，但這使得我們的包體積增加了300kb。至於為什麼不能使用動態載入方案，借用小程式跨端框架Taro的一句話：

平臺客服&旺旺訊息

平臺-買家：小程式目前售後還有所欠缺（難退無賠無任何保障），只有電話客服無法舉證，無法多次連續與平臺溝通，消費者無法解決問題，因此只能投訴到微信平臺。處理反饋和投訴只能人工介入，處理不及時會降低小程式的體驗分，嚴重甚至會導致小程式下架。

商家-買家：小程式的旺旺訊息非常簡陋，只能文字交流，體驗不好會非常影響轉化。

升級前-平臺客服

升級前-旺旺客服

升級後效果

入口-OD截圖

入口-訊息置頂

入口-工作臺

平臺客服

旺旺訊息

方案選型

方案1: 小程式原生開發旺旺訊息頁，由於旺旺卡片數量巨大，有幾百種，工作量巨大，旺旺側團隊粗估60人日。

✅方案2: 複用pc的旺旺訊息聊天頁面，做小程式側的相容，主要是登入態和卡片點選功能相容，工作量主要在於梳理卡片以及前端相容，分3期逐步相容卡片進行上線。

登入態適配：為了解決進入旺旺頁需要登入的問題，對第三方包@ali/im-sdk-saas進行了登入態適配。對卡片點選跳轉的頁面進行登入態適配，包括選擇訂單頁面，FAQ頁面等。
平臺客服卡片梳理與相容：對平臺客服的所有卡片進行了細緻的梳理，並特別針對FAQ卡片實現了DX渲染實現。此外進行了互動方面的相容，對連結進行了攔截控制，比如：商品點選原本是開啟新頁面，會自動喚客戶端，需要禁止，改造為跳轉小程式od、選擇訂單原本是開啟新頁面，改造為半窗互動、點選卡片“去支付”開啟支付頁面，然而小程式有可能未進件，支付不了，改造為跳轉訂單詳情
聊天訊息新增圖片傳送功能： wap旺旺沒有傳送圖片的能力，因為圖床登入態沒法適配。因此開發了新的介面，背後用縱橫平臺儲存圖片，實現了傳送圖片聊天的能力。這一功能的實現，為使用者提供了更加豐富的溝通方式，提升了溝通效率。
卡片展不了的解決方案：為了解決無法展示卡片時可能引起的使用者焦慮，搭建了新的sop流程傳送轉人工卡片。

2.1.2.4旺鋪

圍繞商傢俬域運營能力，從0-1建設極簡旺鋪，強化商家分享和私域運營。

旺鋪頁	新品	動態

sticky效果

難點攻克：原生有下拉重新整理的scroll-view內部無法實現sticky效果

產品給出設計稿包括2層吸頂效果，第一層是商品、新品、分類、動態等tab切換吸頂，第二層是新品上新時間吸頂。so easy！實際動手發現根本吸不了頂。

原因是下拉重新整理的干擾，啟用下拉重新整理（refresher-enabled）會動態修改 <scroll-view> 的結構和樣式（例如新增滾動事件或覆蓋層），進一步破壞子元素的定位邏輯。

那麼方案就來了，一個就是重新實現scroll-view下拉重新整理，另一個就是將吸頂元素放到scroll-view外面。

關鍵流程

1. onTouchStart 手指按下

如果在頂部，沒有在下拉中，沒有停用，記錄開始位置pageX, pageY。

2. onTouchMove 手指移動

更新下拉條高度，內容區用translate3d進行移動。

更新下拉狀態，如果大於下拉閾值，設定為下拉狀態，否則設定為收起狀態。

3. onTouchEnd 手指放開

鬆開時高度超過下拉閾值則觸發重新整理，載入更多資料。

否則設定下拉條高度為0，回彈。

4. 接收外部請求狀態

如果請求完成，觸發回彈動畫。

否則，顯示重新整理中，設定超時時間，超時結束下拉，觸發回彈動畫。

最終效果：

回頂部效果

點選回頂部浮球，設定scrollTop為0，滾動到頂部。在滑動的過程中，點選滾動到頂部，會出現白屏，然後一直沒有恢復。滾動與設定衝突，在滾動過程中，小程式的渲染執行緒可能因同時處理 scrollTop 的設定而陷入死鎖，導致介面卡死。解決方式是在慣性滾動結束後，再操作修改scrollTop。

2.1.2.5採購車

隨著1688微信小程式完成基礎技術架構送代並進入精細化運營階段，提供基於基礎下單鏈路的採購車功能已成為提升使用者使用體驗的核心訴求。然而，採購車作為整個電商體系中最為複雜的功能，在微信小程式這種對於應用效能佔用節省到極致的場景是一個比較大的挑戰。

若直接從0開始建設採購車，成本極其恐怖。經過調研，我們發現1688其它業務的採購車均使用基於AStore（一種快速搭建電商平臺的解決方案）的架構，所以我們也將效仿友團隊的做法直接進行接入。使用這種方案後，服務端是可以直接複用的（這裡感謝家臻的技術支援），唯一的卡點在於AStore是不支援原生小程式DSL的。所以我們按照如下的架構針對AStore服務進行了封裝。

在關鍵資料變化時，我們會設定一個緩衝區，將一次功能的所有變化捏合到一起，同時推送給檢視層以進行渲染層重繪的觸發。這可以減少邏輯層和渲染層之間的通訊次數，提升頁面渲染效能。

透過這種方案，我們做到了購物車整體的權責分離，各個模組可以按照不同的實現方式進行實現。資料模型層的內部邏輯封裝也使得不瞭解AStore的同學可以透過其它3層快速上手購物車業務的迭代開發。對於購物車功能的升級也可以在層的維度去做，而不需要針對整體功能進行重構。

最終效果如下：

2.1.3 效能&監控

基於「無侵入式切面代理」的核心機制

小程式生命週期代理：透過重寫 Page、Component 等原生建構函式，在 onLoad、onShow、onHide 等關鍵節點注入埋點鉤子，實現使用者行為軌跡的全鏈路追蹤（如pv, uv, 頁面停留時長、元件曝光率）。

API函式劫持：劫持 wx.request、wx.navigateTo 等高頻介面，透過Proxy模式實現請求耗時、成功率、路由跳轉路徑的自動採集，避免手動埋點的程式碼冗餘。

2.3 研發平臺

2.2.1 SCRM平臺

微信生態豐富複雜，怎麼樣將微信生態的底層能力與業務相結合，比如公眾號的觸達、小程式的高效裂變、以及公眾號與小程式的相互結合等。如何充分發揮它們的作用？1688微信SCRM平臺應運而生。

作為微信生態運營的利器，平臺具備像微信閘道器、訊息觸達、授權免登、行為分析等能力，將高效助力1688業務連線微信生態，精準觸達客戶、持續提高運營效果。

鑑權SDK

1688小程式依託於微信內小程式為載體，所有介面需要在內部安全的流程上疊加外部鑑權邏輯，1688小程式在開發過程中需要協同全域業務一起進行開發（商品、搜推、旺鋪、購物車、交易、訂單等），在開發過程中幾乎會涉及全站介面，且會頻繁發生介面變更。

傳統方案介面走開放平臺配置鑑權，中心化配置鑑權方案在大規模高頻次介面變更下，一個是影響業務迭代速度，另一個全站流量巨大，走中心化閘道器增加鏈路負載，影響整體穩定性。

因此一種去中心化輕量鑑權SDK，在保障業務穩定性的同時，能夠持續快速的進行業務迭代。

賬號歸一

在建設1688小程式和公眾號的過程中，遇到幾方面問題，一方面是微信內各個觸點的身份歸一問題，比如找工廠小程式、掌櫃上新小程式、1688訂閱號等，這些都沒有打通，每一個微信使用者在不同的觸點都有不同的賬號身份，無法實現聯動，另一方面，微信觸點的使用者和1688APP賬號身份歸一的問題，無法識別微信使用者對應站內app的身份，在做微信使用者運營的時候缺乏資料輸入，只能盲推。

因此需要一套身份歸一的方案，將1688體系下所有小程式、公眾號關聯的同時，能和站內使用者實現身份歸一的對映，不僅將散歩在各小程式的使用者聚攏，也能透過站內已有的購物行為實現微信使用者的精細化運營，提升可運營規模和轉化效率。

整體身份歸一流程

1. 在微信域內一個新使用者在關注公眾號的時候會獲取到公眾號的唯一標識：appID（1688公眾號），使用者在公眾號的唯一標識：openID（1688公眾號），使用者在微信域內的唯一標識：unionID（1688平臺）。如果該使用者註冊了阿里系小程式，透過回撥我們會獲取到使用者的小程式標識appID（1688小程式），使用者在小程式內的唯一標識：openID（1688小程式），以及使用者在微信域內的唯一標識unionID（1688平臺）。透過unionID的對映可以對映到1688公眾號、1688小程式同一個使用者上並關聯起來。

2. 使用者在站內登入賬號的時候，手機號可以作為使用者的唯一標識，利用該手機號可以關聯到使用者登入小程式的賬號，取到使用者在1688微信域內的uinionID，從而進一步關聯到使用者在整個1688微信域內使用的產品，包含不限於（1688小程式、1688企業微信、1688公眾號、1688影片號等）。

事件中心

事件中心是使用者對於公眾號、小程式的所有行為觸點控制。基於使用者的行為可以定製化做不同的響應處理，因此我們決定建設一個微信事件中心，一方面是處理微信官方事件推送，預授權碼，三方授權事件等，另一方面是捕捉使用者行為，攔截進行定製化業務處理的關鍵觸點通道，可以基於事件中心做使用者行為分析、使用者觸點推送和業務定製化等多種使用者運營策略

觸達體系

在平臺基於微信生態多渠道運營的情況下，傳統的單一渠道觸達方式難以滿足使用者日益增長的個性化需求，且難以有效提升資訊的到達率和使用者的參與度，人群特徵的差異性決定了不同的溝通方式與渠道對於不同使用者的觸達效果，因此整個觸達體系圍繞觸達效率、增強使用者體驗，定義了基於人群特徵的多渠道任務觸達機制。

觸達體系一期實現了最基本的多渠道分人群的觸達任務機制，具有兩種運作模式（事件驅動，非事件驅動）。

未來觸達體系二期會基於“人群”、“渠道”以及“訊息”，深度結合AI，提供定製化智慧互動方案。透過使用者資料深度挖掘使用者喜好，透過AIGC豐富訊息結構，構建基於使用者行為的即時互動和基於內容識別的智慧互動兩種互動模式，強化觸達效率。

域名安全

由於外部微信開放平臺的要求，我們請求外部的IP需為固定出口IP，並在微信開放平臺側進行IP白名單配置。目前集團的統一齣口IP微動態性的，IP段過多。

在微信平臺側統一了收口IP進行白名單配置才允許訪問，另一方面也可以透過統一IP出口做公共層事件處理和轉發邏輯，列如token校驗、流量閘道器、訊息中心等。

2.2.2 搭建投放

現在集團記憶體在大量的搭建體系/動線投放解決方案，但是均無法在小程式中直接使用。並且由於小程式沒有辦法直接動態渲染外部元素，所以基於傳統的搭建體系做小程式端的適配也成為了一條死路。為了儘快服務主站大促聯動、會場投放等需求，我們提供了基於天搭搭建體系的小程式外掛，並自建了小程式原生的投放能力。

天搭適配

站內外大促會場的聯動是特別頻繁的場景，通常在小程式中透過webview可以直接將活動會場進行嵌入。但是在小程式端還沒有辦法直接使用，下面是我們針對小程式定製特有解決方案：

會場中的商品並未全部開通微信支付。這裡我們透過選品規劃限定開通微信支付的且符合微信小程式售賣規則的商品，並透過投放位個性化推薦方案透出商品。
會場中的商品、店鋪預設都跳轉到相應的h5。這裡我們撰寫了一個微信側的攔截外掛，透過攔截a標籤的點選和window.open事件的複寫來識別相應跳轉連結，並透過微信官方提供的jssdk 呼叫小程式原生的方法跳轉到對應頁面。
會場分享，開發特有外掛，專門呼叫小程式jssdk的postMessage API將需要分享的內容通訊到native端快取起來，並在使用者觸發分享的時候使用快取內容。

此外，我們還開發了小程式通用feeds流、小程式所見即所得元件等通用元件，這些元件已經預設接入了微信支付、跳轉等能力，可以作為活動會場沒有內容時的兜底。下面是我們基於這些能力搭建的最基礎的會場。（麻雀雖小，五臟俱全）

動線投放

因為已有的投放平臺沒辦法支援小程式的投放訴求，為了支撐小程式業務的快速迭代，逐步自建小程式體系的投放元件&配置，整體支援以下幾種特性：

配置化：內容均轉換為schema配置儲存到服務後臺，支援千人千面、優先順序、疲勞度、線上時間控制等；小程式喚起時讀取這些schema配置進行動態渲染。這樣可以使得各種營銷需求不依賴小程式發版，做到隨配隨上。
環境間隔離：預發環境/正式環境間是互相隔離，這提供了配置完成後的測試方式，也可以及時發現配置問題。

部分配置坑位定製：由於部分內容存在強定製場景，僅依賴平臺提供的視覺化配置可能無法滿足需求，這時候就需要技術同學介入，透過元件化的方式嵌入整體的配置中。

透過上面的配置邏輯，我們實現了配置的按時上下線、分渠道人群的投放、小程式不同坑位的適配。下面是小程式接入1688 3.24拿貨節大促後的小程式效果：

目前我們的modal框、首頁輻條等功能全部是在小程式側實現若干模板後透過配置注入的，也就是靜態渲染方式。之後我們會考慮開發一份動態渲染引擎，實現動態化渲染方案（目前還在方案討論階段）。

2.4 業務能力沉澱&最佳化

2.4.1 微信支付能力

1688微信小程式透過直連方案使用微信支付，實現1688場景內線上交易閉環能力，從而1）提高微信內廣告投放最終交易下單效率，2）達成線下交易線上化，3）針對私域創造分享裂變玩法拉動用增縮短交易路徑。

2.4.2 商家進件能力

建設最佳化商家進件鏈路的，進件成功率S1-S2由40%提升到70%。

同時升級商傢俬域運營能力，由全店進件，升級為品/商進件解耦，提供商傢俬域運營能力，提升商家進件意願，降低進件登出率。

2.4.3 平臺營銷能力

建設微信域直連方案下的平臺營銷能力，在微信支付建立資金運營賬戶，發放渠道專享紅包在微信渠道的補差核銷和退回。針對1688微信小程式的平臺出資的權益能力建設，建成後透過權益分別運營人群、貨盤、玩法等，構建完整的建預算、立模版，使用者端發放、交易核銷、退貨權益回收完整的全鏈路能力，帶來業務新增量。

2.4.4商業化外投能力

小程式缺失商業化廣告能力，因此考慮接入廣告引擎，可提效廣告效果，以及帶來整體商業化收入提升；現有廣告承接鏈路由H5轉為小程式，使用者體驗提升，帶來持續活躍的同時，小程式使用者規模和GMV也會隨之提升；

承接商業化廣告能力效果，包括微信域資訊流廣告（QQ，朋友圈，騰訊影片等）、微信搜一搜廣告、抖音廣告。

v1- H5承接

v2- 資訊流廣告

2.4.5 分享喚端能力

沉澱整個APP小程式分享喚端能力，使用微信小程式承接流量相比傳統H5頁面，具有以下核心優勢，尤其在使用者轉化、社交裂變和商業閉環方面更為突出：

1、入口更淺，轉化路徑更短：使用者點選分享卡片能直接開啟小程式，無需跳轉瀏覽器，減少頁面載入和流失風險；使用者可將小程式新增到“我的小程式”或桌面，後續訪問無需重複搜尋，提升復購率。

2、原生體驗，流暢度高：小程式程式碼包預載入到微信本地，首屏速度比H5快3-5倍，弱網環境下優勢更明顯；支援下拉重新整理、長按選單、掃碼等系統級互動，操作體驗接近原生APP，避免H5的卡頓感。

3、一鍵調起微信支付，支付成功率比H5高30%以上（無需輸入密碼或跳轉）；直接獲取使用者微信繫結的手機號、地址（需授權），降低填寫門檻；無縫使用客服訊息、訂閱通知，提升使用者觸達效率。

1688APP分享鏈路流程圖

H5承接分享 VS 小程式承接

H5承接

小程式承接

三、面向未來

3.1 一碼多端

如上文所述，我們目前的小程式由於只投放在微信平臺，所以使用的原生DSL直接進行開發的。為了響應1688技術部的跨端協同戰役，以及為了之後更加快速地沉澱衛星小程式and將1688小程式投放在支付寶、抖音等平臺，我們將在這個財年將小程式修改為跨端化的DSL。下面將闡述我們的技術選型之路以及如何遷移產生第一個小型demo，如果大家有什麼更好的想法也歡迎在評論區交流：

3.1.1 技術選型

規劃階段的第一件事就是技術選型。小程式跨端化在前端業界是一個比較常見的命題，業界和集團內部也出現了許多解決方案。目前，小程式跨端的解決方案按照不同的跨端方法論分為兩種型別：

編譯時方案：透過撰寫特殊的編譯器將高階語言（React、Vue等DSL）轉換為各個小程式平臺的原生語言（wxml，axml等），為靜態方案（嚴格來說，也存在輕量級的執行時墊片）
執行時方案：透過提供一個執行時墊片（類似React的虛擬dom引擎），將React語法編譯為js後直接執行在這個墊片上，為動態方案（嚴格來說，也存在部分邏輯的靜態編譯）

下面提供了原生、編譯時、執行時3個方案的優劣比較：

綜上所述，我們決定採用執行時方案進行改造。目前業界比較成熟的方案有三種：由DCloud公司提供的uni-app框架、由京東提供的Taro框架、由阿里集團提供的ice3框架。以下為這三種框架的優劣比較：

綜合考慮採用taro方案，社群活躍，相對其他方案有以下優勢：

1. dsl支援react，匹配集團主流react框架，可以接入集團研發體系及基建能力；

2. 支援混編，基於taro框架實現在不影響現有需求迭代的情況下，將原生小程式平滑切換至跨端方案；

3.2 跨端元件庫

藉著本次跨端改造的機會，支援快速跨端的Taro元件庫應用而生，我們需要集百家之長，抽象出元件庫的幾大特性

分包的。鑑於微信小程式treeshake效果較差，我們索性將不同元件分為不同的npm包，按需使用。集團內的O2正好提供了基於lerna的tnpm多包釋出體系，完美適配！
樣式規範是通用的。這樣做是因為將來我們會快速產出各種垂直類小程式，這些小程式的樣式主題等均會產生區別；並且我們也服務了諸多老年客戶，大字版小程式似乎也成為了一個強訴求。所以我們根據設計師的designtoken抽離出了一份統一的樣式變數列表，業務方只需維護一份變數列表即可實現不同樣式的元件。元件側為了方便使用，藉助了cva這個庫實現樣式的邏輯化，業務側只需傳入不同的引數即可快速生成樣式規範統一的元件。

基於此，我們誕生了一個demo專案，其中使用rollup作為元件打包的手段。透過postcss的樣式分離邏輯，這樣我們將元件庫的樣式和互動邏輯完全地拆開了。以下為基礎button按鈕元件的程式碼：

/* eslint-disable id-length *//** 因為大小這個東西變數名確實是短的，所以縮短些 */import { View, Text } from'@tarojs/components';import { cva } from'class-variance-authority';importReactfrom'react';// 樣式規範部分const variants = {size: {l: 'taro-button-l',m: 'taro-button-m',s: 'taro-button-s',xs: 'taro-button-xs', },fill: {solid: '',outline: '', },type: {primary: '',minor: '',assist: '',notallowed: '', },disabled: {y: 'taro-button-disabled',n: '', },};const buttonStyle = cva(['taro-button'], { variants,compoundVariants: (Object.keys(variants.fill) as (keyof typeof variants.fill)[]) .map((fill) => {return (Object.keys(variants.type) as (keyof typeof variants.type)[]) .map((type) => {return { fill,type,className: `taro-button-${fill}-${type}`, }; }); }) .reduce((acc, cur) => acc.concat(cur), []),defaultVariants: {size: 'm',fill: 'solid',type: 'primary',disabled: 'n', },});/// 元件邏輯部分constButton = (props: IButtonProps) => {const { onClick, className, disabled,type, logkey, title, style, } = props;return (<ViewclassName={buttonStyle({...props,className:className,type,disabled:disabled ? 'y' : 'n', })}style={style}onClick={onClick} ><TextclassName="title">{title}</Text></View>);};

同時，我們對於樣式是否為類似tailwindcss的原子化類、是否類似shadcn-ui一樣完全將樣式和邏輯解離開來等問題在持續思考，也歡迎大家來進行討論。

3.3 微信生態探索

微信生態 ≠ 小程式，它由一系列豐富的產品和工具組成，包括微信群 / 朋友圈 / 公眾號 / 小程式 / 微信支付 / 企業微信 / 影片號 / 直播等，生態各環節的場景、流量、資訊可互通，可以滿足對使用者全生命週期的運營動作，並基於社交關係鏈和資訊傳播，實現對買家畫像、商買關係更細緻的洞察。

基於此背景，後續scrm微信生態將整合微信多種矩陣產品形態，構建跨平臺、一體化的技術架構，以實現使用者在生態內生命週期管理、多場景資料協同及業務流程自動化，為全域使用者運營、私域流量沉澱、場景化服務能力提升等方面提供技術能力支撐。