??導(dǎo)讀

Hippy 是騰訊開源的跨端框架，在騰訊內(nèi)部業(yè)務(wù)場景中有廣泛應(yīng)用。騰訊視頻搜索業(yè)務(wù)基于 Hippy 2.0 框架開發(fā)，在使用過程中發(fā)現(xiàn)了一些不便利的地方：動(dòng)畫渲染雙端不一致問題；對(duì)圖片和樣式的處理雙端不一致現(xiàn)象；沒有可用的橫滑組件/雙列流組件等等。Hippy 3.0 框架從底層實(shí)現(xiàn)邏輯進(jìn)行重新構(gòu)建，實(shí)現(xiàn)了 iOS 端和安卓端雙端統(tǒng)一化，標(biāo)準(zhǔn)化和流程的一致性。升級(jí) Hippy 3.0 框架后，開發(fā)雙端不兼容問題大大減少，開發(fā)效率提升，搜索首頁實(shí)現(xiàn)秒開。讀完全文還可以參加驚喜活動(dòng)抽獎(jiǎng)哦！

??目錄

1?前言

2?騰訊視頻搜索在 Hippy 2.0 框架上遇到的問題

3 Hippy 3.0 框架升級(jí)過程

4?新特性支持與一致性優(yōu)化

5?Hippy 3.0 應(yīng)用開發(fā)腳手架

6 對(duì) Hippy 3.0 后續(xù)版本的期待

7 總結(jié)

01

前言

Native 原生的應(yīng)用開發(fā)雖然體驗(yàn)好，性能高，但是安卓端和 iOS 端各自需要開發(fā)和維護(hù)一套代碼帶來了高昂的成本。于是，App 跨端解決方案應(yīng)運(yùn)而生。Hippy 是騰訊?TDF （Tencent Device-oriented Framework）Oteam?下的重要產(chǎn)品，為業(yè)務(wù)提供高性能、跨平臺(tái)、動(dòng)態(tài)化的跨端解決方案，有效幫助業(yè)務(wù)開發(fā)團(tuán)隊(duì)提高研效的同時(shí)也可以讓業(yè)務(wù)獲得接近 Native 的體驗(yàn)。

騰訊視頻搜索業(yè)務(wù)率先接入 Hippy 框架，目前一套代碼同時(shí)支持安卓客戶端、iOS 客戶端和 H5 Web 端，客戶端的體驗(yàn)非常接近 Native 體驗(yàn)，并且大大提高了開發(fā)效率，節(jié)約了人力成本。最近，我們騰訊視頻搜索業(yè)務(wù)成功從 Hippy 2.0 框架升級(jí)到 Hippy 3.0 框架，本文將如實(shí)還原整個(gè)升級(jí)過程，希望能夠給大家有所啟發(fā)。

02

騰訊視頻搜索在 Hippy 2.0 框架上遇到的問題

騰訊視頻搜索業(yè)務(wù)是基于 Hippy 2.0 框架進(jìn)行開發(fā)的。上線近1年以來，在使用上發(fā)現(xiàn)了一些影響開發(fā)效率的問題，總結(jié)主要有以下幾個(gè)方面：

1）在圖片的樣式處理上 iOS 端和安卓端存在許多不一致的地方，需要兼容處理。比如：圖片的圓角在 iOS 端不生效，安卓端生效；需要在圖片外多包一層 div，把樣式應(yīng)用在 div 上，這樣會(huì)增加頁面的層級(jí)數(shù)量；

2）字體的樣式也需要多包一層 div，把字體樣式應(yīng)用在外層的 div 上，這樣也會(huì)增加頁面的層級(jí)數(shù)量；

3）Hippy 2.0 框架上沒有可用的橫滑組件，需要用 Scroll List View 來做橫滑效果，但是，不幸的是，Scroll List View 會(huì)存在 OOM 的問題，需要前端對(duì)橫滑列表的渲染數(shù)量做兼容處理。重點(diǎn)提醒：讓盡量少的節(jié)點(diǎn)數(shù)量留在橫滑列表中，千萬不要把整個(gè)列表數(shù)據(jù)一股腦全部塞進(jìn)橫滑列表中來，否則會(huì)使頁面的內(nèi)存消耗激增；

4）在 Hippy 2.0 上做動(dòng)畫也是比較麻煩的一件事情，iOS 端和安卓端的表現(xiàn)不一致，比如縮放過渡效果等，需要做兼容處理，比較影響開發(fā)體驗(yàn)；

5）子節(jié)點(diǎn)沒辦法繼承父節(jié)點(diǎn)的樣式屬性，比如字體的 Size、Weight、Style 等，要么在每個(gè)子節(jié)點(diǎn)上再把屬性重新設(shè)置一遍，要么用很耗時(shí)的操作去取這些屬性：Vue.Native.getElemCss(this.$el);?這兩種方式都有缺點(diǎn)，第一種方法會(huì)導(dǎo)致節(jié)點(diǎn)的屬性過多；第二種方式 getElemCss() 是一個(gè)比較耗時(shí)的操作，會(huì)增加頁面的渲染耗時(shí)。

Hippy 3.0 框架在今年7月份已經(jīng)對(duì)外發(fā)布，通過跟 Hippy 框架團(tuán)隊(duì)進(jìn)行溝通，了解到很多 Hippy 3.0 的新特性，優(yōu)化升級(jí)能夠幫助解決 Hippy 2.0 框架使用上遇到的問題，于是我們立馬制定了 Hippy 3.0 的升級(jí)方案。

03

Hippy 3.0 框架升級(jí)過程

???3.1?前端工程升級(jí)與發(fā)布

Hippy 3.0 的升級(jí)對(duì)于前端業(yè)務(wù)邏輯來說是不需要做任何適配修改的，只需要升級(jí) Hippy 依賴包就可以。在發(fā)包方面，不同的團(tuán)隊(duì)，接入 Hippy 的時(shí)候，發(fā)包的方式不一樣，使用的離線包平臺(tái)也不一樣。騰訊視頻搜索團(tuán)隊(duì)接入的是 Shiply 離線包平臺(tái)。如果大家用了離線包，最好 Hippy 3.0 框架跟 Hippy 2.0 框架用不同的離線包包名，不要用同一個(gè)包名，否則后續(xù)的升級(jí)和維護(hù)會(huì)非常容易混亂。

???3.2?性能優(yōu)化

雖然 Hippy 3.0 框架渲染層基于 FlattenUI 已經(jīng)在渲染耗時(shí)方面有很明顯的優(yōu)化效果，但為了進(jìn)一步提升頁面打開的速度，我們和 Hippy SDK 小伙伴一起成立了優(yōu)化專項(xiàng)小組，針對(duì)搜索場景對(duì)頁面打開耗時(shí)做了更全面深入的分析。經(jīng)過大家一個(gè)多月的努力，挖掘并完成了多項(xiàng)優(yōu)化實(shí)踐，并取得了不錯(cuò)的優(yōu)化效果。下面給大家分享一下對(duì)于耗時(shí)關(guān)鍵點(diǎn)的分析和一些優(yōu)化方法，希望對(duì)后續(xù)接入 Hippy 3.0 的小伙伴們也有所幫助。

1）Hippy 引擎預(yù)加載，并且在預(yù)加載的時(shí)候提前讀取首頁緩存數(shù)據(jù)。具體的流程如下圖所示。

從圖中可以看出，Hippy 引擎預(yù)加載，能夠節(jié)約 Hippy 引擎啟動(dòng)和加載離線包資源的時(shí)間。提前讀取首頁緩存數(shù)據(jù)，可以節(jié)省讀取緩存的耗時(shí)和解析數(shù)據(jù)的耗時(shí)。讀取緩存數(shù)據(jù)的前提是應(yīng)用頁面有緩存數(shù)據(jù)可讀。如果是一個(gè)頁面數(shù)據(jù)未知的頁面，例如搜索結(jié)果頁的數(shù)據(jù)是需要用戶先輸入搜索關(guān)鍵字才可以得到頁面數(shù)據(jù)，則不可以提前讀緩存數(shù)據(jù)。通過這一步，我們的耗時(shí)直接縮減了26%左右。

2）接入 JSI，通過 JSI 來調(diào)用 JSAPI，提升頁面性能

我們?cè)趯?duì)頁面性能進(jìn)行分析的時(shí)候，發(fā)現(xiàn)很多 JSAPI 調(diào)用比較耗時(shí)，特別是對(duì)頁面渲染有依賴的 JSAPI，如果它耗時(shí)比較久，會(huì)影響到頁面的渲染耗時(shí)。Hippy JSI（JavaScript Interface）模式提供了一種無需經(jīng)歷編解碼（序列化）過程的跨 VM 互相調(diào)用的解決方案，使得 JS 可以和 Native 客戶端直接通信，并且可以定義接口為串行的調(diào)用方式，屏蔽掉了接口異步讀取的不確定性，從而使耗時(shí)比較穩(wěn)定。我們?cè)诒镜貙?duì)同一個(gè) JSAPI 接口分別進(jìn)行正常的 JSBridge 調(diào)用和 JSI 調(diào)用，分別測試5次取平均數(shù)，對(duì)比數(shù)據(jù)發(fā)現(xiàn)，對(duì) JSAPI 通過 JSI 方式調(diào)用，比進(jìn)行正常的 JSBridge 調(diào)用，耗時(shí)能夠縮減90%左右，縮減幅度非常可觀。

3）SDK Hippy-Vue?優(yōu)化

在 Hippy 3.0 的重構(gòu)中，SDK 同學(xué)發(fā)現(xiàn) Hippy 在節(jié)點(diǎn) CSS 樣式計(jì)算耗時(shí)占用比較大，所以 Hippy 3.0?版本對(duì) CSS 算法和 CSS 計(jì)算頻次分別做了優(yōu)化。

(1) CSS 算法優(yōu)化

Hippy-Vue 項(xiàng)目的 CSS 解析算法，早期版本是使用 NativeScript-Vue 框架的 CSS 解析算法，是純 JS 實(shí)現(xiàn)的。那這個(gè) CSS 解析算法本是不是不太高效呢?？通過對(duì)比業(yè)界其它 JS 版本的 CSS-Parse 方案，發(fā)現(xiàn)整體性能差距不大，主要原因是這些算法是按照通用 W3C CSS 規(guī)范實(shí)現(xiàn)的，按照規(guī)范實(shí)現(xiàn)的算法各自的方案整體思路接近，因而性能差距不大。

不過，Hippy 作為一個(gè) App 動(dòng)態(tài)化框架，其實(shí)只實(shí)現(xiàn)了 CSS 的子集，業(yè)界其它框架如 React-Native、微信小程序等也僅實(shí)現(xiàn)了 CSS 的子集，并未實(shí)現(xiàn)屬性選擇器等高級(jí) CSS 能力(可能是性能的考量)。因此，我們可以考慮對(duì) CSS 的高級(jí)能力做一些舍棄，對(duì) Hippy 所定義的 CSS 子集部分重新實(shí)現(xiàn)，從而更好的優(yōu)化算法流程。

一個(gè)典型的例子是 Vue Scoped CSS，Scoped 在 Vue 的編譯期會(huì)轉(zhuǎn)換為屬性選擇器，而屬性選擇器因?yàn)橛袑傩詸?quán)重計(jì)算，解析的算法時(shí)間復(fù)雜度是比較高的。Scoped 的設(shè)計(jì)目的是為了隔離屬性，一種簡單的思路是參考 CSS-Module 方案，在編譯期找出被 Scoped 標(biāo)記的屬性，給屬性名加上后綴，這樣屬性在運(yùn)行期解析時(shí)會(huì)用 Class 選擇器的方式去處理，Class 選擇器解析邏輯是相對(duì)簡單的，從而降低算法的時(shí)間復(fù)雜度。

通過一系列 CSS 算法優(yōu)化后，iOS 整體耗時(shí)下降 18%，Android 整體耗時(shí)下降 10%?，做到在支持 Scoped 等特性的同時(shí)又有效解決了性能問題，同時(shí)，SDK 的同學(xué)也在探索 C++ 版本的 CSS-Parse 方案，從根本上提升解析性能。具體效果如下圖所示。

(2)?CSS?計(jì)算頻次優(yōu)化

除了上面提到的 CSS 算法耗時(shí)，還有比較多場景會(huì)產(chǎn)生冗余的 CSS 計(jì)算，而導(dǎo)致耗時(shí)增加。針對(duì)這個(gè)問題，SDK 內(nèi)部做了如下兩個(gè)優(yōu)化：

第一：CSS 緩存優(yōu)化。

對(duì)已經(jīng)計(jì)算過的 CSS 結(jié)果，做計(jì)算緩存；

對(duì)無須計(jì)算 CSS 的場景，直接跳過計(jì)算；

優(yōu)化效果：應(yīng)用 CSS 緩存優(yōu)化，搜索結(jié)果頁打開耗時(shí)減少了 30ms 左右。

第二：Event 調(diào)用鏈優(yōu)化。

在 Hippy 2.0 的事件模型中，事件是作為節(jié)點(diǎn)的一個(gè) boolean 屬性，通過設(shè)置 true/false 來標(biāo)記是否注冊(cè)事件，并把事件回調(diào)注冊(cè)在全局 map 中。?因而事件注冊(cè)和屬性更新流程是耦合的，每次注冊(cè)/銷毀事件，會(huì)同時(shí)觸發(fā)節(jié)點(diǎn)屬性更新?和 CSS 計(jì)算，造成性能損耗。

在 Hippy 3.0 中，重構(gòu)了事件模型，屬性是作為方法直接掛載在節(jié)點(diǎn)上，把屬性注冊(cè)流程和屬性更新流程分離，從而減少了因注冊(cè)/銷毀事件，而產(chǎn)生的冗余節(jié)點(diǎn)屬性更新和 CSS 計(jì)算帶來的性能開銷。

優(yōu)化效果：搜索結(jié)果頁能減少 300多次節(jié)點(diǎn)的屬性更新，頁面打開耗時(shí)減少30ms左右。

搜索場景接入 Hippy 3.0 框架后，配合系列性能優(yōu)化手段，11月份上線以來，首屏渲染耗時(shí)和結(jié)果頁的渲染耗時(shí)都呈現(xiàn)了下降趨勢，優(yōu)化效果很明顯，具體趨勢圖如下：

04

新特性支持與一致性優(yōu)化

1）Hippy 3.0 動(dòng)畫驅(qū)動(dòng)機(jī)制統(tǒng)一下沉到 C++ DOM 層來實(shí)現(xiàn)，很好的保證了雙端動(dòng)畫的一致性，有效解決了我們一直以來在 Hippy 2.0 由于雙端動(dòng)畫不一致需要做大量兼容處理的問題。

2）在 Hippy 3.0 上，雙端都可以有十分方便的橫滑組件可用，解決了我們?cè)?2.0 使用 Scroll List View 來做橫滑效果的痛點(diǎn)。

3）Hippy 3.0 在 SDK 層面實(shí)現(xiàn)圖片樣式支持的雙端統(tǒng)一，我們也不需要再為了實(shí)現(xiàn)圓角效果，單獨(dú)在圖片外多包一層 div，進(jìn)一步減少頁面節(jié)點(diǎn)層級(jí)與復(fù)雜度。

4）支持 Scoped CSS。在 Hippy 2.0 中，是不支持 Scoped CSS 的，需要自己編寫 Webpack Scoped CSS 插件來支持；在最新版本的 Hippy 3.0 中將會(huì)支持 Scoped CSS，不需要自己寫插件來兼容了。

5）支持子節(jié)點(diǎn)自動(dòng)繼承父節(jié)點(diǎn)樣式屬性。在 Hippy 2.0 中不支持子節(jié)點(diǎn)自動(dòng)繼承父節(jié)點(diǎn)樣式屬性，所以每個(gè)子節(jié)點(diǎn)都需要自己設(shè)置一遍，存在很多冗余屬性的設(shè)置，在 Hippy 3.0 上可以把通用的樣式屬性放到父節(jié)點(diǎn)上，子節(jié)點(diǎn)自動(dòng)繼承父節(jié)點(diǎn)樣式屬性，不用再進(jìn)行每個(gè)子節(jié)點(diǎn)的復(fù)雜樣式設(shè)值了。

05

Hippy 3.0 應(yīng)用開發(fā)腳手架

騰訊視頻前端搜索團(tuán)隊(duì)目前有很多應(yīng)用都是基于 Hippy 框架進(jìn)行構(gòu)建的，例如搜索首頁，搜索結(jié)果頁，篩選系統(tǒng)，榜單系統(tǒng)，找片系統(tǒng)，明星裝扮系統(tǒng)，家庭版 MVP 等。在對(duì)系統(tǒng)進(jìn)行構(gòu)建過程中，我們通過對(duì)系統(tǒng)的框架進(jìn)行提取，通用組件進(jìn)行提取，流水線進(jìn)行提取，構(gòu)建了基于 Hippy 3.0 框架的應(yīng)用開發(fā)腳手架：generator-athena。利用腳手架進(jìn)行 Hippy 框架應(yīng)用開發(fā)，能夠大大提高開發(fā)效率。

Generator-Athena 開發(fā)腳手架的組織結(jié)構(gòu)圖如下圖所示：

本腳手架集成了 Shiply 離線包平臺(tái)，以及離線包平臺(tái)的打包腳本；集成了藍(lán)盾流水線的相關(guān)配置；并且提供了11個(gè)通用組件，能夠讓大家快速開發(fā)大部分應(yīng)用頁面。

同時(shí)，我們?cè)陧撁嫖募刑峁┝藢?shí)例文件，規(guī)范了文件的命名規(guī)則和變量的命名規(guī)則，以達(dá)到 Web 端、小程序端和 App 端多端互相轉(zhuǎn)換的命名規(guī)范要求。

06

對(duì) Hippy 3.0 后續(xù)版本的期待

???6.1?Hermes 性能提升探索

之前一直有看到其他 Hippy 接入方如K歌團(tuán)隊(duì)，瀏覽器團(tuán)隊(duì)分享更換 Hermes 引擎后帶來不錯(cuò)的性能提升，但通過了解后發(fā)現(xiàn)，他們都是在自己獨(dú)立分支進(jìn)行改造接入，并沒有合入 Hippy 官方的代碼倉庫，也就是說他們的改造方案是無法無成本平移到其他接入方的。

針對(duì)這種情況，我們跟 Hippy SDK 的同學(xué)溝通后了解到，Hippy 3.0 對(duì) JS 引擎的封裝層 NAPI 也做了重構(gòu)，能夠支持不同 JS 引擎的接入和切換。而且 Hermes 引擎已經(jīng)完成了80%的適配工作，并在 SDK Demo 跑通了，也就是說未來 Hippy 官方將在 3.0 版本正式支持 Hermes 引擎的接入。

我們也嘗試提前在騰訊視頻搜索場景接入 Hermes 引擎來檢驗(yàn)效果。經(jīng)過和 Hippy SDK 同學(xué)一起努力配合，在解決了 Hermes 引擎加載業(yè)務(wù) Bundle JS 的一些適配問題后，終于在視頻 App 里面基于新引擎的搜索頁面能跑通了。切換 Hermes 引擎后的性能對(duì)比數(shù)據(jù)如下：

說明：測試的時(shí)候，為了避免網(wǎng)絡(luò)拉取數(shù)據(jù)的波動(dòng)影響，通過本地 hook 數(shù)據(jù)錄屏分幀的方式對(duì)搜索首頁和結(jié)果頁打開耗時(shí)分別進(jìn)行了對(duì)比測試。

從 iOS 的測試結(jié)果來看，不論是有預(yù)加載還是沒有預(yù)加載，使用了 HBC 的 Hermes 對(duì)比 JSC，在搜索首頁和搜索結(jié)果頁都有近40%的性能提升，和之前在瀏覽器那邊了解到的數(shù)據(jù)來看頁基本是相符的，iOS 端 Hermes 引擎能帶來較大的性能提升。

從 Android 的測試結(jié)果來看，在無預(yù)加載的情況下，使用了 HBC 的 Hermes 對(duì)比 V8，搜索首頁有 11% 的提升，搜索結(jié)果頁有 4% 的提升。在有預(yù)加載的情況下 Hermes 反而落后于 V8，所以這里就沒有再列舉數(shù)據(jù)了，整體來看 V8 的性能還是不錯(cuò)的，針對(duì) Android 一些處于內(nèi)存考慮無法做預(yù)加載的場景可以考慮使用 Hermes，如果有預(yù)加載的場景還是繼續(xù)使用 V8 可以獲得最好的性能表現(xiàn)。

???6.2?新增能力支持

從 SDK 同學(xué)那里我們也了解到 3.0 后續(xù)版本規(guī)劃的一些非常值得期待的新特性：

1)? Android 端瀑布流組件升級(jí)，支持滾動(dòng)列表更多的布局方式，提供更穩(wěn)定更流暢的體驗(yàn)；

2)? Performance API 與 Aegis-Hippy Sdk 升級(jí)支持更加完善的前端性能監(jiān)控與上報(bào)；

3)? Animation API 與 transformOrigin，對(duì)動(dòng)畫能力支持更加完善；

4)? Intersection Observer API，支持頁面任意節(jié)點(diǎn)做曝光監(jiān)控；

5)? font-face 支持下載遠(yuǎn)程自定義字體。

07

總結(jié)

騰訊視頻搜索業(yè)務(wù)是第一個(gè)吃 Hippy 3.0 框架這個(gè)“螃蟹”的業(yè)務(wù)團(tuán)隊(duì)，在整個(gè) 3.0 升級(jí)過程中，通過和 Hippy 框架團(tuán)隊(duì)的緊密配合，不但解決了之前很多 2.0 開發(fā)過程中遇到的痛點(diǎn)，也成功實(shí)現(xiàn)了我們下半年性能優(yōu)化的挑戰(zhàn)目標(biāo)，最終品嘗到了Hippy 3.0框架這個(gè)“螃蟹”的鮮美。

最后，也歡迎大家在升級(jí) Hippy 3.0 的過程中，隨時(shí)跟我們交流心得，探討問題！

-End-

原創(chuàng)作者｜熊才剛

??

新的一年，你對(duì)前端技術(shù)有什么樣的展望？歡迎評(píng)論分享。我們將選取1則優(yōu)質(zhì)的評(píng)論，送出騰訊云開發(fā)者社區(qū)定制鼠標(biāo)墊1個(gè)（見下圖）。1月23日中午12點(diǎn)開獎(jiǎng)。

分享抽龍年紅包封面?。∞D(zhuǎn)發(fā)本篇文章就能隨機(jī)獲得以下封面 1 個(gè)！限量50個(gè)，周四中午12點(diǎn)開獎(jiǎng)！

參與方式：

1、分享本篇文章到朋友圈，并截圖。

2、到騰訊云開發(fā)者公眾號(hào)后臺(tái)回復(fù)“0117”，經(jīng)核驗(yàn)截圖后，即可隨機(jī)抽取以下 1 款紅包封面！

????歡迎加入騰訊云開發(fā)者社群，社群專享券、大咖交流圈、第一手活動(dòng)通知、限量鵝廠周邊等你來~

（長按圖片立即掃碼）

文章來源地址http://www.zghlxwxcb.cn/news/detail-811663.html