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

[摘要]从微信的诞生,到微信公众号、微信支付,再到小程序,腾讯生态在一次又一次影响用户行为习惯的同时,也为开发者提供了新的思路和技能发展方
从微信的诞生,到微信公众号、微信支付,再到小程序,腾讯生态在一次又一次影响用户行为习惯的同时,也为开发者提供了新的思路和技能发展方向。无可置疑,微信小程序开发浪潮已经来临,也将在2018年成为各行业流量红利的集中爆发入口。

4月28日,腾讯云联合InfoQ举办的云+社区技术沙龙,以小程序开发实战为基准点,围绕小程序云上解决方案,serverless后端架构,小游戏底层设计和直播、电商小程序的开发实战五大主题内容,分享最全面的微信小程序设计开发思路以及解决方案。本文整理了讲师演讲精彩内容,感兴趣的读者可以点击【阅读原文】下载讲师演讲PDF。

 小程序云端解决方案

小程序不需要安装,易于分享与传播、开发容易同时用户体验也非常好,那么,他的这些特性是如何实现的呢?腾讯云高级工程师朱展,从小程序架构分析、小程序解决方案进化历程以及腾讯云小程序解决方案介绍三方面给出了答案。

 小程序的实现原理

小程序的开发模式是一种类Web的模式,它的前端和一般的H5的前端相似,但和JavaScrpit开发比起来的会简单很多,这点得益于小程序的实现原理和架构。下图是程序的基本架构图,它的上层分两个板块,一块是视图层,也是WebViews,另一块是逻辑层,也就是AppService,这两层在两个不同的线里面进行处理,跟传统的web有根本性的差异。

传统的Web渲染时,如果逻辑里面有很复杂的处理,往往会导致界面出现卡顿的现象。小程序没有这个问题,如果没有调用渲染,不会导致界面的流程度下降。不过,由于视图层和逻辑层在不同的线程里面,这两层不能进行直接的交互,必须通过一些手段实现交互,微信采用JSBridge实现JS的运行环境和原生系统的相互调用,当用户在界面上进行操作时候,会触发相关事件,传递到原生 Webviews,再到逻辑层。

是小程序的渲染过程首先是编译打包,开发者编写小程序时需先编写一个WXML的代码,通过WCC的编译工具,进入WAWebView,用户运行小程序时,会和逻辑层传入的数据做一个编译,渲染成最终的界面,下图是一个局部更新的过程。

以下是小程序加载的几种简单的示意图,小程序在手机加载时,要在CDN上面拉一个小程序包,小程序在首次加载时可能有一个等待的时间,当这次安装包缓存到本地以后,下次手机再打开该小程序,则直接从缓存里面读取安装包的内容,如果有新的版本,小程序也不会等新版本更新完了再打开APP,而是直接用上一层缓存的小程序,等下再启动时,直接使用新的安装包替换旧的。

同时,小程序还提供了一个Webview预加载的性能,除了当前看到的Webview的视图以外,在后台还可以看到一个新的Webview,这种预加载性能,能够让一些复杂的小程序在一定程度上保证加载的速度。

小程序的安装包缓存、分包加载、独立渲染线程、Webview 预加载以及一些Native 组件……这些工作在让小程序拥有丰富功能的同时,保证了小程序的打开速度和流畅度,从而给用户带来完美的体验。

  小程序解决方案进化历程

开发者在开发一款小程序时,需要处理很多非业务性的逻辑,同时需要准备自己的服务器,因此需要花费很多精力在服务器运维以及周围环境的部署上,而无法专注于小程序的业务开发。为了让开发者从繁琐的配置上解放出来,腾讯云为企业和机构定制了一套基于腾讯云 IaaS 能力的解决方案,这就是腾讯云微信小程序 Wafer 解决方案,帮助开发者更加便捷的部署和调试服务器。

Wafer1 面向企业和机构客户(以下称为企业级客户),提供了一台业务服务器和一台会话服务器,业务服务器来部署和处理业务相关的逻辑,而会话服务器则用来独立处理与用户会话(登录注册等)相关的逻辑,业务与会话的分离有助于中大型企业级客户将来对小程序后台进行扩展。除此之外,腾讯云还将数据库从云服务器中抽离出来,提供了云数据库。

除了 IaaS 能力的解决方案 wafer ,腾讯云还提供了快速通信接口、登录、语音识别等多种能力,用以满足用户在小程序开发过程中的各项功能需求。

Wafer 的信道服务是由腾讯云提供的一个 PaaS 级的 websocket 服务。利用信道通信技术,可以实现小程序与服务器之间的信息互动和传输。腾讯云信道通信技术可以使当前的用户直接跟信道服务器直接建立 websocket 链接,业务服务器只用处理 http 请求而不需要关心 websocket 信息。

总的来说,Wafer信道服务有以下几大特点:配合SDK无需开发,直接使用;平台提供稳定性和性能保障;能够自动实现断线重连;独立信用服务器,消息搬运工。但同时,Wafer1架构复杂,开发者上手成本高,开发者代码调试也不方便。

针对wafer1不足之处,2017年上半年提出wafer2的解决方案,它是wafer1是一个简化版,把wafer1做一些简化合并,兼顾的安全性和便利性,比如说它把会话服务器和业务服务器做一个合并;在wafer1时代我们会让用户自行部署他的服务器,在这儿我们进行托管式的管理,用户可以购买自己的服务器,但是不需要做服务器端的配置,还会自动免费部署SSL证书,此外,腾讯云和微信进行深度的合作,已经将wafer2的解决方案提进微信开发者空间里面去了。

除了 IaaS 能力的解决方案 wafer ,腾讯云还提供了上传代码到开发环境、使用 Devtools 启动单步调试、在开发环境安装依赖、重启/停止 Node.js 程序、恢复初始状态、上传生产环境代码、带登录态跳转腾讯云控制台等系列解决方案,本文不在此一一赘述,感兴趣的同学可以登录腾讯云官网进行尝试。

  使用 Serverless 构建小程序后台

小程序、小游戏的开发已经越来越火爆,而小程序或者小游戏的后台,通常还是按照传统的服务器模式,提供 API 作为后端服务入口进行开发。腾讯云正在尝试一种新的方法:利用 serverless 架构来实现后端服务,通过结合使用 api 网关、云函数、云数据库等服务,从而能够无需关心服务器,自动实现高并发, 快速上线和无缝更新能力。腾讯云SCF无服务器云函数高级产品经理黄文俊详细讲解了如何使用 Serverless 来构建小程序后台。

 微信小程序及后台交互架构

小程序,是一种全新的连接用户与服务的方式,它可以在微信内被便捷地获取和传播,同时是最具有出色的使用体验。它的加载方式比传统的APP方式更快速,开发上线也更快速。除了本身的界面展示和数据刷新之外,小程序的数据获取通过微信和后端进行交互,小程序的运行,是一种类前端的运行方式,它整个运行是在微信内,而它和后端的交互,是通过微信进行转发的。在实际运行并发出请求时,小程序首先会调用微信API,发出API请求,这个请求发送给微信,微信再通过网络请求发送到用户自己的服务器上,用户在自己的服务上拿到这个请求以后进行数据的处理,然后再来响应给到前端,这就是一个小程序和后台交互的完整过程。

传统的后台架构需要提供API服务的情况下,首先是需要使用负载均衡,然后接入业务应用服务器,之后接入文件存储、包括结构化和非结构化的数据库服务,以及缓存服务。在这个过程中,为了保证系统不会由于某一个的服务器宕机导致服务瘫痪,需要分别建立业务应用集群、数据库集群、分布式文件存储、缓存集群;建立集群的一个首要作用就是确保不会由于某一个单点故障导致整个服务不可用。下图为传统的后台架构图。

这种多服务多集群的架构模式,在中大型互联网公司都是已经具备的了,但是作为个人开发者来说,搭建这一套系统比较困难,开发者需要了解整个系统的配置,如负载均衡怎么配置、数据库集群怎么配置等等。为了让大家把精力从后台的基础架构搭建当中解放出来,将更多的时间投放到业务和小程序本身,腾讯云在这里为大家提供了使用Serverless架构构建小程序后台的方案。

  Serverless 架构介绍

Serverless架构,英文称之为Serverless,中文称之为无服务器,也就是说大家不用购买服务器,不用配置虚拟机或者物理机,它使用计算托管的方式,用户在使用的时候不用担心它的安全性,也不用担心可能服务器宕机导致的故障。

那么,他是如何实现的呢?下图为腾讯云Serverless架构,可以看成两部分,第一部分就是函数即服务,计算托管在云函数内,真正实现了你业务逻辑的托管计算。另外一种是后端即服务,包括对象存储、消息列队、云数据库、云缓存、API网关等等。

因为Serverless架构是计算托管型的,计算托管意味着把真正的业务代码托管到云上面,然后在云上面运行。Serverless架构的运行方式有一个特点,业务逻辑是触发式运行的。云函数在和各个云产品或云服务打通以后,各个产品或服务产生的事件,都能触发业务逻辑的运行。我们在这里会将云函数与API网关进行结合,当小程序发出的请求到API网关时,就会产生一个API请求事件,然后触发业务代码的运行。用户在进行托管的时候,将代码和触发器的配置提交到云上来,代码内容就是对事件进行逻辑处理。在事件发生和处理的过程中,对于每一次的事件,都有一个代码对应的实例拉起,实际上每个实例都是单独处理一个事件。用户发出请求时服务运行,没有请求时服务不运行。同时本身产品的计费模式也是根据实际服务运行的时间计费的。





同时,利用对象存储,大家不用自己构建分布式存储,不用担心数据的丢失和安全性问题;使用在云上提供的数据库、消息队列也是一样,不用购买服务器自己搭建,购买或者开通就立刻可以开始使用,因此这种服务也可以称之为Serverless。

  Serverless 后台开发方案

那么怎么使用Serverless架构实现后台开发呢?传统的架构中的web服务替换为 Serverless 架构的话,对外提供服务所暴露的API,我们使用 API 网关来管理,用户的业务逻辑,我们放在云函数内运行,需要结构化数据存储或者文件存储,我们使用数据库服务,云缓存服务或对象存储服务等,同时其他的更多服务,也都可以直接使用云山提供的,直接通过代码调用。





具体搭建方案如上图,小程序除了本身的页面启动和展示,后续和网络的交互都是由小程序发起,因此,小程序通过网络 API,发起请求,获得响应并将数据展示到界面,使内容可以被用户看到;接着是通过 API 网关 管理 API,配置 API 的路径、方法、参数及校验,管理 API 的发布和切换;API网关之后就是云函数,云函数用来处理业务的逻辑,发起到数据库的连接,读取及写入数据库,生成响应数据,这里根据实际业务情况,如果需要使用数据库,就在代码内发数据库的连接,需要存储文件,就调用相应的对象存储接口来写文件;最后就是云数据库,用于存储业务数据。

通过联合使用 API网关、云函数、云数据库这几款云产品或云服务,我们展示了在没有购买和配置服务器的基础上实现小程序登录服务的实现,完成服务的Serverless化。利用Serverless架构实现的小程序,开发者不需要担心运维,同时因为运行无状态,所以能轻易实现快速迭代、极速部署,其弹性计算能力也能满足用户上万或者更高的并发。

小程序在直播产品中的技术应用

小程序如今已被用于生活的方方面面,包括电商、社交等场景,腾讯Web前端开发高级工程师杨春文,现场以NOW直播为例,介绍腾讯小程序在直播领域的一些尝试,包括登录能力建设、基于腾讯云基础音视频能力的直播流性能对比和选择、动画开发、直播间元素布局开发、官方支持的一些实用基础能力等,并分享在做开发过程中遇到的一些问题及解决方案。

  如何基于腾讯云构建直播小程序?

对于一个直播的小程序而言,怎么样才能够用最低成本构建呢?从小程序层面来说,有两点:主播端和观众端,通常主播端需要通过一些组件,完成视频到服务器的推送,进而到观众端。这个过程里,对于小程序开发者来说,核心点包括两个:一个推流,一个拉流。

一般而言,开发者自建转码、传输等功能来实现视频的推流和拉流是非常麻烦的,腾讯云有非常成熟的视频解决方案帮助完成这个过程。下图为腾讯云的直播小程序解决方案,使用过程也非常简单:

申请腾讯云直播服务;

获取加密私钥;

部署自己的业务后台(提供现成代码);

生成开播端地址(上行);

生成播放端地址(下行);

开启小程序。

通过以上几个步骤,可以基本完成直播小程序的配置工作。





那么,开播地址以及播放的地址是如何生成的?这里面主要包含两部分,如上图,左边的主播端首先生成一个开播地址,主播端的小程序通过推流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。




版权声明:

凡本网注明”来源:中国软件网(http://www.soft6.com)”的所有作品,版权均属于中国软件网或昆仑海比(北京)信息技术有限公司,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

任何行业、传播媒体转载、摘编中国软件网(http://www.soft6.com)刊登、发布的产品信息及新闻文章,必须按有关规定向本网站载明的相应著作权人支付报酬并在其网站上注明真实作者和真实出处,且转载、摘编不得超过本网站刊登、转载该信息的范围;未经本网站的明确书面许可,任何人不得复制或在非本网站所属的服务器上做镜像。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,昆仑海比(北京)信息技术有限公司将追究其相关法律责任。