上一章：OTT端技术赋能之前端收单能力建设 | 《优酷OTT互联网大屏前端技术实践》第四章>>>
下一章：不一样的烟火：记OTT端半屏互动能力建设 | 《优酷OTT互联网大屏前端技术实践》第六章>>>
作者| 阿里巴巴文娱技术 罄天
一、背景
图片作为网页中的重要组成元素，广泛存在于各种站点中，有些站点中的图片内容已经远远超过了其他网页内容总和。如何高效的、快速的制作业务图片就被广泛的提出来。阿里有很多自动化图片生产平台，如海棠，鲁班等。
谈到自动化制图，主要有两种模式：
一是自动化模式：依赖于服务化能力包装，将核心制图能力进行抽取，任何三方通过直接调用服务能力即可完成图片的合成，此种模式完全自动化，无需任何人工干预即可制作出符合指定条件的业务图片；
二是半自动化模式：主要依赖于业务共性的提取与升华，将繁琐的重复的业务流程通过统一的范式来解决，或多或少的需要人工干预。人工干预一方面需要人力投入，另一方面意味着可以发挥人的主观创造性。成品图除了满足指定的共性外，也可以保证输出个性，这种个性与共性并存的方式不失为一种好的折中。
二、OTT自动化制图
1、OTT自动化制图的起源
以前，优酷OTT侧有自动化制图的雏形，主要依据前端提供制图的工具平台，并将OTT主要合作厂商坑位图配置信息进行固化，然后运营在工具平台上做相应的坑位图合成。此模式在一定程度上满足了运营的合图需求。
在2019年，OTT侧开始尝试自动化制图。深入自动化制图的目的也很明显，主要基于以下痛点：
1）内容源与成品沉淀
我们观察到，阿里集团开始大面积的做自动化制图的尝试，有影响力的包括鲁班系统。从OTT的业务场景出发，这些平台存在一些不足：比如，所生产物料的最终落地形式是一次性的，忽略了物料的源和产物最核心的内容价值。从渠道维度来讲，OTT侧坑位图具有高度的同质性，不仅包括内容源如节目，而且从产物的角度也如此。例如《爱我就别想太多》，某电视厂商对资源位有明确的要求，而且优酷等平台方也需要这一内容源，内容源的价值就应该被放大。另外，优酷需要将同一个成品图，投放到不同渠道上，如果能从产物角度做沉淀，成品图才能发挥最大价值。
2）场景单一
制图工具解决的问题非常有限，主要是节目图的制作。前文提到，从内容源到成品图都缺少相应沉淀，这使得自动化制图服务的场景单一，和当前平台能力相比有明显差距。
现阶段OTT自动化制图涵盖了节目图、轮播、专题、动图等常见的制图场景，并结合自动化与半自动化双轨模式。半自动化场景下可以充分发挥运营创造性，基于原材料做创新性尝试；在自动化场景下，直接对接专题轮播系统，使得依赖于特定模板的制图无需人工参与。更近一步，在大数据推荐上也有相应场景，比如依赖于客户端唯一标识实现个性化的专题类推荐，这使得自动化制图一改之前"自动化"包装的外表。
3）分发效率
平台建立之初，从素材源到成品的完整链路都在本地环境完成，依赖于工具平台下载的成品图对接给运营、第三方进行投放。严重依赖于运营的人力投入，分发效率低，其原因是从内容源到成品库，到最终的分发链路缺乏一致性，所以使得整个系统没有“活”起来。
所以从平台建立开始，我们就在探索一条"活"的完整链路。通过链路的升级，不仅能完成内容源、成品库的沉淀，也包括最终分发链路的升级，从而摆脱传统工具平台面临的点状而非面状链路。
4）TOB厂商
"巧妇难为无米之炊"，在自动化制图场景下，所谓的“米”就是模板，模板的格式包括但不限于PSD、SKETCH等，也包括如SVG，比如海棠。“米”是最核心的内容，如果不能从特定的场景中提取内容共性，那么自动化制图领域下的效率提升就非常有限，因此共性才是最应该被重视的特征。
并且，这种共性不仅存在于单个内容提供商，也存在于提供商之间。
2、OTT自动化制图的模式
自动化制图的优势非常明显：
第一是链路的升级：通过自动化制图的流程，可将原来"线下讨论-UED设计-效果确认-开发使用图片"的一次性长链路，转化为"UED设计模板-运营制图-自动/半自动分发"的非一次性完整流程，缩短沟通成本。
第二，内容共享红利：基于系统设计的高质量毛料库，产品库可进一步沉淀，打通多方，减少任何三方重复设计的可能性，将内容价值从原来的一方扩展到整个合作方生态，形成完整的内容回流链路；
第三，分发链路的建设：基于系统设计的成品图无需任何人工对接，可直接输出到渠道三方或者对接任何系统。现有可行的尝试，如专题系统自动化，大数据的个性化推荐场景等，完成从内容生产到内容自动分发的一体化能力建设。
制图效率环节：在半自动化制图场景，站外投放时间可从原来周级缩短为小时级，计件的时间成本减低50%~60%。而在自动化制图场景，无需任何人工干预的方式，使得自动化制图能真正发挥价值。
二、OTT自建自动化制图平台
可能会有人问，阿里已经有鲁班系统等自动化制图平台，为什么优酷OTT要自建？
1、为什么考虑自建？
与鲁班系统服务的（侧重商品化属性）场景不同， OTT场景更侧重媒资属性。图片主体维度的偏差，使得很多原本在商品制图场景下的规则被打破。比如一个简单的元素缩放操作，常规是按照等比加移动的方式解决。但是在以人物为中心的场景，这可能并不合理。因为在以人为主体的场景中，所有模板的指定需要考虑“人物”，而非人物所在元素图片的缩放，简单的说就是人脸，否则可能面临着人物缩放不满足模板要求的场景。因此，我们需要更进一步引入算法或人工打标的新思路。而且，除了元素缩放的特有场景，其实这种区别还很多。比如特定场景的模糊效果、动图绘制、自动化能力输出等等，这种基于特定业务特性的需求海棠确实难以做到定制。
2、商品图使用海棠
除了生产媒资海报图以外，OTT业务也需要生产商品图。比如天猫魔盒:
在没有自建系统之前，所有天猫魔盒的图片生产全部依赖于海棠。设计师从海棠后台传入模板，然后基于此模板在海棠上做相应的坑位图。但自建系统后也慢慢尝试切回到自有系统，主要原因有两个：
第一，内容回流： OTT业务本身是一闭环系统，媒资图和商品图缺一不可。这使得内容隔离渐渐不被接受。内容回流到自有系统后可以做统一管理、分发，享受现有系统提供的能力；
第二，定制化能力：设计师的需求往往依据业务的迭代渐渐变化，渐进增强成为一个常态。因此，当自己的述求不被满足或者不会被满足后可能会渐渐的丧失信心，进而转向新的平台。而自建系统正好提供了这样一个契机。下图提供了一个基于多模板拼接的述求。任何模板可以随意拖进工作区，然后对模板元素加工并设置模板特性，比如模板间距等。
三、OTT自动化制图的流程
关于自动化制图我们是如何实现的？整体流程可以简化为下图:
1、模板解析与数据格式化
自动化制图的前提是内容的共性，共性点更近一步的提取，就是模板，模板格式包括但不限于PSD、SKETCH、SVG等。任意一张成品图都可以看做是基于某一种模板生产出来的，这张成品图由不同图层构成，这和Photoshop中的图层是同一个道理。比如以下示例图就包含了角标、文案卖点、主题、主角、蒙版，背景图等诸多图层。通过对不同图层的自由组合、编辑，得到最终的成品图。
上面讲到模板是由不同的图层所描述的，更形象的，模板就是解析后得到的格式化数据，描述了模板中的元素信息，如位置、尺寸、数量等等。而成品图可以看做是基于这些约定（也可以看做是图纸）生产出来的最终元素。
上图就是对PSD的解析后获取到的模板缩略图。当然，正如前文所讲，解析后图片的存在形式也不再是图片本身，而是格式化的数据，一般是对应的JSON。该JSON包含了模板指定的所有元素信息：
const templateInfo = {
"modelBase": {
// 包括模板本身的信息，如尺寸等
},
"psdLayerInfoList": null,
"person": [
// 模板包含的主体个数，主体可以是人或者其他元素
// 也包括主体的人脸信息等
],
"bgPic": {
//背景图
},
"themeGradientMask": [{
//主题渐变
}],
"showNameH": [{
}],
"showNameV": [{
}],
"mMask": [{}],
"mAppLogo": [{
}],
"mFontAppName": [{}]
}2、前端依据模板绘制流程
服务端做了统一的数据格式化后，给到前端的是格式化的数据，数据指定了模板包含的所有元素信息，前端基于该元素信息进行绘制。
1）分层绘制
HTML5页面中图层的概念大家应该已经很熟悉了。讲到HTML5的网页分层就需要深入理解Chrome渲染原理中的RenderObject,、RenderLayer、Graphiclayer等几棵树。
除了网页会分层以外，Canvas中绘制的元素也可以分层，分层绘制有很多优势。比如在游戏场景中，很多背景类的图层需要重绘的可能性远比动态元素，如障碍物低得多。因此，在每一帧的绘制行为中，可以绕过相应背景图的绘制，直接绘制当前场景变化的图层即可，这与Chrome网页分层要解决的问题是一样的。
class SmallMultiLayerCanvas {
constructor(id) {
this.id = id;
this.canvas = document.getElementById(id);
this.ctx2d = this.canvas.getContext('2d');
this.layers = [];
}
static extend = function (defaults, options) {
var extended = {}, prop;
for (prop in defaults) {
if (Object.prototype.hasOwnProperty.call(defaults, prop))
extended[prop] = defaults[prop];
}
for (prop in options) {
if (Object.prototype.hasOwnProperty.call(options, prop))
extended[prop] = options[prop];
}
return extended;
};
// 添加图层
addLayer(obj) {
const layer = SmallCanvas.extend({
id: Math.random().toString(36).substr(2, 5),
show: true,
render: function (canvas, ctx) { }
}, obj);
if (this.getLayer(layer.id) !== false) {
return false;
}
this.layers.push(layer);
return this;
};
//渲染所有图层
render() {
var canvas = this.canvas;
var ctx = this.ctx2d;
this.layers.forEach(function (item, index, array) {
if (item.show)
item.render(canvas, ctx);
});
};
//获取一个图层
getLayer(id) {
var length = this.layers.length;
for (var i = 0; i < length; i++) {
if (this.layers[i].id === id)
return this.layers[i];
}
return false;
};
// 移除一个图层
removeLayer(id) {
var length = this.layers.length;
for (var i = 0; i < length; i++) {
if (this.layers[i].id === id) {
removed = this.layers[i];
this.layers.splice(i, 1);
return removed;
}
}
return false;
};
}以上是一个简单的分层绘制的类，通过该类可以随意新增、移除、获取、渲染任意的图层。这也是很多复杂的多图层绘制框架的最核心思想，比如fabric.js或者konvajs。有了这样的图层管理框架，就可以根据服务端下发的格式化数据来绘制模板中指定的任意元素，以模板为图纸，生产出符合设计规定的核心产品。例如:
<canvas id="theCanvas" width="512" height="512"></canvas>在该Canvas上，我们绘制出几个指定的图形看看效果如何:
const myCanvas = new SmallMultiLayerCanvas("theCanvas");
myCanvas.addLayer({
id: 'background',
render: function (canvas, ctx) {
ctx.fillStyle = "black";
ctx.fillRect(0, 0, canvas.width, canvas.height);
}
})
.addLayer({
id: 'squares',
render: function (canvas, ctx) {
ctx.fillStyle = "#E5E059";
ctx.fillRect(50, 50, 150, 150);
ctx.fillStyle = "#BDD358";
ctx.fillRect(350, 75, 150, 150);
ctx.fillStyle = "#E5625E";
ctx.fillRect(50, 250, 100, 250);
}
})
.addLayer({
id: 'circles',
render: function (canvas, ctx) {
ctx.fillStyle = "#558B6E";
ctx.beginPath();
ctx.arc(75, 75, 80, 0, 2 * Math.PI);
ctx.fill();
ctx.beginPath();
ctx.fillStyle = "#88A09E";
ctx.arc(275, 275, 150, 0, 2 * Math.PI);
ctx.fill();
ctx.beginPath();
ctx.fillStyle = "#704C5E";
ctx.arc(450, 450, 50, 0, 2 * Math.PI);
ctx.fill();
}
})
.addLayer({
id: 'triangles',
render: function (canvas, ctx) {
ctx.fillStyle = "#DAF7A6";
ctx.beginPath();
ctx.moveTo(120, 400);
ctx.lineTo(250, 300);
ctx.lineTo(300, 500);
ctx.closePath();
ctx.fill();
ctx.fillStyle = "#FFC300";
ctx.beginPath();
ctx.moveTo(400, 100);
ctx.lineTo(350, 300);
ctx.lineTo(230, 200);
ctx.closePath();
ctx.fill();
ctx.fillStyle = "#C70039";
ctx.beginPath();
ctx.moveTo(100, 100);
ctx.lineTo(100, 300);
ctx.lineTo(300, 300);
ctx.closePath();
ctx.fill();
}
});
myCanvas.render();
上面的代码通过链式调用在Canvas中添加了4个对象，id分别为background、squares、circles、triangles。而且每一个对象都有相应的render方法，该方法指定了元素本身在Canvas的上下文是如何绘制的。基于以上代码可以看到在Canvas中绘制的效果：
2）单量与批量模式实时渲染
本小节将讲述首轮绘制后如何基于用户输入做相应的更新。其实所有的半自动化绘图场景，运营不可能只根据某一个模板进行绘制，换句话说，多模板同时绘制的场景必须加以考量。
比如，大多数场景下，运营需要同时基于模板来绘制海信、康佳、歌华、LG的所有坑位图然后导出或者投放，进而摆脱每次只能单独绘制导出单模板的低效模式。因此基于多模板实时绘制渲染的方式就亟待解决。基于此，在半自动化绘制场景中，天生支持多模板实时渲染绘制的模式，正如下面的动图所示：
上图展示的是多模板实时修改的场景，也就是所谓的联动模式。但在未开启联动模式的场景下，所有的修改只针对单模板生效。因此在满足成品图共性的同时又保证了模板的个性。
3、数据统一存储在服务端
前面讲过，工具化平台的设计思路没法做到链路的完整串联，进而完成内容的回流，这在平台化的思路下是行不通的。平台化解决问题的思路是：从内容生产到内容消费的完整链路串联。
基于此，从输入到输出，到最终的分发都需要流动起来，这一切的前提都基于数据的存储，从输入源到输出结果。基于存储的结果，完成了从自动化生产，个性化等自由推荐。
四、OTT蜂鸟制图场景的主要输出与输入
下图展示了制图平台在业务上所做的尝试，也总结了在支撑业务的同时，如何在技术上做范式的探索。
从1.0到2.0，是整个系统架构的升级。系统现有支持能力在OTT场景下已经逐渐完善起来。
1、技术侧主要输出
1）服务化的能力
服务化的能力是上面所述的解决问题范式的具体形式，而制图平台服务化的能力已经涵盖了包括：通用模板解析能力，图片合成服务化能力，素材服务化能力，统一分发能力等等。
a) 通用模板解析能力，不仅适用于制图场景的数据格式化，在智能化领域也有涉及；
b) 图片合成服务化能力，不仅可用于制图场景，对于动画合成场景也有渗透；
c) 至于素材的服务化，分发能力的联合在业务赋能的同时，也能谋求业务发展方向的新思路。
2）半自动化合图尝试
服务化能力将制图的触角做了极大的延展，但在半自动化的制图场景，依然需要探究新的制图范式。基于此，我们产出了自有的Canvas合图尝试，这与鲁班、海棠的模式有极大的差异。这条路没有太多的参考，很多问题需要自己去挖坑和填坑。
2、无人工自动化制图
自动化制图具有极大的吸引力，无需运营任何手动制图干预，直接在系统中选择相应的内容集合即可。因此，这种业务赋能尝试也被极大的重视起来。在OTT业务范围内比较成功的案例就是专题系统：
通过指定内容集合(scgid)以及相应的封面图生成规则就可生成相应的专题推荐内容，极大的节省了人力成本。
