ALive：淘宝双11直播，技术同学却可以“偷懒”？
“疯狂的”淘宝直播间
今年直播又火了！
2019年双11淘宝直播带来近 200亿 成交，以天猫双11交易总额2684亿计算，直播已经占总成交额的近 7.45%！
今年的变化
除了以往的手淘和猫客，现在 UC 浏览器、新浪微博、支付宝、优酷、闲鱼、飞猪、饿了么、口碑等等一系列阿里系 APP 里也可以观看直播、购买商品了，可以想象一下这些场景：
- 点了一杯奶茶外卖，在本地生活 APP 里通过直播能够看到小哥哥正在制作谁的订单，我排在第几号了，线下门店的卫生情况、制作过程、客流量、商品咨询都可以在直播间里了解到
- 在支付宝小程序里，边看直播边抢主播发来的口令红包
- 在阿里健康的消费医疗直播间里，跟今日特约的医师进行线上咨询
- 最近在计划一趟旅行，在飞猪APP里通过直播看着小姐姐介绍航旅套餐，还有小窗合流的当地风景观光片
- ...
除了导购直播、客服直播、医疗直播、手艺直播等等，我们还能看到各种风格类型和互动形式的台网联动直播、秀场直播、晚会直播，以下是今年承接的几场大型互动晚会：
这些直播无论内容和互动有什么样的区别，他们都有一个共同的特征：直播间右上角「淘宝直播」的水印
问个问题，所有这些类型的直播间，都是淘宝直播的开发同学支持的吗？这需要一个多么庞大的技术团队呢？答案是这个团队其实很缺人，所以他们「勤奋」地做了一件「偷懒」的事情：ALive 开放，让阿里经济体里需要直播能力的业务能自主接入、自主开发，于是就有了今年百花齐放的直播生态。
ALive演进
ALive 的使命是汇集淘宝直播强大的音视频处理能力，提供直播、互动、营销一体化解决方案，实现「生态开放、直播未来」的愿景。
时移到2018年7月，当时的淘宝直播还是小作坊模式，所有的业务对接都由淘宝直播技术团队承接，各团队都在超负荷工作。随着对接的外部业务越来越多，各类直播间定制化需求越来越高，技术团队开始构思开放之路，解放一方生产力，赋能二方、三方直播能力。
▶ 分析
直播对于观众来讲其实就是两个诉求：观看直播、参与互动。来看下当时的淘宝直播是如何满足用户这两个诉求的：
整体结构分为两部分：一个是直播能力，一个是互动通信能力。通过直播能力，观众能观看直播流；通过互动通信能力，观众能在直播间里参与实时互动。
- 直播能力：最简单的模型就是“两端加一服”，即推流端、播放端、流媒体服务器。主播通过推流客户端进行直播推流，我们提供了PC端推流工具和淘宝主播APP进行ARTP低延时推流，流媒体服务经过转码、切片、存储、分发等，供播放端拉流播放。
- 互动通信能力：主播在中控台创建、管理直播，开播后推送互动，经过业务服务调用和消息下发，端上渲染业务组件。当时的架构，每一个组件都跑在独立的Weex容器或H5容器里。
**▶ 问题
**
直播能力主要由淘宝直播音视频团队提供，依托阿里云构建了完整的音视频端到端闭环，包括音视频编解码、传输通道、网络调度技术，提供超低延时、超高画质、超大并发访问的音视频服务。二、三方业务只需要接入播放器 SDK ，主播使用我们的推流工具，即可支持直播能力。
互动通信能力主要依赖端侧的技术架构，从上图的架构可以看出两个核心痛点问题：
性能低下：每个组件都是独立的 Weex/H5 页面，内存占用较高，直播间流媒体播放已经占用了较高的内存水位，多个 Weex/H5 叠加后加大了 Crash 风险。同时各组件间相互独立，资源重复加载，加载性能也较差
效能低下：前端组件由客户端挖坑位的方式加载 bundle ，开发、调试环境强依赖客户端，直播环境搭建、消息模拟、数据 Mock 、日志查看、代码调试等链路都非常复杂，开发效率极其低下
▶ 解法
前端的技术工作大部分都在解决两个「能」的问题：性能 和 效能。针对上述痛点，技术侧需要做两件事情：一是构建一个 灵活、高效的直播容器，解决性能问题；二是提供一套 直播间组件开发的工程体系，解决效能问题。在性能和效能都得到提升后，将这些能力通过 ALive 开放平台开放给二、三方业务接入，基于这些思考，我们升级了直播架构：
直播容器的核心区别，是由原来每个组件独立为一个Weex/H5容器，变成只保留一个Weex容器，通过这个直播容器来动态加载组件。
**
▶ 技术实现**
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%左右。
ALive展望
**▶ 业务侧：ALive互动市场
**
今年猫晚直播间里所有的互动都由优酷侧同学通过ALive接入开发，我们看下猫晚同时在线观看人数的曲线图：
这张图里有个比较有意思的规律：猫晚同时在线人数的每一次峰值，都对应有互动的推送。这里有两点思考，第一是我们提供的直播容器其实是跑在刀尖上的，每一次峰值都是一次检验，所以对于直播容器除了前面提到的灵活、高效，还有一个更重要的要素，那就是稳定，这个稳定一方面依赖服务提供方，也就是淘宝直播技术团队的技术保障，另一方面依赖服务调用方严格遵循直播间互动接入SLA。第二个思考，优酷侧这次开发了这么多互动组件，能沉淀复用吗？
嗯，这个问题亚博科技的同学已经给出了答案。今年阿里88会员节演唱会里的互动由亚博科技同学通过ALive接入开发，Bingo幸运球玩法效果非常不错，晚会结束后亚博科技同学主动提出将Bingo玩法沉淀到日常，于是有了后面的连连看、招财猫。招财猫互动在今年的双11活动期间，为直播间促活停留数据带来了非常不错的增长：
基于这些实践经验，ALive后续会规划互动市场，将各方业务开发的互动玩法按照拉新、促活/停留、转粉、成交、回访等维度进行分类管理，其他业务可以通过玩法优势、使用范围、已接入业务效果等选择复用组件，也可以为互动团队提供更多的数据参考，集中精力生产、迭代更优效果的直播互动玩法。
▶ 技术侧：小程序直播开放
在我们讲开放的时候，经常提到的几个关键词是轻量、灵活，但我们发现手淘端外业务在直播接入过程中，需要接入播放器SDK和Weex SDK才能满足直播能力，接入成本依然较高。前端将视角瞄向了小程序体系，期望不依赖SDK来满足其他APP端内的直播诉求。目前我们已经实现了支付宝端小程序直播（支付宝搜索淘宝直播即可体验），目前还有两件事情需要突破：
- 提供类似于Rax直播容器的小程序直播容器，提供二、三方组件开发能力
- 和支付宝端对接过程中，我们大部分精力在处理播放的问题，比如iOS/Android端播放控制不一致、H.265播放黑屏等。如果换一个客户端，是否要重新再对接一遍？
针对第一个问题，已经有可行方案，区别于Rax体系下的组件动态加载，小程序体系下需要预定义好组件使用范围，通过Page生成服务产出对应的Page Bundle。针对第二个问题，鉴于我们团队之前自研了基于WebAssembly的Web端播放器，我们一直在探索将该前端方案的播放器迁入小程序体系，实现前端的播放方案，解决播放器SDK版本限制的束缚，这个突破会极大程度地降低直播接入成本。
另一方面我们团队在尝试通过H5接入ARTC低延时方案，实现H5端的低延时推拉流方案，如果该方案也能在小程序体系下跑通，意味着二、三方业务将能通过H5/小程序实现推流、拉流、播放，形成web和小程序侧的音视频闭环。技术上进一步降低接入成本、增强通投能力，更轻量、灵活、稳定的ALive开放体系，将给业务带来更强劲的推力。
最后
▶ 关联项目
媒体智能：直播、短视频从生产侧到消费侧的媒体智能方案。直播互动目前都是传统互动，互动和流内容是割裂的。直播间里的AR/AI玩法有机会给用户留存和观看时长带来较大提升，设想在直播间里抢的红包雨可能是由主播通过手势挥洒出来的、李佳琦喊出“Oh My God”的时候自动跳出字幕特效等等，除了玩法增强，媒体智能还能提供更智能化的服务，比如主播展示商品时智能识别，用户可在流画面内点击商品直接购买等等，场景非常丰富。团队自研的媒体智能编辑器 Media AI Studio已经产出原型版本，整体项目旨在通过媒体智能工具链和工程化体系建设，将智能玩法开发周期提效成“7+3+1”模式（7天算法开发、3天玩法编写、1天素材制作，即可上线一个全新玩法）
- Electron多媒体生产端：基于Electron + OBS + MLT的多媒体PC生产端工具，包括直播推流、回放编辑、视频剪辑等核心能力
- VideoX播放器：PC/H5/Weex/小程序多场景整合的统一播放方案
团队在多媒体生产端和消费端的各个项目齐头并进，又都和ALive相互串联，最终将形成合力构建出丰满完整的多媒体前端体系。
作者：潘佳(林晚)
本文为云栖社区原创内容，未经允许不得转载。