前言：小程序是一项新的开放能力，开发者可以快速开发一个小程序，在微信中可以方便的获取和传播，并且拥有极佳的用户体验。随着近两年小程序的爆发，越来越多的开发者和企业开始接入小程序。那么在在线教育领域，小程序能做什么呢？本文将介绍腾讯在线教育的小程序矩阵，以及如何进行框架选型设计、工程探索、性能优化等实践。
1. 腾讯在线教育小程序矩阵
首先我先介绍一下腾讯在线教育的三大主营业务：
各业务均有PC Web端、客户端、H5、APP端，满足学生多端学习需求。但由于教育前身是基于QQ群视频孵化的，后续的产品形态也是围绕QQ生态构建的，因此在流量方面，QQ相关流量占比较大。
我们希望利用小程序生态为我们的教育业务增加微信的流量，并优化学生在微信上的课堂体验，所以我们打造了在线教育的小程序矩阵。
我们通过工具型、内容型小程序获取流量，比如腾讯课堂开放小程序、腾讯微课堂、企鹅速算、口语拼读等工具型小程序，并最终转化为平台型小程序。
2. 小程序基础设施设计与工程探索
对于上面提到的众多小程序，我们如何选择框架，如何制定统一的开发规范，在多人协作开发中探索小程序工程化？下面将一一介绍。
在框架选择上，我们对比了几个主流的小程序开发框架，taro，wepy，以及原生开发框架。可以看出，原生框架相比其他框架，在 CSS 预处理、多端复用、数据管理、自动构建等方面的能力有所欠缺。但考虑到以下几点，我们更倾向于使用原生框架进行开发：
那么，使用原生框架能解决上述开发缺陷吗？该如何解决？
1. CSS 预处理
首先我们来看CSS预处理，我们期望在小程序中能够使用CSS预处理，包括嵌套语法，变量等工具，调研之后直接用来编写样式文件，编译到wxss中就可以了。
并且通过引入插件，解决小程序样式开发中的痛点。例如-url解决不支持本地图片的问题，并转换成格式；-font-插件将字体转换成格式。
2.数据管理
对于数据管理，您可以使用访问。
3. 构建
搭建一个小程序需要做什么？小程序开发者工具已经提供了一些能力：ES7/ES6 到 ES5 的转换、NPM 包管理、代码分包、组件化、包合并。我们使用 gulp 来实现上面提到的图片压缩和编译。
为什么要用gulp，而不使用更流行的呢？这里补充的能力主要是文件处理能力，使用gulp开发效率更高，官方的一些小程序脚手架也是用gulp的。
最终我们选择了小程序原生框架作为我们的开发框架，弥补了之前相对于其他开发框架所欠缺的基础能力。当然，这并不是说其他框架不好，具体的选择还是要看具体的业务场景。
4. 目录规范
确定开发框架之后，统一的目录规范也是团队协同开发的必备条件。引入npm包管理之后，我们在小程序的基础目录下新建一个目录，作为小程序代码的根目录。这是因为小程序会把里面的包打包编译到目录下。为了避免小程序和其他工程相关的混在一起，新建一个文件夹存放小程序项目代码。小程序代码的根目录路径可以通过修改..js来配置。
5. 编码标准
约束了目录之后，团队协作开发中如何保持代码规范统一呢？我们希望团队成员在开发时能够统一代码规范、提交规范、风格。因此像我们其他的web项目一样，可以使用、、、等插件来约束规范自己的代码。提交时使用git hook进行验证检测，失败则不允许提交。
使用 和 - 可以自动生成统一的版本号和。它会自动生成您在此版本迭代中提交的标准化日志（遵循团队的规范：#），标明是否为特性发布或，以及对应的日志信息。后期当我们需要回滚或者追溯某个版本的变更时，就可以一目了然了。
基于以上的能力和约束，我们创建了统一的脚手架，方便团队在统一的环境下进行快速开发，并且将其开源（）。
3. 小程序开发实践
介绍完我们的框架选型和工程探索之后，我们来分享一下我们在开发在线教育小程序的实战经验。
1. 小程序音频和视频
第一部分是小程序音视频能力相关的实践。腾讯课堂是一个在线学习平台，所以核心就是音视频直播和录制能力。那么如何在小程序上构建课堂音视频能力呢？
1）直播场景
我们先来看一下腾讯课堂在接入小程序之前的直播架构，我们通过老师上传到云端，然后实时下载到客户端、App学生、PC Web学生。对于对延迟要求不高的场景，我们可以将直播流绕过去转码到CDN，然后让用户拉流观看，节省成本。
这是各个端使用的直播协议以及延迟对比，小程序应该采用什么协议，如何接入？
在揭秘之前，我们先来回顾一下小程序音视频能力的发展历程。最初，小程序只有原生的音视频标签，也就是说只能支持HLS高延迟直播场景。
2017年4月，腾讯云与小程序达成合作，在小程序中嵌入腾讯云音视频SDK，并封装成live-、live-标签，使小程序能够支持rtmp、http-flv等更低延迟的直播协议。
因此我们可以采用live-play rtmp、http-flv协议流媒体进行播放，降低小程序直播场景的延迟。
然而live-还存在一些不足：
使用live-，延迟大概在1-2s左右。那么有没有小程序上延迟更低的直播方案呢？
如果你开通了腾讯云账号，可以使用-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的请求地址中，后续发起请求的时候，业务后端获取认证参数，按照协商好的方法解密，就可以获取到用户登录，判断是否是合法用户，之后按照前面的流程，如果认证通过，则返回解密key。
2. 小程序自动发布
在完成了音视频能力之后，我们的项目就正常上线了，随着平台功能的不断增加，小程序也按照如下的流程进行迭代发布。
但是上面的过程存在一些隐藏的问题，尤其对于新手来说，很容易因为疏忽而犯错，并且我们还造成了现网的一个bug，不知道大家发现了没有？
要揭晓答案，主要有两个问题：
那么我们能否利用自动化工具来帮助我们验证和检测这些隐患呢？
我们希望在上传和发布之前自动检测以下过程：
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多家，有的机构可能没有开发人员，如何帮助机构快速上传发布自己的机构小程序？
这里引入微信第三方平台的概念（）。我们可以向微信开发平台申请成为第三方平台。机构申请独立小程序账号之后，将其授权给我们腾讯课堂第三方平台。这样，我们就可以获得机构的代码管理和版本发布权限。通过上传我们之前建好的小程序模板，调用发布接口，就可以快速帮助机构将其独立个体发布到机构小程序中。
4.性能优化实践
我们的小程序上线之后，通过查看小程序管理后台的总启动时间，我们发现了几个问题：
1、小程序管理后台只展示总启动时间、下载时间、渲染时间三个数据维度，但总启动时间 != 下载时间+渲染时间；
2、启动时间高达3.8s，这个数据合格吗？除了下载时间和渲染时间，这些时间还花在了哪里？
要知道时间都消耗在哪儿，首先要了解小程序启动过程中发生了什么。
1. 小程序初始化
这一步微信会初始化小程序环境，比如逻辑层、视图层的js引擎，注入公共基础库。
2.下载小程序代码包
业务小程序代码包在这里下载。
3.加载业务代码包
下载完成后注入代码包并执行——小程序的代码会被加载到合适的线程中执行。此时所有的app.js、页面所在的JS文件、以及其他所有的JS文件都会自动执行一次，小程序基础库会完成所有页面的注册。