作者|阿里娱乐前端技术专家-编辑莫吉|郑丽媛头部图| CSDN下载自视觉中国
转眼2020年已经过半，我从事OTT开发已经5年多了。回顾OTT的前端建设过程，感触良多。经历了从0到1的艰难起步，也经历了从1到N的共同努力；有通宵的调试之夜，也有阳光明媚的流畅亮点。下面给大家分享一下优酷OTT前端的技术历史。
背景
什么是OTT？
简单来说，“OTT”一词解释为over the top，最初是篮球术语，意为“把球传过头顶”，后来扩展为通过互联网为用户提供各种应用服务，主要由运营商以外的第三方提供。
OTT那边有什么？
OTT开发规范和逻辑与移动APP属于一脉相承，一般都是Android系统支持，APP开发者开发不同类型的软件应用。本文中的OTT端建设是优酷“OTT端酷喵APP”的建设。
前端在OTT中起什么作用？
说起来前端开发和APP原生开发是相辅相成的。OTT端酷喵app的主框架是native开发实现的，而主动坑位投放、部分APP功能页面、快速发布和补充项目则需要前端介入开发，尤其是最常见的“主动坑位投放”，由于内容形式多样、发布频率高，并不适合Native开发。两者恰好都是前端优势。
这几年我们做了什么？
从2015年的OTT电影厅APP，到后来的“中国数字授权方影视”APP，再到现在的“酷喵APP”，经历了多轮APP的衍生开发，多次升级优化前端相关能力。
那么OTT终端和其他终端有很大区别吗？
没错，纵观M端、PC端、Pad端，用户都可以通过鼠标、键盘、触摸来进行页面交互。而OTT-终端上的所有基础操作都依赖于“远程控制”，这就决定了人机交互与其他终端有着本质的区别，“焦点引擎”的概念应运而生。
焦点引擎
我们来看看电视用户交互的现状。我们只有一个遥控器，上下左右ok键可以分别映射到键盘的四个方向键和回车键。我们可以监控文档的关键事件来实现焦点切换的逻辑。那么问题来了。作为一个业务开发人员，是否要在每个页面上花费精力去处理“按下右键后接下来应该选择哪个区域”这样的问题？你就不能像老鼠一样指着打吗？
所谓“打哪里”其实是一个认知问题。无论什么设备，用户和开发者对人机交互都有心理预期。只是PC和手机页面的人机交互做得好，而电视做得不好。所以我们希望通过一些手段让电视上的页面交互更加流畅自然。尤其是对于业务开发者来说，你的代码逻辑、风格、代码量能够在PC和手机上接近H5页面，是我们最大的愿景。
作为一个专注于电视前端开发的团队，我们设计了一套组件树管理和焦点管理的机制来抽象电视上的交互行为。它管理页面中的焦点切换，帮助开发人员从繁琐的焦点处理中解脱出来。开发人员只需要专注于业务代码的编写，提高开发效率。
接下来从组件树和焦点管理两个方面简单介绍一下“焦点引擎”:
组件树
通过对电视页面的分割，大致确定一些使用频率较高的模块:横向/纵向列表、多向无序排列模块、滚动列表等。
我们希望这些模块可以抽象成组件，可以自动实现各种元素之间的焦点切换。同时，页面中组件之间的切换也应该对开发人员透明。为此，我们将这些组件组织成树形结构，组件的层次关系有助于生命周期管理和事件流传输，为焦点管理的实现提供了良好的基础。
Widget是组件的基础类，有指向其父节点的属性parentWidget，实现添加、删除、搜索的方法来管理子节点数组childWidgets。以上模块都是基于基础类的扩展。具体来说，基本类并不直接实现其子节点之间的焦点切换功能，而是通过扩展类来实现。比如横向列表实现了左右按钮的焦点切换，多向无序排列模块实现了多种焦点感应算法，滚动列表实现了电视端焦点切换中的页面滚动逻辑。下面的例子展示了从页面的模块划分到组件树的映射过程:
需要强调的是，虽然html天然是树形结构，但是由于电视中与焦点管理相关的逻辑和事件都不是原生实现的，所以我们还是需要将dom树映射成组件树，方便函数注入。
焦点管理
焦点管理主要有两个技术点，一个是组件树中的事件模拟和事件流管理，另一个是焦点链接构造。
尽管js支持keydown、focus和blur等事件，但这些事件只能在可选元素或文档上触发。在电视上，可选的定义要复杂得多，几乎所有的视觉元素都是可选的，默认的切换行为往往让人不知所措。
我们向组件模块添加on、detach、fire和其他事件管理方法，事件的触发允许在组件树中冒泡。此外，该事件。基类，可以很容易地扩展事件流中传递的事件，比如event。关键事件，事件。焦点事件，事件。选择事件等。
随着事件的模拟，重点已经明确:如果是组件切换逻辑触发，整个过程要从最左端开始；如果通过调用组件的focus方法来获得焦点，请从focus步骤开始。焦点切换的执行流程大致如下图所示。
以上是OTT的特征点“焦点引擎”的介绍，属于技术基础设施支撑。回到业务上，如上所述，“活动坑投放”的开发是前端开发业务的重头戏。我们以“可视化构建”为方向，提高开发效率和页面质量。并在其他平行业务的情况下，升级能力，积极拓展前端赋能。
前端能力覆盖也从最早的活动发起页面发展到目前的OTT端页面建设、半屏互动、APP功能单元、质量监控等领域。在前端加载体验方面，也实现了质的提升，尤其是二次打开率、崩溃率等指标。在这个漫长的建设过程中，我们大致经历了石器时代、农耕时代和工业时代三个阶段。
时代建设
石器时代——源代码发展的时期
刚开始的时候，我们主要以源代码开发为主。每个活动都需要开发生从头开始搭建，效率很低。当活动积累到一定阶段，我们把常用组件拉出来，开发效率略有提升。比如3天的开发变成了1.5天。但本质上并没有解决问题，尤其是在运营活动页面需要频繁调整的时候，更是把前端学员折磨的半死。操作一点内容修改，比如改变图片的位置和大小等。，会在前端发布新版本。这种硬编码的方式真的是硬伤。尤其是双11，前端团齐上阵，苦于活动页面……这个时期持续了半年多，大家都在寻找新的出路。
问题:源代码开发方便，符合前端开发习惯，常用组件沉淀效率有所提升，但无法解决活动页面频繁调整的问题。
[AWP源代码开发]
农耕时代-模板发展时期
这个时期主要是模板化时期。通过坑位配置解决了开发效率问题。技术生与UED沟通制定通用OTT模板，如每周大片、棋牌抽奖、倒计时模板等。，基本上解决了运营效率的问题。
问题:这种方法仍然有局限性。需要以约定的形式规范内容，限制作业生的创造性。这个阶段持续了半年，可以满足运营的基本需求。然而，面对不断创新的活动形式，模板法越来越显得力不从心...
[TMS活动模板]
【斑马斑马模板】
工业时代——视觉建筑时期
最后参考阿里集团的视觉构建体系，尝试构建一套适合2017年电视的构建方案。如果从零开始，肯定是一条很长的路，涉及的开发量很大。由于之前我们一直在阿里集团用B搭建系统，发现这些能力B的系统基本都有了，那我们为什么不利用力量，站在巨人的肩膀上呢？所以我们把页面的托管能力收敛到B系统的底层服务。接下来，我们开始了RD阶段，当时投资的学生记忆犹新。服务器端开发震动负责对接B系统的所有节点服务，我主要负责前端部分。经过两个多月的努力，我们发布了第一个测试版“2016-11-04”。
【方舟视觉建构】
超越时代——前端多元化赋能
标准化、高效化建设完成后，不再需要满足日常运营需求，而是将方向转向技术多元化、赋能化，逐步完成一批创新建设，推进业务建设。
半屏互动依赖于当前weex技术栈的灵活发布和快速阅读覆盖能力。通过前端、客户端、播放器的共同努力，借助OTT酷喵APP自身的硬件特性和用户习惯，创造性地完成“半屏互动”的构建。这种能力建设既满足了用户线运营“大规模曝光”的需求，也满足了会员线运营“精准投放、提升渗透”的需求。从数据结果来看是非常成功的，尤其是在曝光UV的量级上，最终取得了曝光UV提升200%左右的惊人数据。
登录OTT从开发语言、运营理念等方面都遵循了移动APP的相关规范。不同的是，手机APP是触屏操作，OTT一般是遥控操作；OTT终端最常见的登录与常见的PC终端扫码登录一致。OTT终端显示登录二维码，移动终端扫码操作确认登录，即“扫码登录”；我们希望OTT登录状态同步到手机上，手机完成相应的操作。同时，避免因手机上登录状态缺失、登录账号不一致导致的业务操作偏差，即“扫码反向登录”。
质量监控很长一段时间，一直有用户投诉——很难定位——电视页面bug，客服和技术线学员很难获得用户相应的错误数据；使用客户端隐藏调试具有复杂的操作和通信困难。经调查，APP端优质平台的能力与OTT端诉求一致。所以设置Rax开发者、质量平台和Rax容器，完善OTT端质量平台，即实时日志监控。
OTT酷喵会员线获取订单的前端可视化搭建——“获取能力”升级取得一定成效。随着同步登录状态、单一商品收银台等前端创新能力的落地，直接推动OTT登录率提升近10%，简化购买环节，实现可视化搭建。组合能力领先行业。此外，OTT半屏收银台的开发上线，使得OTT酷喵用户触达能力迎来重大升级。依托播放页面，实现一步扫码支付，大大简化了支付环节，提高了转化率。
积分商城OTT积分商城以积分的分发和兑换为基础，建立符合大屏运营特点的用户管理体系。用户通过各种行为获得积分，再通过不同的游戏或商品交换进行积分消费，从而为用户增长、用户活跃度和留存提供了有效的切入点。
积分商城功能二期已经完成，支持积分有序分配，Kumeo自有权益、二三方虚拟权益、电视淘宝权益的兑换，奠定了OTT用户基础运营能力。之后打通电视淘宝，完成账号绑定、追加购买、下单、支付等能力建设。，这将在后续实现资源互补。
以上是优酷OTT大屏前端建设之路，希望能启发大家。
