优化这件事儿我以前很少会在意，因为一直做手机游戏，手机硬件的更新速度非常的快，更快的计算能力，更强的渲染能力，更大的内存。这就导致了如果你不是做一个大型游戏的话，几乎是不太用考虑优化的。
直到我开始做微信小游戏，作为一个小游戏是有诸多的限制的，计算能力，渲染能力，尤其是对游戏大小的限制（不能超过4M），这些限制让我不得不重新的转变一些之前做游戏的想法。
7月4号，我更新了一个新的游戏模式：闯关模式。相当于将原有的游戏扩充了一倍的内容。
我们看一下下方的两张小游戏后台的数据统计图。这里有两项比较重要的数据：
总耗时：是指从玩家点击游戏图标到正式进入到游戏中的时间。
CPU: 是指游戏运行中所需要消耗的计算量。
可以看到在增加了闯关模式之后，游戏的启动时间和 CPU 都开始上升。其中最严重的莫过于启动时间的提升，最高值达到 9 秒钟，想一个如果一个玩家打开一个小游戏需要等待 9 秒钟的时间才能进的去的话，很可能就不会再次打开它了。
针对上述的问题，我开始着手对游戏进行优化，首先看了一下官方文档的优化建议。
内容相对较少，只有一些原则，缺少具体详细的指导。但是至少是有了一些方向了，于是我开始踏上了小游戏优化的旅程。
下面记录的就是我针对一个已上线的微信小游戏的优化操作。
精简游戏资源
每一个被导入的游戏资源最终都会包含在游戏的包体中，在游戏开发的过程中会导入很多的资源，包含各种的图片，音效，数字等等，有些资源最终没有被用到，这时候要仔细的检查这些导入的资源，找到并删除那些没有用到的资源，以避免它们增加游戏的大小。
游戏中的最多的资源类型就是图片，对于图片资源我们要坚持一个原则：尽可能以最小的图片达到预期的效果。
比如说游戏中的对话框背景图，原来使用的是一张 380x580 的圆角矩形图片，在等比例的缩小一倍后，最终使用了 190x290 的图片。
虽然边角和阴影有部分的细节损失，但是总体上是可接受的，这样原来的一张大图就缩减了一半的大小。
对于图片资源的另一个原则就是：复用。只要能重复使用同一张图片的地方，那就一定要重复使用同一张图片。
如图，在优化后的精致1010的首页中，8个按钮只使用了两种类型的图片，一个是长的圆角矩形（用于声音和震感按钮），一个是方的圆角矩形（用于剩余的所有按钮）。通过调整图片的大小和颜色，就可以做出不同的按钮了。
这里我使用的是圆角矩形， 因为圆角矩形在大幅度的放大或者缩小后，圆角处会出问题，所以使用了两种类型的圆角矩形，如果使用方脚矩形的话，那么所有的按钮复用一张图片就可以搞定了。
精简游戏逻辑
游戏逻辑指的就是我们的积木块了。
首先删除游戏中没有用到的积木。仔细检查游戏中的逻辑积木，删除无用的或闲置的游戏积木，平时对于无用的积木块要及时的删除，不要放在那里，养成好习惯。
其次还是要坚持“复用”的原则，对于重复的逻辑通过使用“函数”或者“通知”进行复用，避免多次使用重复的积木块。
使用函数来复用逻辑
举个例子，在精致1010中拖拽的方块不满足放置要求是会退回到原位置的，因为包含多种不满足要求的情况，所以有很多的“如果，否则”积木块，对于所有不满足的情况其实都重复用到了相同的两块积木。
对于这种情况，我们就可以将重复的积木制作成一个函数。
可以看到这个函数中设置了多个参数，这样对于所有需要移动缩小功能的地方，就都可以使用这个函数了。
最后使用函数来替换原来重复使用的积木块。
使用通知来复用逻辑
使用函数有一定的限制，尤其是对于局部变量来说， 将局部变量以参数的形式传递给函数时，在函数内对局部变量的修改不会被保存。比如说一个局部变量 10，当作参数传入函数中，在函数内对局部变量进行加倍处理，最终结果应该是 20，但是函数执行完毕后，这个局部变量的值依然是 10，所以对于函数内处理的变量只能够使用全局变量。
那么对于需要处理局部变量的重复积木，我们可以通过使用“通知”来进行复用。
如图，这是更换主题中的部分逻辑代码，可以看到红框框出的代码是重复使用的，这里我们可以将重复的代码放到一个通知中处理。
对于需要用到重复积木的地方，我们只需要向自己发送一个通知即可。这样原来的这部分代码就通过复用被精简了一半。
这里有一点需要注意一下：当前的微信小游戏开发工具的积木块的数量是有上限的。
这是我前些天在增加新内容时遇到的问题，项目无法进行保存了，咨询过开发团队，才知道是代码超出了限制。
所以要好好斟酌每一个需要使用的积木块，尽可能的以最少的积木块实现想要的功能。
另外有一点需要考虑的是，当前的代码限制决定了你将要开发的游戏的体量， 如果你想要通过微信小游戏开发工具做一个比较大的游戏，那么就需要提前考虑一下这个代码限制了。
合理规划场景
在增加闯关模式时我原来的方案是重新创建一个场景，专门用于闯关模式。这样经典模式和闯关模式两个场景就能够各自独立。在后续不论是针对哪个模式进行修改也好，扩展也好，只需要到其对应的场景中进行开发即可。
多创建一个场景，就相当于多了非常多的资源， 两种游戏模式之间，其实有非常多的东西都是可以共用的。但是，由于很多的资源和积木逻辑无法跨场景共用， 所以很多的内容就只能通过复制粘贴再创建一份了，这就导致了游戏中包含大量的重复的代码和资源。
在遇到了最大代码限制之后，我不得不重新考虑场景的规划，将这两个场景合二为一。
如图， 我将原来的“经典模式”和“关卡模式”两个场景合并到了一个“游戏”场景。在合并之后，节省了大量的代码空间，后来才能够增加“编辑”场景，实现用户自定义关卡的功能。
这里的一点提示就是不要不加节制的使用场景， 如果能使用一个场景搞定的事情，那就不要用更多场景了。
减少游戏中的精灵数目
游戏场景中的精灵的数量决定了渲染和计算需要的消耗量。总体上来讲，精灵的数目越多需要的渲染和计算的量就越多。所以为了提升总体的性能，就需要尽量的精简游戏中的精灵的数量。
点击调试游戏，可以在“全局变量”选项中看到当前场景中的精灵数。
如图，在优化之前，初始场景中的精灵数目是 325。虽然游戏的界面看似非常简单，但是精灵数目却非常的多。
我们的目标就是在保证游戏效果的基础上尽量的精简游戏中的精灵数目，为此我做了如下的优化。
原本游戏中的这个 10x10 的网格是使用单个格子拼出来的， 所以画出这样一张网格就需要 100 个精灵。 我更换了一种方式，直接导入一个画好的 10 x 10 的网格图片，这样一个展示网格只需要使用 1 个精灵就可以了，这样一下就缩减了 99 个精灵。
另外游戏中的所有的形状原本都是使用单个方块拼成的，现在我直接将形状制作成一张图片，这样就又能够减少非常多的精灵。
最终经过优化后，场景中的精灵数目减少了一百多，这还是在后续增加了新功能之后的精灵数目。
同时从CPU的指标中可以明显看的出来，优化后，消耗大幅下降，因为更少的精灵数目，就意味着更少的CPU消耗。
创建一个精简的初始场景
“游戏启动时间”是小游戏中的一个非常重要的指标，它意味着从玩家打开到正式进入游戏需要多长时间，通常这个时间越短越好。
决定这个时间长短的因素很多，包括游戏的大小，资源的多少，网络的状况，玩家手机的性能等等，其中大部分因素其实是不可控的，除了我们上述提到的各种优化方法之外，还有一个方式可以帮助我们提升游戏的启动速度，就是创建一个尽可能简单的启动场景。
原来的启动场景。
新增的精简的启动场景。
如图我为游戏增加了一个非常简单的启动场景，只包含了一个小蚂蚁的图标和很少量的积木块。这样场景的打开速度就会比原来快很多，因为需要加载的资源和积木块都非常的少。
另外，不要忘了在作品设置中选择资源在“切换场景时加载”。
这样由于启动的场景资源非常的少，就可以很快的加载完毕并打开了，然后我们再从启动场景加载打开后面资源比较多的场景。
最后，总结一下，对于微信小游戏的优化，我们可以从下列几个方面着手：
- 精简游戏资源
- 精简游戏逻辑
- 合理规划场景
- 减少游戏中的精灵数目
- 创建一个精简的初始场景
优化是一件永无止境的事情，我认为最好的优化是应该在制作之前进行的，因为一个更优的想法，一个更合理的规划要胜过这些事后的补救措施。
