我们在开发微信小游戏过程中，发现一个不小的问题，虽然并不是时时刻刻体现，但是关键时刻，可能出现隐患，那就是微信小游戏的审核。这个审核时间或长或短，不可控制。正是因为不可控制，所以小游戏的开发是有一定限制的，那么问题来了。当我们想进行热更新的时候，发现小游戏并不支持。为什么这么说呢，因为很多关键性的函数例如eval被小偷袭封了。于是小游戏的热更新才是一个比较显著的问题。

经过这几天的研究和发现，感受到小游戏的热更新似乎还是有其他方案的，这些方案可以包含诸如伪代码实现机制，又例如重新编写一套语言实现解析，又例如文件内容替换执行。伪代码和重新实现一套语言，难度似乎不小不过论实现的话，似乎重新实现一套语言的话，理论上是一个选择，如果有相当丰富经验的开发者，是可以尝试的。伪代码其实就是一个简单的替换和重新识别。这里分别介绍下以上三个方案的实现。

伪代码实现。例如我们的所有代码全部通过自定义的开发工具，全部将函数和类名字换成新的名字，这是其一，其二我们可以或者这些代码字符串或者文件内容之后，同时识别映射到ts或者js上面，这样子我们的代码其实是字符串，而映射之后的才是ts或者Js代码。所以这种方式是可以不断更新和迭代的，如果被微信发掘了内部的实现机制，我们仅仅需要重新实现一套解析方案即可。

重新实现一套语言。重新实现一套语言难度似乎不小，不过如果可以的话，我想可能实现热更新。例如我们实现一套ys语言，中间建立的虚拟机其实就是ys和ts/js之间的相互实现和映射，将所有的ts或js的关键函数和语法进行一次映射，可能包体会大很多，但是足够有效。这种方式的思维是基于lua->c++,这里类同是ys->ts以及ys->js。

文件内容替换。假定我们实现了服务器文件的下载。并且将所有的文件内容进行一次替换，注意是替换，将已经存在项目内部的文件 类名或者其他的进行一次替换，那么重新eval之后，得到的代码数据全部是服务器更新到的，而非当地load的。这似乎是一个好的方案。不过针对那些新增的代码，我们又该怎么处理呢。或者这样的情形，还是需要审核更新吧，毕竟热更新是为了解决线上存在的bug,如果设计功能增加和bug修改设计代码新建类或者函数，这个方案可能需要斟酌了。

以上内容就是小游戏热更新的方案介绍了。后续作者将继续关注这个问题，尽量提供一个可实际使用的方案。