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

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

[[169858]]

現場實錄如下：

對于接口的牽引式，我們希望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也基本上拉通的。如果后面我們采用這種框架的話，對我們工作量減少是非常大的，這也是我們對未來的一個展望。

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