本文作者团队成员Jay于2019年6月21日前往北京GMTC大前端技术大会小程序专场，分享了题为《腾讯在线教育小程序开发实践》的演讲

1、腾讯在线教育小程序矩阵

首先介绍一下腾讯在线教育的三大主营业务：

各业务均设有PC Web端、客户端、H5、APP端，满足学生多端上课需求。 但由于教育的前身是基于QQ群视频孵化的，后续的产品形态都是围绕QQ生态构建的，所以QQ相关的流量占据了大部分流量。

我们希望利用小程序生态为教育业务带来微信流量的增长，优化学生的微信上课体验，因此我们打造了在线教育小程序矩阵。

我们通过工具和基于内容的小程序来获取流量。 比如腾讯课堂开放小程序、腾讯微课堂、企鹅快算、口语拼音等工具型小程序，最后转化为平台小程序。

2、小程序基础设施设计与工程探索

上面提到这么多的小程序，我们如何选择框架以及团队如何制定统一的开发规范，探索小程序在多人协作开发中的工程化？ 下面将一一介绍。

在选择框架时，我们比较了几个主流的小程序开发框架，taro、wepy、原生开发框架。 可见原生框架在CSS预处理、多端复用、管理、自动构建等方面的能力相比其他框架有所欠缺。 但考虑到以下几点，我们更倾向于使用原生框架进行开发：

那么上述开发缺陷是否可以使用原生框架来解决，又如何解决呢？

1.CSS预处理

我们首先看一下 CSS 预处理。 我们期望能够在小程序中使用CSS预处理，包括嵌套语法、变量等以及其他工具。 经过调查，我们可以直接用它来编写样式文件并编译成wxss。

并且通过引入插件，可以解决小程序风格开发的痛点。 例如-url解决不支持本地图片的问题，将其转为格式； -font- 将字体转换为格式。

2. 数据管理

可以使用访问数据管理。

3. 构建

构建小程序需要做什么？ 小程序开发者工具已经提供了一些能力：ES7/ES6 to ES5、NPM包管理、代码分包、组件化、打包合并等。

我们使用gulp来实现图像压缩以及前面提到的Post CSS编译

为什么使用 gulp 而不是更流行的？

这里完成的能力主要涉及文件处理，使用gulp开发效率更高。 一些官方的小程序脚手架也使用了gulp。

最后我们选择了小程序原生框架作为我们的开发框架。 并且弥补了与其他开发框架相比所缺乏的基础能力。 当然，这并不是说其他​​框架不好。 具体选择还是要看具体的业务场景。

4. 目录规范

开发框架确定后，统一的目录规范还必须受到团队协同开发的约束。

引入npm包管理后，我们在小程序的根目录下新建一个目录，作为小程序代码的根目录。 这是因为小程序会将里面的包打包编译到一个目录中。 为了避免小程序与其他工程相关的东西混在一起，新建了一个文件夹来存放小程序工程代码。 您可以通过修改..js来配置小程序代码的根目录路径。

5. 编码标准

约束了目录之后，团队开发时如何保持代码规范统一？ 我们希望团队成员在开发时能够统一代码规范、提交规范、保持风格一致。 因此，和我们其他的Web项目一样，我们可以使用 、 、 等插件来约束和标准化我们的代码。 提交时使用git hook进行验证。 如果未通过，则不允许提交。

使用and-自动生成统一版本号and。 您在本次版本迭代中提交的标准化日志（遵循团队规范：#）将自动生成，表明是否是功能发布，或者，以及相应的日志信息。 以后当我们需要回滚或者回溯某个版本的变更时，我们就能一目了然。

基于以上能力和约束，我们创建了统一的脚手架，方便团队在统一的环境下快速开发，并开源了（ ）。

3. 小程序开发实践

介绍完我们的框架选型和工程探索之后，我们来分享一下我们开发在线教育小程序的实践经验。

1.小程序音视频

第一部分是小程序音视频能力相关的实践。 腾讯课堂是一个在线学习平台，最重要的就是音视频的直播和录制能力。 那么在小程序上，我们如何打造课堂音视频能力呢？

1）、直播场景

在接入小程序之前我们先看一下腾讯课堂的直播结构。 我们通过老师上行到云端，然后实时下行到端端，App学生，下行到PC网页学生。 对于时延要求不高的场景，我们可以将直播流转码到CDN，然后拉流供用户观看，以节省成本。

这是各端使用的直播协议以及延迟对比。 小程序应该使用哪种协议？ 如何访问它？

揭秘之前，我们先来了解一下小程序音视频能力的发展历史。 最初，小程序音视频只有原生标签。 这意味着它只能支持HLS高延迟的直播场景。

2017年4月，腾讯云与小程序达成合作，在小程序中嵌入腾讯云音视频SDK，并封装成live-、live-标签，让小程序支持更低时延的直播协议，例如： rtmp 、 http-flv 等

因此，我们可以使用live-来播放rtmp和http-flv协议流媒体，以减少小程序直播场景下的延迟。

但目前live-还存在一些不足：

使用直播——延迟大概在1-2秒左右，那么小程序上有没有延迟更低的直播方案呢？

在腾讯云开通后，您可以使用-room实现小程序低延迟直播。 原理基于live-RTMP，但采用高速专线，不经过CDN，降低了延迟。

（小程序接入课堂音视频整体架构图）

2）、录播场景

介绍完直播接入方案，我们再来说说录播。 由于版权保护，腾讯课堂录音和播放均采用加密HLS。

由于录制和播放没有延迟要求，因此可以直接在小程序上使用标签来播放加密的HLS流。

在Web上，播放加密HLS的流程如下：

1.获取加密HLS的m3u8地址并传递给；

2、浏览器底层解析m3u8，发现其有加密协议标识-EXT-X-KEY，其值为获取解密密钥的接口地址；

3、浏览器会自动发起请求获取解密密钥；

4、当浏览器自动发起请求时，会通过该方法带上用户的登录状态。 业务后台认证后会返回解密密钥。 之后浏览器得到解密密钥后就可以解密并播放了。

但在小程序中，由于小程序不存在，那么如何验证小程序发起的解密密钥请求呢？

当我们获取m3u8文件时，我们将加密后的认证参数添加到meu8地址中，并添加前缀“..”。 这样，当m3u8文件返回时，就会在EXT-X-KEY的请求地址中添加认证参数。 拼接进去。后续请求时，业务后台获取认证参数并按照协商好的方法解密，然后获取用户登录凭证，判断用户是否为合法用户。 之后按照前面的流程，如果认证通过，就会返回解密密钥。

2.小​​程序自动发布

完成音视频功能后，我们的项目就正常上线了。 随着平台功能的不断丰富，小程序也按照以下流程迭代发布。

但上述过程中还存在一些隐藏的问题。 尤其是对于新人来说，很容易因为疏忽而犯错误。 这也导致了现有的网络错误。 不知道大家能找到吗？

为了揭晓答案，有两个主要问题：

我们希望在上传发布之前能够自动检测以下进程：

1. 代码合并主干检测

2.版本检测必须大于等于当前.json版本

3.自动执行构建npm操作

4.自动执行上传操作，包括填写版本号和备注信息

其中1和2可以通过npm命令来判断。 3和4涉及到能力调用相关的小程序。 有没有暴露的接口可以调用？

这里的小程序开发者工具提供了命令行和http调用方式（），可以让你操作项目如打开/关闭、代码上传、预览、构建npm、自动化测试等功能。 因此，我们利用这个能力来实现使用cli调用等方式构建npm并自动发布的能力。

具体流程如下：

1.检查最新的中继代码是否更新；

2、判断小程序开发者工具是否安装以及环境变量设置正常；

3、进行本地版本检测；

4.调用 npm命令；

5、自动获取.json的版本号作为上传版本，并获取git提交日志作为笔记； 6.调用上传命令进行上传。

3.小程序第三方平台

有了以上工具，我们就可以愉快地进行开发和迭代发布了。 但随着我们课堂平台小程序的推广，课堂平台上的每个机构都希望有自己的机构小程序，其页面是课堂平台小程序的子集。

经过分析，我们决定通过构建将机构小程序代码与平台小程序分离。 通过两套模板配置信息，可以通过构建动态生成平台小程序和组织小程序的app.json。 通过这种方式上传时，只会上传对应的页面。

代码复用的问题解决了，但是还有一个问题。 需要生成的机构有80多个，有些机构不一定有开发者。 如果可以帮助机构快速上传发布自己的机构小程序呢？

这里介绍一下微信第三方平台的概念（list&t=/&=1&id=&=&lang=zhCN）。 我们可以向微信开发平台申请成为第三方平台。 机构申请独立小程序账号后，授权给我们的第三方平台腾讯课堂。 这样我们就可以获得组织对代码管理和版本发布的权限。 通过上传我们之前搭建的机构小程序的模板，然后调用发布接口，我们可以快速帮助机构将其独立个体发布到机构小程序中。

4.性能优化实践

我们的小程序上线后，通过在小程序管理后台查看总启动时间，发现几个问题： 1、小程序管理后台只显示总启动时间、下载时间、渲染时间。 数据纬度，而是总的启动时间！ =下载时间+渲染时间；

2、启动时间实际达到了3.8s。 这是一个合格的数字吗？ 除了下载时间和渲染时间之外，其他时间都花在哪里了？

想要知道时间都花在哪里了，首先要了解小程序启动过程中到底发生了什么。

1.小程序初始化

在这一步中，微信会初始化小程序环境，比如逻辑层、视图层的js引擎，并注入公共基础库。

2.下载小程序代码包

业务小程序代码包在这里下载。

3.加载业务代码包

下载完成后注入并执行代码包——小程序的代码将被加载到相应的线程中执行。 此时，所有app.js、页面所在的JS文件以及所有其他JS文件都会自动执行一次，小程序基础库将完成所有页面的注册。