者 | 葉琰，阿里巴巴達摩院XG實驗室視頻標準團隊負責人
責編 | 夕顏
頭圖 | CSDN付費下載自視覺中國
2020年7月1日晚上（日內瓦時間），第十九次JVET會議在線上落下帷幕，新一代國際視頻編碼標準VVC第一版（Versatile Video Coding version 1）[1] 在這次會議上正式定稿。接下來的兩天里，JVET委員會的兩個上層組織（parent body）分別用各自的方式認可了VVC標準：國際電信聯盟ITU-T的SG16 （study group 16）批準VVC標準并正式定名為ITU H.266，而國際標準化組織ISO/IEC的MPEG工作組在第131次會議閉幕大會上批準VVC成為ISO/IEC 23090-3 FDIS（final draft international standard）并正式啟動各個國家最后的投票過程。從2018年4月JVET在美國圣迭戈召開會議，評估各大公司提交的提案書（response to joint call for proposals）并設立了第一個VVC測試模型（VVC test model 1.0）開始，到2020年7月因為疫情將JVET會議從原計劃在日內瓦ITU-T總部改成網會的形式召開，VVC標準共經歷十次會議，總計六千多份技術提案的激烈討論，第一版終于成功定稿。
相比起現在在業界廣泛使用的H.265/HEVC標準和H.264/AVC標準，H.266/VVC標準的制定考慮了更多樣的視頻格式和內容，旨在為已有和新興的視頻應用提供更加強大的壓縮性能以及更加靈活易用的功能。因此它的定稿將會給全球視頻業界帶來巨大的影響，商用VVC編解碼器的成熟可以大幅度降低成本，提升效率，同時與5G網絡更新換代的步伐相配合，促成更多的新興視頻應用的大規模推廣。VVC的標準制定過程也代表著包括阿里巴巴在內的中國各家互聯網公司第一次參加國際視頻標準的制定，因此，VVC標準對中國視頻業界的意義尤其重大。在這篇文章里，讓我們來一起回顧一下VVC標準的制定過程，它所提供的先進的壓縮工具，強大的壓縮性能和靈活功能，以及達摩院XG實驗室視頻標準團隊對VVC標準的貢獻。
國際標準化組織ISO/IEC MPEG和國際電信聯盟ITU-T VCEG簡介
說起對業界影響最深的國際視頻標準，不得不先說一下兩個重磅國際標準組織：國際電信聯盟ITU-T和國際標準化組織ISO/IEC。從組織架構上來說，國際電信聯盟和國際標準化組織都是聯合國下屬的技術部門。這兩個組織所涉及的標準化范圍非常廣泛，涵蓋了通信行業，多媒體行業，AI行業，以及其它數不勝數的行業，遍及大家現代生活的各個方面。這兩家組織在視頻編解碼標準化方面的委員會分別是VCEG （video coding experts group，正式名稱為ITU-T/SG 16/WP3/Q.6）和MPEG（moving picture experts group，正式名稱是ISO/IEC JTC1/SC 29/WG 11）這兩個工作組。如圖 1所示，這兩個視頻標準工作組都是從90年代初開始就制定視頻編解碼標準，到H.266/VVC已經是他們制定的第6代視頻標準，也是這兩強聯手共同制定的第4代國際視頻標準。這兩強聯合所制定的視頻標準對技術的變革和產品的推動都有深刻影響，比如MPEG2（也是ITU H.262）引領了模擬電視到數字電視的變革，H.264/AVC引入了高清視頻和互聯網視頻，并在各種端設備上（包括電視，手機，電腦，機頂盒等）全面落地，而H.265/HEVC則成功引入了超高清4K和HDR 視頻。H.264／AVC和H.265／HEVC這兩個視頻標準是通過技術的變革來推動了商業上的巨大變革的成功案例。它們大幅度推廣了視頻應用，提高了用戶體驗，對業界產生的深遠影響也讓它們分別獲得了國家電視藝術及科學學院所頒布的電視界最高榮譽：黃金時段艾美獎。
圖 1. 各代國際視頻標準“族譜”
讀到這里，大家可能都想問，為什么幾十年過去了，標準組織還在孜孜不倦的制定新的視頻編解碼標準？答案其實很簡單，就是因為雖然同期內信息論和網絡傳輸技術的迅猛發展給消費者帶來了更多的帶寬，但是光靠帶寬的增長自身遠遠滿足不了越來越多的視頻應用對高效率高質量視頻數據傳輸的需求；因此，供不應求的局面造成帶寬資源的成本一直居高不下。為了解決這個問題，每一代視頻標準的迭代更新都有一個必要條件，就是必須在視頻畫面質量保持不變的前提條件下，新的標準相比上一代視頻標準的壓縮性能要翻倍，也就是可以保證用一半的成本來實現同樣的畫質和用戶體驗。如圖 2所示，這個目標在過去的每一次標準更新換代中都做到了，也同樣代表著視頻業界對最新一代標準VVC的期待。
圖 2. 視頻標準更新換代的性能目標：2x的壓縮性能
雖然從正式的標準化流程來說，VVC標準的制定是從2018年4月圣地亞哥會議開始的，但是其實早在2015年10月，VCEG和MPEG就已經成立了JVET （joint video exploration team）聯合技術委員會，并設立JEM（joint exploration model）參考平臺，在此平臺基礎上專注開發比HEVC更加先進的視頻編解碼技術（圖 3）。通過2年多在編解碼技術上耕耘和積累，到2017年，在PSNR（peak signal to noise ratio）指標保持不變的情況下， JEM相比HEVC的參考測試模型HM已經可以做到34%的編碼效率提升，為開始開發新一代視頻標準奠定了重要的技術基礎。同期內，JVET也致力研究360全景視頻，為支持AR 和VR等新興視頻應用打基礎。2016年內JVET建立了360Lib 這個參考平臺，為360度全景視頻的前后處理，編解碼和全景視頻質量評估等重要技術點定義了一整套全鏈路處理流程和質量評估體系。
圖 3. VVC正式標準化開始之前，經歷了3年的技術積累
2017年10月，ITU-T VCEG和ISO/IEC MPEG正式共同發布了新一代標準的技術征求書（joint call for proposals）[2]。這個技術征求書中不光包括了已經在業界廣泛使用的標準動態范圍（standard dynamic range，簡稱SDR）視頻格式，同時還包括了高動態范圍視頻（high dynamic range，簡稱HDR）和360全景視頻兩種新興視頻格式，是ITU-T和ISO/IEC兩個標準組織歷史上第一次發布多視頻格式的技術征求書。經過半年的準備工作，2018年4月圣地亞哥會議上，JVET共收到了來自全世界各地共32個單位所提交的共23份提案（response to joint call for proposals），其中性能最高的提案在同樣PSNR指標下相比HM可以提升40%以上的編碼效率，充分證明下一代標準的編解碼技術已經成熟 [3]。鑒于這個聯合技術征求書的成功，在圣地亞哥會議上，JVET正式更名為 joint video experts team，并將下一代標準命名為versatile video coding，簡稱VVC，并建立了第一版VVC測試模型（VVC test model）VTM-1.0 [4]。
從2018年4月到2020年7月，JVET委員會共召開了10次會議，經歷了100多個高強度會議工作日，處理了來自全世界各地幾十家公司和單位的6000多份技術提案。兩年的時間內，VVC標準順利通過committee draft （CD），draft international standard（DIS）和final draft international standard（FDIS）三個重要里程碑（圖 4），克服了疫情的影響，并在2020年7月按時發布了VVC標準第一版！[1]
圖 4. VVC標準化進程的主要里程碑
做為一個主流視頻標準， VVC產品型態將廣泛觸及視頻產業鏈的各個環節：視頻內容會涵括專業制作的版權內容，日常生活中拍攝的UGC，會議視頻，直播視頻，點播視頻，體育賽事，HDR視頻，全景視頻，監控視頻等多種視頻類目，而設備上也會廣泛覆蓋手機，電腦，攝像頭，機頂盒，電視，頭戴式設備等多種終端。考慮到不同終端的軟硬件能力相差懸殊，尤其是移動端更需特別關注功耗，JVET在制定VVC標準的過程中，不僅追求卓越的壓縮性能，同時也始終倍加關注VVC編解碼算法的復雜度，以保證VVC標準的實現復雜度不超過目前軟硬件的實現能力，以促進VVC標準可以早日在端上有軟硬件的實現并早日在業務和應用中落地。在視頻編解碼這個領域，絕大多數的應用場景都存在著編碼一次解碼多次的不對稱性（比如直播點播廣播等），因此和歷屆標準一樣，相對于編碼器的復雜度來說，VVC標準對解碼器的復雜度控制得更緊。如圖 5顯示，VVC測試模型在從VTM-1.0到VTM-9.0的版本迭代過程中，在壓縮性能大幅度提升的同時，解碼器的復雜度一直基本持平，相比HEVC的解碼復雜度不超過兩倍。同時，編碼的復雜度與壓縮性能基本保持健康的正比關系。截至到VTM-9.0，VVC的性能基本穩定，在同樣PSNR的條件下，相比HEVC對高清和超高清視頻平均碼率節省達到39%。在后面的章節里我們會看到，如果不用PSNR而是用主觀質量做為衡量基準，這樣的壓縮效率的提升可以換算為50%以上的碼率節省。
圖 5. VTM的性能及復雜度演化史
為了提高壓縮性能， VVC相比HEVC增加了30多種新的編碼工具（圖 6），覆蓋了混合視頻編解碼系統框架中的每個模塊，對包括塊劃分，幀內及幀間預測，殘差編碼，變換量化， CABAC熵編碼，環路濾波等模塊都做了一定程度的改進。
圖 6. VVC編碼工具一覽
由于VVC中的編碼工具眾多，篇幅有限在這里不一一贅述。我們就只拿VVC所支持的塊劃分來做個簡單的例子。VVC的編碼單元（Coding Tree Unit，簡稱CTU）最大可以覆蓋到128x128亮度像素區域，同時除了支持四分樹，也支持二分樹和三分樹的塊劃分。如圖 7所示，由于VVC的塊劃分更加靈活，相比H.265/HEVC標準而言，VVC可以用更大的塊劃分來高效率的表達視頻內容中相對平緩的區域，而對于紋理細致邊緣信息豐富的區域，VVC可以通過二分樹和三分樹的方式做到更加細致的表達。另外，VVC還支持幾何劃分模式這種非矩形形狀的劃分方法，因此可以更加精準地描述物體的輪廓。
圖 7. VVC支持更加靈活的塊劃分
前面提到過，ITU-T VCEG和ISO/IEC MPEG 每次發布新一代的國際視頻標準，其最重要的任務就是在視頻質量相同的前提下，將壓縮性能翻倍，也就是帶寬（或存儲）成本減半。VVC標準也肩負著一樣的性能目標。
在標準開發過程中，JVET標準委員會需要進行大量的核心實驗，來收集編碼工具的壓縮性能和復雜度數據，并根據核心實驗的數據來決定是否采納一個新的編碼工具。為了可以快速收集到壓縮性能和復雜度的數據，標準開發的過程中一般采用大家公認并易于計算的客觀性能指標做為壓縮效率的衡量，比如PSNR就是一個經常被使用的客觀質量評估方法，可以用來衡量經過壓縮后的視頻相比原始視頻的失真度。
如表 1所示，在PSNR保持不變的前提下， VVC參考軟件VTM-9.0相比于HEVC來說，在不同分辨率的視頻平均可以節省碼率37.3％，而且分辨率越高，碼率節省越多，對4K超高清視頻來說，碼率節省可以達到40%以上 [5]。
表 1. VVC在不同分辨率的SDR視頻上的客觀性能增益（基于PSNR的質量評估）
但是對視頻質量評估而言，比PSNR這個客觀質量遠遠更加重要的是主觀質量。國際標準 ITU-R rec. BT500-14 對視頻主觀質量的評估制定了一套嚴謹的評估方法和步驟 [6]，通過讓視力正常的人群對視頻質量打分并進行嚴格的統計分析的方法來得到視頻主觀質量平均分（mean opinion score ,簡稱MOS）和MOS的可信度（confidence interval）。這樣所得到的MOS才是對視頻質量最權威的評估，也是每次在新一代標準定稿以后，正式對比新舊兩代標準的壓縮性能的時候必須使用的質量評估方法。2020年上半年VVC標準即將定稿之際，JVET委員會就已經開始著手籌備VVC的性能驗證測試（VVC verification testing）工作， 開啟基于視頻主觀質量的壓縮性能驗證工作 [7]。如圖 9所示，從目前收集到的初步主觀測試結果上看，在4K視頻內容上，在同樣的主觀質量前提下，VVC 可以達到50%-55%的碼率節省 [8]。VVC性能驗證測試的正式結果預期將在10月份發布。另外說明一下，為了有效地防止壓縮算法的過擬合問題，保證測試結果的公允性，正式的性能驗證測試所使用的視頻內容都是在標準開發過程中從來沒有使用過的視頻內容。
圖 9：兩個4K序列的初步主觀測試結果
前面提到VVC標準的全稱是Versatile Video Coding，所以第一個V代表著VVC“多才多藝“的一面。因為最近幾年視頻采集處理技術的迅猛發展，除了傳統的SDR視頻內容，HDR和360全景視頻等新興視頻內容開始走入消費者的生活。同時，由于遠程辦公的興起，在視頻會議場景中更多的時候需要對屏幕內容（如PPT，文檔，xls等）進行分享。相比起圖 7中攝像頭采集的自然視頻內容，圖 10所示的屏幕視頻內容富含文字，高頻信息豐富，需要不同的編碼工具。為了更好的支持屏幕內容編碼，VVC將HEVC的屏幕編碼擴展（HEVC screen content coding extension）中所支持的幾個屏幕編碼工具也納入了VVC main profile，為屏幕內容編碼提供更廣泛的硬件解碼支持。
圖 10：屏幕內容示例
對于高動態范圍HDR視頻，VVC同時考慮到了業內廣泛使用的HLG（hybrid log-gamma）和PQ （perceptual quantizer）兩種主要變換函數（transfer function）。對于HDR視頻，VTM參考編碼器中支持塊級QP調整的算法來適應HDR視頻更大的亮度動態范圍和更寬的色彩空間，提升HDR視頻（尤其是基于PQ的HDR視頻）的壓縮性能。同時JVET委員會也通過一個叫做HDRTools的參考平臺對HDR視頻處理和質量評估等方面提供全面的技術支持。表 2顯示在PSNR保持不變的前提下，VVC相比于HEVC可以在HLG和PQ兩種HDR視頻上達到快40%的碼率節省 [9]。同時，VVC性能驗證測試中也包括HDR視頻格式，將通過正式主觀質量測試的方法來確認VVC相對于HEVC在HDR視頻上的性能增益，正式測試結果預期將在2020年內發布 [7]。
表 2. VVC在HLG和PQ兩種HDR視頻上的客觀性能增益（基于PSNR的質量評估）
對于360全景視頻來說，在VVC尚未正式開始的JEM時代，JVET委員會就采納了360Lib參考平臺，并將360Lib與HM，JEM和后來的VTM相結合形成一套完整的參考平臺系統，并在這個平臺的基礎上，對360全景視頻的投影，壓縮和質量評估等關鍵技術問題進行了深入的研究。ITU-T和ISO/IEC聯合發布的VVC技術征求書中也包括了360全景視頻這一重要視頻類目。因此，VVC標準從一開始就充分考慮到AR和VR這些新興的視頻應用，在VVC標準開發過程中針對這些應用的需求進行了深度的算法優化。VVC標準支持一個叫做水平環繞運動補償（Horizontal wrap-around motion compensation）的編碼工具，可以顯著提高equi-rectangular projection（ERP）投影格式的主觀質量（ERP是目前業界使用最廣泛的全景視頻投影格式）[10]。
另外，VVC還支持一些比ERP更加先進的投影格式（比如generalized cubemap projection，簡稱GCMP）[11]。實驗證明將這些先進的投影格式與核心VVC編碼器結合后，可以進一步提高全景視頻的壓縮性能。同時，VVC編碼器還可以針對不同的投影格式進行采樣密度的分析，并相應調整塊級QP，這樣的策略也可以用來提高全景視頻的壓縮性能。由于全景視頻相機的可視角度（field of view）遠遠高于傳統相機，因此在對全景視頻進行數字化采樣是，必須使用超高清及以上的分辨率才能保證全景視頻的質量。4K超高清對全景視頻只是最低要求，業界更多的是使用6K和8K這樣的超高清分辨率來表達全景視頻。這樣高的視頻分辨率對全景視頻采集，處理，及壓縮這些環節的算力都提出了很大的挑戰。因此，VVC標準中提供了更多的并行化處理工具（如子圖像，矩形slice等）來更好的支持AR和VR這樣的新興視頻應用。
一般相機是在二維平面上對視頻信號進行采集，而全景視頻相機是基于球面對視頻信號進行采集，然后將在球面上采集到的視頻信號投影到平面上。因為這個特性，在客觀視頻質量評估的時候，一般意義上的PSNR并不適合直接套用在全景視頻上。針對這個技術問題，JVET委員會設計了WS-PSNR （weighted spherical PSNR）這個改進后的PSNR指標對全景視頻進行客觀質量的評估 [11]。表 3中顯示了VVC在同樣的WS-PSNR指標之下，相比HEVC可以做到33%的碼率降低 [12]。當然，與SDR視頻和HDR視頻一樣，VVC在全景視頻上的性能增益也一樣需要通過主觀質量測試的方法來進行正式的評估 [7]。前面所提到的VVC性能驗證測試工作中也包括360全景視頻這個類目，目前正在推進中，正式主觀測試結果預期將在2020年內發布。
表 3. VVC在360全景視頻上的客觀性能增益（基于WS-PSNR的質量評估）
在經歷了JEM上的三年標準前期技術積累，兩年多的標準化，三個重要里程碑，幾千篇技術提案，100多個會議工作日，數十個核心實驗和專題討論組一輪又一輪的激烈討論之后，VVC終于成功誕生！這是視頻編碼標準史中的一個里程碑，標志著視頻編碼技術邁上了一個新的臺階，將推動整個視頻行業又一次產業革新。VVC的成功制定離開不全球幾百位視頻編碼專家的辛勤汗水和付出！
VVC是包括阿里巴巴在內的多個中國互聯網公司第一次入場參與制定的國際視頻標準。在制定過程中，達摩院XG實驗室的視頻標準團隊對VVC中的多個編碼工具做出了重要的技術貢獻，其中包括亮度映射與色度縮放（luma mapping with chroma scaling，簡稱LMCS），幾何劃分，調色板模式，變換跳過模式的殘差編碼，參考幀重采樣等多個編碼技術。同時，我們這個標準團隊的成員也擔任過核心實驗和專題討論組的主席，做過代理主席主持過JVET大會，JVET分會和一些技術小組的會議討論。在VVC性能驗證評測這個重要工作中，團隊成員是全景視頻類目測試的負責人，主導測試環境的定義并幫助生成多個測試碼流。我們為VVC標準所做的這些貢獻，既是XG實驗室視頻團隊的榮幸，也是阿里巴巴作為一家中國互聯網公司應有的技術擔當和社會使命。
目前，XG實驗室視頻技術團隊已啟動VVC標準的軟件編解碼器項目研發，未來將用于提升直播、短視頻等新業態的視頻質量和用戶體驗。
[1]. Versatile Video Coding (Draft 10), http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=10399
[2]. Joint Call for Proposals on Video Compression with Capability beyond HEVC, http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=3361
[3]. Report of results from the Call for Proposals on Video Compression with Capability beyond HEVC, http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=3540
[4]. Versatile Video Coding (Draft 1), http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=3538
[5]. JVET AHG report: Test model software development (AHG3), http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=10370
[6]. Methodologies for the subjective assessment of the quality of television images, https://www.itu.int/rec/recommendation.asp?lang=en&parent=R-REC-BT.500-14-201910-I
[7]. VVC verification test plan (Draft 3), http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=10416
[8]. Results of dry run subjective assessment of SDR UHD verification test, http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=10385
[9]. JVET AHG report: Coding of HDR/WCG material (AHG7), http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=10374
[10]. Algorithm description for Versatile Video Coding and Test Model 9 (VTM 9), http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=10156
[11]. Algorithm descriptions of projection format conversion and video quality metrics in 360Lib (Version 10), http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=9677
[12]. JVET AHG report: 360° video coding tools, software and test conditions (AHG6), http://phenix.it-sudparis.eu/jvet/doc_end_user/current_document.php?id=9366
作者介紹：
葉琰，阿里巴巴達摩院XG實驗室視頻標準團隊負責人，代表阿里巴巴參與VVC標準制定，曾任代理主席主持過JVET大會，并多次擔任VVC制定過程中的核心實驗和專題討論組主席。
在2016年4月份的QCon上，阿里巴巴資深總監，淘寶移動平臺及新業務事業部、阿里百川負責人莊卓然（花名南天）宣布阿里移動端跨平臺開發框架Weex開始內測，并將于6月份開源。在QCon的第二天，阿里技術專家徐凱（花名鬼道）和阿里前端開發專家趙錦江（花名勾股）向參會者做了《Weex——靈活的移動端高性能動態化方案》的演講，對這一技術方案進行了詳細的剖析。
以下為演講內容的整理：
昨天南天宣布Weex啟動開源內測，截至到今天中午，我們統計申請內測用戶突破1400人，大家的熱烈程度遠遠超過我們的設想，非常感謝大家支持。
在我們對移動開發最佳實踐的思考中，我們認為移動開發的未來是更平衡的方案，一定是性能和動態性兼得。第二個，它一定是開放互聯的，PC端一直也是這樣的，也是非常好的狀態。我們覺得移動互聯網將來肯定也是基于更大眾化的技術體系，沒有平臺之間的隔閡，簡單直接易用，這是我們最希望看到的。基于這些設想，我們有了Weex方案。
Weex是從去年雙十一的時候第一次在我們正式產品中使用，承載了雙十一主會場的工作。有人會問，Weex是不是除了做主會場別的地方就比較吃力呢？從去年雙十一到現在，包括我們自己的嘗試和阿里內網做開源內測活動，大家也貢獻了很多內容，包括昨天Keynote演示的僵尸動畫，掃雷、計算器都有，各種豐富場景的東西都可以通過Weex做出來，不僅僅是做主會場的技術方案。
對移動端開發模型的理解
我們談談Weex團隊對移動端開發模型的理解。
今天絕大多數移動端APP是這樣一個最佳實踐，首先把移動端所有界面拆分成各個page，中間有一個路由的控制邏輯。同時我們需要移動端各種各樣豐富的能力，通過API的形式提供給開發者。這是我們認為一個比較理想的開發模型。
從開發模型來講，我們比較傾向于通過標準化的一些東西，包括HTML、CSS、JS這些前端非常快速易用好學的語法作為一個開發體驗，提供給開發者。這里強調一下，我們語法設計尊重了Web標準，包括核心源代碼都是從Vue.js——一個非常優秀的MVVM前端框架來的。我們的開源內測同步在海外通過Vue.js的Twitter等途徑進行宣傳，得到了非常熱烈的反響，短短一天時間內，老外們的關注度和熱情也是出乎我們的意料。有些人非常興奮和激動，想知道什么時候看到源代碼，和我們聯系，我們覺得也是值得高興的一件事情。
Weex的組件化與DSL語法
Weex編寫的頁面天然的支持組件化，首先，我們的界面可以是一個組件化的，把一個復雜界面分成每個組件，剛才演示的都是簡單的組件，每個組件都可以看成是一段template，style，script，放到模型里，對應到界面的結構，樣式細節，行為定義。在view里面我們傾向于把數據和視圖當中需要展示和需要有動態變化的部分做一個數據綁定，綁定之后我如果想更改界面的話，通過改變數據就可以做到。這是從model到view非常順暢的控制邏輯和代碼方式，這也算是Weex上層語法設計的基礎。如果大家做的界面比較復雜，可能有更多細節，或者做更多分解，我們需要從整體上對整個界面以模塊為單位作為拆解，對每個模塊做定義，如果界面足夠復雜，可以先拆成組件，再把每個組件具體內容進行定義。定義方式就是通過結構、樣式和行為角度對它進行定義，通過有機方式把這些組件結合起來，完成頁面開發。
關鍵語法簡述。首先看看template，大概有幾個元素。它首先是virtual DOM tree展示，包括事件綁定，組件跟組件之間還可以嵌套，還可以有子元素，這是整體template結構。再往下是style，一方面可以把共用樣式抽樣出來，另一方面可以讓template結構更加清晰，不至于陷入到整個具體樣式描述當中去。我們在這邊會做一些收斂，我們只支持了單個class的selector寫法，主要從性能角度考慮。傳統的css可以理解為是一個N對N的數據庫，匹配過程非常復雜，性能也得不到非常好的保證，我們為了保證性能，我們把selector約定在單個class，性能可以保證。
另外，我們的樣式天然默認的就是scoped，大家可以放心定義各種各樣的classname，不擔心和其他組件相沖突，全局沖突是CSS“七宗罪”中的一個，其實這也是我們非常重視的，所以在實踐上我們把它做到了scoped。
其他的，可以做一些展示的控制，比如if、repeat剛才演示中也提到了。剛才沒有演示到的這個很特殊，append，在性能不是那么好的Android下，界面加載過程用戶是可感知的，不是一瞬間做到的。我們加這個值可以讓你精細化展示界面的顆粒度，如果上層做了append等于tree的話，里面一系列東西會做一次性的加載，這是從性能優化角度做的特殊設計。再是id，我們可以通過在這里面寫id拿到這個值，把它當作參數傳給API做處理。
我們現在已經支持的組件，除了剛才演示的div空白容器、圖片、文本之外，我們還支持slider：一個性能比較好的滑塊組件，還有list，性能上自動做內存管理和資源管理的組件，把性能和幀率各方面都做的比較好。還有input，輸入框我們是最近才做的，也是剛支持的，可能還有試驗性階段的小東西。在這個范圍之外，業務方可在上層橫向擴展，稍后會有具體介紹。這是template和style部分的介紹。
樣式部分我們支持flexbox，非常靈活通用便捷的布局方式，有了flexbox，只要你的界面可以拆分成豆腐塊的，都可以用flexbox來做，同時我們還做了fixed和sticky這兩個特殊的布局，sticky意思是如果有一個列表分類，比如聯系人ABC字母滾到屏幕外，會停在最上面，那個效果就是sticky，當你劃走它就會跟著走，在各種手機應用當中是一個比較常見的東西。同樣，更多的樣式每個組件也可以自己定制，非常靈活。
從事件角度，click是基礎事件，change在表單的值改變和滑快的第幾幀改變時都會有，同時我們加入了appear和disappear，當我通過任意操作進入屏幕區域內，會觸發appear事件，出來以后會觸發disappear事件，非常適合用在一些lazyload之類的邏輯場景。這些事件也可以在各自組件中做橫向擴展。
Script部分剛才例子也提到了，主要是viewmodel設計，最主要的是data和methods，值修改之后相應數據綁定的值也會發生改變。除此之外我們提供了生命周期的方法，創建的時候，數據監聽完成的時候，渲染完成的時候，你只要把這三個方法同樣寫在data和methods下面。還有原生 API，剛才演示的時候也出現了，這里不多介紹。
組件化搭建很復雜，通過定義子組件，比如我上面有一個foo組件，通過foo標簽就可以把foo嵌入到別的組件中來，數據傳遞的話就可以在foo組件中寫a和b，foo元素就可以通過這種方式傳遞給子元素，然后進行處理。再是組件中間的通信，也是事件機制，每個組件可以通過和off，對自定義事件進行監聽和解綁定，想觸發事件也有三個方法：只傳給自己、dispatch向上冒泡給所有父組件、$broadcast廣播給所有子組件，這些設計和Vue非常相近的，做到組件之間的通信。
除了剛才介紹的這些特性，我們未來還會提供更豐富的、相信也是開發者需要的、平時開發中會碰到的場景，更豐富的表單，還有更好的動畫展示，包括復雜手勢場景。在這方面，無論是性能還是開發體驗、最終效果都能夠非常好，這是團隊正在努力在未來提供給大家的。同時我們希望收集和分享更多相關素材，做出更多工具，提供更好的開發者體驗給大家。
更多的內容，包括剛才演示的Playground App都可以通過我們的官網找到，現在處在開源內測階段，大家提交申請，通過以后可以訪問倉庫，了解更具體的內容。
Weex的工作原理
這張圖大家都不陌生，前面也提到了，勾股說的主要是DSL這層。再往下到了Virtual DOM和Render層；H5，我刻意把它用不一樣的顏色標出來，想讓大家知道我們設計之初就考慮到希望在三端上能夠展現，所以這個地方稍微加亮一些。
我們把剛才這張圖再稍微展開一下，最上面是我們的DSL，我們一般叫Weex文件，通過transformer這層，部署到Server，服務端就完成了。大家不用擔心我們的轉換是不是有性能問題，因為這在服務端就已經完成。到了客戶端，第一層是我們的JS-Framework，最后到RenderRengine，再往下看，左邊是我們的DSL文件，右邊是轉換出來的jsbundle，在DSL中的template會將我們的類型和子節點都表示出來，將classList轉化成基本語法約定，包括自變量的轉換。最后是腳本，腳本基本上是直譯過來。輸入是Virtual DOM輸出是native或者H5 view，還原成內存中的樹型數據結構，再創建view，把事件綁定在view上，把view基本屬性設上去。虛線是在native上經歷一個過程，在H5上相當于把這個事情交給webkit LayoutEngine去做，把所有元素尺寸和位置重新調整。整個這張圖基本上講清楚了Weex Render流程，我們會分三個線程，不同的線程負責不同的事情，讓JS線程優先保障我們的流暢性，未來我們會有更多的技術文檔，比較細節的放出來。
Weex的性能、擴展以及可用性
下面是在整個Weex架構上比較關鍵的點，這些可能是我們目前關注度最高的，包括性能、擴展以及可用性。
首先是性能，我們內部有這樣一個壓測頁面，我們同學把benchmark放在Playground，大家如果下載是能夠看到的。在我們內部做壓測的時候調到三千個節點，大概10屏，一屏有三個卡片，一個卡片有100個節點左右。我們看一下數據，第一個性能對比是我們的加載時間，同樣一個頁面1300、1600，也不算特別大，20%左右，幀率大概差開一幀，scroller差不多，內存這塊會好一點，因為我們這邊用了recycle view，會好一些。再往下是CPU，靜默CPU消耗，還有運行過程中CPU的峰值。靜默CPU接近0點幾，我們不做16毫秒的輪循，如果做16毫秒輪循CPU會更高一些。
這是一個真實業務數據，3月份頁面上線之后我們看了一下，這張頁面是一個活動，3月份新風尚的活動，這個活動頁面沒有用List，沒有特別做內存對比，這兩個設備定義為低端機，幀率差壓比較明顯，無論是數據還是實際中的體驗，流暢性大概是這樣的差距。我們說性能往往都會提到幀率、加載時間，但往往會忽略一個事情，Native UI開發中通常沒有JS資源在服務端加載，Weex以及類似動態化方案有一個副作用，我們有一個JS必須從服務端下載，我們把JS內置到客戶端里，免除下載的問題，這里涉及到一整套的策略。我們內部有一套機制，之后會把這套機制作為獨立的技術產品開放出來。
下一個是我們的兼容性。兼容性不只是對Weex，對偏內核型項目都會有這個問題，舉一個Weex例子，第一排是我們的業務代碼，再往下看，上面兩次變遷，一直到客戶端，整個場景會變成N的立方。舉一個具體數字，我的業務代碼改了三個版本，（英文）三個版本，最后會有三的立方27個場景。兼容性是我們一直重視的問題。我們做了幾件事情，首先單測保證，包括JS和H5的單測，保證最最基礎的UT本身帶來的含義。第二個是JS單測環境，我們一般會將（英文）跑在（英文環境下，但和JS安全還是有差異。再往下是自動化工作，這塊工作細分也可以分成兩塊：一塊是我們針對截圖比對，比如我們同學會說我們設置了很多各種各樣細節屬性，怎么說你渲染出來的就是你實際想要的，通過API級別的效果不是很好。所以這種我們會通過截圖，將最終產生的結果和我們意料中的結果進行圖形比對，比較老的成熟的內核上面做的比較成熟，也會有一些借鑒。另外是layout results，相當一部分，包括model，包括其他的布局類的，其實我們完全可以通過一個元素，最終它的寬高，左上角的點，通過基本的信息，讓它完成測試的過程。所以我們經過這兩塊工作，一旦成熟，我們會盡快放到上面。
再就是擴展性，我們先回顧一下這張圖，前面也有提到，目前Weex給大家直觀的感覺是可以用Weex寫很多頁面，有一個路由機制，內部叫導航，幫助你將頁面進行串連，我們提供很多features，由這樣的形式構成Weex大家所看到的一個結構。細分來看，如果你擴展一個component，特定的一些方法，使用anotation標識輸入輸出參數。這是一個module，在DSL上看到的是API，底層就是module。如果擴展module也是一樣的，這是很簡單的跳轉，基本信息帶上去，實現業務功能，一個module就完成了，很簡單。
這是路由，整個路由在APP Framework中只是一個環節，所以接下來的規劃還是有許多東西需要做的，單獨看components這塊，包括前面兩個，再往下是lifecycle考慮，再是動畫跟手勢，這塊我們覺得都是最基礎的東西。再往下是全局的多個Weex容器之間通信機制，數據存儲、網絡，包括下面涉及到的一堆傳感器，包括基礎的FS，還有偏業務類的東西，整個東西都有同步在做，但現在的工作集中是在這塊。回到剛才的老問題，如果我們開放一個module，上層提供API，中間提供adapter，如果提供自由實現就將默認的覆蓋掉，比如手淘里面（TBxxx），把默認頁面覆蓋掉（WXxxx），對大家來說在已有能力增強，或者是增加新的組件，或者是新的module上，目前已經達到這個狀態。
最后是我們的可用性，前面說的比較多，這塊秀幾張圖就好了。這是我們的工具鏈，紅色代表完成的，黃色是五月份、六月份就會完成，在六月正式開源之前。剩下一些東西是我們內部正在討論以及會安排時間逐步完成的東西，這些都是工具。我們首先給大家提供一個playground，可以掃碼，也有自帶的examples。第二個是調試工具，chrome dev tools常見的功能里面都有。再是腳手架，大家如果只是玩玩的話用playground就可以了，如果自己做一個獨立的APP，你要用Weex做的話我們也會給你提供腳手架。我們的規劃中獨立項目，不是最終的名字，最終會有一個類似APPHub的工具。包括信息察看，在界面上展示結構。這是剛才提到的例子，這個是playground里面的，雖然截圖是iphone效果和android是完全一樣的，已經用Weex現有功能做出比較好玩的組件庫。然后是我們的文檔，包括項目guide、reference、toolchain，細節我不多說了，大家可以去看看。
Weex的集成方式
目前Weex有三種集成方式：
全頁模式
o 目前支持單頁使用或整個app使用weex開發（還不完善，需要開發router和生命周期管理）這是主推的模式，可以類比RN。
Native Component模式
o 把weex當作一個iOS/Android組件來使用，類比ImageView。這類需求遍布手淘主鏈路，如首頁、主搜結果、交易組件化等，和業務同學溝通下來這類Native頁面主體已經很穩定，但是局部動態化需求旺盛導致頻繁發版，解決這類問題也是Weex的重點。
o 這也涉及到如何讓Native同學快速上手“準Web”開發，有意思的話題，大家多給些建議。
H5 Component模式
o 在H5種使用Weex，類比WVC。一些較復雜或特殊的H5頁面短期內無法完全轉為Weex全頁模式（或RN），比如貓超、互動類頁面、一些復雜頻道頁等。針對這個痛點我發起過WVC項目，并在實際業務中驗證了這樣的想法：在現有的H5頁面上做微調，引入Native解決長列表內存暴增、滾動不流暢、動畫/手勢體驗差等問題。
o WVC將會融入到Weex中，成為Weex的H5 Components模式。
這3種模式幾乎涵蓋了淘系業務上的動態化需求（針對Native）或體驗提升需求（針對H5）。更有趣的是這3種模式的技術基礎是一致的，這非常重要，意味著：業務方可以使用Native或H5 Component模式 解決實際的業務痛點，同時平滑過渡到Weex全頁模式。期待Weex成長壯大到AppFramework的那天。
最后是我們過去雙十一到現在大概五個多月時間做的一些事情。首先我們做了原型版本，再將原型版本獨立出獨立客戶端可使用的SDK，擴展樣式和布局，將基礎的component做了擴展，這兩個月集中在工具，還有open source上的工作，最后是六月底就會開放出來。
阿里百川（baichuan.taobao.com)是阿里巴巴集團“云”+“端”的核心戰略是阿里巴巴集團無線開放平臺，基于世界級的后端服務和成熟的商業組件，通過“技術、商業及大數據”的開放，為移動創業者提供可快速搭建App、商業化APP并提升用戶體驗的解決方案；同時提供多元化的創業服務-物理空間、孵化運營、創業投資等，為移動創業者提供全面保障。