微信小游戲開(kāi)發(fā)總結(jié)
|
小游戲是小程序的一個(gè)類(lèi)目，小游戲是微信開(kāi)放給小程序的更多的能力，讓小程序開(kāi)發(fā)者有了開(kāi)發(fā)游戲的能力。小游戲沒(méi)有WXSS、WXML、多頁(yè)面等內(nèi)容，但加了一些渲染、文件系統(tǒng)以及后臺(tái)多線程的功能。 小游戲的運(yùn)行環(huán)境是小程序環(huán)境的擴(kuò)展，基本思路也是封裝必要的 WEB 接口提供給用戶(hù)，盡可能追求和 WEB 同樣的開(kāi)發(fā)體驗(yàn)。小游戲在小程序環(huán)境的基礎(chǔ)上提供了 WebGL 接口的封裝，使得渲染能力和性能有了大幅度提升。不過(guò)由于這些接口都是微信團(tuán)隊(duì)通過(guò)自研的原生實(shí)現(xiàn)封裝的，所以并不可以等同為瀏覽器環(huán)境。 小游戲的運(yùn)行環(huán)境在 iOS 上是 JavaScriptCore（ 注：webkit的一個(gè)重要組成部分，主要是對(duì)JS進(jìn)行解析和提供執(zhí)行環(huán)境。 ），在 Android 上是 V8 （這個(gè)不用多說(shuō)Node.js目前使用的就是V8）。但是兩個(gè)都沒(méi)有 BOM 和 DOM 的運(yùn)行環(huán)境，沒(méi)有全局的 document 和 window 對(duì)象。
小游戲 VS H5游戲 VS 小程序?qū)Ρ葓D 第三方代碼適配（Adapter）主要目的提供 BOM 和 DOM 的運(yùn)行環(huán)境。 由上圖可以看出，因?yàn)闆](méi)有 BOM 和 DOM 的運(yùn)行環(huán)境，沒(méi)有全局的 document 和 window 對(duì)象。為了讓基于瀏覽器環(huán)境（上圖的H5游戲）的第三方代碼更快地適配小游戲運(yùn)行環(huán)境，所以就有了適配器（Adapter）。它是用微信 API 模擬 BOM 和 DOM 的代碼組成的庫(kù)，抽象的代碼層，可以根據(jù)自己的需要去實(shí)現(xiàn)相關(guān)方法。 例如，簡(jiǎn)單實(shí)現(xiàn) document.creatElement 方法：
var document = {
createElement: function (tagName) {
tagName = tagName.toLowerCase()
if (tagName === 'canvas') {
return wx.createCanvas()
}
else if (tagName === 'image') {
return wx.createImage()
}
}
}
Adapter是否使用由開(kāi)發(fā)者自己決定。不使用Adapter時(shí)，可以通過(guò)微信提供的API實(shí)現(xiàn)相應(yīng)的方法，但不能使用 DOM API 來(lái)創(chuàng)建 Canvas 和 Image 等元素。 有的游戲引擎是直接調(diào)用DOM API，和訪問(wèn)DOM屬性 ，所以記得使用Adapter讓游戲引擎適配小游戲的運(yùn)行環(huán)境，保證游戲引擎在調(diào)用 DOM API 和訪問(wèn) DOM 屬性時(shí)不會(huì)產(chǎn)生錯(cuò)誤。 微信官方實(shí)現(xiàn)了一個(gè) weapp-adapter 小游戲適配器，但僅僅只針對(duì)游戲引擎可能訪問(wèn)的屬性和調(diào)用的方法進(jìn)行了模擬，也不保證所有游戲引擎都能通過(guò) weapp-adapter 能順利無(wú)縫接入小游戲。這里將 weapp-adapter 適配器提供給開(kāi)發(fā)者，更多地是讓開(kāi)發(fā)者作為參考，讓開(kāi)發(fā)者可以根據(jù)需要在 weapp-adapter 的基礎(chǔ)上進(jìn)行擴(kuò)展，以適配自己項(xiàng)目使用的游戲引擎。weapp-adapter 會(huì)預(yù)先調(diào)用 wx.createCanvas() 創(chuàng)建一個(gè)上屏 Canvas，并暴露為一個(gè)全局變量 canvas 。
require('./weapp-adapter');
var context = canvas.getContext('2d');
context.fillStyle = 'red';
context.fillRect(0, 0, 100, 100);
weapp-adapter 適配器提供了以下對(duì)象和方法：
其實(shí)官方文檔里面還有很多 ，感興趣可以查看官方 API文檔 。 小游戲的模塊化小游戲提供了 CommonJS 風(fēng)格的模塊 API，可以通過(guò) module.exports 和 exports 導(dǎo)出模塊，通過(guò) require 引入模塊。這里就不用多解釋了，其實(shí)大家按正常的編碼習(xí)慣編碼就可以了。
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'
}
所以小游戲?qū)幋a方面的基礎(chǔ)能力還是很友善的。 小游戲能力這里列出部分已提供的 API 能力，更詳細(xì)的能力及官方實(shí)例可訪問(wèn) API文檔 。
大家對(duì) Canvas 的優(yōu)化或者對(duì)離屏畫(huà)布不了解的可以看這篇文章 Canvas 最佳實(shí)踐（性能篇）。 小游戲引擎游戲引擎是指一些已編寫(xiě)好的可編輯電腦游戲系統(tǒng)或者一些交互式實(shí)時(shí)圖像應(yīng)用程序的核心組件。這些系統(tǒng)為游戲設(shè)計(jì)者提供各種編寫(xiě)游戲所需的各種工具，其目的在于讓游戲設(shè)計(jì)者能容易和快速地做出游戲程式而不用由零開(kāi)始。 Cocos、Egret、Laya 已經(jīng)完成了自身引擎及其工具對(duì)小游戲的適配和支持：
2D、3D、VR的支持
性能從開(kāi)發(fā)者的反饋來(lái)說(shuō)，Layabox本來(lái)就是面向大型游戲的H5游戲引擎，性能優(yōu)勢(shì)是毋庸質(zhì)疑的。
設(shè)計(jì)理念與定位
工作流支持力度工具鏈的提供與支持也是一種選擇考量要素，比如UI編輯器、粒子編輯器、骨骼編輯器、場(chǎng)景編輯器等等，如果引擎方直接提供或支持，那么將會(huì)較大的提升研發(fā)效率。Egret、Layabox、Cocos2d-JS這三個(gè)引擎在工具鏈方面提供足夠全面的支撐。 引擎的應(yīng)用廣度Egret成名比較早，發(fā)展得比較快，各方面的資源而比較多，提供了全套開(kāi)發(fā)流工具。
用游戲引擎的優(yōu)點(diǎn)：開(kāi)發(fā)快，可維護(hù)性高 用游戲引擎的缺點(diǎn)：犧牲一些性能，小游戲用不用引擎幾乎感受不到性能差異。大游戲?yàn)榱碎_(kāi)發(fā)效率和可維護(hù)性，一般都會(huì)使用游戲引擎。 小游戲?qū)崙?zhàn)總結(jié)本次主要實(shí)現(xiàn)的是跳一跳小游戲。游戲大概如下：
跳一跳如何技術(shù)實(shí)現(xiàn)可以參考： 這篇文章 層級(jí)劃分
通過(guò) requestAnimationFrame 循環(huán)調(diào)用一定次數(shù)來(lái)實(shí)現(xiàn)動(dòng)畫(huà)效果。游戲的邏輯通過(guò)監(jiān)聽(tīng)全局的 canvas 對(duì)象實(shí)現(xiàn)。 分層按順序疊加繪至畫(huà)布，先將背景繪上，通過(guò)算法計(jì)算出臺(tái)階位置，結(jié)合上一次的位置用 requestAnimationFrame 實(shí)現(xiàn)移位生成新的臺(tái)階，機(jī)器人單獨(dú)抽離出來(lái)的，沒(méi)有和臺(tái)階一起實(shí)現(xiàn)，通過(guò)位置計(jì)算，得到機(jī)器人的位置，繪制字臺(tái)階上，最后將頂層的樹(shù)葉繪制上。 小游戲開(kāi)發(fā)難點(diǎn)首先，小游戲使用JavaScript語(yǔ)言開(kāi)發(fā)，不存在HTML，CSS，所以需要對(duì)JavaScript語(yǔ)言，Canvas對(duì)象操作熟練。 其次，和H5版游戲開(kāi)發(fā)區(qū)別并不大，但是小游戲支持的庫(kù)較少，并且大部分H5版開(kāi)發(fā)所使用的到的庫(kù)是不支持的。 還有，就是H5版游戲的實(shí)現(xiàn)方式選擇性更多，比如跳一跳原版是使用 createjs 開(kāi)發(fā)，而小游戲版并不能支持所有的引擎，只能通過(guò)上面的幾個(gè)引擎改造適配。 小游戲優(yōu)化為什么要優(yōu)化？其實(shí)為了提高頁(yè)面加載速度，減少游戲運(yùn)行中的卡頓，使動(dòng)畫(huà)看起來(lái)更流暢，游戲的流暢程度及畫(huà)面直接影響了用戶(hù)體驗(yàn)。 以下提供了幾個(gè)優(yōu)化方案。 GC優(yōu)化小游戲的優(yōu)化文檔并未指出，在api中提供一個(gè)性能管理器，通過(guò)獲取性能管理器能夠調(diào)用 API 加快觸發(fā) GC ，GC 時(shí)機(jī)是由 JavaScrpitCore / V8 來(lái)控制的，不能保證調(diào)用后馬上觸發(fā) GC。 setData調(diào)用次數(shù)優(yōu)化小程序端，官方不建議頻繁調(diào)用 setData ，大圖片和長(zhǎng)列表圖片，都有可能導(dǎo)致 iOS 客戶(hù)端內(nèi)存占用上升，從而觸發(fā)系統(tǒng)回收小程序頁(yè)面。 減小代碼包盡量減小代碼包的大小，代碼包直接影響了下載速度，從而影響用戶(hù)的首次打開(kāi)體驗(yàn)。 控制圖片資源控制代碼包內(nèi)圖片資源，小程序代碼包經(jīng)過(guò)編譯后，會(huì)放在微信的 CDN 上供用戶(hù)下載，CDN 開(kāi)啟了 GZIP 壓縮，所以用戶(hù)下載的是壓縮后的 GZIP 包，其大小比代碼包原體積會(huì)更小。 但我們分析數(shù)據(jù)發(fā)現(xiàn)，不同小程序之間的代碼包壓縮比差異也挺大的，部分可以達(dá)到 30%，而部分只有 80%，而造成這部分差異的一個(gè)原因，就是圖片資源的使用。GZIP 對(duì)基于文本資源的壓縮效果最好，在壓縮較大文件時(shí)往往可高達(dá) 70%-80% 的壓縮率，而如果對(duì)已經(jīng)壓縮的資源（例如大多數(shù)的圖片格式）則效果甚微。 清除無(wú)用資源及時(shí)清理沒(méi)有使用到的代碼和資源，小程序打包是會(huì)將工程下所有文件都打入代碼包內(nèi)，也就是說(shuō)，這些沒(méi)有被實(shí)際使用到的庫(kù)文件和資源也會(huì)被打入到代碼包里，從而影響到整體代碼包的大小。 fps調(diào)優(yōu)使用 requestAnimationFrame 實(shí)現(xiàn)動(dòng)畫(huà)時(shí)，調(diào)整到合適的渲染fps(幀率)。 遇到的問(wèn)題圖片尺寸問(wèn)題？小游戲中圖片對(duì)尺寸限制在2048像素，長(zhǎng)寬要小于等于2048像素。
對(duì)外開(kāi)放？小游戲?qū)ν鉀](méi)有開(kāi)放注冊(cè)入口，現(xiàn)在能使用的是前兩天在小程序中開(kāi)放的游戲類(lèi)目，將小程序類(lèi)別設(shè)定為游戲類(lèi)目可開(kāi)發(fā)小游戲，不確定以后是否以這種方式注冊(cè)，或者是單獨(dú)開(kāi)放小游戲的注冊(cè)入口，兩者目前沒(méi)發(fā)現(xiàn)有什么區(qū)別。 官方目前沒(méi)有提供對(duì)外發(fā)布，登錄后臺(tái)能夠點(diǎn)擊發(fā)布，但是需要上傳軟件著作權(quán)證書(shū)等一系列，所以沒(méi)有進(jìn)行下去，不確定能否對(duì)外發(fā)布成功。
關(guān)于小游戲代碼體積大??？關(guān)于小游戲體積問(wèn)題，小游戲的體積不得大于 4M，緩存不得大于 50M。 具體的解釋為：本地的代碼和資源不得超過(guò) 4M。單個(gè)小游戲項(xiàng)目緩存的文件不能超過(guò) 50M，目前當(dāng)緩存超過(guò) 50M 時(shí)后續(xù)的資源將不會(huì)緩存，未來(lái)新版的 AssetsManager 將會(huì)允許開(kāi)發(fā)者自定義哪些資源需要緩存的機(jī)制。不允許從服務(wù)器下載腳本文件。 不允許動(dòng)態(tài)執(zhí)行代碼？不允許動(dòng)態(tài)執(zhí)行代碼的能力， eval 、 setTimeout 和 setInterval 函數(shù)的第一個(gè)參數(shù)不能為字符串， Function 構(gòu)造函數(shù)的參數(shù)不能為字符串。 |
