歡迎關注富途web開發團隊，缺人從眾
原文連結：檢視
小遊戲與小程式的區別？
小遊戲是小程式的一個類目，小遊戲是微信開放給小程式的更多的能力，讓小程式開發者有了開發遊戲的能力。小遊戲沒有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(0, 0, 100, 100);
複製程式碼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 已經完成了自身引擎及其工具對小遊戲的適配和支援：
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建構函式的引數不能為字串。
開發問題
遊戲邏輯沒處理好，動畫有點不流暢，有延時問題。