上期我们只实现了小鸟飞行以及障碍物地图随机生成、绘制和滚动，这期我们要完成整个游戏的大体框架，即游戏运行的主体部分，而其他的比如计分，重新开始等不会去实现。文章最后会讲一些个人心得。
本期内容依旧是在微信小游戏上进行实现的。由于内容以及代码都承接以前文章，如果你没有阅读过，可以从这里开始。
本文不允许任何形式的转载！
阅读提示
本系列文章不适合以下人群阅读，如果你无意点开此文，请对号入座，以免浪费你宝贵的时间。
- 想要学习利用游戏引擎开发游戏的朋友。本文不会涉及任何第三方游戏引擎。
- 不具备面向对象编程经验的朋友。本文的语言主要是Javascript(ECMA 2016)，如果你不具备JS编程经验倒也无妨，但没有面向对象程序语言经验就不好办了。
关注我的微信公众号，回复“源代码4”可获得本文示例代码下载地址，谢谢各位了！
最基础的碰撞判定
为什么要加上一个“最基础的”呢，因为二维图形碰撞（Collision）一般分为Bounds接触判定（可能会碰撞）和最终碰撞判定（多边形到底是否有接触），比如下图：
首先说下Bounds是什么。我们可以认为Bounds就是一个区域，通常我们都以一个矩形作为Bounds，但有时候可能会是其他形状。就上图而言，我们的Bounds是一个矩形，并且是和XY轴平行的，这种Bounds我们成为Axis-aligned bounding boxes，简称AABB（下文提到的Bounds都是这个AABB）。一般只需要知道这个矩形的左上角和右下角两个点的位置，就能通过计算得知两个Bounds是否接触。
通常来说我们称左上角为min，右下角为max，意为该Bounds最小的点和最大的点。而我们接下来用的是[left,top],[right,bottom]分别来表示最小点和最大点的坐标。
怎么判断两个Bounds没有接触呢：
设两个不同的Bounds A和B，如果其中一个的left比另外一个的right大，或者它的top比另一个的bottom大，则我们认为 A没有和B接触。反之，判断两个Bounds是否接触的代码如下：
function overlaps(boundsA,boundsB){
if(boundsA.left > boundsB.right
|| boundsA.top > boundsB.bottom){
return false;
}
if(boundsB.left > boundsA.right
|| boundsB.top > boundsA.bottom){
return false;
}
return true;
}
简化一下上面代码：
function overlaps(boundsA, boundsB) {
return (boundsA.left <= boundsB.right && boundsA.right >= boundsB.left
&& boundsA.bottom >= boundsB.top && boundsA.top <= boundsB.bottom);
}
我就问一下，你觉得哪段代码好？我选第二个。
回到我们的游戏中，为了简化，我们认为只要树干和小鸟的Bounds接触上，就算碰撞。
那小鸟和树干的Bounds怎么得到呢。
Figure类的第1次迭代
综上，我们知道了什么是Bounds，而且注意到，要判断两个Bounds是否接触，必要条件是这两个Bounds必须在同一个坐标系下。
我们设计的Figure类具有left，top，width和height，可以用这几个属性来表示所在区域，所以我们的Figure的Bounds的最小坐标点就是[left,top]，最大坐标点就是[left+width,top+height]，为了便于代码阅读和简化编码，我们给Figure加上两个属性right，bottom以及一个getBounds方法:
Figure.js :
...
getBounds() {
return {
left: this.left, top: this.top,
right: this.right, bottom: this.bottom
};
}
get right() {
return this.left + this.width;
}
get bottom() {
return this.top + this.height;
}
...
如果你对Figure类第0次迭代这篇文章还有印象的话，就应该知道Figure的left和top是相对其父节点的坐标系的，所以Figure的bounds不应该这么简单地计算！比如一个Figure A的子Figure C和另一个Figure B中的子Figure D进行bounds碰撞测试，如果按照上面的代码得到的bounds来判断的话肯定是错了，坐标系都不同比较个卵。
所以我们说bounds首先是有一个相对性的，就我们的游戏而言，要判断小鸟和树桩是否碰撞，就应该获得它们相对于顶层Graph的bounds值，然后再进行判断。幸运的是小鸟和树桩（应该说是障碍地图）正好是Graph的子节点，所以上述代码正好得到它们相对于Graph的bounds，直接判断就好了。
除了相对坐标系的问题，Figure的bounds还应该要考虑到自身的旋转和拉伸，这都会影响到Bounds值，更幸运的是，我们目前这个游戏中小鸟和树桩都没有旋转和拉伸。如何计算旋转和拉伸后的Bounds我会在以后讲到变换矩阵的时候再说，先提示一下各位免得产生误会。
小鸟的Bounds还好说，就刚才代码即可获得，但是TileMap的怎么办？它的Bounds是整个地图的区域，跟树干没关系呀，这里我们就只能是特例特办了，通过TileMap的地图数据来计算地图中所有树干的Bounds。
先看下之前TileMap的drawSelf方法：
drawSelf(ctx) {
let imageManager = ImageManager.getInstance();
let trunk1 = imageManager.getImage('trunk1');
let trunk2 = imageManager.getImage('trunk2');
let trunk3 = imageManager.getImage('trunk3');
let startX = 0;
let startY = 0;
// 一列一列画：
for (let i = 0; i < this.mapData.mapData.length; i++) {
startY = 0;//每一列的y轴坐标都是从0开始
// 先计算出每一列绘制的起始x轴的值：
if (i != 0) {
// 从第二列开始就要计算了，第一列是0
startX += this.trunkWidth;// 第n列比第n-1列绝对多出一个宽度
// 再加上它们之间的间隔：
startX += this.mapData.spaceData[i-1] * this.trunkWidth;
}
// 某一列的地图数据：
let datas = this.mapData.mapData[i];
for (let j = 0; j < datas.length; j++) {
let data = datas[j];
let image = undefined;
switch (data) {
case 1:
image = trunk2;
break;
case 2:
image = trunk3;
break;
case 3:
image = trunk1;
break;
}
// 如果image为空，即地图数据为0，此处是个空白处就不需要绘制
if (image) {
ctx.drawImage(image, startX, startY, this.trunkWidth, this.trunkHeight);
}
// 画好一个就往下y坐标往下移动一个树桩高度
startY += this.trunkHeight;
}
}
}
它是通过地图数据在drawSelf中计算出树桩的位置和类型，然后绘制上去。正好，我们的树桩bounds计算跟这段代码几乎一样，那我们就可以利用这段代码来计算出树桩bounds了。
为了不重复计算，我们可以在生成地图数据的时候就计算出树桩的bounds数据，然后在绘制的时候直接使用即可，无需二次计算。所以我更改了TileMap的代码，你可以拿去和以前的比较一下：
import Figure from "./Figure";
import MapGenerator from "./MapGenerator";
import ImageManager from "./utils/ImageManager";
export default class TileMap extends Figure {
constructor(p) {
super(p);
this.mapData = undefined;
this.trunkHeight = 0; // 单个树桩的高度
this.trunkWidth = 0; // 单个树桩的宽度
this.column = 0;
this.row = 0;
this.boundsArray = []; // 地图中树桩的Bounds数据数组
}
initMap() {
if (this.mapData != undefined) {
MapGenerator.generateMapData(this.mapData);
} else {
this.mapData = MapGenerator.generateMapData(this.mapData, this.column, this.row);
}
// 根据map数据来设置Map的高度和宽度：
this.height = this.mapData.row * this.trunkHeight;
this.width = this.mapData.column * this.trunkWidth;
// 还要加上每列树桩之间的间隔：
for (let i = 0; i < this.mapData.spaceData.length; i++) {
this.width += this.mapData.spaceData[i] * this.trunkWidth;
}
// 生成树桩的bounds数据：
this.calculateTrunkBounds();
}
calculateTrunkBounds() {
let boundsArray = this.boundsArray;
boundsArray.length = 0;// 先清空
let startX = 0;
let startY = 0;
for (let i = 0; i < this.mapData.mapData.length; i++) {
startY = 0;//每一列的y轴坐标都是从0开始
// 先计算出每一列绘制的起始x轴的值：
if (i != 0) {
// 从第二列开始就要计算了，第一列是0
startX += this.trunkWidth;// 第n列比第n-1列绝对多出一个宽度
// 再加上它们之间的间隔：
startX += this.mapData.spaceData[i - 1] * this.trunkWidth;
}
// 某一列的地图数据：
let datas = this.mapData.mapData[i];
for (let j = 0; j < datas.length; j++) {
let data = datas[j];
if (data != 0) {
// 跳过缺口区域, bounds里还多了一个data属性
// 这是为了绘制的时候不必再从mapData里取数据判断树桩image了
boundsArray.push({
left: startX,
top: startY,
right: startX + this.trunkWidth,
bottom: startY + this.trunkHeight,
data: data
});
}
// y坐标往下移动一个树桩高度
startY += this.trunkHeight;
}
}
}
getTrunkBoundsArray() {
return this.boundsArray;
}
drawSelf(ctx) {
let imageManager = ImageManager.getInstance();
let trunk1 = imageManager.getImage('trunk1');
let trunk2 = imageManager.getImage('trunk2');
let trunk3 = imageManager.getImage('trunk3');
let trunkDatas = this.getTrunkBoundsArray();
for(let i = 0 ; i < trunkDatas.length;i++){
let trunkData = trunkDatas[i];
let image = undefined;
switch (trunkData.data) {
case 1:
image = trunk2;
break;
case 2:
image = trunk3;
break;
case 3:
image = trunk1;
break;
}
if (image) {
ctx.drawImage(image, trunkData.left, trunkData.top,
this.trunkWidth, this.trunkHeight);
}
}
}
}
新的TileMap类中增加了一个calculateTrunkBounds方法，和一个getTrunkBoundsArray方法。在我们生成地图的时候就开始计算Bounds，然后绘制的时候直接就使用了。
请注意！！，树桩的Bounds目前并不是相对Graph的，而是相对于其所在地图的，这是因为计算bounds的方法只在生成地图的时候被调用，而这时候的地图坐标和需要计算碰撞时候的坐标是不同的，所以只能先算出树桩相对地图的bounds，然后再在需要进行碰撞测试的时候加上地图的left和top来获取其相对Graph的bounds。
便于测试，我把小鸟和树桩的bounds都绘制成了红色边框，得到如下结果：
注意看，小鸟的bounds实际上有点过大了，因为整个小鸟并没有占满整个Figure的区域，所以在测试碰撞的时候我们要可以缩小一下他的Bounds区域，不然小鸟背部根本没接触到树干还判定为碰撞就不好了。比如这么大，我觉得就挺合适了。
有一种碰撞判定叫做 像素碰撞，即查看两个图片数据中是否有不全透明的像素点重合，我觉得好麻烦啊，这种判断难道不会很慢吗
最后我们就需要在BirdFlyGame里加入碰撞判定代码，一旦碰撞上游戏就结束：
BirdFlyGame.js部分代码：
....
afterRefresh(refreshCount) {
if(!this.gameOver){
this.collisionTest();
}
}
collisionTest() {
// 小鸟bounds：
let birdBounds = this.bird.getBounds();
let scaleW = this.bird.width * 0.2;
let scaleH = this.bird.height * 0.2;
// 让bounds缩小点
let a = {
left: birdBounds.left + scaleW,
top: birdBounds.top + scaleH,
right: birdBounds.left + (this.bird.width - scaleW),
bottom: birdBounds.top + (this.bird.height - scaleH)
};
let that = this;
collisionTrunkTest(this.firstMap);
collisionTrunkTest(this.secondMap);
function collisionTrunkTest(map){
let firstBounds = map.getTrunkBoundsArray();
for (let i = 0; i < firstBounds.length; i++) {
let bounds = firstBounds[i];
// bounds是相对地图的，需要加上它在Graph的位置
// 以此来获得树桩相对于Graph的Bounds
let b = {
left: bounds.left + map.left,
top: bounds.top + map.top,
right: bounds.right + map.left,
bottom: bounds.bottom + map.top
};
if(BirdFlyGame.overlaps(a,b)){
that.processGameOver();
return;
}
}
}
}
processGameOver(){
this.gameOver = true;
this.gameStop();
console.log('game over');
}
static overlaps(bounds1, bounds2) {
let a = bounds1;
let b = bounds2;
return (a.left <= b.right && a.right >= b.left
&& a.bottom >= b.top && a.top <= b.bottom);
}
下面是测试结果，一旦小鸟的红色框碰到树干的，游戏就停止了。
我们就可以在processGameOver里做一些操作，比如显示飞行距离、时间、重来一次按钮等。
性能优化
1.去掉不必要的绘制
如果Figure没有在Graph的显示范围内（即屏幕里面），其实是没必要绘制的。
而我们的地图却不是。第一张地图和第二张地图同时往左移动，在第二张地图实际上还没有进入到Graph的区域的时候，我们却依然在绘制它，并且TileMap类还是一个要绘制大量图片的类，这就让效率降低了不少。
如果我们提前判断出Figure不在父节点的区域内的话，就不要绘制它。所以我们可以在Figure类的drawChildren方法中进行一次Bounds碰撞判断，发现子Figure没有和父Figure所在显示区域接触，就不绘制：
drawChildren(ctx) {
for (let i = 0; i < this.children.length; i++) {
let childFigure = this.children[i];
// bounds碰撞判定基于Figure坐标系
// 所以Figure显示区域的bounds左上角就是[0,0]
let displayBounds = {left:0,top:0,
right:this.width,bottom:this.height};
if(!Utils.overlaps(displayBounds,childFigure.getBounds())){
continue;
}
childFigure.draw(ctx);
}
}
这个解决了整个Figure在父节点区域外会进行绘制的问题。不过TileMap类却要绘制大量树桩，而且有很多树桩都是在显示区域外的，就如上图所示，蓝色背景的地图中，有一部分还是在屏幕外的。
这个也好解决，我们在TileMap的drawSelf中，通过树桩的Bounds来跟Graph的显示区域Bounds做碰撞测试，没有接触的就不绘制：
drawSelf(ctx) {
let imageManager = ImageManager.getInstance();
let trunk1 = imageManager.getImage('trunk1');
let trunk2 = imageManager.getImage('trunk2');
let trunk3 = imageManager.getImage('trunk3');
let trunkDatas = this.getTrunkBoundsArray();
let graph = this.getGraph();
let graphDisplayBounds = {
left: 0, top: 0,
right: graph.width,
bottom: graph.height
};
for (let i = 0; i < trunkDatas.length; i++) {
let trunkData = trunkDatas[i];
let image = undefined;
// 找到树桩对应graph坐标系的Bounds
let absoluteBounds = {
left: trunkData.left + this.left, top: trunkData.top + this.top,
right: trunkData.right + this.left, bottom: trunkData.bottom + this.top
};
// 不在显示区域就跳过这一个（如果像之前是个二维数组就好了，直接可以跳过一列）
if(!Utils.overlaps(absoluteBounds,graphDisplayBounds)){
continue;
}
switch (trunkData.data) {
case 1:
image = trunk2;
break;
case 2:
image = trunk3;
break;
case 3:
image = trunk1;
break;
}
if (image) {
ctx.drawImage(image, trunkData.left, trunkData.top,
this.trunkWidth, this.trunkHeight);
}
}
}
不要小看只是少画了一些图片，性能会提升很多的。再次提醒各位，用CanvasRenderingContext2D绘图是很慢的，能改进的地方就改进，提升一点是一点，否则一旦把程序搬到移动设备上就会卡得出奇。
下图是性能测试的结果，CPU 2 x slowdown，大约录值了6秒，不太准。
2.取消不必要的碰撞测试
在测试小鸟和树干碰撞的时候，我们的代码如下：
collisionTrunkTest(this.firstMap);
collisionTrunkTest(this.secondMap);
是将两张地图的所有树桩Bounds和小鸟的Bounds进行测试，就如上面优化绘制遇到的问题一样，很多树桩位置根本就没进入屏幕，这种碰撞测试就是无意义的。
更进一步来说，如果地图没有进入到小鸟可能在的位置区域，就没必要进行测试，如下图所示：
如果还要细分的话就需要改造之前生成的树桩Bounds数据结构，目前我把所有树桩的Bounds放到了一个数组中，可以把它改成一个二维数据结构：
之前存放的数据是这样的：
一维数组，每个数据表示树桩的Bounds(data是之前为了判断树桩类型保留下来的一个属性)：
[{left:数字,top:数字,right:数字,bottom:数字,data:数字} , ........]
可以改造成：
[
..........
// 某一列树桩bounds数据：
{
trunkBounds : [{left,top,right,bottom,data} , ........]
}
..........
]
目前测试方法是遍历一维数组。改造后虽然也要遍历一遍，但是由于分成了“列”，如果某列第一个不在测试范围，则整列就跳过。这里我只提一下，就不改造原来的数据结构了。
此外，如果某个树桩没有进入小鸟碰撞区域，并且在该区域右侧，那么这个树桩往后的所有树桩都没有进入该区域，不需要测试碰撞：
BirdFlyGame.js ，修改碰撞测试方法：
collisionTest() {
// 小鸟bounds：
let birdBounds = this.bird.getBounds();
let scaleW = this.bird.width * 0.2;
let scaleH = this.bird.height * 0.2;
// 让bounds缩小点
let a = {
left: birdBounds.left + scaleW,
top: birdBounds.top + scaleH,
right: birdBounds.left + (this.bird.width - scaleW),
bottom: birdBounds.top + (this.bird.height - scaleH)
};
let that = this;
// 小鸟可能出现的区域bounds
let birdDisplayBounds = {
left : a.left,
right:a.right,
top:0,
bottom:this.height
};
collisionTrunkTest(this.firstMap);
collisionTrunkTest(this.secondMap);
function collisionTrunkTest(map){
if(!Utils.overlaps(map.getBounds(),birdDisplayBounds)){
// 如果地图没有进入小鸟出现区域，则不测试
return;
}
let firstBounds = map.getTrunkBoundsArray();
for (let i = 0; i < firstBounds.length; i++) {
let bounds = firstBounds[i];
// bounds是相对地图的，需要加上它在Graph的位置
// 以此来获得树桩相对于Graph的Bounds
let b = {
left: bounds.left + map.left,
top: bounds.top + map.top,
right: bounds.right + map.left,
bottom: bounds.bottom + map.top
};
if(Utils.overlaps(a,b)){
that.processGameOver();
return;
}else{
// 树桩和小鸟的bounds没有接触，看一下该bounds是否在小鸟bounds的右侧
// 如果是，则跳过剩余树桩的碰撞测试
if( b.left > a.right ) {
break;
}
}
}
}
}
上面我提到，如果树桩bounds在小鸟右侧并没接触上则跳过剩余的树桩。那如果树桩bounds如果在小鸟左侧也没接触上，那该树桩之前的树桩也是没必要测试碰撞的，但是我们是遍历一个数组，逐个进行比较，且数组里的Bounds数据的left是从左至右的（从小到大），所以刚才说的那个就不好实现。
小结
我们的游戏主体框架就已经全部完成了，即小鸟可以控制飞行，地图可能随机生成并能滚轴移动，可以进行碰撞测试等，并且我们还进行了一些优化，游戏其余的部分：加入音效和背景音乐，游戏结束后计分，游戏开始的界面，游戏结束的界面，这些的工作量其实不比之前做游戏主框架少，甚至更多，所以我就不一一讲述了，毕竟我很懒。
至此《老脸教你做游戏》就告一段落了（实际上我想写的是《老脸教你做游戏引擎》，后来我想了想，还是要点脸吧）。
如果有下期，那应该会是讲质点运动模拟，有缘的话我们会再见的。
再次感谢您的阅读！
如果你已经强打精神看到此处，说明我们有缘。我怕以后不更新blog没机会写，所以在最后我讲讲一些我觉得挺有用的东西。
图形区域划分
用过数据库吗？没用过没关系。数据库可以建立索引，便于快速定位到某个数据。
我们在未优化测试碰撞的方法中，采用了全局遍历，即用图形A和所有其他图形进行碰撞测试，这是很慢的。如果我们能快速定位到图形A和它附近的图形的话，就没必要进行全局测试了。
所以几乎所有游戏引擎都会对图形进行区域划分，就拿目前的游戏为例：
我们可以把整个屏幕划分成n个区域，每当有新的图形加入就计算出该图形的Bounds在哪个区域，并把该图形放到区域里图形数组里，如果图形发生变换（移动、缩放、旋转），重新计算图形所在区域并更新，这就相当于数据库里建立索引。写段伪代码：
function onNewFigureAdded(figure){
updateFigureArea(figure);
}
function onFigureTransformChanged(figure){
updateFigureArea(figure);
}
function updateFigureArea(figure){
// 得到figure对应区域数组
let areas = findFigureAreas(figure);
// 清空figure维护的area数组
while(figure.areaArray.length !=0){
let areaId = figure.areaArray.pop();
let area = getArea(areaId);
area.remove(figure.id);
}
figure.areaArray.length = 0;// 清空figure所在区域id数组
// 重新设置一遍
while(areas.length !=0){
let area = areas.pop();
figure.areaArray.push(area.id);
area.add(figure.id);
}
}
伪代码，不要较真，是这个意思就可以了
这样一来，如果我想知道小鸟所在区域有哪些些的图形，就可以这样：
let otherFigures = [];
for(let i = 0 ; i < bird.areaArray.length; i++){
let area = getArea(bird.areaArray[i]);
copyAll(otherFigures,area.figures);
}
比如想要进行碰撞测试，就不再需要全局比较了，从小鸟所在区域内取出其他图形和小鸟Bounds进行测试即可。
上面例子里的区域是一个固定网格形状的，这种区域划分叫做全局网格（Uniform Grid），是二维中较为简单的区域划分方式，二维游戏引擎常用区域划分还有四叉树（Quadtrees）等，三维的就有BSD等。不管怎么去划分吧，目的就一个，快速定位图形，减少不必要的操作，我们所讲的这个游戏碰撞测试还是很简单的，如果是复杂的碰撞测试，那就会花费很多时间。一帧16毫秒是特别宝贵的，不要浪费在一些无谓的操作上。
当然，选择哪种划分方式还要看区域更新复不复杂，太复杂了也不行，本末倒置了。
下图是我做的刚体运动模拟的网格区域划分测试：
devicePixelRatio
devicePixelRatio顾名思义，设备分辨比。
这个是DOM中windows对象的一个属性，微信小游戏里是通过SystemInfo获取的：
let systemInfo = wx.getSystemInfoSync();
let scale = systemInfo.pixelRatio;
比如你绘制一个图片在canvas上，你可能会发现在手机上比PC上模糊（像素化），这是因为devicePixelRatio的值不为1。
这个属性值的意思是说，当前显示设备的物理像素分辨率和CSS像素分辨率的比值，可以这么理解：一个CSS像素等于多少个物理像素大小，即需要多少个当前设备屏幕像素绘制一个CSS像素。
假设devicePixedlRatio为3.5的话，你绘制出来的图片在设备上显示跟实际屏幕像素就差了3.5倍，所以看着就模糊了。
所以在你用canvas绘制之前需要通过devicePixelRatio的值重新设置canvas在内存里大小：
let scale = windows.devicePixelRatio;
canvas.width *= scale;
cavans.height *= scale;
让canvas的内存大小变成之前的devicePixeloRatio倍，而且canvas的显示大小不要改变：
let scale = windows.devicePixelRatio;
canvas.style.width = canvas.width;// 微信小游戏没有style
cavnas.style.height = canvas.height;
canvas.width *= scale;
cavans.height *= scale;
而通常我们写代码的时候图形的大小都是根据canvas大小来设定的，而且是在canvas内存大小改变之前，所以如果你在代码中一直沿用了为改变内存大小的canvas长宽，那就还需要将context放大相应的倍数：
// 之前这么写的
let myFigure.width = canvas.width;
myFigure.draw();
.....
// 后来才改的内存大小
let scale = windows.devicePixelRatio;
canvas.style.width = canvas.width; // 微信小游戏没有style
cavnas.style.height = canvas.height;
canvas.width *= scale;
cavans.height *= scale;
// 那就让ctx放大scale倍
let ctx = canvas.getContext('2d');
ctx.scale(scale,scale);
这样就不会出现模糊的情况了。
图片尽量放在一起
我们绘制的图片经常都是一张一张的，实际上这样不好，尽量把他们都合到一张图片上，指定好source bounds然后绘制。
这样做一方面是为了节约空间，另一方面是为了方便加载，另外我在做webgl的时候，为了统一绘制，会将多个图片合并到一个texture中，但是不管怎么做都无法让这些图片铺满一个大的空间的，往往会生成多个texture（这也跟我的算法有关）。如果一开始要绘制的图片就是一个大的图片，就不需要来回切换了，一次性就能绘制成功。
建立对象池
如果游戏程序中会频繁生成新的图形对象，请建一个对象池，便于复用。
好多人说对象池的目的是为了减少创建对象时的开销，个人认为这是一方面。另外一方面是为了给GC省时间，太多的对象需要清扫的话GC花的时间很长，以至于出现游戏玩着玩着突然卡一下。
context 2d的clip方法少用为妙
这个方法我再web上倒没有发现问题，可是在微信小游戏里出现了性能爆降的情况。我觉得是微信小游戏的bug，于是在他们论坛提交了，不过过了很久都无人回复，我觉得很有可能是我自己代码烂造成的，于是就默默把提交的bug删了。
这是代码片段导入链接，试试在你的手机上卡不卡：
https://developers.weixin.qq.com/s/AQNhhimW7A4s
context 2d在移动端只适合简单的图形和游戏
我之前做了个打泡泡的微信小游戏，不包括背景图片，里面至少要绘制50个泡泡，而且还会动，起初在模拟器上运行得还好，而且在我的手机上运行也没问题；后来我把这个游戏移植到了web端，一到手机端FPS只有20，我忽略了一点，微信小游戏不是运行在浏览器上的，跟普通的web页面不是一回事。于是我不得不把整个游戏的绘制部分改成了webgl，花了一个月的时候才调试好。
在此提醒一下各位，如果你的程序主要是在移动端运行，开发的时候在模拟器（我是在Chrome上运行）上先将CPU降低到手机的标准，不然会误导各位，还以为程序运行得挺流畅，实际上卡成鬼。
所以说，如果只会画个报表啦，做个Diagram程序啦，canvas2d就够用了，但要想在手机端做出渲染操作比较多而且复杂的游戏（比如3d效果的），用canvas2d是不行的，请转投webgl。
游戏不分贵贱
游戏就是一个程序而已，有的凸出的是画面，有的是在音乐上下了大工夫，而有的却是在游戏剧情安排上很吸引人，各有各的受众。
有些人就喜欢绝地求生，我就不喜欢，而我很爱玩连连看，却被别人笑话幼稚。玩家即是如此，何况开发者：你用的Unreal引擎开发的3d游戏，我用的原生js开发的2d游戏，你的就要高一档次？
游戏不分贵贱的，只有喜欢和不喜欢
