ALive：淘宝双 11 直播，技术同学却可以“偷懒”？（二）

▶ 技术实现

1、直播容器

我们设想的灵活、高效的直播容器，应该具有以下几个特征：

• 统一规范的组件消息协议：包括组件包名、组件行为、业务自定义字段等，统一由 PowerMessage 的固定消息下发

• 支持动态加载：直播间不同于其他详情页，互动的发送依赖主播操作，也依赖用户进入直播间的时机，每个用户参与到的互动可能都不一样，所以互动组件的动态加载对首屏性能很关键

• 缓存及依赖去重：同一个互动，主播可以多次推送，各个互动依赖的基础库（rax-xxx、universal-xxx）也存在较多重复，所以设计合理的缓存和依赖去重机制对性能提升也很重要

• HOC 高阶组件：直播间里的业务开发不同于其他独立的源码页面，比如直播间数据获取、消息和事件监听、横竖屏状态获取、带小窗跳转、直播观看时长等等都依赖直播间环境或者客户端 API，业务组件都需要这些基础能力，需要通过 HOC 来增强业务组件

基于这些特征设定，我们设计的直播容器技术结构如下：

直播容器的核心工作流程包括以下几点：

• 消息和指令：容器初始化时从 Native 获取缓存里 Mtop 请求的组件列表，同时消息模块监听 Native 转发的固定消息。协议解析成标准化指令，交给渲染模块执行后续操作

• 渲染管理：渲染模块接收到创建、更新、销毁组件指令后，传递给组件 HOC，如果是创建组件指令，则从加载引擎拉取组件 bundle

• 加载引擎：rloader 维护了组件缓存，当拉取的组件不在缓存内时，会解析依赖，优先从缓存的基础依赖里查找基础组件，如果没有则 combo 拼接，最后拉取最小量的组件 bundle，并将拉取的 bundle 加入缓存

• 组件 HOC：高阶组件除了上述的能力，还提供了 API Bridge、全局变量注入、事件分发以及一些监控容错等机制

2、 ALive 工程体系

笔者加入淘宝直播后接手的第一个项目，是由客户端同学开发的 H5 版本亲密度组件，直播间里的组件开发强依赖客户端环境，当时的开发调试手段只能通过 Charles 代理本地静态资源，没有日志、没有断点、没有 Mock ，开发环境极其恶劣。

引入直播容器后，改善了性能，但是在直播间里开发组件，需要一个完整的直播间环境和直播容器才能开发调试，没有配套的工程体系，组件开发依然很低效。我们设想的 ALive 工程体系，应该包含以下几个部分：

• ALive def 套件：直播间组件开发脚手架，增强调试能力，包括直播间模拟、调试代理、热更新、编译检测等功能

• 直播间 Debug 工具：基于直播容器开发一个 Debug 组件，提供日志调试、容器化 API 调用、数据 Mock、消息 Mock 等功能

• VS Code 插件：直播间 Debug 工具在 PC 端的同等方案，结合模拟器可以独立在 PC 端开发调试

基于这些诉求，我们设计的 ALive 工程体系技术结构如下：

效果演示：组件代码热更新

效果演示：VS Code 插件 Mock 消息

效果演示：VS Code 插件 Mock 直播间数据

▶ 数据表现

业务数据上通过 ALive 开放带来的外部流量早已超过百万 DAU ，每一个对接方都蕴含着一个大的垂直市场。

技术数据上直播容器的稳定性较好，组件的渲染时长由于并发请求限制，还存在一定的优化空间。ALive 工程体系建设带来的提效非常明显，通过团队日常排期表数据粗略统计，开发效能提升大约在 30%左右。

本文转载自淘系技术公众号。

原文链接：https://mp.weixin.qq.com/s/L5lggzXju1ajAjUfaaDGLw