开发小游戏，云开发真的是银弹吗？（一）-InfoQ

GTLC全球技术领导力峰会·上海站，首批讲师正式上线！了解详情 



 写点什么

8 月 17 日，“小程序·云开发”系列沙龙（小游戏专场）圆满落幕。本期沙龙云+社区携手微信 & 云开发官方团队为大家揭秘爆款微信小游戏背后的技术，全面讲解小程序·云开发、实时数据库库及小游戏联机对战引擎，助力小游戏开发。
下面是杨航老师针对云开发带来了哪些便捷能力，使用云开发是怎样一种体验以及云开发又有哪些银弹助力小游戏场景的开发的分享。主要从历史情况，为什么有云开发？云开发是怎么样的？以及我们落地和规划、思考这几个方面来讲解。

小游戏的发展现状

最先认识到小游戏是从跳一跳开始的，2017 年 12 月份上线，大家的朋友圈、群里转发，产生了这样的营销效果。在小游戏形式之前，我们在游戏方面传播比较广的是传统的 H5 游戏，在我那个时候，《围住神经猫》这种游戏在短时间内有很大量的传播。

根据跳一跳来看一下小游戏的特点，你在微信中可以直接使用，加载速度比普通 H5 快很多，随点随用。在底层封装屏蔽了不同平台差异，暴露相同的接口，基本上一次开发接后，可以在安卓、IOS 两端的微信运行环境下直接运行。

有 H5 开发经验的同学可以知道，H5 基于浏览器，根据不同的场合、不同的机型，甚至不同应用 webview 内核不同，有很多需要兼容的地方，小游戏没有这样的问题。小游戏基于微信是天然可分享的，很方便的分享到图文平台、群聊等等。小游戏的底层基于 canvas 的，这个 canvas 是原生 webgl 上的一层封装，所以它的性能会好很多。另外，基于微信，你可以随便的扫扫码，搜一搜，也可以根据朋友的推荐很方便的获取。

正基于这样的特点，出现很多场景的小游戏，最左边是进博会官方的小游戏，配合展会进行推广。口袋工匠是故宫为了推广文物做的小游戏。最右边是腾讯的《灯山行动》，很有影响力的公益小程序。这些小游戏休闲游戏居多，随走随用。从轻量的角度来讲，很便于利用等地铁、车、电梯的碎片化时间。在文化方面，通过小游戏也可以做到很好的传播，这些都有非常丰富的文化属性，用有上千万的用户量。

小游戏的生态，有数十万的开发者，小游戏月活达到 4 亿，4 亿的数量与传统移动游戏的用户量相当。小游戏有很大的潜力，58%以上是 30 岁以上的用户，31%是 40 岁以上的用户，之后父母辈会成为小游戏的主力。我们过年回家看到爸妈在那里玩各种小游戏，玩跳一跳，而且他们的水平比我们好很多。

上图左下方分别是次留，7 留，月留数据，达到这样的留存很不容易。在安卓内购流水超过千万级别有 10 款小游戏，小游戏有丰富变现的能力，有很多的商业潜质。

生态丰富来自于基础能力，从最初的 canvas，到现在的各种引擎的适配，从标准的图形库到引擎，门槛在一步一步的下降。还有一些硬件接口的暴露，像刚才提到的陀螺仪、重力感应，它都拓展了游戏开发的边界。

基于微信的关系链、图文安全、动态消息、内购等这些特有的能力，及数据运营、资金结算能力的更完善，整个生态都进入了良性的循环，开发者可以通过其完善自己的小游戏，并且从游戏中获得利益、推广。

为什么要有云开发？

除了小游的基础能力，开发层面上还有云开发，云开发是基础架构层面更加轻量创新的服务端研发模式，可以降低开发门槛，使开发者专注于业务内容创作。

为什么要有云开发？在传统的开发模式上，我们感觉有很多痛点没有解决。首先，你要发布一款生产级别的应用，除保证业务逻辑没有问题以外，有很多内容需要自己处理，像高并发、弹性伸缩、负载，每一个项单拿出来都要讲很多，很难。作为业务开发来讲，很难 cover 住所有这些。从现代软件工程来讲，让更专业的人来做更专业的事，才能让你的服务更加稳定，这个逻辑是高效。

在传统模式下，从物理机托管，有自己的 IDC 机房，然后到上云，使用云上的服务云主机，到 PaaS 级别的服务，像容器、监控，这些都在减少资金投入成本和人力投入成本，云上的封装层级越高，暴露出来的越少，就需要更少的人去关心这些事情。即使走到 PaaS 这一步，你也需要专业的运维人原来跟进刚刚所讲的内容。人力的引入和自动化能力相比，可能会带来更多引入错误的风险。

现在应用开发比较现行的是 BS、CS 架构，前后端分离已经提了很多年，大家都在说前后端分离，这个事很好，大家各干各的，最后联调就行了。但开发者在真正的开发过程中，经常会遇到各种权责划分、反复沟通的问题。时间成本很高，导致整个开发进度缓慢。

我们想，有没有一种开发模式让开发者可以更多地专注业务逻辑，让开发者自己可以包揽更多的业务，从而减少沟通上的成本。从小程序的技术栈来看，主要限定在 JS 上，是前端开发的主要技术栈，大多数的前端也都听说过 Node.js，通过 Node.js 可以在一定程度上 Hold 住后端业务逻辑。如果我们只有前端开发来负责 JS 与 Node.js，这样就可以降低沟通成本，减少甚至免除与后端服务交互，做到更彻底的前后端分离。