簡單5步，從0開始搭建你的第一款小程序

時間 2019-12-14

標籤簡單開始搭建一款程序简体版

原文原文鏈接

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

從微信的誕生，到微信公衆號、微信支付，再到小程序，騰訊生態在一次又一次影響用戶行爲習慣的同時，也爲開發者提供了新的思路和技能發展方向。不容置疑，微信小程序開發浪潮已經來臨，也將在 2018年成爲各行業流量紅利的集中爆發入口。webpack

4月28日，騰訊雲聯合 InfoQ舉辦的雲+社區技術沙龍，以小程序開發實戰爲基準點，圍繞小程序雲上解決方案，serverless後端架構，小遊戲底層設計和直播、電商小程序的開發實戰五大主題內容，分享最全面的微信小程序設計開發思路以及解決方案。本文整理了講師演講精彩內容，感興趣的讀者能夠拉到文末下載講師演講 PPT。nginx

小程序雲端解決方案

小程序不須要安裝，易於分享與傳播、開發容易同時用戶體驗也很是好，那麼，他的這些特性是如何實現的呢？騰訊雲高級工程師朱展，從小程序架構分析、小程序解決方案進化歷程以及騰訊雲小程序解決方案介紹三方面給出了答案。git

小程序的實現原理

小程序的開發模式是一種類 Web的模式，它的前端和通常的 H5的前端類似，但和 JavaScrpit開發比起來的會簡單不少，這點得益於小程序的實現原理和架構。下圖是程序的基本架構圖，它的上層分兩個板塊，一塊是視圖層，也是 WebViews，另外一塊是邏輯層，也就是 AppService，這兩層在兩個不一樣的線裏面進行處理，跟傳統的 web有根本性的差別。github

傳統的 Web渲染時，若是邏輯裏面有很複雜的處理，每每會致使界面出現卡頓的現象。小程序沒有這個問題，若是沒有調用渲染，不會致使界面的流程度降低。不過，因爲視圖層和邏輯層在不一樣的線程裏面，這兩層不能進行直接的交互，必須經過一些手段實現交互，微信採用 JSBridge實現 JS的運行環境和原生系統的相互調用，當用戶在界面上進行操做時候，會觸發相關事件，傳遞到原生 Webviews，再到邏輯層。web

下圖是小程序的渲染流程圖，編譯打包的階段，編寫小程序時需先編寫一個 WXML的代碼，經過 WCC的編譯工具，進入 WAWebView，用戶運行小程序時，會和邏輯層傳入的數據作一個編譯，渲染成最終的界面，下圖是一個局部更新的過程。數據庫

如下是小程序加載的幾種簡單的示意圖，小程序在手機加載時，要在 CDN上面拉一個小程序包，小程序在首次加載時可能有一個等待的時間，當此次安裝包緩存到本地之後，下次手機再打開該小程序，則直接從緩存裏面讀取安裝包的內容，若是有新的版本，小程序也不會等新版本更新完了再打開 APP，而是直接用上一層緩存的小程序，等下再啓動時，直接使用新的安裝包替換舊的。json

同時，小程序還提供了一個 Webview預加載的性能，除了當前看到的 Webview的視圖之外，在後臺還能夠看到一個新的 Webview，這種預加載性能，可以讓一些複雜的小程序在必定程度上保證加載的速度。canvas

小程序的安裝包緩存、分包加載、獨立渲染線程、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直播爲例，介紹騰訊小程序在直播領域的一些嘗試，包括登陸能力建設、基於騰訊雲基礎音視頻能力的直播流性能對比和選擇、動畫開發、直播間元素佈局開發、官方支持的一些實用基礎能力等，並分享在作開發過程當中遇到的一些問題及解決方案。

如何基於騰訊雲構建直播小程序？

對於一個直播的小程序而言，怎麼樣纔可以用最低成本構建呢？從小程序層面來講，有兩點：主播端和觀衆端，一般主播端須要經過一些組件，完成視頻到服務器的推送，進而到觀衆端。這個過程裏，對於小程序開發者來講，核心點包括兩個：一個推流，一個拉流。

通常而言，開發者自建轉碼、傳輸等功能來實現視頻的推流和拉流是很是麻煩的，騰訊雲有很是成熟的視頻解決方案幫助完成這個過程。下圖爲騰訊雲的直播小程序解決方案，使用過程也很是簡單：

1.申請騰訊雲直播服務；
2.獲取加密私鑰；
3.部署本身的業務後臺 (提供現成代碼)；
4.生成開播端地址 (上行)；
5.生成播放端地址 (下行)；
6.開啓小程序。
經過以上幾個步驟，能夠基本完成直播小程序的配置工做。

那麼，開播地址以及播放的地址是如何生成的？這裏面主要包含兩部分，如上圖，左邊的主播端首先生成一個開播地址，主播端的小程序經過推流 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/zan... ），Star 已經 4k多了。
Zan Proxy（https://github.com/youzan/zan...）是咱們開源的代理、Mock工具，功能比較全面，能夠很方便地作到本地代碼調試線上頁面線上接口。若是你還在用 nginx作這個事情，能夠試試 ZanProxy。
前店後廠與商家共建產品的模式，快速迭代往前跑，減小中間環節。

如何提升穩定性？
有讚的方法就是體驗版、穩定版機制。每 2個星期發一個新版本，在更新全部小程序前，會先讓 100+小程序先升級到新版本，至少內測一個星期。這 100+小程序對應的商家就是咱們的內測商家。
另一種方法是利用好回滾、撤銷審覈接口，這部分是騰訊提供的能力，當有贊發現某一個版本有問題，能夠把全部或者部分商家的小程序都回滾到上一個版本。