杭州是一座極有包容性的城市，古韻清雅的街道景點(diǎn)隨處可見，現(xiàn)代建筑群設(shè)計(jì)感十足，傳統(tǒng)底蘊(yùn)與現(xiàn)代科技被這座古城兼容并蓄，完美融合。HDG華為開發(fā)者匯，就將杭州作為第四站，5位講師首次揭秘華為的CloudOpera、PaaS、融合視頻3個(gè)生態(tài)圈，技術(shù)干貨無私分享，聽眾疑問現(xiàn)場(chǎng)解答，思想的小火花一直在碰撞，參會(huì)的開發(fā)者大呼過癮。

華為融合視頻多屏應(yīng)用系統(tǒng)工程師彭浩是杭州站沙龍最后一位發(fā)言的講師，由于他所演講的內(nèi)容全部是華為之前沒有公開過的，因此引起開發(fā)者們極大的關(guān)注，甚至一位來自UT斯達(dá)康的開發(fā)者，由于在后排視線不夠廣，一直在站著聽彭浩講解。

[[169858]]

現(xiàn)場(chǎng)實(shí)錄如下：

對(duì)于接口的牽引式，我們希望90%以上的這些頁(yè)面或者說用戶的操作，比如說加PI的操作，我們只調(diào)一個(gè)接口，就可以把我們所需要的數(shù)據(jù)和業(yè)務(wù)完成，這是我們的牽引。基于這樣的牽引，我們重新構(gòu)建了平臺(tái)的這些接口定義。我們又抽出了一個(gè)業(yè)務(wù)層，雖然這個(gè)平臺(tái)實(shí)現(xiàn)大宗業(yè)務(wù)，但是我們這邊還是有一些業(yè)務(wù)的東西，把業(yè)務(wù)層抽出來，把公共業(yè)務(wù)放在這一層里面，這是我們V6版本的一個(gè)架構(gòu)。

基于這樣的架構(gòu)，我們定義了四種定制模式。一種就是最簡(jiǎn)單的白標(biāo)定制，白標(biāo)定制就是支持定制的東西，支持定制參數(shù)、logo、配色、圖片、文字這些資源文獻(xiàn)的東西。這個(gè)定制能力主要是提供給運(yùn)營(yíng)商用的，讓運(yùn)營(yíng)商可以比較方便的改改色調(diào)，改改logo。我們提供的定制方式是無碼化錄制，我們會(huì)提供一個(gè)基線的代工程，提供一個(gè)白標(biāo)的定制工具，提供一個(gè)定制指南。運(yùn)營(yíng)商可以利用工具加載我們的代碼，加載代碼之后我們的定制項(xiàng)就會(huì)顯示在上面，定制運(yùn)營(yíng)可以切換替換這些文件，達(dá)到一種定制。我們可以提供這種打增量包或者打全量包的能力，運(yùn)營(yíng)商可以進(jìn)行全量征集或者增量征集，這是針對(duì)運(yùn)營(yíng)商的白標(biāo)定制。

后面一種定制形式是我們交付團(tuán)隊(duì)或者是第三方來做的定制，UI簡(jiǎn)單定制就是基于我們基線的這套UI，做一些界面上的簡(jiǎn)單調(diào)整，比如說如果運(yùn)營(yíng)商覺得這個(gè)VOD的布局要換一換了，就是個(gè)別頁(yè)面的調(diào)整，我們把它叫做UI簡(jiǎn)單定制。UI簡(jiǎn)單定制我們提供了基線的代碼工程，基線的定制的開發(fā)指南，平臺(tái)的接口模擬器，和工程能力的推薦工具。交付團(tuán)隊(duì)或者開發(fā)團(tuán)隊(duì)可以通過我們基線的代碼工程，進(jìn)行一些簡(jiǎn)單定制。

UI全新定制就是基于我們的SDK和控件庫(kù)做UI定制，我們提供的代碼工程實(shí)際就是一個(gè)參考作用，交付團(tuán)隊(duì)會(huì)選擇用或者不用。如果是我們自己交付的話，我們交付團(tuán)隊(duì)肯定會(huì)用這個(gè)代碼。但是如果是請(qǐng)第三方來做交付的話，他們可以選擇性的用不用。但是同時(shí)我們業(yè)提供了大量的SDK，來屏蔽了平臺(tái)式的接口，定制團(tuán)隊(duì)可以直接使用我們現(xiàn)成的SDK，不需要暴露平臺(tái)的接口給第三方了。包括我們的控件庫(kù)第三方也可以正常使用。這是UI的全新定制，提供平臺(tái)的接口，包括這些開發(fā)指南，開發(fā)指南又包括SDK如何使用。在這個(gè)下面局方請(qǐng)第三方全新開發(fā)，這是基于這個(gè)框架定義的四種定制模式。

我們對(duì)V2和V6的總結(jié)是，它的優(yōu)勢(shì)相當(dāng)于我們又回到了Native，在體驗(yàn)和性能上面得到保證，技術(shù)通用。多屏又車去了基礎(chǔ)控件庫(kù)及SDK，可以獨(dú)立發(fā)布，支持屏與屏、版本與版本之間的共享。缺點(diǎn)還是在于IOS門檻比較高，人力資源無法共享，工作量相對(duì)比較大。

下面再介紹一下我們框架里面的一些關(guān)鍵技術(shù)，第一個(gè)是NodeJS，我們?cè)谟肗odeJS之前，一般頁(yè)面的運(yùn)行模式是這樣的，瀏覽器加載我們的模板，模板解析完之后執(zhí)行代碼，做(04：52)的數(shù)據(jù)請(qǐng)求，訪問數(shù)據(jù)之后，數(shù)據(jù)JS處理完數(shù)據(jù)，數(shù)據(jù)生成一個(gè)頁(yè)面，操作觸發(fā)瀏覽器渲染頁(yè)面。我們可以看到在這樣的所謂的胖客戶端模式下面，我們對(duì)終端的性能和瀏覽器的性能依賴是比較強(qiáng)的。如果打個(gè)比方是在PC上面可能還好，或者一些簡(jiǎn)單頁(yè)面可能還好。但是如果是我們對(duì)運(yùn)營(yíng)商，除了交付高端的機(jī)頂盒，還有低端機(jī)頂盒，低端機(jī)頂盒上面又是一些復(fù)雜頁(yè)面，做這些業(yè)務(wù)邏輯相對(duì)來說對(duì)KPI影響流必須大。

在引入了NodeJS之后，我們的頁(yè)面交付模式就是這樣，我們請(qǐng)求放在NodeJS上面這個(gè)模板，服務(wù)器側(cè)執(zhí)行代碼，然后去向平臺(tái)去請(qǐng)求接口，訪問數(shù)據(jù)。服務(wù)器側(cè)把這些數(shù)據(jù)處理完之后，通過操作把數(shù)據(jù)和模板綁定，生成HTML頁(yè)面，到終端這邊瀏覽器只需要直接去渲染HTML頁(yè)面就可以了。這樣的話就減輕了對(duì)終端性能的依賴，也就是說在服務(wù)器端就完成了(06：17)操作和渲染的能力。我們測(cè)試大概在一些復(fù)雜頁(yè)面上，KPI大概能提升一兩百毫秒左右，對(duì)于低端的盒子提升就會(huì)更多一點(diǎn)。

這是我們對(duì)NodeJS的一個(gè)應(yīng)用，EPG的首頁(yè)布局動(dòng)態(tài)管理的功能。這是我們的首頁(yè)，首頁(yè)所謂動(dòng)態(tài)是指什么呢，就是我們模板這一套上去之后，運(yùn)營(yíng)商可以自己定制這些(06：55)。頁(yè)面上的這些布局都是局方可以自己調(diào)整的。比如說導(dǎo)航欄到底配置幾個(gè)，每一個(gè)多寬，里面展示什么字段，每個(gè)group里面有多少個(gè)元素，group的名字是什么，group的商業(yè)位置是什么，group的大小是什么，group里面取的是哪塊數(shù)據(jù)，每個(gè)數(shù)據(jù)里面排版，比如說復(fù)版海報(bào)到底怎么放，也可以豎版，也可以橫版，里面海報(bào)大小都是可以自定義調(diào)整的，不需要生成代碼。這個(gè)工作方式就是運(yùn)維人員可以用動(dòng)態(tài)的桌面的管理工具，通過拖拽式的方式定義這些布局和這些數(shù)據(jù)是從哪兒來的，保存之后生成一個(gè)桌面的描述文件，把這個(gè)桌面的描述文件部署到VS平臺(tái)上面去，我們?cè)谡?qǐng)求的時(shí)候直接訪問NodeJS里面的部署模板，NodeJS部署模板里面先去請(qǐng)求桌面的描述文件，根據(jù)描述文件然后去獲取對(duì)應(yīng)的接口。根據(jù)描述文件調(diào)用這個(gè)接口，獲取到相應(yīng)的數(shù)據(jù)，然后再根據(jù)描述文件里面的布局信息，把這些EMI生成起來之后，一次性的反饋給模板，模板只需要渲染和展示就可以了。

我們看到這么一大堆東西如果是在客戶端做是很耗性能的，因?yàn)檫@邊數(shù)據(jù)量也很大，動(dòng)能量也很大，如果在客戶端這邊組織的話，性能消耗比較大，因?yàn)檫@全都是動(dòng)態(tài)的內(nèi)容，不是靜態(tài)的內(nèi)容，現(xiàn)在這種東西都是放在服務(wù)器端做，放在NodeJS里面做。我們還有一些其他頁(yè)面，比如說TV大的頁(yè)面，那種動(dòng)態(tài)的TV的頁(yè)面，根據(jù)節(jié)目時(shí)長(zhǎng)可以展示這個(gè)節(jié)目單大小的比較復(fù)雜的TV大的頁(yè)面，也是在這個(gè)NodeJS里面，在服務(wù)器端做渲染的。

另外我們引用了一個(gè)Angular2這個(gè)開源的框架了，我們引入這個(gè)框架的原因主要還是在于我們?cè)瓉碜约簩懙膃Base的框架有一些關(guān)鍵的問題解決不了，因?yàn)槲覀僥Base框架寫的比較薄，就會(huì)導(dǎo)致這個(gè)性能這塊我們是沒法掌控的。但是性能這個(gè)東西，KPI的東西只能靠開發(fā)人員自己的開發(fā)水平來保障。如果開發(fā)水平高一點(diǎn)，知道我們要對(duì)動(dòng)作要做一次性渲染的動(dòng)作，少出漏洞，我性能就會(huì)高一點(diǎn)。開發(fā)水平比較低的話，頻繁操作，可渲染能力就會(huì)差，這是我們eBase無法掌控這個(gè)東西在Angular2里面沒有有這個(gè)問題，因?yàn)锳ngularGS2.0本身自身就有模板，并且它有數(shù)據(jù)訪問的功能。只要我們?cè)趯懘a的時(shí)候把這個(gè)數(shù)據(jù)跟模板進(jìn)行綁定，用戶就不需要操作DOM了，只需要操作數(shù)據(jù)就可以了，這是Angular2天然的優(yōu)勢(shì)。

我們知道框架這個(gè)東西并不能優(yōu)化性能，因?yàn)椴挥每蚣苄阅苁亲詈玫?，怎么好呢，就是看開發(fā)人員水平了，開發(fā)人員水平越高，不用框架自然性能就越好?？蚣芙鉀Q什么，框架解決的就是用比較低的技術(shù)門檻來實(shí)現(xiàn)高性能的應(yīng)用，Angular2在這方面有天然的優(yōu)勢(shì)。另外就是開發(fā)效率，由于我們不需要做DOM操作了。Angular2又是支持這種TS的，我們現(xiàn)在PC和AP模板現(xiàn)在都是用TS去編寫，支持TS編譯，所以也避免了很多低級(jí)問題，因?yàn)閖Query沒法預(yù)編譯。我們?cè)陂_發(fā)的時(shí)候，如果開發(fā)人員水平不夠的話，可能就會(huì)出現(xiàn)一些低級(jí)問題。在Angular2里面這個(gè)問題就能比較好的解決。

在工程能力方面，Angular2本身提供了很多單元測(cè)試、UI測(cè)試、性能測(cè)試的功能，我們?cè)瓉砭蜎]有這樣的能力。Angular2是基于組建開發(fā)的，它的代碼的模塊化是比較好的，這也是它的一個(gè)優(yōu)勢(shì)。在開源方面，它有強(qiáng)大的社區(qū)，資料學(xué)習(xí)比較方便。我們?nèi)绻觅Y源框架的話，可用量比較大。引入Angular2也是我們之前的一個(gè)原則，盡量使用開源的一些東西，公共技術(shù)。

我們?cè)谶x取Angular2的時(shí)候也做了一些不同技術(shù)的對(duì)比，主要還是從性能方面對(duì)比了幾個(gè)框架，Angular2是最佳的，比reacts和Angular1好不少。我們一開始選定的選的是Angular1，后來通過性能對(duì)比發(fā)現(xiàn)Angular1性能比較差，它本身在框架性能方面表現(xiàn)不太好。我們又做了機(jī)頂盒上兼容性的測(cè)試，機(jī)頂盒里面的瀏覽器和GS引擎是比較老的，我們做了測(cè)試之后發(fā)現(xiàn)最新的機(jī)頂盒是完全兼容的，以前一些老的機(jī)頂盒發(fā)現(xiàn)一些不兼容的對(duì)象，我們也通過加載了對(duì)應(yīng)的GS的模擬庫(kù)，來解決這個(gè)問題。前面也提到Angular2可以實(shí)現(xiàn)高的KPI，讓技術(shù)門檻比較低的人實(shí)現(xiàn)一個(gè)高KPI的APP，這方面它的表現(xiàn)也是不錯(cuò)的。在成本上我們也做了一些測(cè)試頁(yè)面，做這種自化腳本去跑，也沒有發(fā)現(xiàn)常有的問題，沒有發(fā)現(xiàn)內(nèi)存泄漏。

簡(jiǎn)單說一下Angular2，Angular2是谷歌開源的一個(gè)框架，全名叫AngularJS 2，它有很多特點(diǎn)，速度快，模塊化，跨平臺(tái)，服務(wù)器渲染，我們主要是關(guān)注它的性能，一個(gè)模塊化，一個(gè)自動(dòng)綁定。自動(dòng)綁定功能用起來比較舒服，有了這個(gè)功能，開發(fā)人員就不需要操作DOM，只需要操作數(shù)據(jù)就可以了，可以專心的組織數(shù)據(jù)，組織業(yè)務(wù)邏輯，DOM渲染是由Angular2這個(gè)框架本身把它隔離出去了，Angular框架會(huì)自動(dòng)的在數(shù)據(jù)改變的時(shí)候一次性的渲染DOM。Angular2未來也將是一個(gè)跨平臺(tái)的web框架，它的安卓的渲染引擎和IOS渲染引擎現(xiàn)在還在開發(fā)當(dāng)中，我們也是對(duì)這個(gè)期待比較高。

隨著我們現(xiàn)在機(jī)頂盒的能力越來越強(qiáng)，機(jī)頂盒對(duì)webGL支持的也越來越好，對(duì)一些動(dòng)畫效果我們現(xiàn)在也在用webGL技術(shù)來做。我們?cè)趯W(xué)webGL引擎的時(shí)候通過開發(fā)云的支持，3D、2D、VR的支持和性能的維度來選擇的，我們對(duì)比了業(yè)界比較流行的幾個(gè)webGL引擎，Pixi-js、LayaBox、Cocosed-js、Three-js。在語(yǔ)言上面我們是希望它可以支持Type script，所以在這點(diǎn)上Pixi-js和LayaBox其他兩個(gè)就不支持了。在2D和3D上面我們要支持2D，因?yàn)?D和VR對(duì)我們來說在機(jī)頂盒上目前還應(yīng)用不到，短期內(nèi)也看不到，2D是滿足的。性能上面Pixi-js性能在2D上面也是最高的，LayaBox也不錯(cuò)。我們之所以沒有選LayaBox是因?yàn)樗婚_源，所以最后我們選型選的是Pixi-js。我們做了一些對(duì)面的對(duì)話效果現(xiàn)在是用webGL去做的，在我們支持webGL瀏覽器上面，性能非常不錯(cuò)。

在定制能力上面前面提到了，原來大的界面上面數(shù)據(jù)比較多，有頻道列表，有節(jié)目單列表，有節(jié)目單詳情，有PPI圖表，頻道收藏這些東西。原來這個(gè)頁(yè)面我們可能要調(diào)用平臺(tái)兩到三個(gè)借口，現(xiàn)在調(diào)用一個(gè)接口就可以了。但也不是所有頁(yè)面都是調(diào)月一個(gè)接口可以搞定的，比如像首頁(yè)，這邊的數(shù)據(jù)是比較多的。對(duì)于有些達(dá)不到調(diào)用接口考慮的事的時(shí)候，平臺(tái)也提供這種接口編排能力，把這種大顆粒接口通過界面的拖拖拽拽，就可以編排一個(gè)接口出來。當(dāng)然這種拖拖拽拽效果只是基于接口沒有先后關(guān)系的情況去搞定的。如果接口和接口之間有關(guān)系的話，它也提供微量編碼的能力，就是我們可以通過GS編碼的能力，把幾個(gè)接口編排起來。這是我們對(duì)平臺(tái)接口的一個(gè)優(yōu)化。

我們還提供了豐富的控件庫(kù)，到時(shí)候可以看一下。包括提供了大量的SDK。這些是目前我們對(duì)當(dāng)前的框架的一些關(guān)注的介紹。我們也對(duì)未來，如何視頻的多屏未來的框架進(jìn)行了思考，現(xiàn)在主要還是OTT屏的交互方式，比如剛才說到Native 在工作量上還是比較大，我們也對(duì)比了目前比較主流的開發(fā)方式，一種是純Native的，一種是Native+HK85的，還有純HK85。如果是純Native的話，開發(fā)人員需要掌握，IOS來說需要掌握Obiectwe-C，IOSSDK，對(duì)安卓來說需要掌握jave和安卓SDK，這個(gè)門檻相對(duì)來說比較高。但是對(duì)于Hybrid這種方式開發(fā)人員需要掌握HTML，CSS，javascript，和一個(gè)開源的跨平臺(tái)的框架就可以了，技術(shù)門檻相對(duì)來說會(huì)低一點(diǎn)。如果是純APP的，就只需要掌握HTML，CSS，javascript就可以了，門檻是最低的。從發(fā)布方式來說，Native和Hybrid發(fā)布的周期比較長(zhǎng)，都是要通過app Store/Market的方式來發(fā)布，純APP只要通過web發(fā)布就可以了。從速度和開發(fā)成本和維護(hù)成本來說，Native都是最高的，Hybrid是居中，純APP是最低的。從圖形的渲染能力和應(yīng)用的性能上面來看，Native也是最優(yōu)的，APP和Hybried是居中的。

從目前主流上來說，還是Native的應(yīng)用占大多數(shù)，Hybrid和app還是躋身于微信平臺(tái)的小游戲，相對(duì)來說不多，而且對(duì)我們來說不太適用。我們這邊考慮的是，后面轉(zhuǎn)型通過hybrid方式可能是未來的主流，因?yàn)橥ㄟ^hybrid交付的東西它的優(yōu)點(diǎn)是顯而易見的，開發(fā)開發(fā)速度都是比較高，開發(fā)成本比較低，維護(hù)成本也比較低，相對(duì)Native優(yōu)點(diǎn)顯而易見。而它的缺點(diǎn)正在慢慢的抹平，由于現(xiàn)在跨平臺(tái)的框架越來越成熟，性能越來越好，再加上現(xiàn)在硬件設(shè)備提升的越來越強(qiáng)，它的缺點(diǎn)在抹平。我們認(rèn)為未來應(yīng)該是用hybried方式來開發(fā)。

通過hybrid方式，目前業(yè)界比較流行的剛才提到的一個(gè)是react Native這種框架，react Native是facebook開發(fā)的，weex是阿里最近才開源的一個(gè)項(xiàng)目。從成熟度上來說，我們可能傾向于react Native，但是從編碼的習(xí)慣上來說，我們認(rèn)為前端人員更能接受weex的的編碼的形式。weex這邊還支持動(dòng)態(tài)發(fā)布，這個(gè)我們也是相對(duì)來說比較看重的東西。它可以發(fā)布到server平臺(tái)，應(yīng)用加載的時(shí)候可以把這一小段代碼下載下來，直接提供一個(gè)端到端的解決方案。這個(gè)東西對(duì)我們來說比較有用，因?yàn)槲覀兪敲嫦蜻\(yùn)營(yíng)商開發(fā)，整個(gè)交互壓力比較大。一旦我們應(yīng)用出現(xiàn)了一個(gè)bug，如果bug小還好，如果這個(gè)bug比較大的話，耽誤一周時(shí)間，也許我們的運(yùn)營(yíng)商已經(jīng)丟了，后果是比較嚴(yán)重的。所以這個(gè)東西能幫助我們快速的在線的修復(fù)一些問題，這是比較吸引人的一個(gè)特性。

在阿里給的這個(gè)各方面數(shù)據(jù)上來看，他們也是聲稱在各方面的表現(xiàn)上面都不比react Native差，甚至比他們還好。從這方面來看weex也是一個(gè)非常吸引人的框架，我們也會(huì)對(duì)他們做一些預(yù)言，就是對(duì)未來的思考。我們也期待Angular2.0跨平臺(tái)的能力提供之后，我們也會(huì)考察一下。如果我們對(duì)未來架構(gòu)掌握的話，我們也期望在IOS和安卓還是使用開源的框架來實(shí)現(xiàn)(23：55)方式的交付?；谶@兩個(gè)我們整個(gè)代碼供應(yīng)度就比較高了，在IOS和安卓上面UR代碼是可以供應(yīng)的，JS代碼，頁(yè)面的控制代碼也是可以供應(yīng)的。整個(gè)業(yè)務(wù)層的代碼是完全拉通的，全部通過JS四個(gè)是統(tǒng)一的?？丶右捕际怯肏TMI、CSS、JS這樣的技術(shù)去提供控件?？蚣軐尤绻鸄ngular2預(yù)言沒什么問題的話，我們選型選Angular2，整個(gè)上面也是拉通的。數(shù)據(jù)層也是全部通過拉通的，通過JS層。SDK也是基本上大部分，跟平臺(tái)接口對(duì)接的SDK也基本上拉通的。如果后面我們采用這種框架的話，對(duì)我們工作量減少是非常大的，這也是我們對(duì)未來的一個(gè)展望。

今天跟大家分享的就這么多，謝謝大家。