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

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

[[169858]]

現(xiàn)場實錄如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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