我们基于上面的能力以及约束规范，做成统一的脚手架，方便团队在统一的环境下快速开发，并且开源了：https://github.com/imweb/generator-imweb-wxapp 。

小程序开发实践

介绍完我们的框架选型，工程化探索，接下去分享下在线教育小程序的开发实践经历。

小程序音视频

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

1. 直播场景

我们先来看未接入小程序前，腾讯课堂的直播架构。我们通过老师上行到云上，再实时下行到端上, App 学生以及通过 WebRTC 下行到 PC web 学生。对于延迟要求不高的场景，我们可以将直播流旁路转码到 CDN，再供用户拉流观看，以节省成本。

这是各端使用的直播协议以及延迟对比，小程序应该采用那种协议，如何接入呢？

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

2017 年 4 月份，腾讯云与小程序达成合作，在小程序上嵌入腾讯云音视频 SDK，并封装成了 live-pusher,live-player 标签,使小程序能够支持更低延迟的直播协议，如：rtmp, http-flv 等。

因此，我们可以使用 live-player 来播放 rtmp,http-flv 协议的流媒体来播放，降低小程序直播场景上的延迟。

不过目前 live-player 还存在一些不足:

• 比如全屏按钮不支持，需要自己定义。

• 由于 live-player 是原生组件，因此需要通过 cover-view 以及一些 hack 方式来实现自定义控制条的全屏按钮跟视频窗口显示层级的 bug。

• IOS 全屏时，bindevent 无效。

不过小程序后面采用同层渲染的方案，解决了原生组件需要使用 cover-view 来解决显示层级问题，使用最新版本的基础库即可。

使用 live-player 大概 1-2s 的延迟，那么小程序上还有没更低延迟的直播方案呢？

加入你是在腾讯云上面开通了 WebRTC 后，可以使用 wbertc-room 去实现小程序上更低延迟的直播。其原理是基于 live-player 的 RTMP，但走的高速专线，不经过 CDN，降低了延迟。

(小程序接入课堂音视频的整体架构图)

2. 录播场景

介绍完直播接入方案，接着讲下录播。由于版权保护，腾讯课堂录播播放采用了加密 HLS。

由于录播对延迟没要求，小程序上面可以直接使用 video 标签来播放加密 hls 流。

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

1. 获取到加密 HLS 的 m3u8 地址，传给 video;

2. 浏览器 video 底层解析 m3u8，发现其带有加密协议标识-EXT-X-KEY，其值是一个获取解密 key 的接口地址；

3. 浏览器会自动发起该请求，发起请求，去获取解密 key；

4. 浏览器自动发起请求时，会把用户登陆态通过 cookie 方式带上，业务后台对 cookie 鉴权后返回解密 key，之后浏览器拿到解密 key 后就可以解密播放了。

但在小程序中，由于小程序是没有 cookie 的，那么怎么去针对小程序发起的获取解密 key 请求鉴权呢？

我们通过在获取 m3u8 文件时，在 meu8 地址加入加密后的鉴权参数，并加上前缀"voddrm.token."，这样 server 返回 m3u8 文件时，会在 EXT-X-KEY 的请求地址上，将鉴权参数拼接进去。后面发起请求时，业务后台获取到鉴权参数，按照协商好到方式解密，即可获取到用户登陆票据进行判断是否合法用户。之后就按照之前的流程，鉴权通过即返回解密 key。

小程序自动化发布

补齐了音视频能力后，我们项目也正常上线。由于平台功能不断增加，小程序也在按照以下流程进行迭代发布。

但是上面流程是存在一些隐藏问题的，特别对于新人，容易因疏忽导致出错，我们也因此导致了一个现网 bug。不知道大家能发现不？

揭晓下答案，主要有 2 个问题：

1. 多人开发过程，npm 包可能存在不同版本，比如登录能力的 npm 包，有可能会忘记更新最新包。

2. 构建 npm 按钮在开发者工具上面入口比较隐蔽，容易导致更新了 npm 包但是忘记点击构建 npm，覆盖了线上的特性.

上面操作对于熟悉小程序开发的人来说不容易出错，但对于新人，由于不熟悉，容易疏忽。即使犯错但概率很小，但是也必须解决。

那么我们能否通过自动化工具来帮我们校验检测这些隐患呢？

我们希望在上传发布前，可以进行以下流程的自动检测：

1. 代码合并主干检测。

2. node_modules 版本检测，必须是大于或者等于当前 package.json 的版本。

3. 自动执行构建 npm 操作。

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

其中 1 跟 2 可以通过 githook 以及 npm 命令来判断，3 跟 4 涉及到小程序相关到能力调用，是否有暴露相关到接口可以调用呢？

这里小程序开发者工具提供了命令行以及 http 调用方式：https://developers.weixin.qq.com/miniprogram/dev/devtools/cli.html

，可以让你操作项目打开/关闭，代码上传，预览，构建 npm, 自动化测试等功能。因此，我们利用这个能力，采用 cli 调用等方式，实现了构建 npm 以及自动发布等能力。

具体流程如下：

1. 进行是否更新最新主干代码检测；

2. 判断是否安装了小程序开发者工具且正常设置到环境变量；

3. 进行本地 node_modules 版本检测；

4. 调用构建 npm 命令；

5. 自动获取 package.json 的版本号作为上传版本，获取 git 提交 log 作为备注；

6. 调用上传命令进行上传

自动化发布流程示例

小程序第三方平台

有了以上工具后，我们就可以愉快地进行开发迭代发布了。但随着我们课堂平台小程序的推广，课堂平台的各家机构都想拥有其自己的机构小程序，并且其页面是课堂平台小程序的一个子集。

通过分析后，我们决定通过构建的方式，从平台小程序中拆离出机构小程序代码。通过 2 份模版配置信息, 通过构建，可以动态生成平台小程序以及机构小程序的 app.json。这样进行上传的时候，就只会上传对应的页面。

代码复用的问题解决了，但随着而来还有另外一个问题。需要生成的机构有 80 多家，有些机构不一定有开发人员，如果帮助机构快速上传发布他们自己的机构小程序呢？

这里引入微信第三方平台的概念，我们可以往微信开发平台申请成为第三方平台。机构申请完独立的小程序账号后，将其授权给我们腾讯课堂第三方平台。这样我们就可以获取到该机构到代码管理，版本发布到权限。通过上传我们之前构建好到机构小程序模版，再调用发布接口，就可以快速实现帮助机构发布其独立个体到机构小程序了。

性能优化实践

我们的小程序上线后，通过在小程序管理后台看到的启动总耗时，发现几个问题：

1. 小程序管理后台只展示了启动总耗时，下载耗时，渲染耗时这 3 个数据纬度，但是启动总耗时!= 下载耗时 + 渲染耗时；

2. 启动耗时居然达到了 3.8s，这是一个合格都数据吗？除了下载耗时跟渲染耗时，其他耗时消耗在哪个环节呢？

要想知道耗时消耗在哪里，首先要先了解小程序启动过程中究竟发生了什么。

**1. 小程序初始化 **

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

**2. 下载小程序代码包 **

这里会进行业务小程序代码包的下载。

**3. 加载业务代码包 **

对下载完成对代码包进行注入执行 - 小程序的代码会被加载到适当的线程中执行。此时，所有 app.js、页面所在的 JS 文件和所有其他被 require 的 JS 文件会被自动执行一次，小程序基础库会完成所有页面的注册。

**4. 初始化小程序首页 **

拉取数据，从逻辑层传递到视图层，生成 VD 树，进行渲染。

了解完小程序的启动过程后，我们经过分析定位，个阶段耗时如上图所示。

其中灰色部分是小程序底层的执行耗时，这块开发者是无法操控的。那在其他耗时中，下载代码包这块占比比较高。我们能怎么去减少这块耗时呢？

原先对课堂小程序的所有页面都是在一个包里面，那么这里我们采用分包方案。将主 tab 的 3 个页面以及 util, 常用组件这种公共模块放在主包。其他每个页面单独分成 300-500k 左右大小对子包，子包可以引用主包对公共模块。

经过分包处理后，下载代码包对耗时减少了 500ms 左右，整体启动耗时降到了 3.2s。整体来说，已经比小程序大盘平均启动耗时 4.5s 少了 1.3s。

不过随着而来的，也有其他问题的引入，比如从首页打开课程详情页这一场景。

这个时候点击详情页时，需要先下载完详情页分包，才能打开课程详情页，显然这样的体验是极差的。

我们可以通过分包预加载的方案，来解决这个问题。打开首页，加载完主包后，可以静默加载其他分包，通过配置 preloadRule 即可实现分包预加载。

下面是一组本地测试数据，可以看到使用分包以及分包预加载的方案，可以减少启动耗时以及提高用户体验。

除了普通分包方案，小程序还有独立分包的方案。不依赖主包加载，即可打开分包页面。常用于一些比较独立的页面，比如活动页等。

但使用独立分包也有一些限制：

• 独立分包无法引用主包或其他分包的资源。

• 全局 App 对象只能在主包定义，独立分包不能使用 App 对象。

• 生命周期只能通过：wx.onAppShow, wx.onAppHide 来监听。

解决了代码包下载的耗时以及采用分包，以及分包与加载提高页面打开性能以及效率。我们接下来看渲染耗时这块。

这是一个典型但小程序双线程通信的模型。每次调用 setData 方法，都会将数据从逻辑层传递到 native 层，再到渲染层，形成 VD 树进行渲染。

以上是 setData 传输数据量以及传输时间的关系图，可以看到当数据量大于 64kb 时，传输时间呈指数级增长。

因此，在使用 setData 时，应该尽量遵循以下建议：

• 不要频繁调用 setData, 尽量合并到一次 setData 调用。

• 传输数据量跟通信性能有关，尽量少于 64k，避免一些不需要在页面展示的复杂数据结构或者长字符串。

• 与界面无关的数据最好不要设置在 data 中。

• 去掉不必要的事件绑定，减少通信的数据量以及次数。

• 不要在节点 data 前缀放置过大数据（需要传输 target 的 currentTarget 和 dataset）。

公共基础组件库

为了提高开发效率，代码复用率，我们对常见的一些能力以及功能型组件进行了封装（后续计划开源）。

这里拿基础能力的 request 组件来看，我们基于 wx.request 来封装，利用 storage 来存储登陆后的 cookie 信息，并在后续发起请求的时候，将登陆票据设置到请求头中。

采用可插拔插件式封装方法，来做各种插件到扩展。例如有 loading 插件，一个可以在发起请求的时候，自动显示 loading，请求完成后，自动隐藏的插件。

以上就是小程序开发实践相关的分享。

QQ 小程序

QQ 小程序是一个基于手 Q 庞大流量，面向年轻化群体，跟随小程序行业标准的小程序平台。启动于 18 年 12 月份，并于 6 月底全量发布，目前覆盖微信小程序 API 达到了 95%以上。

从用户侧来看，基本跟微信小程序类似。在聊天下拉即可发现小程序入口，里面有小程序商城，可发现各类小程序以及小游戏。它的开发者工具的 UI 也类似微信开发者工具。

它跟微信小程序之间有以下的一些区别：

API 以及功能方面

• 调用前缀：例如：qq.getSystemInfoSync (也兼容 wx 语法) ，覆盖率 95%。

• webview: QQ 小程序暂不支持 webview 。

• 唤起方式：支持 http 链接唤起小程序。

• 组件：不支持 live-player, live-pusher 组件。

• 分享：QQ 小程序支持分享到 QQ 空间。

开发者工具方面

• 底层框架：都是基于 nw.js。

• 编译能力：

• 不支持增强型编译。

• 不支持多核心编译。

• 其他

• 不支持体验评分。

• 不支持自动化测试。

总的来说，QQ 小程序的 API 基本对齐微信小程序，它的迭代速度较快，能力逐渐补齐中。并且拥有 QQ 生态流量红利，最重要的是从微信小程序迁移到 QQ 小程序工作量较小，代码 95%以上基本可以复用。

总结

小程序生态发展之迅速，支付宝，百度等各大厂商都在各自研发自己的小程序。从开发者的角度来说，希望能够统一一套 API 规范，形成行业标准。前不久 W3C 中文兴趣组也在对小程序的生态进行了规范的相关讨论，相信后续必然会朝着标准化的方向发展。