歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
從微信的誕生，到微信公眾號、微信支付，再到小程式，騰訊生態在一次又一次影響使用者行為習慣的同時，也為開發者提供了新的思路和技能發展方向。無可置疑，微信小程式開發浪潮已經來臨，也將在 2018年成為各行業流量紅利的集中爆發入口。
4月28日，騰訊雲聯合 InfoQ舉辦的雲+社群技術沙龍，以小程式開發實戰為基準點，圍繞小程式雲上解決方案，serverless後端架構，小遊戲底層設計和直播、電商小程式的開發實戰五大主題內容，分享最全面的微信小程式設計開發思路以及解決方案。本文整理了講師演講精彩內容，感興趣的讀者可以拉到文末下載講師演講 PPT。
小程式雲端解決方案
小程式不需要安裝，易於分享與傳播、開發容易同時使用者體驗也非常好，那麼，他的這些特性是如何實現的呢？騰訊雲高階工程師朱展，從小程式架構分析、小程式解決方案進化歷程以及騰訊雲小程式解決方案介紹三方面給出了答案。
小程式的實現原理
小程式的開發模式是一種類 Web的模式，它的前端和一般的 H5的前端相似，但和 JavaScrpit開發比起來的會簡單很多，這點得益於小程式的實現原理和架構。下圖是程式的基本架構圖，它的上層分兩個板塊，一塊是檢視層，也是 WebViews，另一塊是邏輯層，也就是 AppService，這兩層在兩個不同的線裡面進行處理，跟傳統的 web有根本性的差異。
傳統的 Web渲染時，如果邏輯裡面有很複雜的處理，往往會導致介面出現卡頓的現象。小程式沒有這個問題，如果沒有呼叫渲染，不會導致介面的流程度下降。不過，由於檢視層和邏輯層在不同的執行緒裡面，這兩層不能進行直接的互動，必須通過一些手段實現互動，微信採用 JSBridge實現 JS的執行環境和原生系統的相互呼叫，當使用者在介面上進行操作時候，會觸發相關事件，傳遞到原生 Webviews，再到邏輯層。
下圖是小程式的渲染流程圖，編譯打包的階段，編寫小程式時需先編寫一個 WXML的程式碼，通過 WCC的編譯工具，進入 WAWebView，使用者執行小程式時，會和邏輯層傳入的資料做一個編譯，渲染成最終的介面，下圖是一個區域性更新的過程。
以下是小程式載入的幾種簡單的示意圖，小程式在手機載入時，要在 CDN上面拉一個小程式包，小程式在首次載入時可能有一個等待的時間，當這次安裝包快取到本地以後，下次手機再開啟該小程式，則直接從快取裡面讀取安裝包的內容，如果有新的版本，小程式也不會等新版本更新完了再開啟 APP，而是直接用上一層快取的小程式，等下再啟動時，直接使用新的安裝包替換舊的。
同時，小程式還提供了一個 Webview預載入的效能，除了當前看到的 Webview的檢視以外，在後臺還可以看到一個新的 Webview，這種預載入效能，能夠讓一些複雜的小程式在一定程度上保證載入的速度。
小程式的安裝包快取、分包載入、獨立渲染執行緒、Webview 預載入以及一些 Native 元件……這些工作在讓小程式擁有豐富功能的同時，保證了小程式的開啟速度和流暢度，從而給使用者帶來完美的體驗。
小程式解決方案進化歷程
開發者在開發一款小程式時，需要處理很多非業務性的邏輯，同時需要準備自己的伺服器，因此需要花費很多精力在伺服器運維以及周圍環境的部署上，而無法專注於小程式的業務開發。為了讓開發者從繁瑣的配置上解放出來，騰訊云為企業和機構定製了一套基於騰訊雲 IaaS 能力的解決方案，這就是騰訊雲微信小程式 Wafer 解決方案，幫助開發者更加便捷的部署和除錯伺服器。
Wafer1 面向企業和機構客戶（以下稱為企業級客戶），提供了一臺業務伺服器和一臺會話伺服器，業務伺服器來部署和處理業務相關的邏輯，而會話伺服器則用來獨立處理與使用者會話（登入註冊等）相關的邏輯，業務與會話的分離有助於中大型企業級客戶將來對小程式後臺進行擴充套件。除此之外，騰訊雲還將資料庫從雲伺服器中抽離出來，提供了雲資料庫。
除了 IaaS 能力的解決方案 wafer ，騰訊雲還提供了快速通訊介面、登入、語音識別等多種能力，用以滿足使用者在小程式開發過程中的各項功能需求。
Wafer 的通道服務是由騰訊雲提供的一個 PaaS 級的 websocket 服務。利用通道通訊技術，可以實現小程式與伺服器之間的資訊互動和傳輸。騰訊雲通道通訊技術可以使當前的使用者直接跟通道伺服器直接建立 websocket 連結，業務伺服器只用處理 http 請求而不需要關心 websocket 資訊。
總的來說，Wafer通道服務有以下幾大特點：配合 SDK無需開發，直接使用；平臺提供穩定性和效能保障；能夠自動實現斷線重連；獨立信用伺服器，訊息搬運工。但同時，Wafer1架構複雜，開發者上手成本高，開發者程式碼除錯也不方便。
針對 wafer1不足之處，2017年上半年提出 wafer2的解決方案，它是 wafer1是一個簡化版，把 wafer1做一些簡化合並，兼顧的安全性和便利性，比如說它把會話伺服器和業務伺服器做一個合併；在 wafer1時代我們會讓使用者自行部署他的伺服器，在這兒我們進行託管式的管理，使用者可以購買自己的伺服器，但是不需要做伺服器端的配置，還會自動免費部署 SSL證照，此外，騰訊雲和微信進行深度的合作，已經將 wafer2的解決方案提進微信開發者空間裡面去了。
除了 IaaS 能力的解決方案 wafer ，騰訊雲還提供了上傳程式碼到開發環境、使用 Devtools 啟動單步除錯、在開發環境安裝依賴、重啟 /停止 Node.js 程式、恢復初始狀態、上傳生產環境程式碼、帶登入態跳轉騰訊雲控制檯等系列解決方案，本文不在此一一贅述，感興趣的同學可以登入騰訊雲官網進行嘗試。
使用 Serverless 構建小程式後臺
小程式、小遊戲的開發已經越來越火爆，而小程式或者小遊戲的後臺，通常還是按照傳統的伺服器模式，提供 API 作為後端服務入口進行開發。騰訊雲正在嘗試一種新的方法：利用 serverless 架構來實現後端服務，通過結合使用 api 閘道器、雲函式、雲資料庫等服務，從而能夠無需關心伺服器，自動實現高併發，快速上線和無縫更新能力。騰訊雲 SCF無伺服器雲函式高階產品經理黃文俊詳細講解了如何使用 Serverless 來構建小程式後臺。
微信小程式及後臺互動架構
小程式，是一種全新的連線使用者與服務的方式，它可以在微信內被便捷地獲取和傳播，同時是最具有出色的使用體驗。它的載入方式比傳統的 APP方式更快速，開發上線也更快速。除了本身的介面展示和資料重新整理之外，小程式的資料獲取通過微信和後端進行互動，小程式的執行，是一種類前端的執行方式，它整個執行是在微信內，而它和後端的互動，是通過微信進行轉發的。在實際執行併發出請求時，小程式首先會呼叫微信 API，發出 API請求，這個請求傳送給微信，微信再通過網路請求傳送到使用者自己的伺服器上，使用者在自己的服務上拿到這個請求以後進行資料的處理，然後再來響應給到前端，這就是一個小程式和後臺互動的完整過程。
傳統的後臺架構需要提供 API服務的情況下，首先是需要使用負載均衡，然後接入業務應用伺服器，之後接入檔案儲存、包括結構化和非結構化的資料庫服務，以及快取服務。在這個過程中，為了保證系統不會由於某一個的伺服器當機導致服務癱瘓，需要分別建立業務應用叢集、資料庫叢集、分散式檔案儲存、快取叢集；建立叢集的一個首要作用就是確保不會由於某一個單點故障導致整個服務不可用。下圖為傳統的後臺架構圖。
這種多服務多叢集的架構模式，在中大型網際網路公司都是已經具備的了，但是作為個人開發者來說，搭建這一套系統比較困難，開發者需要了解整個系統的配置，如負載均衡怎麼配置、資料庫叢集怎麼配置等等。為了讓大家把精力從後臺的基礎架構搭建當中解放出來，將更多的時間投放到業務和小程式本身，騰訊雲在這裡為大家提供了使用 Serverless架構構建小程式後臺的方案。
Serverless 架構介紹
Serverless架構，英文稱之為 Serverless，中文稱之為無伺服器，也就是說大家不用購買伺服器，不用配置虛擬機器或者物理機，它使用計算託管的方式，使用者在使用的時候不用擔心它的安全性，也不用擔心可能伺服器當機導致的故障。
那麼，他是如何實現的呢？下圖為騰訊雲 Serverless架構，可以看成兩部分，第一部分就是函式即服務，計算託管在雲函式內，真正實現了你業務邏輯的託管計算。另外一種是後端即服務，包括物件儲存、訊息列隊、雲資料庫、雲快取、API閘道器等等。
因為 Serverless架構是計算託管型的，計算託管意味著把真正的業務程式碼託管到雲上面，然後在雲上面執行。Serverless架構的執行方式有一個特點，業務邏輯是觸發式執行的。雲函式在和各個雲產品或雲服務打通以後，各個產品或服務產生的事件，都能觸發業務邏輯的執行。我們在這裡會將雲函式與 API閘道器進行結合，當小程式發出的請求到 API閘道器時，就會產生一個 API請求事件，然後觸發業務程式碼的執行。使用者在進行託管的時候，將程式碼和觸發器的配置提交到雲上來，程式碼內容就是對事件進行邏輯處理。在事件發生和處理的過程中，對於每一次的事件，都有一個程式碼對應的例項拉起，實際上每個例項都是單獨處理一個事件。使用者發出請求時服務執行，沒有請求時服務不執行。同時本身產品的計費模式也是根據實際服務執行的時間計費的。
同時，利用物件儲存，大家不用自己構建分散式儲存，不用擔心資料的丟失和安全性問題；使用在雲上提供的資料庫、訊息佇列也是一樣，不用購買伺服器自己搭建，購買或者開通就立刻可以開始使用，因此這種服務也可以稱之為 Serverless。
Serverless 後臺開發方案
那麼怎麼使用 Serverless架構實現後臺開發呢？傳統的架構中的 web服務替換為 Serverless 架構的話，對外提供服務所暴露的 API，我們使用 API 閘道器來管理，使用者的業務邏輯，我們放在雲函式內執行，需要結構化資料儲存或者檔案儲存，我們使用資料庫服務，雲快取服務或物件儲存服務等，同時其他的更多服務，也都可以直接使用雲山提供的，直接通過程式碼呼叫。
具體搭建方案如上圖，小程式除了本身的頁面啟動和展示，後續和網路的互動都是由小程式發起，因此，小程式通過網路 API，發起請求，獲得響應並將資料展示到介面，使內容可以被使用者看到；接著是通過 API 閘道器 管理 API，配置 API 的路徑、方法、引數及校驗，管理 API 的釋出和切換；API閘道器之後就是雲函式，雲函式用來處理業務的邏輯，發起到資料庫的連線，讀取及寫入資料庫，生成響應資料，這裡根據實際業務情況，如果需要使用資料庫，就在程式碼內發資料庫的連線，需要儲存檔案，就呼叫相應的物件儲存介面來寫檔案；最後就是雲資料庫，用於儲存業務資料。
通過聯合使用 API閘道器、雲函式、雲資料庫這幾款雲產品或雲服務，我們展示了在沒有購買和配置伺服器的基礎上實現小程式登入服務的實現，完成服務的 Serverless化。利用 Serverless架構實現的小程式，開發者不需要擔心運維，同時因為執行無狀態，所以能輕易實現快速迭代、極速部署，其彈性計算能力也能滿足使用者上萬或者更高的併發。
小程式在直播產品中的技術應用
小程式如今已被用於生活的方方面面，包括電商、社交等場景，騰訊 Web前端開發高階工程師楊春文，現場以 NOW直播為例，介紹騰訊小程式在直播領域的一些嘗試，包括登入能力建設、基於騰訊雲基礎音視訊能力的直播流效能對比和選擇、動畫開發、直播間元素佈局開發、官方支援的一些實用基礎能力等，並分享在做開發過程中遇到的一些問題及解決方案。
如何基於騰訊雲構建直播小程式？
對於一個直播的小程式而言，怎麼樣才能夠用最低成本構建呢？從小程式層面來說，有兩點：主播端和觀眾端，通常主播端需要通過一些元件，完成視訊到伺服器的推送，進而到觀眾端。這個過程裡，對於小程式開發者來說，核心點包括兩個：一個推流，一個拉流。
一般而言，開發者自建轉碼、傳輸等功能來實現視訊的推流和拉流是非常麻煩的，騰訊雲有非常成熟的視訊解決方案幫助完成這個過程。下圖為騰訊雲的直播小程式解決方案，使用過程也非常簡單：
- 申請騰訊雲直播服務；
- 獲取加密私鑰；
- 部署自己的業務後臺 (提供現成程式碼)；
- 生成開播端地址 (上行)；
- 生成播放端地址 (下行)；
- 開啟小程式。
通過以上幾個步驟，可以基本完成直播小程式的配置工作。
那麼，開播地址以及播放的地址是如何生成的？這裡面主要包含兩部分，如上圖，左邊的主播端首先生成一個開播地址，主播端的小程式通過推流 URL，把視訊推送到騰訊雲裡面，騰訊雲通過系列的編碼、傳輸、解碼工作，生成播放 URL，通過播放 URL(觀看地址)推流給觀眾。
遇到的一些坑及其解決方案
上面講的是怎麼構建一個小程式，騰訊 NOW直播團隊在開發直播應用的時候，也遇到了許多問題，楊春文現場就佈局、setData、大圖片和預載入四方面的痛點和解決方案展開了詳細講解。
佈局之痛
問題描述：video等 native元素無法和 webview元素重疊，視訊與直播間元素的混排實現困難，cover-view元件與普通元件差異太大。
解決方案：折衷使用 canvas來實現動態的效果，canvas是一個原生的元件，可以用於複雜佈局。但 canvas實現也有一些問題，就目前來說，比如用 canvas實現的功能放在小程式裡面使用時，手機溫度升高、會有發熱現象產生等等，解決方案是將客戶端實現的 canvas和我們 web實現的 canvas在效能上面差異化，以適配不同端的需求。同時，NOW直播團隊也在嘗試做一些效能上的改進的工作，解決使用者體驗問題。
setData優化
問題描述：setData 函式用於將資料從邏輯層傳送到檢視層，頻繁 SetData等於頻繁 DOM操作，從而導致 UI延遲；同時超大資料 setData也會使指令碼執行時間過大，在後臺 setData，也會產生多餘的資源 (CPU/記憶體 /電量…)消耗，佔用前臺 JS執行。
解決方案：避免頻繁的 SetData操作。如我們不停滾動的評論以及彈幕的訊息，最開始的時候每展示一條就需要進行一次 SetData操作，然後產生一個 dom操作，這是非常消耗成本的。改進方案是一次返回多條訊息，在小程式端滾動展示，避免一條訊息產生一次 setData，完成體驗上面的權衡。另外，在 onHide 時停止資料更新，從前一個頁面切換到後一個，暫停前一個頁面推薦更新操作。
大圖片之殤
問題描述：小程式渲染層，通過 webview的方式進行，如果圖片較大，不僅會佔用過多記憶體，也會導致延遲和卡頓現象。
解決方案：如果一定需要大圖片，建議定期銷燬這些大圖片，比如以下圖片，只要在區域裡面才不會銷燬，如果不在這個區域裡面就可以銷燬，一些不需要的圖片如果一直存在，對效能的消耗會比較大。
預載入
問題描述：資料預載入的過程，頁面切換，這個過程比較消耗時間
解決方案：當使用者剛剛進入下一個頁面時，頁面還需要拉取資料，進行渲染，這個過程從需要從 A頁面進入到 B頁面，然後再到資料，中間這個 A切換到 B，這裡面有一段時間的消耗，在 A頁面切到 B頁面的過程當中，可以同時拉取一個資料，B頁面進來，直接從這個資料裡面提取需要的資料，這樣就不需要再發一個請求重新拉去資料，避免中間時間的消耗等等延遲的問題。
如何開發一款小遊戲
小遊戲目前的火爆程度已毋庸置疑，從全民“跳一跳”到如今的“星途 WeGoing”，小遊戲已逐漸滲入消費者日常，成為老少皆宜的娛樂產品之一。騰訊微信高階工程師鄒偉現場結合《星途 WeGoing》的底層架構和研發設計，分享瞭如何更好的利用微信的開放能力開發一款小遊戲。
什麼是小遊戲？
從普通使用者的視角看，小遊戲是小程式的一個子類目，可在微信內被便捷的獲取和傳播，即點即玩，具備出色的使用者體驗。小遊戲是小程式，普通使用者分不清也無需分清。
同時，從開發者的視角，它可以看作是基於 Canvas/WebGL + 微信社交開放能力的一個新平臺。下圖是一個小遊戲的一個架構概覽：
這是一個典型的分層架構。最上層藍色部分，是遊戲程式碼，分為遊戲邏輯，遊戲引擎、weapp-adapter三部分。大部分遊戲開發會用到一些引擎的工具、工作流，以及利用引擎封裝的高層 API去實現遊戲邏輯。其次是 weapp-adapter，因為小遊戲的底層一方面不是 webview，可以簡單看成是 webview經過精簡、優化過後的平臺；另一方面核心能力的實現上卻參考了 webview。所以這裡如果有一個介面卡，把小遊戲的底層 API——wx API適配到一個接近 webview的介面，對上層引擎、已存在的遊戲接入微信小遊戲平臺則會更加容易，這個就是 weapp-adapter的作用。其中只有遊戲邏輯是必要的。
中間層紅色部分是微信以及小遊戲 Runtime，Runtime對外暴露的能力叫 wx API，有一個基礎庫的。有一個 jsvm用於執行遊戲的 Javascript程式碼，在安卓上是用 V8Core，iOS則是 JavaScriptCore。再下面一層是核心的渲染能力的實現，包括 Canvas 2d以及 WebGL，當然還有微信開放能力相關 API的實現。
可以看到，在架構上小遊戲和小程式是有差別的，小遊戲沒有頁面概念的，wxss/wxml不再存在。其次，底層實現也不是 webview，小遊戲和 webview的關係只能說是渲染相關的核心能力可以通過 weapp-adapter的簡單適配保持介面一致，但同時很多 webview上存在的功能並沒有對等的實現，比如小遊戲就沒有 DOM/BOM的概念，也沒有全域性的 document/window物件。
小遊戲的入口為 game js檔案，語言為 Javascript，但有一些限制，比如禁止執行動態程式碼，因此 eval、new Function等能力是不支援的。配置為 game.json，可以配置橫豎屏、介面超時等引數。js裡面可以組合 wx API的能力來實現遊戲邏輯， 非程式碼類的資源應該儘量放到 cdn，減少整個程式碼包打包後的大小，以加快使用者首次進入時的速度，微信對首包的大小目前限制為 4MB。
小遊戲能力概覽（小遊戲能力在不斷擴充中，最新、完整能力可關注我們的開發文件）：
如何開發一款小遊戲？
小遊戲的核心邏輯的開發過程和傳統的端遊、頁遊以及現在的手遊，並沒有多大區別。這裡會著重介紹一下怎麼更好的利用微信小遊戲的平臺開放能力，包括選擇小遊戲引擎選擇、裝置 /環境適配、微信登入、快取、開放資料域、分享、支付、效能、版本更新機制、運維這幾個部分。
選擇小遊戲引擎
微信跟引擎商也有比較密切的合作，一般現在的遊戲引擎都會支援釋出到多個平臺，對微信小遊戲這個新平臺而言，已經有一部分引擎做了適配，比如 Cocos Creator、Egret Engine以及 LayAir Engine。適配的主要工作，類似之前提到的 weapp-adapter，把 wx API的能力，和引擎銜接起來。比如引擎一般會把小遊戲平臺和 webview平臺對標，適配過程就是把 wx API對應到 webview的能力，同時把只存在於 webview能力的依賴去除，比如不再依賴 BOM、DOM。
裝置 /環境適配
微信本身執行在不同 OS平臺，如 iOS、Android，而不同平臺又執行於不同的物理裝置。執行於微信之上的小遊戲，自然就面對不同型別裝置和環境的適配。當然能力上，小遊戲平臺已經儘量消除了它們的區別。但仍然有一些工作需要開發者去針對性的優化，比如高解析度螢幕，可以提供更高清的畫質。小遊戲會有 API提供獲取螢幕的寬高、裝置畫素比等能力。小遊戲開發完成後，在開發者工具也可以發起真機測試的請求，微信提供了不同裝置的測試叢集，幫助開發者提前去發現問題。基礎庫提供的 wx API本身是一個不斷迭代更新的過程，對於使用了新能力的小遊戲，需要做低版本相容。比如在檢測到不支援新 API的低版本允許有損服務使用者。同時，如果某個低版本的使用者佔比較少，可以考慮在 mp.weixin.qq.com管理後臺直接配置小遊戲要求的基礎庫最低版本，當然也意味著這一部分使用者在接觸到這個小遊戲時，微信客戶端會彈出一個要求使用者更新到微信新版本才可使用該小遊戲的提示，如果他不更新，你就可能失去了這個使用者。
微信登入
小遊戲的登入過程，跟小程式是類似的。需要使用者自己去定義登入狀態。appsecret/session_key代表的是小遊戲開發者和微信平臺之間的一種信任約定，比如支付、上報託管資料，平臺方需要驗證 access_token(只有 appsecret才能換得到)，和使用者相關的還要驗證 session_key的簽名，才能保證請求來自於小遊戲開發者 /使用者，而不是惡意的第三方和隨意捏造的使用者。access_token是一種應用態的 access_token，和使用者無關，需要保證全域性維護一份，應該有一箇中控的模組去保證 access_token有效，同時在有效期內直接使用本地 cache的 access_token，而不是每次使用都去生成新的 access_token，否則可能遇到呼叫頻率限制的錯誤而影響服務。切記 appsecret/session_key不要放到前端程式碼中去，否則可能會被壞人利用損壞小遊戲開發者 /使用者的權益。
快取
快取型別包括資料快取和檔案快取兩類。資料快取即 key-value儲存，適合結構化型別的小資料儲存，上限為 10MB。檔案快取提供了一個完整的檔案系統 API，包括目錄 /檔案的增刪改讀，適合針對經常使用的網路資源做本地快取，上限是 50MB。
和瀏覽器不同的是，微信只提供了基本的儲存管理能力，並不對儲存什麼，和儲存滿時刪除什麼做一些操作。開發者自行靈活定義快取以及淘汰策略，比如對經常訪問的資源儲存到檔案系統以及在檔案儲存滿時，清理一些最近不常訪問的檔案。
開放資料域
開放資料域是一個封閉、獨立的 JavaScript 作用域，和執行遊戲邏輯的環境——稱為“主域”隔離。其目的是在保證使用者隱私的前提下開放使用者資料給第三方，提升小遊戲的整體使用者體驗。以下為物理檢視，主域的入口為 game.js，開放資料域則是一個獨立的目錄，其入口檔案為 index.js：
主域和開放資料域的通訊受到嚴格的管制，基本原則是隻進不“出”。
只進：允許外部的資料進入開放資料域，即主域可以隨時 postMessage到開放域，以及開放域引用主域準備好的本地資源
不“出”：不允許開放資料域的資料被上傳到第三方伺服器去。因為開放資料域裡面，index.js是可以直接訪問到使用者敏感資料的，比如同玩好友資料。當然最終開放資料域需要 index.js在綜合各種資料後把資料以圖形影象的方式渲染到 sharedCanvas上，在主語 sharedCanvas允許 draw到主域的上屏 Canvas上，終端使用者會在螢幕上看到 game.js畫出來的好友排行榜、群排行榜或好友超越等社互動動資訊。
目前開放資料域僅支援 2D渲染模式。
分享
包括自定義分享和系統選單分享，可以分享到群聊、單聊。也可以把分享上下文與特定的群關聯，實現一些群 PK、群排行榜的場景。分享是一把雙刃劍，需要謹慎使用，一方面避免過度騷擾使用者 /群聊，另一方面增強社互動動提供好的遊戲體驗，需要找到一個合適的平衡點。
支付
小遊戲在安卓下支援虛擬支付，它的方式目前只有一種：即貨幣託管的方式。主要分為 2個流程：
- 充值：RMB -> 遊戲幣，這裡開發者只需要拉起支付的流程，平臺負責把使用者 RMB兌換成對應的遊戲幣，儲存到使用者對應的遊戲帳號上
- 使用遊戲幣購買道具：開發者可以扣除對應的遊戲幣，給使用者發放遊戲內道具，扣除遊戲幣的過程需要有一定的事務機制，去保證在網路異常的情況下交易正常。扣除遊戲幣的介面支援根據訂單 id去重，意味著網路超時等情況下，開發者可用同樣的訂單 id去重試扣除，直至返回明確的響應。
以下為簡單時序圖，部分角色針對開發者無需關心的部分做了相應簡化處理：
效能
小遊戲常見的效能問題，一般是記憶體造成的。如果記憶體佔用太多會被微信客戶端主動關閉，因此開發者在使用者遊戲過程中要及時釋放不再使用的記憶體（js程式碼去除引用，或主動呼叫對應資源的釋放介面，如果有的話），特別是 Canvas和 Image類大型物件，同時可以主動呼叫 wx.triggerGC觸發底層回收對應資源。
對於和遊戲邏輯相對獨立的工作，可以考慮在 worker中去實現，小遊戲提供了獨立的 worker執行緒執行 js邏輯的能力。
版本更新機制
小遊戲啟動的過程分為冷啟動和熱啟動。冷啟動是指記憶體中無該小遊戲的執行例項的情況下，啟動小遊戲的過程；熱啟動是指小遊戲的執行例項在記憶體中還存在，只是暫時切換到了後臺，這時使用者再次觸發小遊戲回到前臺的過程。
小遊戲會在冷啟動時檢查小遊戲的版本，如有新版本，在下載回本地後，下一次冷啟動即可使用最新版。當然，我們也提供了 API可以供開發者決策在有版本可用時，是否需要強制更新：
運維
mp.weixin.qq.com管理端提供了釋出、灰度釋出、回滾、停服等能力，可以充分利用平臺已有的能力。
特別提醒，小遊戲有完善的後端監控，可以通過“運維中心”開啟，比如指令碼錯誤監控（指令碼錯誤主要由執行過程中未捕獲的異常觸發，需要重點關注。該類異常，可能會導致使用者小遊戲前端的 js邏輯暫停執行）：
有贊電商小程式的實踐
黎貝卡小程式店鋪“首次上新 7分鐘破百萬”、“二次上新 59秒破百萬”，這些傲人的成績背後離不開有贊技術團隊的保駕護航，有贊電商小程式負責人施德來現場與大家分享有贊在電商小程式的發展歷史與現狀，以及有贊在小程式技術上的積累。例如小程式元件庫的開源、在微頁面裡如何將 H5與小程式合二為一以及有贊在開發過程中遇到的一些問題，如何利用官方解決方案進行最優處理等。
在小程式出現之前，做移動開發一般有兩個模式：第一種是 web應用如 H5，一種是原生應用。這兩種模式的特點都是很鮮明的，比如 H5這類應用無需安裝、跨平臺、易開發、傳播性比較好，但頁面簡單，開啟速度慢、Native能力差，使用者體驗一般。而原生 APP體驗流程、功能齊全，但則需要安裝，開發速度慢、更新麻煩，對開發的專業要求也比較高。
小程式結合了兩者的優點，很多 H5裡面需要高階能力才能解決的問題，被小程式用降維的方式解決了，比如說 H5裡面原先要做非同步載入等系列優化措施，才能讓 H5頁面開啟更快但小程式通過打包提交、提前下載、Native 和 Web 混合渲染的方式很低門檻地解決了這些問題。總的來說，小程式集合了開發簡單、功能多、體驗好等系列特點，是現今主流的移動應用。
有贊從 17年開始介入小程式開發，隨著微信小程式功能與介面的逐步完善和更新，在 17年下半年時有贊集中發力，並在 18年開始爆發。
在功能上，有贊將原先 H5裡面大量的核心能力全部搬到小程式，同時也做了小程式特有的能力。包括店鋪、商品、訂單、客戶管理、資料，營銷工具，營銷渠道等等，這裡面有些是參考的，有些是有贊首創的。
這裡面的功能可以說是非常齊全的，商家可以根據自己的需求進行功能選擇。同時，有贊也為海量小程式商家提供小程式技術服務，確保商家小程式正常上線運營。
技術上的探索和積累
如何同時產出海量獨立的微商城小程式？
雖然程式碼是同一套，但每個商家的小程式都是獨立名字的，獨立提交稽核的，版本也不同。作為平臺開發者，微信是提供這種能力的，幫商家提交新版本小程式的時候，使用相同的模板 ID的同時，每個商家的小程式額外提交一份 ext.json，裡面包含這個商家的小程式特有的東西，比如 appid、底部導航配置等。有贊把這兩個資訊提交給微信，微信開始稽核這個小程式。
一套程式碼兩個馬甲
像有讚的公共版小程式和專享版小程式，他們之間有大量的公共業務程式碼，程式碼都在同一個倉庫裡，專享版是公共版的一個子集。公共版有一個專門的“app.json”，我們把它命名為 app-youzan.json，專享版對應的就是預設的 app.json。我們自己寫了個 webpack的外掛，會在開始編譯程式碼前把 app.json裡的內容 merge到 app-youzan.json，然後在後續的編譯過程裡，針對 app-youzan.json(公共版)和 app.json(專享版)分別打兩次，以輸出 2個版本。
體積來越大，馬上就突破 2M了
17年 11月份就已經 1.4M了，眼看按這個趨勢很快要到 2M，有贊嘗試了用第三方工具 wxapp—webpack—plugin，在它基礎上二次開發了下，只打包有用到的模組，合併重複的模組。如上圖，12月份包的大小降了下去了，後來微信開放了分包的功能，有贊 4月份也簡單嘗試了一下，推薦大家用起來。
如何提高開發效率？
- 推薦有贊開源的 ZanUI-Weapp 元件庫（ https://github.com/youzan/zanui-weapp ），Star 已經 4k多了。
- Zan Proxy（https://github.com/youzan/zan-proxy） 是我們開源的代理、Mock工具，功能比較全面，可以很方便地做到原生程式碼除錯線上頁面線上介面。如果你還在用 nginx做這個事情，可以試試 ZanProxy。
- 前店後廠與商家共建產品的模式，快速迭代往前跑，減少中間環節。
如何提高穩定性？
有讚的方法就是體驗版、穩定版機制。每 2個星期發一個新版本，在更新所有小程式前，會先讓 100+小程式先升級到新版本，至少內測一個星期。這 100+小程式對應的商家就是我們的內測商家。
另外一種方法是利用好回滾、撤銷稽核介面，這部分是騰訊提供的能力，當有贊發現某一個版本有問題，可以把所有或者部分商家的小程式都回滾到上一個版本。
瞭解更多詳情，請戳下面的連結：
問答
相關閱讀
此文已由作者授權騰訊雲+社群釋出，原文連結：https://cloud.tencent.com/developer/article/1117472?fromSource=waitui
