該文還提到與火爆相關的兩個姿勢。一是社交匹配度，在小遊戲這樣一個去中心化的大背景下，讓遊戲內容和微信社交相結合是一個很重要的點，同時開發者也需要在利用社互動動提升使用者體驗和群聊分享造成使用者騷擾之間選擇一個平衡點，過猶不及。第二是操作簡便度，說的是遊戲易上手操作簡單。這是我們根據遊戲成為爆款後觀察得出的結論，並不是說具備這兩個特性就一定能開發出一款火爆的遊戲，並且新的爆款遊戲也不一定符合這些特點，僅供參考。

什麼是“小遊戲”？小遊戲是什麼？

小遊戲Runtime

如果放大小遊戲的Runtime可以看到很多的細節，這是一個典型的分層架構：

最上層藍色部分，是遊戲程式碼，分為遊戲邏輯，遊戲引擎、weapp-adapter三部分。大部分遊戲開發會用到一些引擎的工具、工作流，以及利用引擎封裝的高層API去實現遊戲邏輯。其次是weapp-adapter，因為小遊戲的底層一方面不是webview，可以簡單看成是webview經過精簡、最佳化過後的平臺；另一方面核心能力的實現上卻參考了webview。所以這裡如果有一個介面卡，把小遊戲的底層API——wx API適配到一個接近webview的介面，對上層引擎、已存在的遊戲接入微信小遊戲平臺則會更加容易，這個就是weapp-adapter的作用。其中只有遊戲邏輯是必要的。

可以看到，在架構上小遊戲和小程式是有差別的，小遊戲沒有頁面概念的，wxss/wxml不再存在。其次，底層實現也不是webview，小遊戲和webview的關係只能說是渲染相關的核心能力可以透過weapp-adapter的簡單適配保持介面一致，但同時很多webview上存在的功能並沒有對等的實現，比如小遊戲就沒有DOM/BOM的概念，也沒有全域性的document/window物件。

小遊戲的入口為game js檔案，語言為Javascript，但有一些限制，比如禁止執行動態程式碼，因此eval、new Function等能力是不支援的。配置為game.json，可以配置橫豎屏、介面超時等引數。js裡面可以組合wx API的能力來實現遊戲邏輯， 非程式碼類的資源應該儘量放到cdn，減少整個程式碼包打包後的大小，以加快使用者首次進入時的速度，微信對首包的大小目前限制為4MB。

Webview Adapter

下面來說一下Webview Adapter，它的初衷是為了讓遊戲開發者更好地熟悉我們的平臺，所以我們的平臺在能力上會盡可能地與webview做一些適配，其實這個適配也是很簡單的一層。比如說我們在瀏覽器裡面使用image物件建立一個圖片，而在小遊戲裡是透過wx.createimage來建立的，在程式碼中需要做一個簡單的適配。

以此類推，常見的Canvas、document物件都是在Adapter中透過一個簡單的適配實現的，大家可以研究連結中的程式碼。之後官方不會繼續維護這個Adapter，我們會更專注於底層能力的建設。

小遊戲能力概覽

下圖是小遊戲能力的概覽，小遊戲能力的迭代比較快，部分能力還沒有來得及羅列出來。比如最近剛釋出的遊戲圈、健康系統防沉迷相關的一些介面。

我們先看一下基礎能力，在渲染這部分WebGL1.0和Canvas 2D都是支援的，這裡的Canvas更接近於瀏覽器裡面的標準。同時，這裡提到的可控幀率的概念，如果小遊戲在後臺執行的話，可以儘量將幀率降低。

在多媒體部分，小遊戲還不能像小程式一樣實現實時的音訊影片流，這是我們在後續要進一步支援的。網路IO的部分與小程式也是類似的，我們也提供了一些UI的元件，比如說拉起鍵盤，模態對話方塊等。

因為小遊戲去中心化的特點，分享這一部分也是非常重要的，開發者要考慮如何將這個能力利用起來。在程式碼方面，因為首包限制是4MB，但部分小遊戲的程式碼量可能比較大。我們最近也在規劃一個分包的能力，允許非同步載入程式碼並執行，但這個程式碼是一定要經過我們稽核的。

如何開發一款小遊戲？

選擇小遊戲引擎

微信跟引擎商也有比較密切的合作，一般現在的遊戲引擎都會支援釋出到多個平臺，對微信小遊戲這個新平臺而言，已經有一部分引擎做了適配，比如Cocos Creator、Egret Engine以及LayAir Engine。適配的主要工作，類似之前提到的weapp-adapter，把wx API的能力，和引擎銜接起來。

比如引擎一般會把小遊戲平臺和webview平臺對標，適配過程就是把wx API對應到webview的能力，同時把只存在於webview能力的依賴去除，比如不再依賴BOM、DOM。已適配的引擎都有相應的文章介紹如何把遊戲釋出到微信小遊戲平臺。

裝置/環境適配

小遊戲會有API提供獲取螢幕的寬高、裝置畫素比等能力。小遊戲開發完成後，在開發者工具也可以發起真機測試的請求，微信提供了不同裝置的測試叢集，幫助開發者提前去發現問題。基礎庫提供的wx API本身是一個不斷迭代更新的過程，對於使用了新能力的小遊戲，需要做低版本相容。

小遊戲的登入過程，跟小程式是類似的。需要使用者自己去定義登入狀態。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畫出來的好友排行榜、群排行榜或好友超越等社互動動資訊。

在開發資料域中的資料，開發者沒法把資料拿出去和遊戲資料做關聯，所以如果需要在開放域下展示的遊戲資料，比如分數，開發者需要將該資料透過上報介面把遊戲資料託管到平臺。這樣就可以在開發資料域裡面就取到相關資料，其應用場景有好友排行、群排行榜、超越好友提示等。

分享

包括自定義分享和系統選單分享，可以分享到群聊、單聊。也可以把分享上下文與特定的群關聯，實現一些群PK、群排行榜的場景。分享是一把雙刃劍，需要謹慎使用，一方面避免過度騷擾使用者/群聊，另一方面增強社互動動提供好的遊戲體驗，需要找到一個合適的平衡點。

支付

小遊戲在安卓下支援虛擬支付，它的方式目前只有一種：即貨幣託管的方式。主要分為2個流程：

1.充值：RMB -> 遊戲幣，這裡開發者只需要拉起支付的流程，平臺負責把使用者RMB兌換成對應的遊戲幣，儲存到使用者對應的遊戲帳號上

2.使用遊戲幣購買道具：開發者可以扣除對應的遊戲幣，給使用者發放遊戲內道具，扣除遊戲幣的過程需要有一定的事務機制，去保證在網路異常的情況下交易正常。扣除遊戲幣的介面支援根據訂單id去重，意味著網路超時等情況下，開發者可用同樣的訂單id去重試扣除，直至返回明確的響應。

以下為簡單時序圖，部分角色針對開發者無需關心的部分做了相應簡化處理：

效能

小遊戲常見的效能問題，一般是記憶體造成的。如果記憶體佔用太多會被微信客戶端主動關閉，因此開發者在使用者遊戲過程中要及時釋放不再使用的記憶體（js程式碼去除引用，或主動呼叫對應資源的釋放介面，如果有的話），特別是Canvas和Image類大型物件，同時可以主動呼叫wx.triggerGC觸發底層回收對應資源。

對於和遊戲邏輯相對獨立的工作，可以考慮在worker中去實現，小遊戲提供了獨立的worker執行緒執行js邏輯的能力。

版本更新機制

小遊戲啟動的過程分為冷啟動和熱啟動。冷啟動是指記憶體中無該小遊戲的執行例項的情況下，啟動小遊戲的過程；熱啟動是指小遊戲的執行例項在記憶體中還存在，只是暫時切換到了後臺，這時使用者再次觸發小遊戲回到前臺的過程。

小遊戲會在冷啟動時檢查小遊戲的版本，如有新版本，在下載回本地後，下一次冷啟動即可使用最新版。當然，我們也提供了API可以供開發者決策在有版本可用時，是否需要強制更新。

運維

特別提醒，小遊戲有完善的後端監控，可以透過“運維中心”開啟，比如指令碼錯誤監控。指令碼錯誤主要由執行過程中未捕獲的異常觸發，需要重點關注。該類異常，可能會導致使用者小遊戲前端的js邏輯暫停執行。

同時，平臺也提供了完善的資料分析服務，可以透過“小遊戲資料助手”進行資料分析。

該文還提到與火爆相關的兩個姿勢。一是社交匹配度，在小遊戲這樣一個去中心化的大背景下，讓遊戲內容和微信社交相結合是一個很重要的點，同時開發者也需要在利用社互動動提升使用者體驗和群聊分享造成使用者騷擾之間選擇一個平衡點，過猶不及。第二是操作簡便度，說的是遊戲易上手操作簡單。這是我們根據遊戲成為爆款後觀察得出的結論，並不是說具備這兩個特性就一定能開發出一款火爆的遊戲，並且新的爆款遊戲也不一定符合這些特點，僅供參考。