这两天最热的一个话题，现在只要更新到6.6.1版本的微信，开场就会出现一个游戏。你也可以到发现-游戏里找其他所有的小游戏。

这应该是小程序有史以来最大的一次更新，还记得1月10日发布时，小程序是明确说明暂不支持开发游戏的，短短数月，态度却发生了180度转弯。

可能有人还来不及反应，心里就疑问：为何这么善变？

谁说不是呢？但是做互联网技术，特别是做前端开发的同学都知道，技术一年一年变，从2010年进腾讯到现在以来，前端技术的持续演变以及人力模型的多向发展，时下还处于“技术驱动产品”的年代。

随着技术复杂度以及创新度的变化，产品的形态也随之发生一连串的革新。更何况那是生来就带着“技术”和“产品”特质的腾讯。所以，只要是正向，能为行业带来活力，谁在乎变还是不变。

再说，“小游戏”可不是一时半刻就做得出来的东西，也许就在小程序发布后不久，又或者是小程序发布前，“小游戏”可能就在策划中。 为何这么说？因为“小游戏”虽然依赖于小程序的账号体系，但从技术层面来看，这完完全全是一套全新的、庞大的、完整的以及独立的开发体系。

接下来小编要给大家说说它到底是什么？我们来解决2个问题吧。

一.“小游戏”跟公众号、小程序什么关系？ 众所周知，小程序跟公众号可以算是“兄弟关系”，也有人说小程序就是公众号的补充，小编不大认同。公众号是以内容为主，小程序则是以服务为主的，“服务”与“内容”的关系。

小编总觉得不应该是“补充”关系吧？暂且把“小程序”和“公众号”的关系定义成“对等”的，按这逻辑也就是说，公众号能做的，小程序应该也能做才

对，只不过做的东西内容是一样但形态不大一样。

可以，其实基于公众号能实现一些h5游戏，这些h5游戏能具备普通h5没法实现的功能，如微信支付、用户信息获取等功能。

于是小程序支持做游戏，好像也不是特别难理解。“小游戏”是小程序的子分支，现在可以暂且把小程序归类为：

普通小程序

小游戏

具体来说，小游戏就是小程序里的一个类目，只不过这个类目有点特别，一旦被定义后，后面就没法改了，而且这个类目会让这个小程序号具备了游戏的标识，也让这个小程序号的开发模式锁定在游戏开发的解决方案中。

理清这些关系后，咱们从技术层面看看它是个什么货。

二.“小游戏”是什么技术？

它是基于微信原生功能特性的、仅保留微信html5游戏特性的综合技术。说这个前，我们还是复习一个功课。

现在市面看到的H5游戏有很多，微信也有专门发展h5游戏，如： 大

家应该知道那是基于通用html5技术的游戏，html5技术是基于浏览器统一标准的网页技术，是一种通用技术，提供了游戏以及非游戏应用所能用到的所有技术。

那么问题又来了，我做个游戏，给我提供那么多附带技术干嘛，是不是有点“杀鸡焉用牛刀”的感觉？而且这些附带的技术还可能会带来一些不必要的消耗。

做h5游戏，技术上应该要做“减法”。

“小游戏”保留了H5中游戏相关的技术，而在此基础上又追加了小程序部分特性能力。这样出来的游戏，技术更专注、特点更微信。

把游戏相关的技术揪出来，加上微信原来的功能特性接口，这样会使得运行效率更高、更精简而又能让微信为其赋予创造力，从用户层面看，游戏会更流畅，提供的功能服务会更强大。

技术选型角度看，除了“难以跨平台”这个缺点外，也没什么坏处，总结一下“小游戏”的技术点：

①难以跨平台

基于小程序的账号体系，与小程序一样，小游戏只能运行于微信中，难以跨平台。

②与普通小程序设计模式不一样

普通小程序的设计模式是“单向”绑定的模式，入口在app.js，通过定义各个页面，然后在页面中给回调事件定义逻辑代码实现数据呈现。

而“小游戏”更加自由，入口在game.js，没有page的概念，通过weapp-adapter.js引进canvas实例，无设计模式要求。

③基于普通H5游戏技术，更多的是Canvas技术，同时提供原生能力API。

现有游戏框架，如createjs、threejs等2d或者3d框架，经过小改就能直接应用于小程序的“小游戏”中，同样，小游戏也会如普通小程序一样支持部分原生功能。

④应该暂不对个人开发者开放

跟普通小程序一样，小游戏暂不对个人开发者开放。

最后大家发现没，第一批小游戏中大多具备展示关系链数据的功能块，未来会不会开放这块数据呢？嘿嘿嘿~

综合上述，这种“技术形态的拆减和组装”本身就是一种创新，而往往技术的创新会带来深远影响。

想必这又会掀起一波热浪，您准备好了么？

微信小程序开发公司:www.c5c6.cn