▶ 技术实现

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

创作场景

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