欢迎关注富途web开发团队,缺人从众html
原文连接:查看git
小游戏是小程序的一个类目,小游戏是微信开放给小程序的更多的能力,让小程序开发者有了开发游戏的能力。小游戏没有WXSS、WXML、多页面等内容,但加了一些渲染、文件系统以及后台多线程的功能。github
小游戏的运行环境是小程序环境的扩展,基本思路也是封装必要的 WEB 接口提供给用户,尽量追求和 WEB 一样的开发体验。小游戏在小程序环境的基础上提供了 WebGL 接口的封装,使得渲染能力和性能有了大幅度提高。不过因为这些接口都是微信团队经过自研的原生实现封装的,因此并不能够等同为浏览器环境。web
小游戏的运行环境在 iOS 上是 JavaScriptCore(注:webkit的一个重要组成部分,主要是对JS进行解析和提供执行环境。),在 Android 上是 V8 (这个不用多说Node.js目前使用的就是V8)。可是两个都没有 BOM 和 DOM 的运行环境,没有全局的 document
和 window
对象。算法
小游戏 VS H5游戏 VS 小程序对比图canvas
主要目的提供 BOM 和 DOM 的运行环境。小程序
由上图能够看出,由于没有 BOM 和 DOM 的运行环境,没有全局的 document
和 window
对象。为了让基于浏览器环境(上图的H5游戏)的第三方代码更快地适配小游戏运行环境,因此就有了适配器(Adapter)。它是用微信 API 模拟 BOM 和 DOM 的代码组成的库,抽象的代码层,能够根据本身的须要去实现相关方法。api
例如,简单实现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 适配器提供了如下对象和方法:
其实官方文档里面还有不少 ,感兴趣能够查看官方 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 已经完成了自身引擎及其工具对小游戏的适配和支持:
从开发者的反馈来讲,Layabox原本就是面向大型游戏的H5游戏引擎,性能优点是毋庸质疑的。
工具链的提供与支持也是一种选择考量要素,好比UI编辑器、粒子编辑器、骨骼编辑器、场景编辑器等等,若是引擎方直接提供或支持,那么将会较大的提高研发效率。Egret、Layabox、Cocos2d-JS这三个引擎在工具链方面提供足够全面的支撑。
Egret成名比较早,发展得比较快,各方面的资源而比较多,提供了全套开发流工具。
用游戏引擎的优势:开发快,可维护性高
用游戏引擎的缺点:牺牲一些性能,小游戏用不用引擎几乎感觉不到性能差别。大游戏为了开发效率和可维护性,通常都会使用游戏引擎。
本次主要实现的是跳一跳小游戏。游戏大概以下:
跳一跳如何技术实现能够参考:这篇文章
经过requestAnimationFrame
循环调用必定次数来实现动画效果。游戏的逻辑经过监听全局的canvas
对象实现。
分层按顺序叠加绘至画布,先将背景绘上,经过算法计算出台阶位置,结合上一次的位置用requestAnimationFrame
实现移位生成新的台阶,机器人单独抽离出来的,没有和台阶一块儿实现,经过位置计算,获得机器人的位置,绘制字台阶上,最后将顶层的树叶绘制上。
首先,小游戏使用JavaScript语言开发,不存在HTML,CSS,因此须要对JavaScript语言,Canvas对象操做熟练。
其次,和H5版游戏开发区别并不大,可是小游戏支持的库较少,而且大部分H5版开发所使用的到的库是不支持的。
还有,就是H5版游戏的实现方式选择性更多,好比跳一跳原版是使用createjs
开发,而小游戏版并不能支持全部的引擎,只能经过上面的几个引擎改造适配。
为何要优化? 其实为了提升页面加载速度,减小游戏运行中的卡顿,使动画看起来更流畅,游戏的流畅程度及画面直接影响了用户体验。
如下提供了几个优化方案。
小游戏的优化文档并未指出,在api中提供一个性能管理器,经过获取性能管理器可以调用 API 加快触发 GC ,GC 时机是由 JavaScrpitCore / V8 来控制的,不能保证调用后立刻触发 GC。
小程序端,官方不建议频繁调用 setData
,大图片和长列表图片,都有可能致使 iOS 客户端内存占用上升,从而触发系统回收小程序页面。
尽可能减少代码包的大小,代码包直接影响了下载速度,从而影响用户的首次打开体验。
控制代码包内图片资源,小程序代码包通过编译后,会放在微信的 CDN 上供用户下载,CDN 开启了 GZIP 压缩,因此用户下载的是压缩后的 GZIP 包,其大小比代码包原体积会更小。 但咱们分析数据发现,不一样小程序之间的代码包压缩比差别也挺大的,部分能够达到 30%,而部分只有 80%,而形成这部分差别的一个缘由,就是图片资源的使用。GZIP 对基于文本资源的压缩效果最好,在压缩较大文件时每每可高达 70%-80% 的压缩率,而若是对已经压缩的资源(例如大多数的图片格式)则效果甚微。
及时清理没有使用到的代码和资源,小程序打包是会将工程下全部文件都打入代码包内,也就是说,这些没有被实际使用到的库文件和资源也会被打入到代码包里,从而影响到总体代码包的大小。
使用 requestAnimationFrame
实现动画时,调整到合适的渲染fps(帧率)。
小游戏中图片对尺寸限制在2048像素,长宽要小于等于2048像素。
小游戏对外没有开放注册入口,如今能使用的是前两天在小程序中开放的游戏类目,将小程序类别设定为游戏类目可开发小游戏,不肯定之后是否以这种方式注册,或者是单独开放小游戏的注册入口,二者目前没发现有什么区别。
官方目前没有提供对外发布,登陆后台可以点击发布,可是须要上传软件著做权证书等一系列,因此没有进行下去,不肯定可否对外发布成功。
关于小游戏体积问题,小游戏的体积不得大于 4M,缓存不得大于 50M。 具体的解释为:本地的代码和资源不得超过 4M。单个小游戏项目缓存的文件不能超过 50M,目前当缓存超过 50M 时后续的资源将不会缓存,将来新版的 AssetsManager 将会容许开发者自定义哪些资源须要缓存的机制。不容许从服务器下载脚本文件。
不容许动态执行代码的能力,eval
、setTimeout
和 setInterval
函数的第一个参数不能为字符串,Function
构造函数的参数不能为字符串。
游戏逻辑没处理好,动画有点不流畅,有延时问题。