四、部分功能技术解析
（一）微信小程序扫描web二维码登陆
上图为web页面登陆的总体逻辑
（1）框架使用
1.1 传统轮询
为了实现小程序与web端的实时通信，定时获取并刷新页面上的数据，以达到两端信息的及时传递，开始自己选择了使用轮询的方式来进行数据的传输。简单来说使用轮循的程序会每隔一定的时间向服务器请求一次数据，并在数据到达后存储。这个实现方法通常可以满足简单的需求，然而同时也存在着很大的缺陷：在网络情况不稳定的情况下，服务器从接收请求、发送请求到客户端接收请求的总时间有可能超过一定的时间，而请求是以一定的时间间隔发送的，这样会导致接收的数据到达先后顺序与发送顺序不一致。但是这样的优点和缺点也是显而易见的：
- 优点：后端程序编写比较容易（几乎不用做什么特殊处理）。
- 缺点：因为是不断请求，服务端有没有更新数据都会返回。这就造成了请求中有大半是无用，浪费带宽和服务器资源。
- 实例：适用于小型应用。
1.2 长轮询
上面所说的传统轮询方式都存在一个严重缺陷：程序每发出一次请求就要新建一个Http请求。因为发起Http请求时会有很多头部信息，真正的请求信息几乎很少，这样就会造成资源浪费，频繁的轮询使得Web服务器遭受"凌迟"之苦。而长轮询意味着浏览器只需启动一个HTTP请求，其连接的服务器会“hold”住此次连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的Http请求,以此类推。
- 优点：在无消息的情况下不会频繁的请求，耗费资源小。
- 缺点：服务器hold住连接会消耗资源，返回数据顺序无保证，难于管理维护。
- 实例：WebQQ、Hi网页版、Facebook IM。
1.3 WebSocket
WebSocket是HTML5开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。WebSocket通讯协议于2011年被IETF定为标准RFC 6455，WebSocketAPI被W3C定为标准。 在WebSocket API中，浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。WebSocket API最伟大之处在于服务器和客户端可以在给定的时间范围内的任意时刻，相互推送信息。WebSocket并不限于以Ajax(或XHR)方式通信，因为Ajax技术需要客户端发起请求，而WebSocket服务器和客户端可以彼此相互推送信息。
1.4 workerman框架
Workerman是一款纯PHP开发的开源高性能异步PHP socket框架。支持高并发，超高稳定性，被广泛的用于手机app、移动通讯，微信小程序，手游服务端、网络游戏、PHP聊天室、硬件通讯、智能家居、车联网、物联网等领域的开发。 支持TCP长连接，支持Websocket、HTTP等协议，支持自定义协议。拥有异步Mysql、异步Redis、异步Http、MQTT物联网客户端、异步消息队列等众多高性能组件。Workerman支持的特性:
- 纯PHP开发，多进程支持，支持php7，支持hhvm
- 支持TCP/UDP，单机可支持数百万以上TCP长连接
- 支持分布式部署，集群能支持数百万甚至更高的并发TCP连接
- 支持libevent事件触发网络库
- 支持热更新及服务器平滑重启
- 拥有异步Mysql、Redis、Dns等众多高性能组件
1.5 总结
经过后来的需求分析和从用户体验、服务器负载等多方面考虑，最终我选择了使用workerman框架，一方面其支持高并发，可以很好的避免当系统流量过大时带来的相应延迟，另一方面其异步Mysql、异步消息队列等组件也可以很好的对后端的信息进行相应的处理。同时其支持心跳检测，即服务器会定时向客户端发送心跳检测，若客户端回复相应，服务器则保持连接，否则服务器将自动断开连接，这样的处理方式也很好的节省了服务器资源，提高相应速率，为使用者带来更好的使用体验。并且其提供的浏览器定向推送，也便于后期的小程序端和web端信息实时更新互通。
（2）二维码生成
2.1 二维码原理
二维码即为通过黑白矩形图案来搭载二进制数据，也就是储存相应的字符串，并且每一段字符串对应着唯一的一个二维码，当你使用扫一扫功能扫描二维码时，其实程序得到的就是储存在二维码中的字符串信息。当你扫描二维码后，程序获取相应的字符串信息，再通过相应的逻辑判断，即可完成相应的一些功能的实现。
2.2 免费的生成二维码API
网上有许多的批量生成二维码的API接口，如草料二维码等等，但其都是要进行收费的。当我们进行小的项目搭建时，我们可以使用百度提供的免费二维码生成API接口。使用方法如下：
https://pan.baidu.com/share/qrcode?w={宽度}&h={高度}&url={内容}
调用此接口，即会返回你所要求大小的字符串所对应的二维码图片。
（3）扫描登陆相关逻辑
因为我已经使用了workerman框架，在这个框架中，服务器会为每一个浏览器分配一个唯一的client_id。而openid为小程序为用户分为的唯一ID。具体的逻辑如下：
1.web端将用户浏览器注册至服务器；
2.服务器记录该浏览器的登陆状态，将其注册，为其分配唯一的client_id，并将此Id返回为浏览器，浏览器根据此id生成相应的二维码；
3.小程序端通过扫描二维码来获取要登陆的web浏览器的client_id（上图中的第二个移动端应为web浏览器）；
4.小程序端通过将唯一的openid和web浏览器的client_id同时发送至服务器；
5.服务器根据小程序发送的openid来确定用户身份，到数据库中查找该用户的会议信息，并进行相关的逻辑处理；
6.数据库查询到该用户的会议信息后返回给服务器；
7.服务器将该用户的会议列表信息直接发送至用户要登陆的web浏览器（即client_id所唯一对应的浏览器）供用户选择其将要操作的会议；
8.用户在web浏览器上选择相应的会议后，web浏览器将会议Id和自己的client_id传输给服务器；
9.服务器在数据库中进行该会议的相关信息查询后，将其查询到的信息回传发送至web浏览器（即刚刚发送会议Id的浏览器，服务器根据其client_id对其进行定向推送）；