ALive:助力阿里经济体,开启直播新纪元
作者:林晚 发布于:2019-11-28 10:43:25

1 “疯狂的”淘宝直播间


今年直播又火了!


2019年双11淘宝直播带来近 200亿 成交,以天猫双11交易总额2684亿计算,直播已经占总成交额的近 7.45%



2 今年的变化


除了以往的手淘和猫客,现在UC浏览器、新浪微博、支付宝、优酷、闲鱼、飞猪、饿了么、口碑等等一系列阿里系APP里也可以观看直播、购买商品了,可以想象一下这些场景:


  • 点了一杯奶茶外卖,在本地生活APP里通过直播能够看到小哥哥正在制作谁的订单,我排在第几号了,线下门店的卫生情况、制作过程、客流量、商品咨询都可以在直播间里了解到
  • 在支付宝小程序里,边看直播边抢主播发来的口令红包
  • 在阿里健康的消费医疗直播间里,跟今日特约的医师进行线上咨询
  • 最近在计划一趟旅行,在飞猪APP里通过直播看着小姐姐介绍航旅套餐,还有小窗合流的当地风景观光片
  • ...



除了导购直播、客服直播、医疗直播、手艺直播等等,我们还能看到各种风格类型和互动形式的台网联动直播、秀场直播、晚会直播,以下是今年承接的几场大型互动晚会:



这些直播无论内容和互动有什么样的区别,他们都有一个共同的特征:直播间右上角「淘宝直播」的水印


问个问题,所有这些类型的直播间,都是淘宝直播的开发同学支持的吗?这需要一个多么庞大的技术团队呢?答案是这个团队其实很缺人,所以他们「勤奋」地做了一件「偷懒」的事情:ALive开放,让阿里经济体里需要直播能力的业务能自主接入、自主开发,于是就有了今年百花齐放的直播生态。


3 ALive演进


ALive的使命是汇集淘宝直播强大的音视频处理能力,提供直播、互动、营销一体化解决方案,实现「生态开放、直播未来」的愿景。


时移到2018年7月,当时的淘宝直播还是小作坊模式,所有的业务对接都由淘宝直播技术团队承接,各团队都在超负荷工作。随着对接的外部业务越来越多,各类直播间定制化需求越来越高,技术团队开始构思开放之路,解放一方生产力,赋能二方、三方直播能力。


3.1 分析


直播对于观众来讲其实就是两个诉求:观看直播、参与互动。来看下当时的淘宝直播是如何满足用户这两个诉求的:



整体结构分为两部分:一个是直播能力,一个是互动通信能力。通过直播能力,观众能观看直播流;通过互动通信能力,观众能在直播间里参与实时互动。


  • 直播能力:最简单的模型就是“两端加一服”,即推流端、播放端、流媒体服务器。主播通过推流客户端进行直播推流,我们提供了PC端推流工具和淘宝主播APP进行ARTP低延时推流,流媒体服务经过转码、切片、存储、分发等,供播放端拉流播放。
  • 互动通信能力:主播在中控台创建、管理直播,开播后推送互动,经过业务服务调用和消息下发,端上渲染业务组件。当时的架构,每一个组件都跑在独立的Weex容器或H5容器里。


3.2 问题


直播能力主要由淘宝直播音视频团队提供,依托阿里云构建了完整的音视频端到端闭环,包括音视频编解码、传输通道、网络调度技术,提供超低延时、超高画质、超大并发访问的音视频服务。二、三方业务只需要接入播放器SDK,主播使用我们的推流工具,即可支持直播能力。


互动通信能力主要依赖端侧的技术架构,从上图的架构可以看出两个核心痛点问题:


  • 性能低下:每个组件都是独立的Weex/H5页面,内存占用较高,直播间流媒体播放已经占用了较高的内存水位,多个Weex/H5叠加后加大了Crash风险。同时各组件间相互独立,资源重复加载,加载性能也较差
  • 效能低下:前端组件由客户端挖坑位的方式加载bundle,开发、调试环境强依赖客户端,直播环境搭建、消息模拟、数据Mock、日志查看、代码调试等链路都非常复杂,开发效率极其低下


3.3 解法


前端的技术工作大部分都在解决两个「能」的问题:性能效能。针对上述痛点,技术侧需要做两件事情:一是构建一个 灵活、高效的直播容器,解决性能问题;二是提供一套 直播间组件开发的工程体系,解决效能问题。在性能和效能都得到提升后,将这些能力通过ALive开放平台开放给二、三方业务接入,基于这些思考,我们升级了直播架构:



直播容器的核心区别,是由原来每个组件独立为一个Weex/H5容器,变成只保留一个Weex容器,通过这个直播容器来动态加载组件。



3.4 技术实现


3.4.1 直播容器


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


  • 统一规范的组件消息协议:包括组件包名、组件行为、业务自定义字段等,统一由PowerMessage的固定消息下发
  • 支持动态加载:直播间不同于其他详情页,互动的发送依赖主播操作,也依赖用户进入直播间的时机,每个用户参与到的互动可能都不一样,所以互动组件的动态加载对首屏性能很关键
  • 缓存及依赖去重:同一个互动,主播可以多次推送,各个互动依赖的基础库(rax-xxx、universal-xxx)也存在较多重复,所以设计合理的缓存和依赖去重机制对性能提升也很重要
  • HOC高阶组件:直播间里的业务开发不同于其他独立的源码页面,比如直播间数据获取、消息和事件监听、横竖屏状态获取、带小窗跳转、直播观看时长等等都依赖直播间环境或者客户端API,业务组件都需要这些基础能力,需要通过HOC来增强业务组件


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



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


  • 消息和指令:容器初始化时从Native获取缓存里Mtop请求的组件列表,同时消息模块监听Native转发的固定消息。协议解析成标准化指令,交给渲染模块执行后续操作
  • 渲染管理:渲染模块接收到创建、更新、销毁组件指令后,传递给组件HOC,如果是创建组件指令,则从加载引擎拉取组件bundle
  • 加载引擎:rloader维护了组件缓存,当拉取的组件不在缓存内时,会解析依赖,优先从缓存的基础依赖里查找基础组件,如果没有则combo拼接,最后拉取最小量的组件bundle,并将拉取的bundle加入缓存
  • 组件HOC:高阶组件除了上述的能力,还提供了API Bridge、全局变量注入、事件分发以及一些监控容错等机制


3.4.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直播间数据



3.5 数据表现



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


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


4 ALive展望


4.1 业务侧:ALive互动市场


今年猫晚直播间里所有的互动都由优酷侧同学通过ALive接入开发,我们看下猫晚同时在线观看人数的曲线图:



这张图里有个比较有意思的规律:猫晚同时在线人数的每一次峰值,都对应有互动的推送。这里有两点思考,第一是我们提供的直播容器其实是跑在刀尖上的,每一次峰值都是一次检验,所以对于直播容器除了前面提到的灵活、高效,还有一个更重要的要素,那就是稳定,这个稳定一方面依赖服务提供方,也就是淘宝直播技术团队的技术保障,另一方面依赖服务调用方严格遵循直播间互动接入SLA。第二个思考,优酷侧这次开发了这么多互动组件,能沉淀复用吗?


嗯,这个问题亚博科技的同学已经给出了答案。今年阿里88会员节演唱会里的互动由亚博科技同学通过ALive接入开发,Bingo幸运球玩法效果非常不错,晚会结束后亚博科技同学主动提出将Bingo玩法沉淀到日常,于是有了后面的连连看、招财猫。招财猫互动在今年的双11活动期间,为直播间促活停留数据带来了非常不错的增长:



基于这些实践经验,ALive后续会规划互动市场,将各方业务开发的互动玩法按照拉新、促活/停留、转粉、成交、回访等维度进行分类管理,其他业务可以通过玩法优势、使用范围、已接入业务效果等选择复用组件,也可以为互动团队提供更多的数据参考,集中精力生产、迭代更优效果的直播互动玩法。



4.2 技术侧:小程序直播开放


在我们讲开放的时候,经常提到的几个关键词是轻量、灵活,但我们发现手淘端外业务在直播接入过程中,需要接入播放器SDK和Weex SDK才能满足直播能力,接入成本依然较高。前端将视角瞄向了小程序体系,期望不依赖SDK来满足其他APP端内的直播诉求。目前我们已经实现了支付宝端小程序直播(支付宝搜索淘宝直播即可体验),目前还有两件事情需要突破:


  • 提供类似于Rax直播容器的小程序直播容器,提供二、三方组件开发能力
  • 和支付宝端对接过程中,我们大部分精力在处理播放的问题,比如iOS/Android端播放控制不一致、H.265播放黑屏等。如果换一个客户端,是否要重新再对接一遍?


针对第一个问题,已经有可行方案,区别于Rax体系下的组件动态加载,小程序体系下需要预定义好组件使用范围,通过Page生成服务产出对应的Page Bundle。针对第二个问题,鉴于我们团队之前自研了基于WebAssembly的Web端播放器,我们一直在探索将该前端方案的播放器迁入小程序体系,实现前端的播放方案,解决播放器SDK版本限制的束缚,这个突破会极大程度地降低直播接入成本。



另一方面我们团队在尝试通过H5接入ARTC低延时方案,实现H5端的低延时推拉流方案,如果该方案也能在小程序体系下跑通,意味着二、三方业务将能通过H5/小程序实现推流、拉流、播放,形成web和小程序侧的音视频闭环。技术上进一步降低接入成本、增强通投能力,更轻量、灵活、稳定的ALive开放体系,将给业务带来更强劲的推力。


5 最后


5.1 关联项目


  • 媒体智能:直播、短视频从生产侧到消费侧的媒体智能方案。直播互动目前都是传统互动,互动和流内容是割裂的。直播间里的AR/AI玩法有机会给用户留存和观看时长带来较大提升,设想在直播间里抢的红包雨可能是由主播通过手势挥洒出来的、李佳琦喊出“Oh My God”的时候自动跳出字幕特效等等,除了玩法增强,媒体智能还能提供更智能化的服务,比如主播展示商品时智能识别,用户可在流画面内点击商品直接购买等等,场景非常丰富。团队自研的媒体智能编辑器 Media AI Studio已经产出原型版本,整体项目旨在通过媒体智能工具链和工程化体系建设,将智能玩法开发周期提效成“7+3+1”模式(7天算法开发、3天玩法编写、1天素材制作,即可上线一个全新玩法)
  • Electron多媒体生产端:基于Electron + OBS + MLT的多媒体PC生产端工具,包括直播推流、回放编辑、视频剪辑等核心能力
  • VideoX播放器:PC/H5/Weex/小程序多场景整合的统一播放方案


团队在多媒体生产端和消费端的各个项目齐头并进,又都和ALive相互串联,最终将形成合力构建出丰满完整的多媒体前端体系。


5.2 最后的最后


淘宝直播多媒体团队火热招聘


  • 或微信沟通: Jovenpan