Web技術老矣，尚能Run否？| U4核心在Web開發平臺的探索之路

摘要： Web技術是不是太老了，沒有生命力了？成了又卡又慢、體驗又不好的代名詞？客觀來講，前些年還真的是這麼回事。但是經過最近幾年的Web引擎技術的突飛猛進的發展，在Web引擎技術方面已經發生了非常大的變化，如今的Web引擎技術已經走出了黑暗，迎來了新的黎明，用一個詞來形容，那就是老當益壯。本文根據2...

Web技術是不是太老了，沒有生命力了？成了又卡又慢、體驗又不好的代名詞？客觀來講，前些年還真的是這麼回事。但是經過最近幾年的Web引擎技術的突飛猛進的發展，在Web引擎技術方面已經發生了非常大的變化，如今的Web引擎技術已經走出了黑暗，迎來了新的黎明，用一個詞來形容，那就是老當益壯。本文根據2018年杭州雲棲大會現場，UC資深技術專家鷹一的演講《服務Web開發者：U4核心開發平臺化探索》整理成文。

今天主要跟大家聊一聊面向開發者，U4核心在Web開發平臺化上的一些探索。具體分為四部分：第一，U4核心在阿里技術生態裡的定位；第二，過去一年U4核心在服務阿里技術平臺的進展；第三，U4 3.0的規劃思考以及在開發者基礎設施建設方面的進展；第四，在Web技術及社群這一塊，現在正在發生以及未來重點規劃的一些事情。

一、U4核心在阿里技術生態的定位

U4核心是一個基於開放Web技術的高效能渲染引擎，目前服務於整個阿里集團幾乎所有的APP，在集團外部也有不少重量級合作伙伴。作為渲染引擎，U4核心是阿里技術生態的重要組成部分。簡單來講，我們是服務於阿里技術平臺的。

一直以來，大家在移動端上可能還是有著不小的質疑，是不是Web已經死了？大家的體感是什麼？Web技術是不是太老了，已經沒有生命力了？又卡又慢、體驗又不好的代名詞？其實客觀來講，前些年還真的是這麼回事。但是經過最近幾年的Web引擎技術的突飛猛進的發展，在Web引擎技術方面已經發生了非常大的變化，在此我比較有信心地講Web引擎技術已經走出了黑暗，迎來了新的黎明，用一個詞來形容，那就是老當益壯。

移動端的開發，近些年經過百家爭鳴以後，現在慢慢走向小程式或者是快應用，這一型別的開發逐漸成為主流。從幾個主要平臺來看，其實Web都佔有一定的比較重要的地位，那從技術實現角度來講，背後的根源到底是什麼？

很顯然Web技術肯定有著它自己獨特的優勢。首先，作為一個開放的標準技術，它有著眾多的開發者。得開發者得天下，這是一個永恆的真理。開放Web技術天然地在跨端跨平臺投放上有著巨大優勢，在研發效率、研發成本上的優勢比較明顯，各種配套設施也比較完善。其次，利用開放的標準的Web技術開發的應用，在分享、轉發、傳播方面也有著巨大優勢。比如某多多風捲殘雲式營銷就是一個非常經典的案例。現在是內容為王的時代，無論是圖文，還是視訊、音樂、遊戲甚至是微商，它都有著很強烈的轉發、分享、傳播的訴求，Web技術是一個非常好的技術載體。更重要的是現在Web技術經過近幾年的發展，在效能、體驗上已經具備了非常大的競爭力。

我們先從技術的角度來看Web有哪些主要的效能問題。我簡單做了下分類，主要有六類問題（如上圖）。其實針對這六類問題，Web引擎最近幾年解決得還是相當不錯的，而且解決的思路也很簡單。 第一，提升計算的吞吐量。 就是儘可能充分發揮多核CPU以及GPU等硬體能力，比如多執行緒、GPU光柵化，neon優化等； 第二，減少重複計算量。 舉例就是各個層次的快取機制以及區域性重新整理能力，這都是解決計算量重複的問題； 第三，提前計算 ，像預載入、預渲染、預連線以及預解碼等相關的技術。

我們再看一下Web的引擎架構。這個圖是我高度簡化過的，這是一個示意圖。從執行緒模型設計方面其實是相當不錯的。我們也知道在APP的體驗上，影響使用者體驗一個非常重要的執行緒就是UI執行緒。在Web引擎上，UI執行緒做得非常薄，這就是為什麼在慣性滾動方面通常來講Web的體驗是更有優勢的原因之一。為了更進一步增強慣性滾動的效能，還獨立出來了個執行緒，叫合成執行緒，這更進一步增強了慣性滾動的效能。對於Web引擎的主執行緒，它的計算量非常大，為了解決這個問題，對於繪製等計算量非常大的操作，專門獨立出了光柵化執行緒，而且充分利用了GPU的能力。對於Web引擎的主執行緒，它在機制上嚴格保證了不會有任何的IO操作。相應的就衍生出了像IO執行緒、DB執行緒，File執行緒等。對於JS執行，有一些是執行邏輯比較複雜的場景，就又有了像後臺的Worker執行緒的機制。對於超大圖片解碼比較久場景，又從機制上提供後臺執行緒解碼能力。

所以說從整個架構上來講，Web引擎的架構相對來講雖然較為複雜，但是又是比較科學合理和具有一定的先進性的。

二、U4核心賦能阿里生態的最新進展

不會是老王賣瓜吧？當然不是，有視訊有真相。

我這裡對比的是從手淘的真實業務場景裡面摘出來的案例，這個視訊本身是連續錄製的，我為了對比方便拆成了兩段。這都是真實的案例，一個是Web，一個是native。為了讓它有對比性，我們專門選用了低端機，因為在高階機場景其實看不出多大的差別。從效果上來看，Web的體驗還是非常不錯的。其實優化思路也很簡單，一定要做到首屏和非首屏資料和邏輯的分離，這是最核心的地方。鑑於Web效能提升已經非常明顯了，我們可以開啟手淘看一下，其實手淘裡面好幾個頻道里面有native、Weex、H5，如果是中高階機基本上看不出來它們到底是哪一種技術實現的。天施老大也提到雙11會場問題，現在不少會場也切換到H5，為什麼？主要有兩點：第一，H5效能，最近幾年確實提上來了，另外很多會場的流量，除了端內以外，我們在端外也有很大流量，端外的流量目前還只能用H5投放。所以基於這兩點原因，還是有不少會場轉向H5。這個效果，主要是業務的開發者以及像天施老大下面牛叉的容器團隊通力合作的結果，核心在其中只是起到輔助作用。這也從一個角度可以說明針對於Web應用的效能體驗，開發者的掌控力還是比較大的。

針對特殊的場景，比如說只有native才能搞定的場景，我們有沒有方案？這個是有的。 U4核心提供了一個native view混合渲染模型。什麼意思？我們可以把native view非常自然的嵌入到Web View裡面去，而且保持開發者所指定的層次關係。這個案例是以地圖場景做的Demo，地圖是一個native view，上下都是H5的內容。從使用者視覺的角度，做到了無法區分哪些是native、哪些是Web的內容。

現在小遊戲的開發也是非常的火熱，Web技術在小遊戲這塊的表現又如何？剛才二同老師也提到了DOM和CSS對Web小遊戲的效能有影響，確實是這樣。除了對效能有影響以外，影響最大的其實是功耗。根本原因就是Web渲染流水線比較長。為了解決這個問題，UC核心提出並實現了遊戲模式。遊戲模式的原理是什麼？我們通過簡化、優化渲染流水線，提升它的效能並降低能耗。

這是我們和友商小遊戲方案做的對比，友商小遊戲做的是native方案。結果還是挺意外的，因為除了一款機器我們基本和它持平，絕大部分都比他們好，而且有些機器上好的還比較多。為了驗證結果的準確性，我們專門找了接近20臺機器連續測了三輪，結果都是一致的。針對這樣的結果我們有以下的解讀：第一個解讀，我們的測試覆蓋畢竟有限，只能反映這些機型的結果；第二個解讀， Web引擎對於WebGL，起步比較早做的還是比較完善的，在機型以及驅動的相容性方面做得比較好；第三個解讀，友商小遊戲的方案可能也不完善，還有比較大的提升空間，所以結果只是作為參考。

這是經典的WebGLAqua魚的案例。我們沒有放五百條魚或一千條魚對比，因為基本都能達到滿幀，對比差異不大。我們放了兩千條魚，遊戲模式的幀率最高。

我再給大家看下已經上線的兩個真實的小遊戲的效果，從效果來講其實是比較流暢的。還有就是開發者為了降低功耗，還專門做了降幀處理，所以從另外一個角度說明Web技術在小遊戲場景的效能上其實不是什麼問題，因為他們都做了降幀，大部分場景下我們是可以做到滿幀。

總結一下Web小遊戲的優勢。第一，Web小遊戲對於開發者是比較友好的，它能很簡單地可以支援市面上絕大部分的遊戲開發平臺，像白鷺，cocos，unity等。另外一點，效能上有自己的特點，尤其是在iOS上有一定的效能優勢。為什麼這麼講？這裡會涉及到偏底層的技術問題，JIT和Web assembly對於JS效能的提升非常大，但是iOS在它提供的JSC的引擎裡面閹割了這兩個功能，這兩個功能只能在Web上才能使用。第三點，Web開發的小遊戲在分享傳播方面的優勢還是比較明顯的。

安全也是阿里經濟體非常看重的能力。為什麼？因為阿里的主場景畢竟主要是商品交易，和錢打交道。為了進一步提升安全等級，U4核心提出並實現了一套基於系統isolate的沙箱多程序隔離方案。當然這個技術聽起來可能比較拗口，我打個比方，就是普通的單程序的安全級別就類似於你家裡安裝有一個防盜門，對於友商的多程序方案，就類似於家裡買了一個保險櫃，把貴重物品放到家裡面的這個保險櫃裡面。但是我們提供的方案，相當於我們把自己的貴重物品放到一個大銀行的保險櫃裡面。安全能力的對比就一目瞭然了。

三、U4 3.0演進和開發者基建

接下來跟大家聊一下U4 3.0的規劃和思考。針對U4核心的發展我們有兩大堅持：第一個堅持，我們一定會堅持開放Web技術的路線不動搖。我們要持續服務好體量最大的Web技術棧的開發者群體；第二個堅持，我們一定要具備持續的演進能力。我們要能及時並且全面地應用到整個開源社群的最新成果。U4 3.0基於Chromium M69版本，除了在效能和體驗方面持續極致優化以外，我們主要解決兩個核心問題：第一，基於定製阿里Web標準，實現MVP小型化目標；第二，Web引擎在冷啟動的速度是比較慢的，我們也致力於解決冷啟動慢的問題。另外，我們在V8引擎領域，在國內也是比較領先的，每年BlinkOn我們都有一個和V8優化有關的演講主題，我們力爭以後持續下去。像手機淘寶的Weex，JS引擎也是U4提供支援的。

U4 3.0是一個非常重要的版本，帶來了很多有特色的能力，比如:

除了在引擎方面我們會進一步發力以外，為了更好的服務好開發者，我們在開發者基礎設施方面也做了不少探索，主要面向兩個場景，一個是H5，一個是小程式。在開發者工具上我們開發了挺有特色的能力，就是無線除錯。在使用者許可的前提下，我們可以遠端除錯使用者手機上的頁面。另外我們做了雲測工具，針對H5或者小程式的應用我們可以做非常全面的效能體驗檢測，可以發現實現的問題並提出針對性的改進修改建議。第三針對線上的Web應用痛點問題，像白屏，確實很難跟進，我們也推出了Web高可用的平臺，通過核心收集的非使用者隱私類的全面的日誌資訊，可以定位到白屏根本原因在哪裡，協助開發者快速跟進解決這方面的問題。

另外，為了更好的服務好前端開發者，我們也開放了針對性能和體驗方面全方面的API，便於開發者搭建自己的業務監控系統。這些API，除了涵蓋我們傳統意義上的首屏外，覆蓋了很多也比較全面的使用者體驗級的指標。

四、Web技術生態現在未來時

最後和大家聊一下Web技術生態現在發生或者後面正在重點佈局的一些事情。

我們和chromium 團隊交流比較多，有一個觀點：Web業務的效能體驗問題，除了需要Web引擎持續進行優化以外，其實很大程度上也是跟開發者有關係的。根據我個人以及團隊的經驗，我完全認同這一點。當然這兒的前端開發者不要朝我丟雞蛋啊，真的是這樣子的。

舉一個例子，基於我的技術背景，讓我不小心混進了阿里的前端晉升面試官以及交叉面試官領域，有一個挺有意思的案例，一個同學宣稱把一個業務的Web首屏效能從七八秒甚至十秒提升到四秒左右，他覺得很牛逼。但從我的角度看，兩到三秒的首屏也只能算是一個勉強及格的水平，我更想聽到的是如何把它的首屏效能從兩到三秒給我搞到一秒以內，做到秒開，這才是我更想聽到的。為了更好地服務開發者進行效能體驗的優化，chromium團隊提出了一個模型，就是RAIL，相信很多開發者聽說過這個模型。為了進一步從資料上量化這個模型，也做了很多使用者體驗級別的資料收集。此外，在API方面也做了很多的擴充套件，可以提供給前端開發者來作為自己業務效能體驗的指標。UC這一塊也做了一些擴充套件。另外在引擎演進方面，其實也有非常多的重量級的事情在推進，主要分為兩類：第一類是架構層面的，比如Slimming Paint，LayoutNG，Viz，Web Assembly等。還有另外一類是和開發者社群互相借鑑、互相吸收、互相促進的技術，像Web components，houdini，最近提出的Layered API，還有像ES6的module等，這些都是和開發者社群共同促進，然後把一些非常重要的能力固化到引擎內部來實現，提升它的效能。除了引擎層面上，整個開發者社群也是異常活躍、欣欣向榮的，比如框架層面元彥老師負責的rax 2.0，vue，react，谷歌的polymer，angular，AMP其實也算。另外在開發者工具方面持續發力，有大家所熟悉的DevTools、Lighthouse，Pagespeed、UC雲測工具等。除此以外，我覺得前端開發者是相當幸福的，無論是線上還是線下都可以找到海量的相關技術資料。當然為什麼會有這麼多的技術資料？其實也是和Web生態異常活躍有關。在這裡頭，Web技術領域事實上的領導者谷歌確實也起到了非常重要的作用。

回顧下今天的分享。Web作為一個開放標準的技術，擁有著最大的開發者群體，Web技術對開發者比較友好，在跨端跨平臺投放以及分享，轉發，傳播方面具有獨特的優勢，在整個效能體驗方面最近幾年其實也已經提上來了，具備了非常強的競爭力。從技術架構的角度來看雖然略顯複雜，但是是非常科學，合理有著其先進性的，而且這一塊還在持續演進中。另外，通過線上Web業務以及兩個小遊戲的真實案例來看，也能明確感受到Web在效能和體驗方面表現的其實還是相當不錯的，是能夠作出效能體驗卓越的Web應用的。另外從整個技術社群來看，也並沒有Web已死的苗頭，相反還是一直處於非常活躍的狀態，持續演進而且近些年還在加速演進過程中，所以對Web的未來是非常可期的。

總結為一句話，Web技術是老當益壯、歷久彌堅，而且一定是未來更美好。

原文釋出時間為：2018-10-23

本文來自雲棲社群合作伙伴“ ofollow,noindex">淘寶技術 ”，瞭解相關資訊可以關注“ 淘寶技術 ”。