之前H2的播放器进行过一次重构，旨在将UI，交互，数据和各个业务功能拆分开来。
来到H2O之后，由于也是当年老播放器一样的问题，所以准备这个月进行了一次相同目的的重构。
并且，基于之前的经验，这次的思维更加成熟了一些。
在谈播放器重构前，我们先来谈谈组件化。
组件化一直是我们最近技术工作的关键词，并且后面的各个控件都尽量使用组件化思想。
那么我们为什么需要做组件化呢？我们的目的主要有以下几个：
提高代码复用率，减少重复工作
统一App内的设计语言
约束一条产品->UI->技术的工作流程和语义说明。减少沟通成本
基于以上，作为技术人员，我们究竟应该符合设计一个组件呢？
用播放器来举例，
首先，一个组件，会有三个职能：
-
内在功能职能
这个组件本身是做什么用的，最基础的功能是什么？
例如，H2O本地播放器的内在功能职能，就是用来播放下载的课程视频。
再例如，一个弹框的内在功能就是在全局之上，弹出一个蒙层，蒙层之上再弹出一个区域作为弹框载体
-
展示职能
这个组件具体长什么样子，根据UI设计，会有不同的样子。
例如，播放器中会有暂停按钮，进度条等等，这些就算没有，也不影响播放器本身的功能，就是播放视频
再例如，弹框组件中，会有标题，副标题等等，就算没有这些，也不影响弹框本身的功能就是弹出一个额外页面
-
交互职能
例如，播放器提供播放暂停，镜面等等功能
再例如，弹框提供展示信息，点击按钮反馈等功能
其中，交互职能和展示职能大部分时候是相关的，交互的前提是让用户知道这里可交互，所以需要展示。
接下来，在上面描述的基础上，我们来看看，这次播放器的重构是如何设计，抽离，实现的。
播放器经过上面的思维过滤之后，拆分为下图所示模块：
其中，播放器最中心的功能就是播放视频，围绕这层之上的，
是我们的第一层业务需求，即：
- 播放片头视频，动作视频，以及全部动作结束后的片尾视频
- 在整个播放进程当中，需要有和当前动作视频绑定的指导人声音频，以及穿插在整个播放过程中的背景音乐音频
这个时候，几乎还不牵扯UI，我们的诉求目前为止只是加载资源播放而已。
接下来，是我们的第二层业务需求，即：
- 需要有控制页面，可以控制播放器，播放/暂停/上一个动作/下一个动作/全屏播放/镜面播放/调整音量大小
- 需要有信息展示，第几个动作/播放总时长/当前动作播放时长 等等
随之而来的，就是各个功能在播放器中的视觉体现，以及交互效果。
第三层，即：
数据上报
广告展示
Apple watch交互
-
siri
等等。。。
这个时候我们反过来推论，如果没有第三层，第二层可以单独成立吗？没有第二层，第一层可以单独成立吗？
结论显然是可以的，他们之间都是在之前一层之上增加的功能，在代码实现时，也应该遵循这种原则，避免过度的耦合。
在上面的图中，我们可以看到两个相对突兀的存在：
- 播放上报信息收集者
- 播放时间信息观察者
他们也是因为业务需要才加的，但是为了避免第一层和第二层之前存在直接的耦合，所以增加中间信息传递者。从第一层收集信息，然后发送给第二层。
其中，第二层由于各个业务众多，我们也需要将其每一个都模块化，进行引入式添加，这样，即使我们后面增加一个功能，减少一个功能，都对原有的模块以及其API是不影响的。
即使，未来增加的功能会牵扯到之前的模块，我们也可以增量添加。
面对一个乍一眼看过去非常复杂的需求，作为技术人员，应该学会本能地运用这种思维工具，将其层层剖析，一点点拆分开来。
接下来，贴上工程中的分布：
Let’s think!
