ALive:淘宝双 11 直播,技术同学却可以“偷懒”?(二)

发布于:2019 年 12 月 17 日 14:12

ALive:淘宝双11直播,技术同学却可以“偷懒”?(二)

▶ 技术实现

1、直播容器

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

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

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

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

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

基于这些特征设定,我们设计的直播容器技术结构如下:
ALive:淘宝双11直播,技术同学却可以“偷懒”?(二)
直播容器的核心工作流程包括以下几点:

  • 消息和指令:容器初始化时从 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 工程体系技术结构如下:
ALive:淘宝双11直播,技术同学却可以“偷懒”?(二)

效果演示:组件代码热更新
ALive:淘宝双11直播,技术同学却可以“偷懒”?(二)
效果演示:VS Code 插件 Mock 消息
ALive:淘宝双11直播,技术同学却可以“偷懒”?(二)
效果演示:VS Code 插件 Mock 直播间数据
ALive:淘宝双11直播,技术同学却可以“偷懒”?(二)

▶ 数据表现
ALive:淘宝双11直播,技术同学却可以“偷懒”?(二)

业务数据上通过 ALive 开放带来的外部流量早已超过百万 DAU ,每一个对接方都蕴含着一个大的垂直市场。
技术数据上直播容器的稳定性较好,组件的渲染时长由于并发请求限制,还存在一定的优化空间。ALive 工程体系建设带来的提效非常明显,通过团队日常排期表数据粗略统计,开发效能提升大约在 30% 左右。

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

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

阅读数:28 发布于:2019 年 12 月 17 日 14:12

评论

发布
暂无评论