施德來：有贊電商小程序的實踐

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

施德來，畢業於浙江大學計算機學院。曾任職於淘寶、網易，現任有贊前端技術負責人、電商小程序技術負責人。

由於有贊恰好在移動電商這個賽道上，整個行業都推進着咱們向前走。海量的商家有各自的需求，不斷地在業務上督促咱們作一些事。此次我表明團隊爲你們彙報一下咱們被商家推進着作了哪些事，主要是關於技術方面的。

我眼中的小程序

首先和你們分享一下我眼中的小程序究竟是什麼？關於小程序，有兩大矛盾困擾着全部的移動開發者。一個是H5跨平臺的開發速度很快，可是打開速度很慢，Native能力差。這是它的開放性所決定的，這是一個矛盾。另一個矛盾是Native的APP體驗流暢、功能齊全，可是開發速度極慢、更新麻煩，並且ios和安卓要重複開發。

Write Once，Run Anywhere. 我知道你們都很喜歡這句話，我在後面加了一個Like Native。爲了這個目標各大公司都給出了本身的方案，好比Google給出的方案是PWA，由於國內互聯網的現狀，這個PWA最多能夠作到離線緩存、通知推送，因此其實PWA不是一個出路。其餘也有一些方案，好比說Hybrid App，PhoneGap、lonic，充分使用Native的能力，但性能終究仍是有問題的。我給你們提供另一個方案：React Native、Weex，充分利用Native的能力，同時也能達到一處編寫處處執行，並且也可以寫得很快，至少不用寫兩次。可是它也有一些問題，事實上前端工程師是不可能拋開安卓和ios獨立進行開發的，必定須要大量的適配，但這已經算是很大的進步了。

在我眼中如今只有一個選擇：JS Native APP，微信本質上就是作JS Native APP，也就是小程序。它擁有JS Native APP的各類優勢，不再須要安卓的工程師和ios的工程師幫助解決系統問題了。結合Win7自己的公衆號、瀏覽器功能，以及它底層的賬號能力，事實上微信已經有點像操做系統了。因此最終的結構是WeChat Operating System，什麼事情均可以在微信裏面完成，事實上就是這樣。

有人提出這樣的觀點，隨着微信小程序生態的完善，中國的操做系統可能就是要靠騰訊了。這就是我理解的小程序是JS Native APP中將來至關有競爭力的方案，由於一半以上的人都使用微信。不少H5中須要高階能力才能解決的問題，被小程序用降維解決了。小程序爲何要打包上傳？實際上是由於微信能夠經過必定的策略讓這個包提早下載，你們若是推送太小程序新版本的話就會知道，包是分批更新的，我相信微信底層有更新這個小程序代碼或小程序包的機制。它省去了H5中咱們要作的大量工做，好比原先要完成的異步加載等等。這些都是爲了讓打開速度更快，但若是代碼被預先加載好了這些問題就都沒有了。

以碼農的視角介紹有贊微商城小程序

下面我將以碼農的視角介紹一下有贊微商城小程序，或許哪天你在作一個小程序的時候，又須要有電商的功能。這時你能夠經過小程序之間的跳轉，在有贊註冊一個小程序，把課程、服務等跳轉到有贊這邊，進行完購買流程再跳回去。在H5的年代咱們有幾千個商家就是這麼作的，在他們的APP中嵌入了咱們的H5，其實在小程序裏面也是能夠這麼作的。

簡單來說，有贊介入得很早，也有過彷徨。小程序是在2016年9月21日開始內測，2017年1月9日正式發佈。其實咱們2016年就介入了小程序，當時對於小程序的理解又結合了小程序基於地理定位的特色，也就是發現附近的小程序。咱們以爲餐飲是很好的切入口，固然電商是咱們的老本行，咱們很快就作出了電商的小程序。在1月9日小程序發佈的時候，咱們同時也發佈了有讚的電商小程序，那時只能將代碼生成給到商家，讓商家本身提交。由於當時微信沒有提供相關的平臺型能力，因此直到如今有些商家仍是用咱們一年前的代碼。其實外界也對小程序有不少的質疑，大概持續了半年不到，咱們在這方面的投入其實也很少。隨着微信官方推出了不少新的功能，你們對於小程序愈來愈清晰，商家的需求也愈來愈大，2017年下半年咱們開始發力，商家也開始更重視起來，到了2018年有贊小程序開始爆發。

首先聲明一下這個數字是被我假裝過的，由於如今不能給你們透露真實的數據，這是購買有贊小程序的每月的數量，趨勢是沒有問題的。你們能夠簡單看到，一開始的趨勢是降低的。2017年1月的購買量比較大，剛發佈的時候你們都過來用，後來發現好像也沒什麼。由於那時不少能力沒有開放，羣的能力、附近的小程序都沒有開放，後來慢慢了提供更多的能力，你們慢慢開始有感受了。

下面來介紹一下咱們在小程序裏面作了哪些功能。若是你們瞭解有贊就會知道，咱們是把H5裏面大量的核心能力所有搬到小程序，同時也作了小程序特有的能力。後臺包括店鋪、商品、訂單、客戶、數據、營銷工具、營銷渠道，市面上有的各類營銷工具基本上咱們都作了，有些是咱們獨創的，有些是參考的。

這是咱們頁面的編輯器，左邊是編輯，右邊是編輯出的頁面，全部頁面都是商家本身編的。如今咱們已經實現了每秒5萬筆訂單的處理能力，多門店選擇能夠根據地理位置選擇門店。對於賣水果、賣蛋糕的商家比較有用。其餘功能還有拼團、新人有禮、瓜分券等。瓜分券就是分享給本身的小夥伴，好比5我的來領才能領到。這是咱們小程序獨有的功能，由於小程序在羣的能力上，分享頁面更方便一些。

簡單來說，咱們的小程序包袱重、工做量大、場景複雜。首先，商家想要全部H5微商的功能，只是想要的比例不同，咱們要選擇性地去搬。第二，咱們要服務海量的商家，提供他們須要的技術服務，咱們要生成海量的小程序。第三，H5微商城大量模塊正在重構。這也是咱們的工做環境。

技術上的探索和積累

接下來說一下有關技術上的探索和積累，第一個問題是如何同時產出海量獨立的微商城小程序，每一個商家一個版本還不一樣。微信是提供這種能力的，同一份代碼在不一樣的ID提交後到微信的開發平臺能夠生成一個模板ID，拿到模板ID後全部商家在咱們的後臺批量提交小程序。在提交的時候把商家特有的配置，包括商家的APP ID和底部導航信息一塊兒提交給微信，微信再開始審覈。

有贊擁有公共版的小程序和專享版的小程序，一套代碼兩個馬甲，共用業務代碼。若是小程序的名字是本身的，相似於垂直商城這種有本身的店且徹底獨立的小程序就屬於專享版。公共版是免費的，全部有讚的商家均可以使用。事實上二者的功能基本是同樣的，只是底層的導航不同，本質上咱們須要在一套代碼裏面輸出兩種小程序。左圖爲公共版，右圖爲專享版。在一個倉庫裏輸出兩種小程序，解法其實很簡單。通常而言咱們小程序有一個APP的json，羅列小程序中基本有哪些頁面。咱們另外羅列出了基於原先的小程序額外多出的頁面，底部的導航條信息是獨立的，這是不會被合併的。

富文本如今已經不是什麼大問題了，在之前對咱們來講倒是比較難解決的問題。最先的時候富文本是圖文編輯的組件，咱們最先用的是wxParse，這是開源項目，它可以比較好的解決問題。可是它存在兩個問題，一是沒有辦法很好地處理表格、列表標籤，二是它最多隻能嵌套11層。通常來講是沒有問題的，可是有些商家會從第三方的編輯器編輯源碼，再複製到有讚的頁面編輯器裏。第三方編輯器有的嵌了幾十層，在小程序中就會出現不少內容丟失的狀況。在2017年7月10日官方推出了一個rich-text，也存在一些問題。總結下來是svg沒法在組件裏面正常展現，可以展現但不能縮放。

下圖是咱們整個包大小的變遷，剛剛提到上半年發力，到11月份已經有1.4M，按照這個趨勢再過兩個月就要超過2M的限制了。咱們用了一個叫作wxapp-webpack-plugin的開源工具，由於業務場景不同可能須要二次開發。它能夠幫助咱們只打包有用的代碼，在H5的生態裏是最簡單的東西，在小程序裏會稍微有點麻煩，咱們的結果就是把0.3的包變成0.93兆。12月份微信推出了分包，全部的包加起來4M，每一個包不能超過2M。

接下來還有兩部分，一是如何提升開發效率，二是如何提升穩定性。咱們在2017年的1月開源了有贊小程序的組件庫，咱們擁有組件庫的傳統，最近也改用了官方推薦的自定義組件的寫法。在開發的過程中，一樣也會涉及到接口的東西，有切換的問題，有接口轉發的問題。在這裏推薦你們嘗試使用ZanProxy，如今咱們的小夥伴沒有這個工具就沒有辦法寫代碼，它能夠很方便地轉發。咱們也支持自定義插件，作一些不一樣業務場景須要的關於接口文件、轉發以及改造的相關需求，包括在H5的頭裏面加一些字段之類。

前店後廠模式仍是跟效率有關，爲了可以比較快速地把小程序作起來，咱們回顧總結出了前店後廠模式，也就是減小環節快速往前跑。咱們組建了對接商家的羣，商家提出需求，開發的同窗以爲這個需求有道理就立刻去作，有些需求是憑感受就知道有道理的。由於已經有了H5的能力在參照，咱們要作的是選擇哪些要復刻到小程序中去。提出的痛點解決以後立刻給商家講清楚，減小所謂的產品測試等各類環節，整個過程是很順暢的。但須要核心人物同時發揮PM、產品經理以及開發的角色，或者團隊裏有人天天有一部分時間切換爲產品經理。

關於如何提升穩定性，在我看來這是本次分享裏比較有含金量的部分。簡單來說就是想要快速迭代但同時活多人少，並且沒有測試資源的狀況下要怎麼快速向前跑。咱們的解法就是體驗版、穩定版機制，前端工程師從來都是改完立刻生效，徹底無論以前的版本，最多就是灰度發佈。咱們組建了一個內測商家羣，每一個星期及時同步穩定版發佈時間以及體驗版的新功能。內測商家所有默認使用體驗版，但這些商家也是要進行篩選的。咱們會在後臺單獨操做進行更新，也能夠進行批量更新。基本上保持的節奏是兩個星期一版，因此一個體驗版的代碼將被100來個內測商家至少使用一個星期。因此體驗版小程序在改爲穩定版提供給全部商家使用的時候，基本上已經沒有什麼問題了。其中惟一一次故障就是由於沒有遵循這個原則，在體驗版上停留三四天就着急上穩定版了。第二就是利用好回滾、撤銷接口。對於這個版本出現的全部問題，咱們能夠批量地把全部商家的小程序都回撤到上一個版本，這是官方提供的藉口。咱們須要去開發，回撤以前會確認一下。

最後回顧一下，本次分享首先是爲你們介紹了我眼中的小程序，簡單來說小程序就是微信操做系統中的APP，解決了以前H5和Native APP的各類問題，下降了開發門檻。第二是從碼農的視角介紹了有贊微商城小程序，第三是介紹了咱們團隊技術上的探索和積累。

Q/A

Q：數據和數據之間作的隔離是在騰訊雲上作一個集羣嗎？
A：這個事和騰訊沒有什麼關係，咱們有本身的運維團隊，基本上管得比較底層。固然對於我的開發者而言，我仍是蠻推薦騰訊雲的套路。剛纔你說的商家數據隔離，咱們如今沒有作這樣的事情。確實有給商家提供審覈的時候，商家本身的配置，其中一個配置就是在小程序申請的APP ID，咱們全部的請求都會帶上這個ID，後端會拿到對應的數據。

Q：使用體驗版的商家爲何願意作小白鼠？是由於有一些優惠仍是確實看中？
A：這個問題問得很是好，有兩個理由。作生意的人，由於跟錢掛鉤，他們會認定有些東西是很須要的，是他們下一步商業計劃裏急需的一環，他願意承擔這個不穩定的風險去使用這個功能。實際上咱們的體驗版質量也沒有那麼差，至少咱們本身去迴歸過，該測仍是會測。商家很願意影響你，他對這個產品有本身的想法，人人都是產品經理，他們都但願這個產品按照他的想法去作，因此很願意參與這個共建。如今不少產品都這麼用，咱們也用相似的套路去作這個事情，對於咱們而言好處固然更多了。

Q：剛纔說的體驗是在現場，不是在小程序客戶端，正兒八經的發到線上？
A：對，無非就是有一個名單，給這個名單發的時候給他提交的是制定的模板ID，是體驗版的，只是提交審覈的時候不同而已。回撤是微信最近一兩個月才公佈的能力，咱們也剛剛用起來，以前若是發了一個有問題的版本也沒有辦法，只能再發一次。

Q：剛纔提到跟用戶之間直接聯繫，我想問一個細節，這個推進過程是把多個商家拉到一個羣裏面這樣操做，仍是有分開？
A：把多個商家拉到一塊兒。

Q：會不會有不和諧或者衝突的？
A：我不是特別明白你說的不和諧？

Q：好比說有些功能是增強版，我想擁有可是它沒有，若是這個版本的價格跟別人的價格都會在羣裏提到？
A：在有讚我以爲是沒有問題的，由於有贊各個版本的價格是比較透明的。說得再直白一些，哪怕你跟咱們的CEO是很鐵的哥們也沒有優惠碼，除非是商業定製款、高階的、有更高的價格，須要有BD的同窗進行對接。

Q：單獨對接？
A：若是是特別高階的幾十萬幾百萬的確定須要單獨對接，咱們普通的基本款是4800，還有9800，都是同樣的。

更多分享資料，請戳下面的連接：
有贊電商小程序的實踐.pdf

問答
小程序能夠實現哪些音視頻解決方案？
相關閱讀
鄒偉：如何開發一款小遊戲
朱展：騰訊雲小程序解決方案
劉翌：如何利用小程序技術解決企業銷售難題

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/dev...