作者｜陈天辰

编辑｜贾亚宁

本文整理自腾讯CSIG在线教育部前端高级开发工程师陈天辰在GMTC全球前端技术大会（深圳站）2021上分享的《腾讯课堂小程序开发实践》。

大家好，我是腾讯CSIG在线教育部的陈天辰。我所在的团队主要负责腾讯课堂平台的开发和维护。加入团队以来，我围绕小程序做了很多探索和优化。我目前是腾讯课堂小程序的负责人。

我这次分享的内容分为五个部分。首先我们从整体的角度来看一下腾讯课堂小程序的技术演进。接下来我们将从开发经验、性能优化和监控系统三个角度来分享一些实践和经验。 ，最后做个总结。

腾讯课堂小程序的技术演进路线

我刚加入团队的时候，腾讯课堂小程序的工具链还处于比较原始的阶段。除了在编码层面使用web比较成熟的scss、lint、gulp来做一些语法级的编译之外，我们还依靠小程序开发者工具和管理后台手动完成。

石器时代

现阶段，大多数人只是简单地使用一些现有的工具，我们称之为腾讯课堂小程序的石器时代。

现阶段存在几个明显的问题：

为了解决手动操作带来的隐患，我们基于小程序提供的命令行工具从头开始构建小程序CI。让源代码编译、npm构建、上传、生成开发版/体验版二维码、自动化测试等流程在CI管道中自动流动。

同时，我们还将小程序CI与企业微信对接，实时同步小程序建设进度和小程序二维码，还支持通过企业微信主动触发小程序建设，解决了小程序建设的难题。开发版本2在测试过程中出现的问题。由于二维码过期，测试被中断。

为了解决发布流程不规范的问题，我们还将小程序的发布接入了业务发布平台。对发布平台进行流程流转、发布审核、发布环境管理、静态资源发布等流程，保证需求发布的质量、合规性和有序性。

工业时代

解决了开发过程中的问题后，我们将更多的精力投入到小程序的开发效率和性能上。在开发建设阶段，我们创建跨端的公共模块。通过同构开发，我们利用云开发辅助首屏性能优化，并替代部分后端开发。在施工方面，我们将施工工具从gulp迁移到gulp，这可以改善施工常规。更细致的优化。

发布后，通过完善监控和报警，可以使发布质量可视化，及时接收和感知出现的问题，减少用户反馈。

现代

至此我们可以看到整个技术演进过程，涵盖了小程序的开发、构建、测试、部署、发布和监控，形成了小程序的开发模式。这具体是如何做到的呢？

构建“酷”的开发体验

首先是发展阶段。我们想要形成一种可以称为“酷”的开发体验。这不仅仅指阶段，还需要涵盖测试和发布阶段：

为此，我们通过打造跨端可复用的公共模块、小程序CI、统一的业务发布平台等方式，提升了开发体验。

提升开发体验

跨端通用模块

从实际场景出发，之前我们有一个需求：产品希望在本机构正在直播的课程的每一端的课程详情页上有提醒，可以引导用户跳转到直播间收听向老师解释课程的细节。

公共模块

梳理了一下这个需求的流程，发现其实还是蛮简单的：

详情页渲染完成后->调用接口拉取直播间数据->渲染引导模块->用户点击跳转直播

可以看到，业务的主要逻辑在所有端都是一样的，但是如果你仔细观察这些逻辑的细节，你会发现每个端实际上需要不同的实现。例如，发起请求的API是在浏览器和小程序中实现的。他们是不同的；提示疲劳控制需要使用本地缓存能力，浏览器​​和小程序的API也不同；而在业务方面，直播间三端的页面地址也不同。

两端的逻辑差异

当然也可以通过运行时判断当前的执行环境，然后调用不同的分支逻辑来满足要求，但是这种方式会允许一端同时拥有来自三端的逻辑。如果这样的逻辑太多，就会造成明显的代码冗余，而且由于小程序端有2M包大小限制，所以对代码冗余相对敏感。

为了解决代码冗余的问题，大家自然会想到在构建的时候注入一个环境变量，利用树的能力在不同的一端构建对应端所需要的逻辑。但该方案对施工工具有一定的要求。在实际工作场景中，新老项目往往会因为历史原因而带有历史包袱，不仅是源码，还有构建中的技术栈，比如gulp、fis。等等，如果想全部统一的话，成本和风险会比较高。

因此，我们需要一个可以跨终端复用、按需打包、不依赖于项目构建系统的通用模块。

我们基于 git 的方法从三个维度开始：组件、业务和工具。每个维度根据具体逻辑和执行环境，分为同构目录（）、浏览器目录（lib）、小程序目录（wx）。 ，每个项目都以lib目录或wx目录作为入口点进行引用，入口文件会继承或传递目录中的逻辑。依赖于环境的特殊逻辑分别在lib目录和wx目录中实现。

在开发阶段，使用路径别名来统一引用路径。例如，在小程序项目中，将.json设置为“ke-/*”:“/ke-/*/wx”，这样可以统一业务层面的代码逻辑。在阶段，ts会单独编译成js。对于h5和PC项目，产品中只会内置lib目录和lib目录。对于小程序项目，产品中只会内置wx目录。

公共模块编译阶段

这样就保证了在保证兼容性的基础上不会产生冗余代码，从而满足我们之前提出的几个要求。

小程序CI/CD构建

我们之所以为小程序构建CI/CD，是因为开发者工具中很多手动操作导致的一系列问题，比如：

我们首先基于小程序官方提供的命令行工具进行了封装和扩展。支持小程序的npm构建、上传、获取二维码、自动获取版本号、版本信息等功能，作为小程序CI管道。核心插件。

CI管道支持通过git hook和手动方法触发执行。流水线流程执行过程中，代码拉取、分支检查、版本号迭代和版本信息更新、小程序代码包上传、开发/体验版二维码获取、小程序产品等文件归档，方便性能和评估。分析错误。

同时，CI插件连接企业微信机器人，将施工进度和搭建的小程序二维码同步到企业微信。还支持以@微信机器人的形式主动触发流水线执行，让产品和测试都能完成。您可以实时获取最新的小程序二维码进行测试和体验。

在发布阶段，与Web项目一样，接入统一的业务发布平台，在发布平台上规范发布流程，确保预发布、发布审核等流程正确执行。发布开始后，对发布环境进行管理，设置访问控制，保证同一时间只有一个需求在发布，避免多个需求并行造成的发布混乱问题。发布完成且现网观察没有问题后，环境将发布到下一个A需求。

小程序CI/CD流程搭建

搭建了这样的CI/CD流程后，之前遇到的问题都迎刃而解了。

这是我们在CI/CD方面的一些实践经验以及开发经验的一些解决方案。

小程序性能优化

小程序的启动方式分为冷启动和热启动，小程序的性能瓶颈大部分集中在冷启动阶段。

小程序冷启动

冷启动阶段分为上述步骤。环境初始化对于开发者来说是一个黑匣子，暂时无法干预。下载和加载代码包的时间主要与小程序代码包的大小有关。数据拉取需要开发者优化请求时序，页面渲染需要优化渲染策略。

音量优化

业务代码的体积优化需要通过构建来解决。从项目的常规结构来看，我们一般都会将一些可能复用的模块放到公共模块中。如下图所示，如果只编译引用关系，根据小程序的规则，公共模块和组件的大小会被计算到主包中。我们希望通过建设来优化产品结构，避免主包装过大的问题。

主包太大了

此外，随着需求的迭代，对某个组件的引用可能会丢失。这种情况下，根据小程序的规则，仍然会算在主包中。你可以看到下面的图片。我们希望通过构建过滤掉未使用的模块或组件。

不过滤未使用的模块

另外，如果子包和主包引用了同一个模块，则可以将该模块计算到主包中。但是，如果这个子包是一个独立的子包，那么就引用主包。模块可能会报告错误。对于上述情况，需要通过构建的方式复制模块，并将其置于独立的分包下，以保证小程序的正确执行。

独立分包参考错误

我们面临的上述三个问题的核心思想之一就是我们需要在构建过程中对小程序的规则进行依赖分析。下面我们对目前市场上比较成熟的施工工具进行比较，并从四个维度进行分析：

支持组件依赖分析

从对比结果来看，需求支撑较为成熟。我们最终决定选择它作为小程序的构建工具，但是它不支持小程序的组件，所以需要我们自己支持。

使用app.js作为入口文件，根据小程序的配置规则找到对应的json文件，并逐层递归分析整个小程序所使用的页面和组件，将所有页面和组件作为.您可以在小程序中获取js模块的参考信息。

通过按照一定的策略计算参考信息：

分包

例如，如果一个页面引用了一个模块，首先判断该模块是否在分包内。如果是分包合同内的，则按照常规方案进行包装；如果不在分包合同范围内，则判断引用的分包合同是否为独立分包合同。如果是独立分包合同，则制作一份副本（新建一份）；如果是普通分包，则收集是否被多个分包引用。如果没有，则将该模块移动到子包中（创建一个新的并删除原来的）。

计算完成后，就可以使用load来处理其他资源文件，包括css、font，提取静态资源文件，并替换引用路径。

处理资源文件

处理完成后的效果也是相当明显的。我们的主包从1900多kb优化到了900多kb，优化幅度达到了50%。总包的某些卷也优化了 27%。

音量优化效果

优化的体积主要来自以下三个方面：

我们的优化对实际启动时间也有显着影响。主包下载时间优化43%，js注入时间优化18%。

启动耗时优化效果

兼容小程序的SDK方案

另一方面，当小程序需要使用npm形式的更复杂的SDK时，由于小程序的npm包需要单独构建，因此在编译时无法按需打包，这也会遇到尺寸较大的问题。 。

我们实际的业务场景中存在这样的问题。作为在线教育企业，腾讯课堂拥有直播互动的核心能力，即用户在线上课时以聊天、举手、接麦克风、画画等形式出现的互动行为。 。

为了让这个核心能力能够实现跨端、跨业务复用，我们团队开发了直播互动SDK，对外提供简单的API，内部设计了接口层、适配层、通道层、策略层和结构。它非常清晰且易于使用。初始化后，开发只需要监听或者请求对应的命令字，无需关心内部的转换，可以利用ts的类型推断能力，直接获取通道返回的数据类型。

改造前结构及用途

但当我们接入小程序时，遇到了几个问题：

为了解决上述问题，我们必须升级SDK。

我们的改造方案是实现插件化处理，提取接入层（业务层）和适配层作为SDK的核心，并增加对插件的适配管理，整合策略层和通道连接层的逻辑。进行抽象处理，根据抽象类和业务需求，制定相应的规范，实现相应的策略插件和通道插件。

插件改造

业务转型非常简单。您只需在初始化前注册当前场景和功能所需的插件即可。后续使用和之前一模一样，业务改造成本很低。

修改后如何使用

在兼容性方面，通过打包的方式，在构建时注入不同的环境变量，输出对应端所需要的内容。

盒

插件化改造后，好处显而易见：

运行时请求优化

请求优化也是小程序性能优化中非常重要的一环。在冷启动和页面跳转过程中，我们分别优化了请求时序和弱网络阻塞情况。

关于请求时序，可以利用小程序的全局应用实例将数据请求时序提前到页面加载之前，进一步利用小程序的数据预加载能力将首屏数据请求时序提前到小程序加载时。推出：

请求优化

页面加载前发起请求的流程如下。当页面跳转或者页面跳转时，直接发起下一页的请求，并将请求挂载到app实例上。当页面加载启动时，直接通过app上的返回进行处理。根据我们的统计，可以优化平均渲染时间，可以将相对静态的数据缓存在本地，在页面第二次加载时通过缓存的数据进行渲染，达到秒开的效果。

页面加载前发出请求的过程

数据预拉取类似于Web服务器端渲染。小程序启动时，云函数根据启动参数调用业务后台服务获取数据并返回给小程序。小程序启动后，可以直接使用预拉取的数据。数据渲染完成，成功预取平均可以优化90%的首屏数据请求时间。

数据预拉取流程

除了上述一般情况下的请求优化外，我们还注意到小程序有网络使用限制，最大并发数限制为10，这会造成隐患。由于小程序加载和用户交互过程中会产生很多上报请求，比如PV上报、错误日志等，在网络弱的情况下，很容易出现上报请求响应慢、阻塞的情况发送业务请求，导致超时。我们确实收到了类似情况的反馈。

为了优化弱网情况下的隐患，我们对请求队列进行了优化。通过设置请求池和等待队列，并劫持wx.，我们在发送请求时对请求的URL进行优先级排序，将业务请求设置为高优先级请求，降低上报请求的优先级。当请求通道比较紧张时，会先发送高优先级的请求，当请求通道空闲时，会重新发送低优先级的请求。

弱网下请求排队

实际运行时的逻辑如下：

弱网下请求排队操作逻辑

渲染优化

视图渲染和更新可以通过推迟非首屏和非核心模块数据的更新来优化，因为更新太大的视图数据会增加通信和解析时间。以我们最复杂的课程详细信息页面为例。由于模块较多，页面比较长，通常有5到7屏内容。如果需要等到页面上的所有数据都读完才开始更新视图，那么白屏时间和视图更新时间会更长。更合理的渲染策略应该是优先首屏，分步渲染。

首屏优先，分步渲染

但由于小程序的双线程模式，更新视图的方式是同步更新逻辑层数据，异步更新视图层数据。因此，不能简单地在处理完部分数据后调用并继续处理其余数据。即使不进行分步渲染，所使用的回调或方法也会造成逻辑嵌套问题，降低代码的可读性和可维护性。

针对这个问题，我们的解决方案是根据表示封装一个类，这样我们就可以通过then方法将小程序的渲染拆分为多个步骤，从而达到渐进渲染的效果。

渐进式渲染

通过分步渲染，我们可以将首屏渲染的启动时间提前到90ms，从而减少用户的等待焦虑，提升用户体验。

质量保证监控系统

一个产品的质量不仅取决于良好的产品设计和代码质量，还需要很大一部分收集操作和性能日志，为技术优化提供解决方案。监控现有网络上报告的错误的比例和数量使我们能够及时响应并修复。之前我们的小程序举报依赖于几个举报系统：

通过不同系统报送时存在一些问题：

解决这些问题的首要任务就是将这些上报的SDK进行整合，根据产品和业务的需求，将日志采集、测速、监控、上报集成到一个SDK中，并统一上报的数据结构。部分功能将在SDK中进行备份转发，保证原有报表系统的功能也能使用。

监控系统

结合小程序提供的多个API，可以在收集日志的同时对用户进行多维度的统计：

性能监控

在统一报表数据结构的前提下，可以定制多维度的统一仪表板，降低质量监控成本。

图像性能监控可视化

总结

以上就是本次分享的主要内容。让我们简单总结一下。

随着课堂小程序的技术演进，围绕小程序的开发模式逐渐形成：在开发阶段，我们创建了兼容小程序的公共模块，通过以下方式提高小程序的研发效率： 30%到40%。同时，在CI/CD建设方面，降低了人工操作的风险，充分利用工程自动化，解放开发的生产力。而且小程序CI建设非常通用，公司内部已经接入了140+个项目。

改善开发体验

性能优化方面，我们通过体积、请求、渲染等方面的优化，将冷启动首屏性能优化了1.5秒，优化比例达到42.7%。

性能优化与提升

在监控报警方面，通过小程序的API结合集成的报表SDK，可以进行更详细的统计，并且可以定制可视化效果。

图像监控报警改进

前景

其次，小程序还有一些非常有用的功能可以利用。我们更关心分包、异步化和自动化测试。

1. 异步打包策略

分装异步可以大大减小首屏封装的尺寸。目前分包异步功能已经适配到2.11.2基础库版本，并且兼容性问题也已经解决；获得分包异步能力，在构建和打包小程序时，可以尝试将页面拆分为首屏包+异步逻辑包+异步组件包的形式。结合分包预加载功能，减少首屏代码包下载时间和加载时间。最小化。

2. 基于录音和回放的自动化测试

小程序团队长期支持小程序的自动化测试。然而，就UI自动化测试而言，测试用例的维护成本是最大的痛点。我们尝试将操作过程记录在本地，并按照一定的约定转换成测试用例，这样可以非常有效。大大降低测试用例维护成本，提高代码质量。

关于作者

陈天辰

腾讯CSIG在线教育部前端高级开发项目

2019年加入腾讯，现任腾讯高级前端工程师、团队成员。负责腾讯课堂平台教研方面的开发和维护。作为腾讯课堂小程序负责人，在小程序性能优化、持续集成等方面有着深入的见解和丰富的实践经验。2019年，小程序CI在公司内部开发上线，并持续进行优化和迭代。其跨系统兼容性和优秀的用户体验已被各BG 150多个项目接入使用，为开发测试和产品赋能，依托腾讯CI开发的小程序插件荣获2020腾讯CI年度优秀插件——在。

推荐活动

2022年6月10-11日，GMTC全球前端技术大会将再次在北京召开。前端业务架构、前端、前端性能优化、物联网动态应用开发、移动终端性能与效率优化、前端成长实践、可持续团队建设、跨端技术选型等15个专题，最热门的方向，解决您最紧迫的问题。

点击底部【阅读原文】可直接进入会议官网。会议早鸟票优惠30%，即刻优惠1440元。小组学习还有更多惊喜。有兴趣的同学可以联系票务经理：

点击查看更少的错误