微信小遊戲開發總結

小遊戲是小程式的一個類目，小遊戲是微信開放給小程式的更多的能力，讓小程式開發者有了開發遊戲的能力。小遊戲沒有WXSS、WXML、多頁面等内容，但加了一些渲染、檔案系統以及背景多線程的功能。 小遊戲的運作環境是小程式環境的擴充，基本思路也是封裝必要的 WEB 接口提供給使用者，盡可能追求和 WEB 同樣的開發體驗。小遊戲在小程式環境的基礎上提供了 WebGL 接口的封裝，使得渲染能力和性能有了大幅度提升。不過由于這些接口都是微信團隊通過自研的原生實作封裝的，是以并不可以等同為浏覽器環境。 小遊戲的運作環境在 iOS 上是 JavaScriptCore（ 注：webkit的一個重要組成部分，主要是對JS進行解析和提供執行環境。 ），在 Android 上是 V8 （這個不用多說Node.js目前使用的就是V8）。但是兩個都沒有 BOM 和 DOM 的運作環境，沒有全局的  document  和  window  對象。 小遊戲 VS H5遊戲 VS 小程式對比圖 第三方代碼适配（Adapter） 主要目的提供 BOM 和 DOM 的運作環境。 由上圖可以看出，因為沒有 BOM 和 DOM 的運作環境，沒有全局的  document  和  window  對象。為了讓基于浏覽器環境（上圖的H5遊戲）的第三方代碼更快地适配小遊戲運作環境，是以就有了擴充卡（Adapter）。它是用微信 API 模拟 BOM 和 DOM 的代碼組成的庫，抽象的代碼層，可以根據自己的需要去實作相關方法。 例如，簡單實作  document.creatElement  方法： var document = { createElement: function (tagName) { tagName = tagName.toLowerCase() if (tagName === 'canvas') { return wx.createCanvas() } else if (tagName === 'image') { return wx.createImage() } } } Adapter是否使用由開發者自己決定。不使用Adapter時，可以通過微信提供的API實作相應的方法，但不能使用 DOM API 來建立 Canvas 和 Image 等元素。 有的遊戲引擎是直接調用DOM API，和通路DOM屬性 ，是以記得使用Adapter讓遊戲引擎适配小遊戲的運作環境，保證遊戲引擎在調用 DOM API 和通路 DOM 屬性時不會産生錯誤。 微信官方實作了一個 weapp-adapter 小遊戲擴充卡，但僅僅隻針對遊戲引擎可能通路的屬性和調用的方法進行了模拟，也不保證所有遊戲引擎都能通過 weapp-adapter 能順利無縫接入小遊戲。這裡将 weapp-adapter 擴充卡提供給開發者，更多地是讓開發者作為參考，讓開發者可以根據需要在 weapp-adapter 的基礎上進行擴充，以适配自己項目使用的遊戲引擎。weapp-adapter 會預先調用  wx.createCanvas()  建立一個上屏 Canvas，并暴露為一個全局變量  canvas  。 require('./weapp-adapter'); var context = canvas.getContext('2d'); context.fillStyle = 'red'; context.fillRect(, , , ); weapp-adapter 擴充卡提供了以下對象和方法： document.createElement canvas.addEventListener localStorage Audio Image WebSocket XMLHttpRequest 其實官方文檔裡面還有很多 ，感興趣可以檢視官方 API文檔 。 小遊戲的子產品化 小遊戲提供了 CommonJS 風格的子產品 API，可以通過  module.exports  和  exports  導出子產品，通過  require  引入子產品。這裡就不用多解釋了，其實大家按正常的編碼習慣編碼就可以了。 module.exports = function (canvas, x, y) { var image = new Image() image.onload = function () { var context = canvas.getContext('2d') context.drawImage(image, x, y) } image.src = 'res/image/logo.png' } 是以小遊戲對編碼方面的基礎能力還是很友善的。 小遊戲能力 這裡列出部分已提供的 API 能力，更詳細的能力及官方執行個體可通路 API文檔 。 大家對 Canvas 的優化或者對離屏畫布不了解的可以看這篇文章 Canvas 最佳實踐（性能篇）。 小遊戲引擎 遊戲引擎是指一些已編寫好的可編輯電腦遊戲系統或者一些互動式實時圖像應用程式的核心元件。這些系統為遊戲設計者提供各種編寫遊戲所需的各種工具，其目的在于讓遊戲設計者能容易和快速地做出遊戲程式而不用由零開始。 Cocos、Egret、Laya 已經完成了自身引擎及其工具對小遊戲的适配和支援： Cocos Egret(白鹭) LayaBox Three.js 是一款運作在浏覽器中的 3D 引擎，你可以用它建立各種三維場景，包括了攝影機、光影、材質等各種對象 2D、3D、VR的支援 性能 從開發者的回報來說，Layabox本來就是面向大型遊戲的H5遊戲引擎，性能優勢是毋庸質疑的。 設計理念與定位 工作流支援力度 工具鍊的提供與支援也是一種選擇考量要素，比如UI編輯器、粒子編輯器、骨骼編輯器、場景編輯器等等，如果引擎方直接提供或支援，那麼将會較大的提升研發效率。Egret、Layabox、Cocos2d-JS這三個引擎在工具鍊方面提供足夠全面的支撐。 引擎的應用廣度 Egret成名比較早，發展得比較快，各方面的資源而比較多，提供了全套開發流工具。 用遊戲引擎的優點：開發快，可維護性高 用遊戲引擎的缺點：犧牲一些性能，小遊戲用不用引擎幾乎感受不到性能差異。大遊戲為了開發效率和可維護性，一般都會使用遊戲引擎。 小遊戲實戰總結 本次主要實作的是跳一跳小遊戲。遊戲大概如下： 跳一跳如何技術實作可以參考： 這篇文章 層級劃分 景物層：負責兩側樹葉裝飾的渲染，實作其無限循環滑動的動畫效果； 階梯層：負責階梯和機器人的渲染，實作階梯的随機生成與自動掉落階磚、機器人的操控； 背景層：負責背景底色的渲染，以及開始結束面闆渲染。 通過  requestAnimationFrame  循環調用一定次數來實作動畫效果。遊戲的邏輯通過監聽全局的  canvas  對象實作。 分層按順序疊加繪至畫布，先将背景繪上，通過算法計算出台階位置，結合上一次的位置用  requestAnimationFrame  實作移位生成新的台階，機器人單獨抽離出來的，沒有和台階一起實作，通過位置計算，得到機器人的位置，繪制字台階上，最後将頂層的樹葉繪制上。 小遊戲開發難點 首先，小遊戲使用JavaScript語言開發，不存在HTML，CSS，是以需要對JavaScript語言，Canvas對象操作熟練。 其次，和H5版遊戲開發差別并不大，但是小遊戲支援的庫較少，并且大部分H5版開發所使用的到的庫是不支援的。 還有，就是H5版遊戲的實作方式選擇性更多，比如跳一跳原版是使用  createjs  開發，而小遊戲版并不能支援所有的引擎，隻能通過上面的幾個引擎改造适配。 小遊戲優化 為什麼要優化？其實為了提高頁面加載速度，減少遊戲運作中的卡頓，使動畫看起來更流暢，遊戲的流暢程度及畫面直接影響了使用者體驗。 以下提供了幾個優化方案。 GC優化 小遊戲的優化文檔并未指出，在api中提供一個性能管理器，通過擷取性能管理器能夠調用 API 加快觸發 GC ，GC 時機是由 JavaScrpitCore / V8 來控制的，不能保證調用後馬上觸發 GC。 setData調用次數優化 小程式端，官方不建議頻繁調用  setData  ，大圖檔和長清單圖檔，都有可能導緻 iOS 用戶端記憶體占用上升，進而觸發系統回收小程式頁面。 減小代碼包 盡量減小代碼包的大小，代碼包直接影響了下載下傳速度，進而影響使用者的首次打開體驗。 控制圖檔資源 控制代碼包内圖檔資源，小程式代碼包經過編譯後，會放在微信的 CDN 上供使用者下載下傳，CDN 開啟了 GZIP 壓縮，是以使用者下載下傳的是壓縮後的 GZIP 包，其大小比代碼包原體積會更小。 但我們分析資料發現，不同小程式之間的代碼包壓縮比差異也挺大的，部分可以達到 30%，而部分隻有 80%，而造成這部分差異的一個原因，就是圖檔資源的使用。GZIP 對基于文本資源的壓縮效果最好，在壓縮較大檔案時往往可高達 70%-80% 的壓縮率，而如果對已經壓縮的資源（例如大多數的圖檔格式）則效果甚微。 清除無用資源 及時清理沒有使用到的代碼和資源，小程式打包是會将工程下所有檔案都打入代碼包内，也就是說，這些沒有被實際使用到的庫檔案和資源也會被打入到代碼包裡，進而影響到整體代碼包的大小。 fps調優 使用  requestAnimationFrame  實作動畫時，調整到合适的渲染fps(幀率)。 遇到的問題 圖檔尺寸問題？ 小遊戲中圖檔對尺寸限制在2048像素，長寬要小于等于2048像素。 對外開放？ 小遊戲對外沒有開放注冊入口，現在能使用的是前兩天在小程式中開放的遊戲類目，将小程式類别設定為遊戲類目可開發小遊戲，不确定以後是否以這種方式注冊，或者是單獨開放小遊戲的注冊入口，兩者目前沒發現有什麼差別。 官方目前沒有提供對外釋出，登入背景能夠點選釋出，但是需要上傳軟體著作權證書等一系列，是以沒有進行下去，不确定能否對外釋出成功。 關于小遊戲代碼體積大小？ 關于小遊戲體積問題，小遊戲的體積不得大于 4M，緩存不得大于 50M。 具體的解釋為：本地的代碼和資源不得超過 4M。單個小遊戲項目緩存的檔案不能超過 50M，目前當緩存超過 50M 時後續的資源将不會緩存，未來新版的 AssetsManager 将會允許開發者自定義哪些資源需要緩存的機制。不允許從伺服器下載下傳腳本檔案。 不允許動态執行代碼？ 不允許動态執行代碼的能力，  eval  、  setTimeout  和  setInterval  函數的第一個參數不能為字元串，  Function  構造函數的參數不能為字元串。