杭州是一座极有包容性的城市，古韵清雅的街道景点随处可见，现代建筑群设计感十足，传统底蕴与现代科技被这座古城兼容并蓄，完美融合。HDG华为开发者汇，就将杭州作为第四站，5位讲师首次揭秘华为的CloudOpera、PaaS、融合视频3个生态圈，技术干货无私分享，听众疑问现场解答，思想的小火花一直在碰撞，参会的开发者大呼过瘾。
华为融合视频多屏应用系统工程师彭浩是杭州站沙龙最后一位发言的讲师，由于他所演讲的内容全部是华为之前没有公开过的，因此引起开发者们极大的关注，甚至一位来自UT斯达康的开发者，由于在后排视线不够广，一直在站着听彭浩讲解。
现场实录如下：
对于接口的牵引式，我们希望90%以上的这些页面或者说用户的操作，比如说加PI的操作，我们只调一个接口，就可以把我们所需要的数据和业务完成，这是我们的牵引。基于这样的牵引，我们重新构建了平台的这些接口定义。我们又抽出了一个业务层，虽然这个平台实现大宗业务，但是我们这边还是有一些业务的东西，把业务层抽出来，把公共业务放在这一层里面，这是我们V6版本的一个架构。
基于这样的架构，我们定义了四种定制模式。一种就是最简单的白标定制，白标定制就是支持定制的东西，支持定制参数、logo、配色、图片、文字这些资源文献的东西。这个定制能力主要是提供给运营商用的，让运营商可以比较方便的改改色调，改改logo。我们提供的定制方式是无码化录制，我们会提供一个基线的代工程，提供一个白标的定制工具，提供一个定制指南。运营商可以利用工具加载我们的代码，加载代码之后我们的定制项就会显示在上面，定制运营可以切换替换这些文件，达到一种定制。我们可以提供这种打增量包或者打全量包的能力，运营商可以进行全量征集或者增量征集，这是针对运营商的白标定制。
后面一种定制形式是我们交付团队或者是第三方来做的定制，UI简单定制就是基于我们基线的这套UI，做一些界面上的简单调整，比如说如果运营商觉得这个VOD的布局要换一换了，就是个别页面的调整，我们把它叫做UI简单定制。UI简单定制我们提供了基线的代码工程，基线的定制的开发指南，平台的接口模拟器，和工程能力的推荐工具。交付团队或者开发团队可以通过我们基线的代码工程，进行一些简单定制。
UI全新定制就是基于我们的SDK和控件库做UI定制，我们提供的代码工程实际就是一个参考作用，交付团队会选择用或者不用。如果是我们自己交付的话，我们交付团队肯定会用这个代码。但是如果是请第三方来做交付的话，他们可以选择性的用不用。但是同时我们业提供了大量的SDK，来屏蔽了平台式的接口，定制团队可以直接使用我们现成的SDK，不需要暴露平台的接口给第三方了。包括我们的控件库第三方也可以正常使用。这是UI的全新定制，提供平台的接口，包括这些开发指南，开发指南又包括SDK如何使用。在这个下面局方请第三方全新开发，这是基于这个框架定义的四种定制模式。
我们对V2和V6的总结是，它的优势相当于我们又回到了Native，在体验和性能上面得到保证，技术通用。多屏又车去了基础控件库及SDK，可以独立发布，支持屏与屏、版本与版本之间的共享。缺点还是在于IOS门槛比较高，人力资源无法共享，工作量相对比较大。
下面再介绍一下我们框架里面的一些关键技术，第一个是NodeJS，我们在用NodeJS之前，一般页面的运行模式是这样的，浏览器加载我们的模板，模板解析完之后执行代码，做(04：52)的数据请求，访问数据之后，数据JS处理完数据，数据生成一个页面，操作触发浏览器渲染页面。我们可以看到在这样的所谓的胖客户端模式下面，我们对终端的性能和浏览器的性能依赖是比较强的。如果打个比方是在PC上面可能还好，或者一些简单页面可能还好。但是如果是我们对运营商，除了交付高端的机顶盒，还有低端机顶盒，低端机顶盒上面又是一些复杂页面，做这些业务逻辑相对来说对KPI影响流必须大。
在引入了NodeJS之后，我们的页面交付模式就是这样，我们请求放在NodeJS上面这个模板，服务器侧执行代码，然后去向平台去请求接口，访问数据。服务器侧把这些数据处理完之后，通过操作把数据和模板绑定，生成HTML页面，到终端这边浏览器只需要直接去渲染HTML页面就可以了。这样的话就减轻了对终端性能的依赖，也就是说在服务器端就完成了(06：17)操作和渲染的能力。我们测试大概在一些复杂页面上，KPI大概能提升一两百毫秒左右，对于低端的盒子提升就会更多一点。
这是我们对NodeJS的一个应用，EPG的首页布局动态管理的功能。这是我们的首页，首页所谓动态是指什么呢，就是我们模板这一套上去之后，运营商可以自己定制这些(06：55)。页面上的这些布局都是局方可以自己调整的。比如说导航栏到底配置几个，每一个多宽，里面展示什么字段，每个group里面有多少个元素，group的名字是什么，group的商业位置是什么，group的大小是什么，group里面取的是哪块数据，每个数据里面排版，比如说复版海报到底怎么放，也可以竖版，也可以横版，里面海报大小都是可以自定义调整的，不需要生成代码。这个工作方式就是运维人员可以用动态的桌面的管理工具，通过拖拽式的方式定义这些布局和这些数据是从哪儿来的，保存之后生成一个桌面的描述文件，把这个桌面的描述文件部署到VS平台上面去，我们在请求的时候直接访问NodeJS里面的部署模板，NodeJS部署模板里面先去请求桌面的描述文件，根据描述文件然后去获取对应的接口。根据描述文件调用这个接口，获取到相应的数据，然后再根据描述文件里面的布局信息，把这些EMI生成起来之后，一次性的反馈给模板，模板只需要渲染和展示就可以了。
我们看到这么一大堆东西如果是在客户端做是很耗性能的，因为这边数据量也很大，动能量也很大，如果在客户端这边组织的话，性能消耗比较大，因为这全都是动态的内容，不是静态的内容，现在这种东西都是放在服务器端做，放在NodeJS里面做。我们还有一些其他页面，比如说TV大的页面，那种动态的TV的页面，根据节目时长可以展示这个节目单大小的比较复杂的TV大的页面，也是在这个NodeJS里面，在服务器端做渲染的。
另外我们引用了一个Angular2这个开源的框架了，我们引入这个框架的原因主要还是在于我们原来自己写的eBase的框架有一些关键的问题解决不了，因为我们eBase框架写的比较薄，就会导致这个性能这块我们是没法掌控的。但是性能这个东西，KPI的东西只能靠开发人员自己的开发水平来保障。如果开发水平高一点，知道我们要对动作要做一次性渲染的动作，少出漏洞，我性能就会高一点。开发水平比较低的话，频繁操作，可渲染能力就会差，这是我们eBase无法掌控这个东西在Angular2里面没有有这个问题，因为AngularGS2.0本身自身就有模板，并且它有数据访问的功能。只要我们在写代码的时候把这个数据跟模板进行绑定，用户就不需要操作DOM了，只需要操作数据就可以了，这是Angular2天然的优势。
我们知道框架这个东西并不能优化性能，因为不用框架性能是最好的，怎么好呢，就是看开发人员水平了，开发人员水平越高，不用框架自然性能就越好。框架解决什么，框架解决的就是用比较低的技术门槛来实现高性能的应用，Angular2在这方面有天然的优势。另外就是开发效率，由于我们不需要做DOM操作了。Angular2又是支持这种TS的，我们现在PC和AP模板现在都是用TS去编写，支持TS编译，所以也避免了很多低级问题，因为jQuery没法预编译。我们在开发的时候，如果开发人员水平不够的话，可能就会出现一些低级问题。在Angular2里面这个问题就能比较好的解决。
在工程能力方面，Angular2本身提供了很多单元测试、UI测试、性能测试的功能，我们原来就没有这样的能力。Angular2是基于组建开发的，它的代码的模块化是比较好的，这也是它的一个优势。在开源方面，它有强大的社区，资料学习比较方便。我们如果用资源框架的话，可用量比较大。引入Angular2也是我们之前的一个原则，尽量使用开源的一些东西，公共技术。
我们在选取Angular2的时候也做了一些不同技术的对比，主要还是从性能方面对比了几个框架，Angular2是最佳的，比reacts和Angular1好不少。我们一开始选定的选的是Angular1，后来通过性能对比发现Angular1性能比较差，它本身在框架性能方面表现不太好。我们又做了机顶盒上兼容性的测试，机顶盒里面的浏览器和GS引擎是比较老的，我们做了测试之后发现最新的机顶盒是完全兼容的，以前一些老的机顶盒发现一些不兼容的对象，我们也通过加载了对应的GS的模拟库，来解决这个问题。前面也提到Angular2可以实现高的KPI，让技术门槛比较低的人实现一个高KPI的APP，这方面它的表现也是不错的。在成本上我们也做了一些测试页面，做这种自化脚本去跑，也没有发现常有的问题，没有发现内存泄漏。
简单说一下Angular2，Angular2是谷歌开源的一个框架，全名叫AngularJS 2，它有很多特点，速度快，模块化，跨平台，服务器渲染，我们主要是关注它的性能，一个模块化，一个自动绑定。自动绑定功能用起来比较舒服，有了这个功能，开发人员就不需要操作DOM，只需要操作数据就可以了，可以专心的组织数据，组织业务逻辑，DOM渲染是由Angular2这个框架本身把它隔离出去了，Angular框架会自动的在数据改变的时候一次性的渲染DOM。Angular2未来也将是一个跨平台的web框架，它的安卓的渲染引擎和IOS渲染引擎现在还在开发当中，我们也是对这个期待比较高。
随着我们现在机顶盒的能力越来越强，机顶盒对webGL支持的也越来越好，对一些动画效果我们现在也在用webGL技术来做。我们在学webGL引擎的时候通过开发云的支持，3D、2D、VR的支持和性能的维度来选择的，我们对比了业界比较流行的几个webGL引擎，Pixi-js、LayaBox、Cocosed-js、Three-js。在语言上面我们是希望它可以支持Type script，所以在这点上Pixi-js和LayaBox其他两个就不支持了。在2D和3D上面我们要支持2D，因为3D和VR对我们来说在机顶盒上目前还应用不到，短期内也看不到，2D是满足的。性能上面Pixi-js性能在2D上面也是最高的，LayaBox也不错。我们之所以没有选LayaBox是因为它不开源，所以最后我们选型选的是Pixi-js。我们做了一些对面的对话效果现在是用webGL去做的，在我们支持webGL浏览器上面，性能非常不错。
在定制能力上面前面提到了，原来大的界面上面数据比较多，有频道列表，有节目单列表，有节目单详情，有PPI图表，频道收藏这些东西。原来这个页面我们可能要调用平台两到三个借口，现在调用一个接口就可以了。但也不是所有页面都是调月一个接口可以搞定的，比如像首页，这边的数据是比较多的。对于有些达不到调用接口考虑的事的时候，平台也提供这种接口编排能力，把这种大颗粒接口通过界面的拖拖拽拽，就可以编排一个接口出来。当然这种拖拖拽拽效果只是基于接口没有先后关系的情况去搞定的。如果接口和接口之间有关系的话，它也提供微量编码的能力，就是我们可以通过GS编码的能力，把几个接口编排起来。这是我们对平台接口的一个优化。
我们还提供了丰富的控件库，到时候可以看一下。包括提供了大量的SDK。这些是目前我们对当前的框架的一些关注的介绍。我们也对未来，如何视频的多屏未来的框架进行了思考，现在主要还是OTT屏的交互方式，比如刚才说到Native 在工作量上还是比较大，我们也对比了目前比较主流的开发方式，一种是纯Native的，一种是Native+HK85的，还有纯HK85。如果是纯Native的话，开发人员需要掌握，IOS来说需要掌握Obiectwe-C，IOSSDK，对安卓来说需要掌握jave和安卓SDK，这个门槛相对来说比较高。但是对于Hybrid这种方式开发人员需要掌握HTML，CSS，javascript，和一个开源的跨平台的框架就可以了，技术门槛相对来说会低一点。如果是纯APP的，就只需要掌握HTML，CSS，javascript就可以了，门槛是最低的。从发布方式来说，Native和Hybrid发布的周期比较长，都是要通过app Store/Market的方式来发布，纯APP只要通过web发布就可以了。从速度和开发成本和维护成本来说，Native都是最高的，Hybrid是居中，纯APP是最低的。从图形的渲染能力和应用的性能上面来看，Native也是最优的，APP和Hybried是居中的。
从目前主流上来说，还是Native的应用占大多数，Hybrid和app还是跻身于微信平台的小游戏，相对来说不多，而且对我们来说不太适用。我们这边考虑的是，后面转型通过hybrid方式可能是未来的主流，因为通过hybrid交付的东西它的优点是显而易见的，开发开发速度都是比较高，开发成本比较低，维护成本也比较低，相对Native优点显而易见。而它的缺点正在慢慢的抹平，由于现在跨平台的框架越来越成熟，性能越来越好，再加上现在硬件设备提升的越来越强，它的缺点在抹平。我们认为未来应该是用hybried方式来开发。
通过hybrid方式，目前业界比较流行的刚才提到的一个是react Native这种框架，react Native是facebook开发的，weex是阿里最近才开源的一个项目。从成熟度上来说，我们可能倾向于react Native，但是从编码的习惯上来说，我们认为前端人员更能接受weex的的编码的形式。weex这边还支持动态发布，这个我们也是相对来说比较看重的东西。它可以发布到server平台，应用加载的时候可以把这一小段代码下载下来，直接提供一个端到端的解决方案。这个东西对我们来说比较有用，因为我们是面向运营商开发，整个交互压力比较大。一旦我们应用出现了一个bug，如果bug小还好，如果这个bug比较大的话，耽误一周时间，也许我们的运营商已经丢了，后果是比较严重的。所以这个东西能帮助我们快速的在线的修复一些问题，这是比较吸引人的一个特性。
在阿里给的这个各方面数据上来看，他们也是声称在各方面的表现上面都不比react Native差，甚至比他们还好。从这方面来看weex也是一个非常吸引人的框架，我们也会对他们做一些预言，就是对未来的思考。我们也期待Angular2.0跨平台的能力提供之后，我们也会考察一下。如果我们对未来架构掌握的话，我们也期望在IOS和安卓还是使用开源的框架来实现(23：55)方式的交付。基于这两个我们整个代码供应度就比较高了，在IOS和安卓上面UR代码是可以供应的，JS代码，页面的控制代码也是可以供应的。整个业务层的代码是完全拉通的，全部通过JS四个是统一的。控件层也都是用HTMI、CSS、JS这样的技术去提供控件。框架层如果Angular2预言没什么问题的话，我们选型选Angular2，整个上面也是拉通的。数据层也是全部通过拉通的，通过JS层。SDK也是基本上大部分，跟平台接口对接的SDK也基本上拉通的。如果后面我们采用这种框架的话，对我们工作量减少是非常大的，这也是我们对未来的一个展望。
今天跟大家分享的就这么多，谢谢大家。
