组件化与插件化的差别在哪里，多媒体前端技术入门指南，神级前端进阶笔记

本文链接：https://blog.csdn.net/m0_57502067/article/details/137513350

在端侧如果采用原生video方案，存在兼容性及性能问题，播放器本身占用内存高，业务不规范使用会带来稳定性风险，甚至导致APP Crash。以端内H5为例，采用的是和Rax团队、客户端基础团队、客户端播放器团队一起打造的同层渲染方案：

Native播放器：负责播放器的基础能力，播放器内核fetch流地址后，解封装(demux)后解码(decode)，然后输出到上层Naitve同层组件层，Native播放器提供了点播/直播能力
Native同层组件：为底层播放器实例封装，主要负责联通通信连接层，并控制渲染
通信连接层：通过windmix管理渲染通道，再通过windvane绑定事件，传递属性，api能力调动，连接到前端播放器
前端播放器核心：担任前端播放器输出，将下层提供的事件/api/属性抹平成W3C制定的播放器标准，同时负责播放器稳定性相关能力
业务播放器封装：对下层的前端播放器核心封装播控协议，通过事件中心，管理各个播放器播放能力；同时从业务角度出发，对网络和设备性能进行监测，判断是否降级

▐ 多实例控制****

前面提到的都是单个视频播放的场景，实际业务中还有同一个页面中多个播放器的场景，比如列表流、版头等，这时候就引入了播放器多实例控制的问题，需要保证页面内只有一个播放器播放（播放甜区）、内存管理等。

播放器需要具备强大的播控能力，即播放调度能力：

事件中心驱动

播放器内部维护一份待播放队列，由rax-view的onAppear和onDisappear实现，当执行onAppear时，待播放队列将对应播放器唯一id存入到队列中，当对应播放器执行onDisappear时，从队列中剔除
队列中的播放形式主要分为3种：1，滚动播放；2，指定id播放；3，onAppear场景播放；均由事件管控。再由事件中心分发到不同播放器，告知哪个播放器可播放，哪个不可播放
播放器存在于pcom库，无论是对于会场场景或是源码开发场景，均可保证事件中心通知到所有播放器

播控调度
播放器实例内存占用大概在20-40MB，对于一个H5页面来说，内存占用过高，极容易引发页面内存占用过大，导致crash等严重问题。所以在事件驱动播放同时，事件中心会保证有且仅有一个播放器实例正在播放

面向消费：直播视频里的业务体系

前面提到的都是单纯的播放功能，但实际的业务场景是直播间或者短视频全屏页，从播放器到直播间/短视频，还有很重要的一个部分就是用户互动层，这就引入了直播视频里的业务体系。

以直播为例，对于观众有两个诉求：观看直播、参与互动。一般直播的设计如下：

通常的直播间架构分为三种：Web直播间、Hybrid直播间、小程序直播间，比如钉钉公开课直播采用的是Web直播间架构，蚂蚁、天猫精灵等采用的是小程序直播间架构，其他绝大多数的业务采用的是Hybrid直播间架构。

▐ Web 直播间架构

纯Web直播间，是指主要运行在Web浏览器上的H5直播间，主要包括H5播放器、事件通道、UI组件等。但移动端浏览器兼容性较差，移动端播放延时较高，所以一般对体验和性能要求高的业务场景，都会选择Hybrid直播间架构。

Hybrid直播间使用原生的播放器能力，兼容性更好，体验更流畅；同时事件通道是Native通道，相对于Web直播间 websocket更安全。

▐ Hybrid 直播间架构

Hybrid直播间的宿主是Native，使用原生播放器，互动玩法是在播放器上面盖了一层互动层（Webview或WEEX容器），并且能够和播放器通信。

Hybrid架构中互动层方案也经历了几个阶段的演变，从最开始的每个玩法组件一个独立层，到所有玩法组件打包到一个层，再到定义出直播容器来动态加载组件：

直播容器具有以下几个特征：

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

在Hybrid架构下开发调试组件，需要一个完整的直播间环境和直播容器才能开发调试，没有配套的工程体系，组件开发很低效。所以这种架构下还需要配套的工程体系，主要包含以下几个部分：

def 套件：直播间组件开发脚手架，增强调试能力，包括直播间模拟、调试代理、热更新、编译检测等功能
直播间 Debug 工具：基于直播容器开发一个Debug组件，提供日志调试、容器化API调用、数据Mock、消息Mock等功能
VS Code 插件：直播间Debug工具在PC端的同等方案，结合模拟器可以独立在PC端开发调试

多媒体前端团队通过打造直播容器和工程体系，才能高效、稳定的构建出直播视频里的业务体系。

当然Hybrid架构因为其联合Native和前端带来了架构上的复杂度，特别是在直播和视频上下滑时直播间的状态管理、播放器实例和webview实例管理等，会导致一些状态问题，比如某直播平台曾出现过“神奇三串”bug：薇娅直播间里播放的是李佳琦的直播流，但展示的是叶一茜的商品：

基于Hybrid架构我们可以考虑进一步升级，让播放器和互动层更加融合，形成「超级Video」，或者叫可交互的Video方案，甚至定义新的标准。

▐ 小程序直播间架构

随着跨端业务的出现，尤其是跨APP的场景，Hybrid直播间架构就像个大胖子，天然没有跨端优势（客户端集成、维护SDK成本极高），在这个背景下小程序直播间架构出现了。小程序直播间设计上分为以下几层：

直播插件：插件里除了包含最基本的播放器、无限列表、官方组件，还封装了组件布局规则、事件中心、容器api模块等基础能力
跨端通信层：由于插件和小程序宿主实例之间的js上下文完全隔离，因此@alipay/armer-x借助了appx对特定函数的声明不做序列化的特性进行了插件和宿主小程序之间的通信桥接，如给插件
赋予函数onConnectEmitter，在appx里是不做会做序列化的，因此数据可以通过该函数给予插件通知信息
小程序组件：二方、三方定制的小程序组件，满足特定的接入规则就可以借助直播间的容器能力进行定制
小程序实例：在拥有了二方组件、直播插件后，我们可以将二者进行整合、打包构建，生成一个新的小程序实例，实例的生成方式可以通过IDE构建，也可以通过搭建平台，如：「闪蝶」，目前的策略是支付宝侧通过闪蝶的方式构建生成实例，而百川侧，则通过IDE上传，并且借助淘宝开发平台进行百川投放

由蚂蚁和淘宝直播联合打造的小程序直播方案，在多个APP端（包括外部媒体APP）得到了广泛应用。

面向生产：直播推流、视频剪辑等工具

前面提到的更多的是面向消费侧的场景，随着业务的发展，各个多媒体团队开始更加关注生产侧的能力建设，毕竟内容的生产是整个内容生态的血液供给。作为开发者，需要给商家、主播、达人等创作者提供高效、好用的生产工具。在生产侧主要有两个方向，一个是面向直播的直播推流工具，一个是面向视频的视频剪辑工具。

▐ 直播推流

直播推流前端主要有两种方案:

桌面客户端

采用Electron + OBS方案（OBS是一个用于录制和进行网络直播的自由开源软件包，OBS使用C和C++语音编写，提供实时源和设备捕获、场景组成、编码、录制和广播等）。在设计上，OBS不负责业务功能，仅作为一个纯推流SDK。通过IPC通信将OBS的接口封装成V8的接口，再通过CMake或者GYP打包成Node模块供前端调用。播放区域（大小、padding等）、元素的交互行为（旋转、缩放等）、推流参数等全部封装成接口暴露给前端。整个APP为Electron中的一个BrowerView，采用React支撑视图，Mobx管理数据，跨页面通信以及相应的数据流转、缓存和窗口管理都由Electron主进程进行管理，前端通过将webview窗口句柄提供给OBS进程来保证推流画面的流畅显示。

淘宝直播主播工作台和 1688直播伴侣都是采用的这个方案。

Web浏览器端

采用WebRTC方案，相对于桌面端推流清晰度低、性能吃紧。比如融媒体团队由于业务特性，不能使用第三方的OBS开源软件，选择了该方案，产出了PC网页采集推流混流SDK，支持摄像头、电脑画面和垫片推流。

▐ 视频剪辑

相对于直播的生产，视频的生产覆盖度更广，参与到这个方向建设的团队也更多，包括阿里妈妈、淘系、盒马、1688、阿里小蜜、蚂蚁等。生产文章内容需要用富文本编辑器，那生产视频内容就需要视频剪辑工具，当然这两者的复杂度是完全不一样的。我们打造或智能生产、或高效好用的深度剪辑工具，都是期望降低生产成本，能像编辑文章一样方便地剪辑视频。

传统的桌面剪辑软件是提供一个GUI界面，给用户提供所见既所得的编辑效果反馈，并在编辑完成之后产生编辑描述数据，最后交由图形图像模块、音频处理模块以及视频编码模块去生成最终视频文件。参考大部分开源剪辑软件实现，前半部分GUI通过操作系统图形界面或跨平台如QT、SDL、SWT方式实现，这部分我们称之为 “GUI前端”，而后面涉及图形图像、音频、编码相关部分，大部分都会有一套媒体编辑内核来支撑，例如Linux下著名的MLT、GStreamer等等，这里我们称之为 “编辑内核”。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。