本地播放器重构 —— 组件化和解耦

之前H2的播放器进行过一次重构，旨在将UI，交互，数据和各个业务功能拆分开来。

来到H2O之后，由于也是当年老播放器一样的问题，所以准备这个月进行了一次相同目的的重构。

并且，基于之前的经验，这次的思维更加成熟了一些。

在谈播放器重构前，我们先来谈谈组件化。

组件化一直是我们最近技术工作的关键词，并且后面的各个控件都尽量使用组件化思想。

那么我们为什么需要做组件化呢？我们的目的主要有以下几个：

1. 提高代码复用率，减少重复工作

2. 统一App内的设计语言

3. 约束一条产品->UI->技术的工作流程和语义说明。减少沟通成本

基于以上，作为技术人员，我们究竟应该符合设计一个组件呢？

用播放器来举例，

首先，一个组件，会有三个职能：

1. 内在功能职能

   这个组件本身是做什么用的，最基础的功能是什么？

   例如，H2O本地播放器的内在功能职能，就是用来播放下载的课程视频。

   再例如，一个弹框的内在功能就是在全局之上，弹出一个蒙层，蒙层之上再弹出一个区域作为弹框载体

2. 展示职能

   这个组件具体长什么样子，根据UI设计，会有不同的样子。

   例如，播放器中会有暂停按钮，进度条等等，这些就算没有，也不影响播放器本身的功能，就是播放视频

   再例如，弹框组件中，会有标题，副标题等等，就算没有这些，也不影响弹框本身的功能就是弹出一个额外页面

3. 交互职能

   例如，播放器提供播放暂停，镜面等等功能

   再例如，弹框提供展示信息，点击按钮反馈等功能

其中，交互职能和展示职能大部分时候是相关的，交互的前提是让用户知道这里可交互，所以需要展示。

BVDvHe.png

---

接下来，在上面描述的基础上，我们来看看，这次播放器的重构是如何设计，抽离，实现的。

播放器经过上面的思维过滤之后，拆分为下图所示模块：

BVsadg.png

其中，播放器最中心的功能就是播放视频，围绕这层之上的，

是我们的第一层业务需求，即：

1. 播放片头视频，动作视频，以及全部动作结束后的片尾视频
2. 在整个播放进程当中，需要有和当前动作视频绑定的指导人声音频，以及穿插在整个播放过程中的背景音乐音频

这个时候，几乎还不牵扯UI，我们的诉求目前为止只是加载资源播放而已。

接下来，是我们的第二层业务需求，即：

1. 需要有控制页面，可以控制播放器，播放/暂停/上一个动作/下一个动作/全屏播放/镜面播放/调整音量大小
2. 需要有信息展示，第几个动作/播放总时长/当前动作播放时长 等等

随之而来的，就是各个功能在播放器中的视觉体现，以及交互效果。

第三层，即：

1. 数据上报

2. 广告展示

3. Apple watch交互

4. siri

   等等。。。

这个时候我们反过来推论，如果没有第三层，第二层可以单独成立吗？没有第二层，第一层可以单独成立吗？

结论显然是可以的，他们之间都是在之前一层之上增加的功能，在代码实现时，也应该遵循这种原则，避免过度的耦合。

在上面的图中，我们可以看到两个相对突兀的存在：

1. 播放上报信息收集者
2. 播放时间信息观察者

他们也是因为业务需要才加的，但是为了避免第一层和第二层之前存在直接的耦合，所以增加中间信息传递者。从第一层收集信息，然后发送给第二层。

其中，第二层由于各个业务众多，我们也需要将其每一个都模块化，进行引入式添加，这样，即使我们后面增加一个功能，减少一个功能，都对原有的模块以及其API是不影响的。

即使，未来增加的功能会牵扯到之前的模块，我们也可以增量添加。

面对一个乍一眼看过去非常复杂的需求，作为技术人员，应该学会本能地运用这种思维工具，将其层层剖析，一点点拆分开来。

接下来，贴上工程中的分布：

BVcUeK.png

Let’s think!