Electron 在作业帮直播课 PC 学生端的实践

背景

公司直播课业务快速迭代，PC 学生端日渐显现出技术栈老旧，模块依赖复杂等问题，导致稳定性问题不断，维护成本高，不能满足于业务需求迭代速度。在这种情况下，就需要重新设计和改造来提高应用的稳定性、扩展性、可维护性，高质高效地满足业务需求。

首先，简单介绍下 Electron：可使用端与 FE 技术栈构建跨平台桌面应用程序的开源框架，社区活跃。基于该框架开发的应用有 VSCode，Notion，Postman 等。

问题与目标

学生端集成了从课前设备检测、选课、课中环节的签到、媒体直播 / 回放、Cocos 题目、手势、语音、选项卡等多类互动，到课后环节的学习测验。复杂场景流程让⼀些问题更为凸显，基于这些问题及现状分析，我们确定了本次重构的主要方式和目标：

1. 前期实现简单，稳定性扩展性不足，维护多套直播间成本高，且无法保证线上质量，因此我们计划通过⼀套配置化的功能组件来满足多套直播间的需求，从而降低成本，并且其他业务线也可以低成本接入。

2. 可以通过进程隔离、架构分层、封装底层细节等手段来解决无规范、无封装调用引起稳定性的问题。降低业务迭代风险，提高线上稳定性，也是防迭代劣化手段之⼀。

3. 通过降低应用 CPU，内存资源消耗来解决部分低端机上卡顿体验不佳的问题。

4. 目前日志混乱缺失，定位问题成本高，无机制监控应用状态。可以建立应用日志及数据体系来解决，确保应用状态及线上问题有数据可查，并有数据指标来指导应用优化。

分析

以目标拆分，PC 学生端新架构如下：

存在平滑过渡需求，所以需要从运行流程方面做好规划，按模块优先级分批迭代替换。

PC 学生端生命周期及运行流程如下：

模块设计

按架构图拆解，列举⼀些核心功能模块，简述功能与设计思路：

信令模块

作用：信令主要用于主讲端、服务端、学生端之间数据交互。

设计：之前信令操作没有封装与业务逻辑耦合，维护成本高。

1. 对信令数据交互逻辑做了封装。业务研发只需注册相关事件即可收发信令，降低研发成本及风险。

2. 信令通道：使用 Node 实现长链接替换了之前 PPAPI 实现的信令数据交互逻辑，功能及稳定性更可控。

日志及数据链路

作用：日志在开发调试，线上问题追溯，应用监控都是必不可少的数据源。收集必要数据上报后多维分析来满足业务 / 技术指标，报警需求。

设计

1. 数据收集：客户端区分日志种类级别采用不同的刷盘和上报策略进行持久化，供数据消费环节使用。上报失败有补发机制避免关键日志丢失。

2. 数据链路：目前有指标监控报警、问题定位、业务数据分析多种结合了 OLAP， OLTP 的场景的需求，以公司单套数据基建无法满足。我们推动打通了公司的 Rlog 和 Nlog 数据通路，使得日志在⼀处上报即有 Rlog 的时效性及报警相关功能，又可以享受 Nlog 强大的数据处理基建的福利。

3. 数据消费：对于指标监控报警类需求则使用 Rlog 通路上的 promethus+grafana 满足，对于时效性 T+1 的业务 / 技术指标数据则使用 Nlog 通路上的报表平台满足。其他直播课定制化的数据需求，我们开发了哈勃平台，解决了直播课大前端团队线上 Case 定位难的问题。

下面是数据链路图，数据链路建设过程复杂可另起篇幅详述。

BVManager 模块

作用：BV（BrowserView）是 Electron 提供的一种 Web 容器。BVManager 模块主要是对 BV 容器生命周期的创建、更新、销毁和 JS/CSS 注入、层级切换、BV 池操作等的封装。

设计：

1. 在 BrowserWindow、iframe、BrowserView 中选择 Web 容器时，需要从性能、易用性、可维护性方面综合考虑。有多业务线接入需求，所以要在隔离性方面做到渲染进程间相互隔离，资源销毁可控，性能优异并有完备 API 满足业务场景，基于这些原因，最终选择了 BV。

2. 为性能与安全起见，在不同类型的 BV 中做了精细化的环境初始化，只注入必要的方法。

3. 业务使用 BV 时需要及时响应，做了 BV 池封装处理来提高用户体验。

各 Web 容器对比细节：

播放器模块

作用：集成流媒体 SDK，负责推拉流操作及视频帧渲染。

设计：

1. 早期是 PPAPI 封装数据处理逻辑，线上问题不少。新版将流媒体 C++ 部分封装为 Node 模块去做分流、转码、裁切、渲染等数据操作，性能及稳定性可控。

2. 渲染更改为视频数据消费侧主动拉取帧数据，避免 SDK 推视频帧数据在低端设备中消费不及时渲染数据堆积导致的卡顿及内存溢出。

流媒体数据相关链路如下：

还有⼀些 AI 模块、数据存储模块、IPC 通信模块、热更 / 热修复模块、打包签名模块等，这里就不一一列举了。

遇到的一些问题

新架构的迭代中也遇到了⼀些问题，这里记录⼀下：

1. 架构升级带来的新的兼容问题：

a. 杀毒软件对进程创建和文件读写权限的干涉导致的各类问题。

b. Win7 系统上 Electron 新版本的兼容性引起的 Crash 问题。

2. PC 学生端在部分低端设备中有卡顿现象。通过数据分析，4G 内存以下和 Win7 用户占比较大，PC 客户端需要对老旧系统设备做兼容。

以上为稳定性相关问题，按工单定量来看低端设备导致卡顿的工单占问题工单总量 70% 以上，杀软及安全设置问题占工单总量 20%。针对于低端设备兼容与杀软兼容性问题我们做了专项优化，主要三方面着手解决：

1. 通过火焰图分析定位到性能瓶颈，根据场景进行针对性的性能优化：

a. 对日志读写模块进行专项优化。

b. 对部分 Electron 第三方模块进行自研，增强扩展性及性能。

c. 部分低端机型下流媒体，Cocos 互动效果降级。

2. 安全相关优化：了解安全软件策略，尽量避免 CLI 运行可执行文件，非用户目录的文件读写，注册表的操作等系统敏感操作。

3. 规范 & 流程：

a. 建立 PC 端设备分级规范（设备分为不支持、不推荐、推荐），对于不支持、不推荐设备进行提示与引导，有助于快速解决用户问题。

b. 部分杀软问题可以从业务 SOP，应用相关提示引导来解决。

通过专项优化后，基本解决了上述问题。还有⼀些如特定 Win7 小版本系统上极小概率 Crash 等长尾问题需要持续跟进。

效果收益

综合来看优化效果明显，着重说以下几点：

1. 对于业务：

a. 产品配置化，技术模块化可以低成本的满足多种直播间需求，其他业务线也可以轻松的接入直播间功能。

b. 提高了线上稳定性，提供更好的用户体验。

2. 性能方面：在 CPU 及内存方面新架构消耗整体优于老架构。以教学内容及交互类似的课程对比新老架构：

老架构下：

新架构下：

3. 稳定性

a. Crash 率远低于老架构：经过灰度数据来看，整体应用 Crash 率均值为万分之 8，低于之前 0.6%。

b. 系统资源可控：通过下图可以看出在直播过程中有内存回收痕迹，新架构内存回收及时。

老架构：

新架构：

4. 迭代提效：PC 学生端分为 Electron 层、业务容器层、前端应用层。各层边界分工清晰明确，维护性与迭代效率的增加，也在⼀定程度上防劣化。

其他

该项目涉及到的业务流程和技术栈复杂，细节繁多，欢迎有感兴趣的小伙伴来一起探讨。感谢。

作者介绍：

刘泉有

作业帮直播 PC 端负责人，目前主要聚焦于直播、Electron、大数据应用基建方向，在该领域有一定的架构设计，优化与实践经验。