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

✪ 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 相互串联，最终将形成合力构建出丰满完整的多媒体前端体系。

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

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