前言

H5 在轉(zhuǎn)轉(zhuǎn) App 中有著較高的比重，承載了 B2C，C2B，C2C 多個(gè)業(yè)務(wù)的巨大流量，轉(zhuǎn)轉(zhuǎn)在前端技術(shù)這塊，考慮到業(yè)務(wù)架構(gòu)和人員結(jié)構(gòu)的情況，沒(méi)有采用 ReactNative，Weex，小程序等技術(shù)，一直在 Hybrid 領(lǐng)域進(jìn)行深耕。

從 App 誕生之初直到現(xiàn)在，轉(zhuǎn)轉(zhuǎn)的 Hybrid 體系經(jīng)歷了一些迭代和演進(jìn)。之前公眾號(hào)歷史文章曾經(jīng)發(fā)布過(guò)《轉(zhuǎn)轉(zhuǎn)Hybrid體系建設(shè)》，這篇文章是站在前端視角為我們展現(xiàn)了其中一部分內(nèi)容。今天我嘗試客戶(hù)端的視角來(lái)回顧下轉(zhuǎn)轉(zhuǎn) Hybrid 體系的建設(shè)歷程，在這個(gè)建設(shè)歷程中，有著一些我們的困惑、挫敗、思考以及喜悅，希望與屏幕前的你，一起分享。

幾個(gè)時(shí)期

轉(zhuǎn)轉(zhuǎn)的 Hybrid 體系建設(shè)，經(jīng)歷了幾個(gè)重要的時(shí)期，我把總結(jié)為下面三個(gè)階段：

• 野蠻生長(zhǎng)
• 混亂之治
• 性能優(yōu)化和開(kāi)發(fā)調(diào)試體驗(yàn)提升

下面，我來(lái)詳細(xì)闡述下這三個(gè)階段。文章比較長(zhǎng)，信息密度不大，一起來(lái)吧 :)

1. 野蠻生長(zhǎng)時(shí)期

在轉(zhuǎn)轉(zhuǎn) App 發(fā)展的前幾年，大概是 2015 年 ~ 2020 年上半年這段時(shí)間，Hybrid 缺少系統(tǒng)的規(guī)劃，我們剛出茅廬，Hybrid 在我們眼中是什么呢？

一個(gè)WebView，加載一個(gè) H5，將前端內(nèi)容加載展示出來(lái)，H5 JavaScript 與 App 進(jìn)行通信交互，僅此而已。

我們當(dāng)時(shí)還不能很好的意識(shí)到，一個(gè)成熟的或者理想中 Hybrid 體系應(yīng)該要建設(shè)成什么樣。

這時(shí)候 App 承載的業(yè)務(wù)形態(tài)在不斷的嘗試中，前端與 App 的通信接口，也在野蠻不斷擴(kuò)充添加著。A 業(yè)務(wù)今天來(lái)了個(gè)需求，說(shuō)我們需要加一個(gè)通信接口，OK，前端和 App 同學(xué)約定好，測(cè)試了下沒(méi)發(fā)現(xiàn)問(wèn)題上線??。B 業(yè)務(wù)明天來(lái)了一個(gè)需求，說(shuō)我們也需要一個(gè)，OK，再來(lái)，接口不斷添加著。

從開(kāi)發(fā)過(guò)程，到測(cè)試過(guò)程，最后到上線運(yùn)行，問(wèn)題也隨之慢慢的暴露出來(lái)。

1.1 開(kāi)發(fā)過(guò)程

我們沒(méi)有接口相關(guān)的文檔或者非常的缺乏，前端同學(xué)在開(kāi)發(fā)使用的時(shí)候，無(wú)法很好的知曉 App 目前有哪些能力可以使用，以及接口的參數(shù)和返回值是什么樣的，更多的是靠查看代碼和詢(xún)問(wèn)客戶(hù)端同學(xué)，非常的不方便，溝通成本還是挺高的。

另外就是由于沒(méi)有合理的規(guī)劃和接口分類(lèi)，造成了不少接口的功能是類(lèi)似的，但實(shí)現(xiàn)上有一些差異，會(huì)給前端同學(xué)在使用上造成困惑，究竟用哪一個(gè)才對(duì)。

1.2 測(cè)試過(guò)程

在通信接口開(kāi)發(fā)時(shí)，客戶(hù)端同學(xué)自測(cè)怎么做的呢？Android 和 iOS 客戶(hù)端內(nèi)置了一個(gè) html 文件，里面有一些通信的接口，每次都往這個(gè)文件添加，然后編譯到手機(jī)上進(jìn)行測(cè)試。

非常的不方便，每次要添加接口都要修改本地內(nèi)置的 html 測(cè)試文件，然后進(jìn)行編譯，但并不是所有人都可以正確的編寫(xiě)這個(gè) js 測(cè)試接口。

1.3 上線運(yùn)行

線上頁(yè)面出現(xiàn)問(wèn)題，客戶(hù)端同學(xué)是比較抓瞎的：

• 頁(yè)面地址是啥？
• 問(wèn)題發(fā)生時(shí) js 調(diào)用了 native 什么接口？參數(shù)是什么？有沒(méi)有問(wèn)題？
• 是離線包引發(fā)的問(wèn)題嗎？是否可以通過(guò)關(guān)閉和打開(kāi)離線包進(jìn)行驗(yàn)證和定位問(wèn)題？
• ···
  

一方面是我們的日志上報(bào)還不夠全面，另一個(gè)是沒(méi)有方便的小工具可以直接查看，只能通過(guò)本地調(diào)試 app 查看斷點(diǎn)數(shù)據(jù)和本地 log，排查定位問(wèn)題的鏈路比較長(zhǎng)，有些低效。

另外一個(gè)顯著的問(wèn)題就是線上我們的 WebView 出現(xiàn)了安全問(wèn)題，有騙子利用轉(zhuǎn)轉(zhuǎn)沒(méi)有限制頁(yè)面打開(kāi)或者限制頁(yè)面存在漏洞的情況，引導(dǎo)用戶(hù)在 App 內(nèi)打開(kāi)騙子網(wǎng)頁(yè)完成支付，用戶(hù)被騙投訴到平臺(tái)，給我們的口碑也造成了不小的影響。

2. 混亂之治

上面的問(wèn)題已經(jīng)暴露，加之本身 WebView 也開(kāi)始面臨著不少問(wèn)題，重新設(shè)計(jì)一個(gè)全新 Hybrid 架構(gòu)體系迫在眉睫。建設(shè)這樣新體系囊括了客戶(hù)端 WebView 的重構(gòu)，以及相關(guān)平臺(tái)的建設(shè)，再到 JS SDK的優(yōu)化，涉及到了整個(gè)大前端基建層面。

我們?cè)?2020 年中的時(shí)候，基本已經(jīng)完成了新的 Hybrid 體系設(shè)計(jì)，截止到目前，整體是這樣的：

2.1 WebView 重構(gòu)

歷史 WebView 面臨著諸多問(wèn)題，比如

• 存在大量歷史廢棄代碼
• 代碼冗余，業(yè)務(wù)耦合嚴(yán)重
• Native接口設(shè)計(jì)存在不合理的情況
• 代碼全部集中在主工程內(nèi)
• 無(wú)法對(duì)多 App 提供能力
• 代碼過(guò)于集中不便維護(hù)
• Webview本身功能、白名單、Cookie管理等混合在一起，且不具有對(duì)外擴(kuò)展性
• 缺乏 Hybrid 接口的分組設(shè)計(jì)以及權(quán)限控制，缺乏安全性

在 Android 和 iOS 兩端，我們重寫(xiě)了 WebView，并積極的采用了 Kotlin 和 Swift 語(yǔ)言。重寫(xiě)之后，將上面面臨的問(wèn)題就全部解決掉了。上線之后，經(jīng)過(guò)一段時(shí)間的灰度，對(duì)存在的問(wèn)題進(jìn)行不斷優(yōu)化和調(diào)整，最終進(jìn)行了全量，且將項(xiàng)目的 legacy webview 代碼全部刪除下線。

至此，我們?cè)诨靵y治理中，邁出了最重要的第一步。

2.2 DSBridge的兼容引入

2020 年 5 月 6 號(hào)，轉(zhuǎn)轉(zhuǎn)和找靚機(jī)合并，找靚機(jī)的整個(gè) WebView 體系和轉(zhuǎn)轉(zhuǎn)還不太一樣。找靚機(jī)使用的基于開(kāi)源方案 DSBridge 的通信方式。

DSBridge這套開(kāi)源方案其實(shí)挺優(yōu)秀：

1. 同時(shí)支持同步調(diào)用和異步調(diào)用
2. 支持以類(lèi)的方式集中統(tǒng)一管理 API
3. 支持 API 命名空間
4. 支持調(diào)試模式
5. 支持 API 存在性檢測(cè)
6. 支持進(jìn)度回調(diào)：一次調(diào)用，多次返回
7. 支持 Javascript 關(guān)閉頁(yè)面事件回調(diào)
8. 支持 Javascript 模態(tài)/非模態(tài)對(duì)話框

優(yōu)點(diǎn)有很多，但這些優(yōu)點(diǎn)并不是我們考慮的重點(diǎn)，合并融合后，我們需要考慮的重點(diǎn)是：

• 找靚機(jī)側(cè) H5 如何運(yùn)行在轉(zhuǎn)轉(zhuǎn) App 上
• 轉(zhuǎn)轉(zhuǎn)側(cè) H5 如何運(yùn)行在找靚機(jī) App 上

核心就是如何統(tǒng)一 WebView，更多的是考慮如何讓找靚機(jī)的 WebView 平滑過(guò)渡到轉(zhuǎn)轉(zhuǎn)的 WebView 體系中來(lái)。

轉(zhuǎn)轉(zhuǎn)使用自定義的通訊方案，有 200多 個(gè) API，找靚機(jī)采用了 DSBridge 通訊方案有 100 多個(gè) API。要考慮到 H5 在多 App 的運(yùn)行該怎么做呢？

• 統(tǒng)一的 WebView 容器這個(gè)是必須的，意義重大，意味著后續(xù)多 App 共享核心的 WebView 架構(gòu)體系，享受統(tǒng)一的功能升級(jí)和 Bug 修復(fù)，享受統(tǒng)一的平臺(tái)能力
• 統(tǒng)一的基礎(chǔ)能力接口，如路由、緩存、多媒體、設(shè)備、界面、位置、分享等等，這些能力獨(dú)立出單獨(dú)的組件，進(jìn)行多 App 復(fù)用
• 部分暫時(shí)無(wú)法統(tǒng)一的接口能力，JS Adapter 抽象出 H5 接口，內(nèi)部進(jìn)行多 App 差異化調(diào)用，抹平差異
• 考慮到歷史接口兼容問(wèn)題，存量的歷史接口，仍然保持原有的通信方案，新增接口統(tǒng)一按照轉(zhuǎn)轉(zhuǎn)目前推薦的標(biāo)準(zhǔn)形式進(jìn)行新增

在 App 早期，使用 iOS 7 系統(tǒng)的用戶(hù)還有一定的占比，為了兼容這些用戶(hù)，那時(shí)候我們并沒(méi)有使用 WKWebView。

UIWebView 我們采用的是基于 iFrame url 攔截解析獲取到執(zhí)行函數(shù)名和參數(shù)的方式來(lái)實(shí)現(xiàn) JS 調(diào)用 Native。后面隨著 iOS 7 用戶(hù)的縮小，以及 iOS 7 帶來(lái)的額外維護(hù)性問(wèn)題，我們逐步放棄了 iOS 7，應(yīng)用最低的支持版本從 iOS 7 變成 iOS 8（現(xiàn)在最低iOS 11），此時(shí)歷史 UIWebView 的通信接口 API 作為存量，很多業(yè)務(wù)在用，也一直保留到了現(xiàn)在。

取而代之的是采用 WKWebView。畢竟  WKWebView 相比 UIWebView 有著非常大的優(yōu)勢(shì)，獨(dú)立進(jìn)程和更好的 JS 引擎帶來(lái)的性能提升以及 WKWebView 在穩(wěn)定性、內(nèi)存管理、兼容性、安全性、后臺(tái)加載等方面的表現(xiàn)都更優(yōu)于 UIWebView。

所以，在轉(zhuǎn)轉(zhuǎn) App 中，由于 iOS 7 的歷史原因，存在著兩套通信方式：一個(gè)是兼容 UIWebView 的 iFrame url 攔截解析通信的方式，另外一個(gè)就是 WKWebView 的 WKScriptMessageHandler 協(xié)議通信方式。

融合初期，為了支持找靚機(jī)的 H5 通信，轉(zhuǎn)轉(zhuǎn) iOS 這邊移植新增了 DSBridge 的實(shí)現(xiàn)，使得找靚機(jī)的 H5 完美運(yùn)行在轉(zhuǎn)轉(zhuǎn) WebView 容器之上，此時(shí)，接口調(diào)用的 Native 能力仍然是找靚機(jī)側(cè)的。

后面隨著融合的不斷加深，基礎(chǔ)能力也在不斷的擴(kuò)大，僅有一些少數(shù)存量的接口仍然會(huì)調(diào)用到找靚機(jī)的 DSBridge 老接口 API，大部分都會(huì)調(diào)用到客戶(hù)端提供的基礎(chǔ)能力 API 以及找靚機(jī)新增的轉(zhuǎn)轉(zhuǎn)式規(guī)范接口 API。

2.3 平臺(tái)的建設(shè)

在整個(gè) Hybrid 體系建設(shè)中，平臺(tái)的建設(shè)是不可忽視的。我們不斷收集一線的反饋，和前端支撐組不斷磨合，由前端支撐組打造出統(tǒng)跳、接口管理、離線包、預(yù)渲染等平臺(tái)。這幾個(gè)平臺(tái)和客戶(hù)端關(guān)系緊密，還有一些其他平臺(tái)如前端的性能平臺(tái)、異常監(jiān)控平臺(tái)、報(bào)警平臺(tái)等等，和客戶(hù)端這邊關(guān)系不大，這里就不展開(kāi)說(shuō)了。

• 統(tǒng)跳平臺(tái)：在 Hybrid 中進(jìn)行路由跳轉(zhuǎn)的信息，由統(tǒng)跳平臺(tái)統(tǒng)一管理維護(hù)

• 接口管理平臺(tái)：解決 Native 提供的接口能力的增刪改查問(wèn)題，修改后，一鍵同步更新到前端文檔頁(yè)面。

• 離線包和預(yù)渲染管理平臺(tái)：解決離線包配置和預(yù)渲染配置的平臺(tái)

2.4 規(guī)范！規(guī)范！規(guī)范！

無(wú)規(guī)矩不成方圓，沒(méi)有規(guī)范，就容易引發(fā)破窗效應(yīng)與混亂，長(zhǎng)期下去，積重難返。

2.4.1 WebView基本規(guī)范

WebView Cookie、UA、Url Query、通信格式規(guī)范，詳情見(jiàn)：轉(zhuǎn)轉(zhuǎn)Hybrid-SDK重構(gòu)和實(shí)踐 一文中的『轉(zhuǎn)轉(zhuǎn)解決方案』部分。

2.4.2 安全規(guī)范

騙子通過(guò)聊天向用戶(hù)發(fā)送一些騙子網(wǎng)頁(yè)，用戶(hù)中招被騙錢(qián)后投訴到平臺(tái)，這樣的情況我們遇到了不止一個(gè)。后面我們經(jīng)過(guò)白名單的多次升級(jí)，逐步完善了整個(gè)白名單體系。

從添加域名的審批，到域名的定時(shí)清理，以及精細(xì)到 url path 級(jí)別的授信級(jí)別，使得近兩年來(lái)，騙子通過(guò)鉆白名單漏洞去行騙的的情況幾乎被完全封殺掉。

2.5 大禹 - 重點(diǎn)解決多 App 接口表現(xiàn)不一致

我們經(jīng)常收到前端同學(xué)的吐槽：

• 為什么同一個(gè)接口在轉(zhuǎn)轉(zhuǎn)iOS、Android上表現(xiàn)不同呢！
• 為什么同一個(gè)接口兩端回調(diào)的數(shù)據(jù)格式還有這么多差異！
• 為什么同一個(gè)接口轉(zhuǎn)轉(zhuǎn) App 和找靚機(jī) App 入?yún)⒑托袨楸憩F(xiàn)這么多不一致呢！
• 為什么？？？別說(shuō)啦別說(shuō)啦??（逃～）
  

有一段時(shí)間，我們會(huì)被拉入各種各樣的群里，面對(duì)群里拋出的類(lèi)似上面的問(wèn)題，解決起來(lái)非常的心累。

不行了，得專(zhuān)門(mén)搞一下了。遂立項(xiàng)大禹，治水行動(dòng)開(kāi)始。

治水基本方針：

• 能統(tǒng)一的基礎(chǔ)能力如掃碼、分享等等，客戶(hù)端要統(tǒng)一起來(lái)在基礎(chǔ)能力層實(shí)現(xiàn)，避免轉(zhuǎn)轉(zhuǎn)、找靚機(jī)各自實(shí)現(xiàn)導(dǎo)致的參數(shù)、行為、回調(diào)的不一致。雖然前端 JS Adapter 可以做一層適配，但工作會(huì)非常繁雜，在客戶(hù)端層面統(tǒng)一也有利于多 APP 基礎(chǔ)能力的復(fù)用。
• 對(duì)于強(qiáng)業(yè)務(wù)實(shí)現(xiàn)的一些能力，比如登錄 login，仍然交由各自 App 實(shí)現(xiàn)，這種情況，JS Adapter 需要抹平差異。

經(jīng)過(guò)大禹多期的優(yōu)化，我們將頁(yè)面棧管理、分享、相冊(cè)選圖、日歷、掃碼、通訊錄、通用存儲(chǔ)、剪貼板、系統(tǒng)權(quán)限等多個(gè)基礎(chǔ)能力，進(jìn)行了統(tǒng)一。沒(méi)有數(shù)據(jù)統(tǒng)計(jì)，這個(gè)帶來(lái)了多大的收益，但是明顯的感覺(jué)，被拉群的次數(shù)少了，之前的一些長(zhǎng)期被吐槽的接口也很少再收到吐槽了。

但大禹治水不能停下來(lái)，這是一件需要長(zhǎng)期堅(jiān)持做下去的事情。

3. 性能優(yōu)化和開(kāi)發(fā)調(diào)試體驗(yàn)提升

3.1 初期的優(yōu)化

性能優(yōu)化其實(shí)不是最后才開(kāi)始做的，而是從頭到現(xiàn)在，一直在進(jìn)行，只是階段性的重點(diǎn)不太一樣。

早期我們?cè)诖笄岸祟I(lǐng)域優(yōu)化手段做的比較有限，包括了

• 公共資源預(yù)加載
• 使用了離線包加快資源的訪問(wèn)速度，縮短頁(yè)面打開(kāi)的白屏?xí)r長(zhǎng)
• 離線包圖片骨架屏優(yōu)化白屏問(wèn)題

除了上面幾點(diǎn)，前端同學(xué)也在積極的嘗試各種優(yōu)化方案，包括但不限于：

• 能讓你縱享絲滑的SSR技術(shù)，轉(zhuǎn)轉(zhuǎn)這樣實(shí)踐
• 來(lái)，一起偷偷優(yōu)化前端請(qǐng)求性能，然后驚艷所有人
• SSR同構(gòu)降級(jí)策略
• 離線預(yù)渲染OPR：0成本接入 媲美SSR效果
  
  

3.2 Kraken的嘗試

2021 年是 Flutter 高速發(fā)展的一年，但是官方的 Flutter for Web 并不如人意，此時(shí)阿里的 Kraken 北海（目前的WebF）方案的出現(xiàn)，讓我們看到了另外的一種可能。

Kraken 方案上層采用 Web 技術(shù)棧進(jìn)行開(kāi)發(fā)，無(wú)論是 Vue 還是 React 又或者其他如 Angular，通通不限制，底層使用 Flutter 引擎自渲染，保證多端的一致性，使用 AOT 編譯將 Kraken 編譯成機(jī)器碼，提供接近原生的性能。由于上層基于 W3C 標(biāo)準(zhǔn)實(shí)現(xiàn)，所以擁有非常龐大的前端開(kāi)發(fā)者生態(tài)。

我們聯(lián)合前端同學(xué)，在 Kraken 方向做了一些嘗試：將轉(zhuǎn)轉(zhuǎn)內(nèi)的“附近的人”頁(yè)面，試著用 Kraken 實(shí)現(xiàn)。

通過(guò)這個(gè)頁(yè)面的改造，我們看到了 Kraken 還存在了許多不足，還不足以支撐我們?cè)诰€上大規(guī)模使用。

存在的問(wèn)題包括但不限于下面列舉的一些：

• 表現(xiàn)不一致問(wèn)題
• CSS 定位、布局表現(xiàn)與瀏覽器表現(xiàn)不一致
• 部分 API 表現(xiàn)與瀏覽器不一致(getBoundingClientRect等)
• iOS，Android系統(tǒng)表現(xiàn)不一致
• 重大 Bug
• 頁(yè)面初始化渲染完成，動(dòng)態(tài)修改元素樣式，DOM不重新渲染
• 滑動(dòng)監(jiān)聽(tīng)計(jì)算導(dǎo)致 APP 崩潰
• 調(diào)試成本高
• 不支持 vue-router，單項(xiàng)目單路由
• 不支持熱更新，npm run build 預(yù)覽
• 不支持 sourceMap，無(wú)法定位源代碼
• 真機(jī)調(diào)試只支持 element 和 network；dom 和 element 無(wú)法互相選中；無(wú)法動(dòng)態(tài)修改 dom 結(jié)構(gòu)，無(wú)法直接修改樣式.......
• 頁(yè)面白屏，假死
• 安全性問(wèn)題
• 無(wú)瀏覽器中的“同源策略”限制
• 兼容性
• npm包不兼容等

由于上面存在的問(wèn)題帶來(lái)的高額的開(kāi)發(fā)調(diào)試以及維護(hù)成本，我們暫停了在 Kraken 方向的投入。但對(duì)后續(xù)也就是目前的 WebF 仍然保持著關(guān)注。

3.3 帝江 - 一次性能和開(kāi)發(fā)體驗(yàn)的飛躍

3.3.1  性能提升

除去 Kraken 等方案的嘗試，我們積極的在探索和尋找其他優(yōu)化方式，最終確定了離線包、預(yù)渲染、預(yù)加載、預(yù)請(qǐng)求、接口請(qǐng)求代理、圖片緩存共享等多個(gè)優(yōu)化手段。

離線包消除靜態(tài)資源下載耗時(shí)、預(yù)渲染消除??初始化耗時(shí)、預(yù)加載提前緩存常用靜態(tài)資源、預(yù)請(qǐng)求提前獲取主屏數(shù)據(jù)解決??跳動(dòng)和?絡(luò)請(qǐng)求鏈路?、圖片緩存共享將 Native 圖片緩存共享給 H5 提供視覺(jué)占位等，通過(guò)一系列多級(jí)優(yōu)化方案，前端可以靈活的組合上面的優(yōu)化手段，使得性能體驗(yàn)大大提升。

使用預(yù)渲染的頁(yè)面，就是秒開(kāi)的體驗(yàn)，平均首屏?xí)r間從 1500ms 下降到 400ms 左右。關(guān)于預(yù)渲染這塊，后面有機(jī)會(huì)的話，我們會(huì)單獨(dú)再開(kāi)一篇文章一起深入聊聊。

上面提到的這些方案具有正交性，可以隨意進(jìn)行組合接入。

正常無(wú)優(yōu)化的 H5 加載展示流程：

離線包：

預(yù)渲染+預(yù)請(qǐng)求：

無(wú)預(yù)渲染+預(yù)請(qǐng)求：

預(yù)渲染+預(yù)請(qǐng)求+圖片緩存共享：

下圖點(diǎn)開(kāi)可以動(dòng)

3.3.2 開(kāi)發(fā)調(diào)試體驗(yàn)

我們很關(guān)注前端開(kāi)發(fā)同學(xué)的開(kāi)發(fā)、調(diào)試體驗(yàn)，以及在線上排查問(wèn)題的時(shí)候，客戶(hù)端能做什么可以更快的幫助定位問(wèn)題。

基于這個(gè)簡(jiǎn)單的愿景，我們開(kāi)發(fā)了 WebView 小工具。

概覽：在概覽中，我們可以清晰看到 API 接口日志，離線包，預(yù)渲染等優(yōu)化手段的命中情況，此外我們也可以直接控制 eruda 調(diào)試工具以及 UI 走查小工具的開(kāi)關(guān)，以及頁(yè)面的 Url，Cookie，Query，UserAgent 等情況。

API接口日志： 詳細(xì)記錄了 JS call Native 的每一個(gè)接口，包括 request 和 response 詳情。

預(yù)渲染： 記錄了預(yù)渲染當(dāng)前的下發(fā)配置，以及預(yù)渲染模版的當(dāng)前狀態(tài)，可以方便查看模版是不是已就緒還是渲染中或者被加入了黑名單。同時(shí)也添加了客戶(hù)端的預(yù)渲染日志，方便排查頁(yè)面為什么沒(méi)有命中預(yù)渲染。

。

預(yù)請(qǐng)求：記錄發(fā)出了哪些預(yù)請(qǐng)求，以及這些預(yù)請(qǐng)求的 request 和 response 詳情。

離線包：開(kāi)啟和關(guān)閉離線包功能，刪除離線包緩存，以及展示離線資源的命中記錄。

接口代理：展示接口代理記錄以及接口的 request 和 response 詳情。

圖片緩存共享：記錄緩存共享請(qǐng)求，包含目標(biāo)圖片和命中圖片地址。

后續(xù)規(guī)劃

文檔建設(shè)

持續(xù)優(yōu)化前端的接口文檔以及平臺(tái)，在接口的用途、參數(shù)和響應(yīng)描述方面力爭(zhēng)清晰和準(zhǔn)確，且對(duì)接口的升級(jí)改動(dòng)形成變更歷史等，方便追溯和兼容。

埋點(diǎn)統(tǒng)一和監(jiān)控

統(tǒng)一大前端的埋點(diǎn)，建立更全面的埋點(diǎn)和監(jiān)控，如頁(yè)面白屏?xí)r長(zhǎng)、大前端全鏈路埋點(diǎn)監(jiān)控等，實(shí)現(xiàn)對(duì) H5 頁(yè)面的全方位把控。

性能優(yōu)化

還有很多事情需要做，如

• 進(jìn)一步提升離線包、預(yù)渲染的命中率
• 智能預(yù)渲染，減少不必要的模版渲染
• 啟動(dòng)時(shí)的預(yù)渲染，進(jìn)一步降低對(duì) App 主線程卡頓的影響
• 保持對(duì) WebF 等技術(shù)的持續(xù)關(guān)注，探索應(yīng)用的可能性
• ···

鴻蒙

HarmonyOS Next 的即將出現(xiàn)，意味著要基于純鴻蒙系統(tǒng)重新構(gòu)建一套 WebView 解決方案，整個(gè)架構(gòu)體系和當(dāng)前可能是一致的，但可能會(huì)融合鴻蒙系統(tǒng)的原子化服務(wù)以及多設(shè)備流轉(zhuǎn)等特性，提升用戶(hù)在 HarmonyOS 上的 Web 使用體驗(yàn)。