跟着这五步 从0开始搭建你的第一款小程序

那么，开播地址以及播放的地址是如何生成的？这里面主要包含两部分，如上图，左边的主播端首先生成一个开播地址，主播端的小程序通过推流URL，把视频推送到腾讯云里面，腾讯云通过系列的编码、传输、解码工作，生成播放URL，通过播放URL（观看地址）推流给观众。

遇到的一些坑及其解决方案

上面讲的是怎么构建一个小程序，腾讯NOW直播团队在开发直播应用的时候，也遇到了许多问题，杨春文现场就布局、setData、大图片和预加载四方面的痛点和解决方案展开了详细讲解。

布局之痛

问题描述：video等native元素无法和webview元素重叠，视频与直播间元素的混排实现困难，cover-view组件与普通组件差异太大。

解决方案：折衷使用canvas来实现动态的效果，canvas是一个原生的组件，可以用于复杂布局。但canvas实现也有一些问题，就目前来说，比如用canvas实现的功能放在小程序里面使用时，手机温度升高、会有发热现象产生等等，解决方案是将客户端实现的canvas和我们web实现的canvas在性能上面差异化，以适配不同端的需求。同时，NOW直播团队也在尝试做一些性能上的改进的工作，解决用户体验问题。

setData优化

问题描述：setData 函数用于将数据从逻辑层发送到视图层，频繁SetData等于频繁DOM操作，从而导致UI延迟；同时超大数据setData也会使脚本执行时间过大，在后台setData，也会产生多余的资源（CPU/内存/电量…）消耗，占用前台JS执行。

解决方案：避免频繁的SetData操作。如我们不停滚动的评论以及弹幕的消息，最开始的时候每展示一条就需要进行一次SetData操作，然后产生一个dom操作，这是非常消耗成本的。改进方案是一次返回多条消息，在小程序端滚动展示，避免一条消息产生一次setData，完成体验上面的权衡。另外，在onHide 时停止数据更新，从前一个页面切换到后一个，暂停前一个页面推荐更新操作。

大图片之殇

问题描述：小程序渲染层，通过webview的方式进行，如果图片较大，不仅会占用过多内存，也会导致延迟和卡顿现象。

解决方案：如果一定需要大图片，建议定期销毁这些大图片，比如以下图片，只要在区域里面才不会销毁，如果不在这个区域里面就可以销毁，一些不需要的图片如果一直存在，对性能的消耗会比较大。

预加载

问题描述：数据预加载的过程，页面切换，这个过程比较消耗时间

解决方案：当用户刚刚进入下一个页面时，页面还需要拉取数据，进行渲染，这个过程从需要从A页面进入到B页面，然后再到数据，中间这个A切换到B，这里面有一段时间的消耗，在A页面切到B页面的过程当中，可以同时拉取一个数据，B页面进来，直接从这个数据里面提取需要的数据，这样就不需要再发一个请求重新拉去数据，避免中间时间的消耗等等延迟的问题。

如何开发一款小游戏

小游戏目前的火爆程度已毋庸置疑，从全民“跳一跳”到如今的“星途WeGoing”，小游戏已逐渐渗入消费者日常，成为老少皆宜的娱乐产品之一。腾讯微信高级工程师邹伟现场结合《星途WeGoing》的底层架构和研发设计，分享了如何更好的利用微信的开放能力开发一款小游戏。

什么是小游戏？

从普通用户的视角看，小游戏是小程序的一个子类目，可在微信内被便捷的获取和传播，即点即玩，具备出色的用户体验。小游戏是小程序，普通用户分不清也无需分清。

同时，从开发者的视角，它可以看作是基于Canvas/WebGL + 微信社交开放能力的一个新平台。下图是一个小游戏的一个架构概览：

这是一个典型的分层架构。最上层蓝色部分，是游戏代码，分为游戏逻辑，游戏引擎、weapp-adapter三部分。大部分游戏开发会用到一些引擎的工具、工作流，以及利用引擎封装的高层API去实现游戏逻辑。其次是weapp-adapter，因为小游戏的底层一方面不是webview，可以简单看成是webview经过精简、优化过后的平台；另一方面核心能力的实现上却参考了webview.所以这里如果有一个适配器，把小游戏的底层API——wx API适配到一个接近webview的接口，对上层引擎、已存在的游戏接入微信小游戏平台则会更加容易，这个就是weapp-adapter的作用。其中只有游戏逻辑是必要的。

中间层红色部分是微信以及小游戏Runtime，Runtime对外暴露的能力叫wx API，有一个基础库的。有一个jsvm用于执行游戏的Javascript代码，在安卓上是用V8Core，iOS则是JavaScriptCore.再下面一层是核心的渲染能力的实现，包括Canvas 2d以及WebGL，当然还有微信开放能力相关API的实现。

可以看到，在架构上小游戏和小程序是有差别的，小游戏没有页面概念的，wxss/wxml不再存在。其次，底层实现也不是webview，小游戏和webview的关系只能说是渲染相关的核心能力可以通过weapp-adapter的简单适配保持接口一致，但同时很多webview上存在的功能并没有对等的实现，比如小游戏就没有DOM/BOM的概念，也没有全局的document/window对象。

小游戏的入口为game js文件，语言为Javascript，但有一些限制，比如禁止执行动态代码，因此eval、new Function等能力是不支持的。配置为game.json，可以配置横竖屏、接口超时等参数。js里面可以组合wx API的能力来实现游戏逻辑， 非代码类的资源应该尽量放到cdn，减少整个代码包打包后的大小，以加快用户首次进入时的速度，微信对首包的大小目前限制为4MB.

小游戏能力概览（小游戏能力在不断扩充中，最新、完整能力可关注我们的开发文档）：

如何开发一款小游戏？

小游戏的核心逻辑的开发过程和传统的端游、页游以及现在的手游，并没有多大区别。这里会着重介绍一下怎么更好的利用微信小游戏的平台开放能力，包括选择小游戏引擎选择、设备/环境适配、微信登录、缓存、开放数据域、分享、支付、性能、版本更新机制、运维这几个部分。

选择小游戏引擎

微信跟引擎商也有比较密切的合作，一般现在的游戏引擎都会支持发布到多个平台，对微信小游戏这个新平台而言，已经有一部分引擎做了适配，比如Cocos Creator、Egret Engine以及LayAir Engine.适配的主要工作，类似之前提到的weapp-adapter，把wx API的能力，和引擎衔接起来。比如引擎一般会把小游戏平台和webview平台对标，适配过程就是把wx API对应到webview的能力，同时把只存在于webview能力的依赖去除，比如不再依赖BOM、DOM.

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!