背景

做爲日活6億的國民級App，抖音中存在着很是很是多的用戶功能，而且幾乎天天都有新業務在抖音中孵化、上線。很顯然，Native原生開發的速度和發版節奏是沒法知足業務快速迭代的訴求的。所以在抖音中，存在着大量的Hybrid業務場景，使用的技術棧包括傳統的webview、reactNative，以及字節自研的Lynx。前端

Lynx，字節跳動原創客戶端跨端引擎框架，以JavaScript做爲開發語言，可讓前端研發使用熟悉的DSL進行跨端開發。在今年的春晚活動中，Lynx取得了很是亮眼的表現，在縮減客戶端發板成本的同時，有效保障了頁面體驗。react

抖音音樂業務在端內開展Hybrid場景時，就選擇了Lynx技術框架。得益於公司自研，業務在監控上有了很是多的自主性。針對實際業務場景，從用戶視角出發，定製了一套業務監控指標。web

容器介紹

區別於傳統的H5場景的容器Webview，Lynx有着本身的跨端容器Bullet。容器對於跨端業務的全鏈路的監控來講很是重要，下面先來簡單介紹下抖音跨端Bullet。緩存

Bullet是什麼？

Bullet，字節自研的跨端通用容器，它能夠同時處理Lynx、webview、reactNative三種跨端實現，集合了跨端場景所須要的基礎能力，抹平了三種技術棧在JSB、資源加載等方面的差別。讓接入的業務客戶端作到一次接入，各跨端場景都可適用。21年春節活動中也使用了Bullet容器。性能優化

下面是一張Bullet的結構圖，大致展示了Bullet所具有的能力。👇markdown

Lynx頁面加載過程

在正式介紹跨端監控前，先來簡單介紹下Lynx頁面在Bullet中被加載的過程。網絡

Bullet架構中將Lynx完整的加載鏈路拆解成了一個個獨立的子任務，執行上相似於前端中的**「鏈式執行的Promise」，**一個任務後緊接下一個任務，上一個任務的結果會做爲下一個任務的輸入。架構

整個過程大致分爲4個子任務：路由解析、離線資源加載、Lynx Client初始化，Lynx首屏渲染。框架

執行的順序以下圖所示👇函數

Bullet針對Lynx場景，定製了一套特殊的schema規則。不只支持Lynx資源的解析與渲染，還支持降級H5。

當用戶行爲觸發喚起Lynx場景的頁面時，Bullet會攔截schema，並進行路由解析，根據路由規則結合Gecko進行Lynx靜態資源的加載，完成資源加載後，初始化Lynx，將資源交由Lynx進行解析渲染。

Gecko，字節跳動資源分發中臺，專一於客戶端文件分發場景，是提高客戶端動態化能力的重要基礎設施。做爲資源分發通道，支持各種靈活可定製的分發規則，助力業務快速迭代，大幅提高用戶體驗。

以上是各個鏈路都執行正常時的路徑。當其中每一個環節出現異常時，Bullet會觸發相應的錯誤處理機制。

當路由解析失敗，Bullet會加載兜底的BulletView，呈現給用戶錯誤提示頁面。在其餘環節出現異常時，若schema上帶有fallback連接，則Bullet會進入兜底的fallbackPipeline，再次開始路由規則的解析，資源的加載，跟Lynx場景不一樣的時是，此時初始化的webview，在webivew中呈現web資源。

監控方案

指標定義

針對上述Bullet以及Lynx的執行過程，結合音樂場景的高體驗要求的特性，咱們自定義了多種監控指標，主要分爲兩大類，一類是性能指標，一類是錯誤指標。

性能監控

Bullet容器首屏時間🌟🌟🌟🌟🌟

不一樣於web場景經常使用的FMP指標，咱們監測了從用戶點擊到Lynx頁面首屏加載完成的時間間隔。在抖音，Hybrid頁面的schema是由Bullet中的router service管理，所以用戶點擊時～= Bullet中router的open方法被調用時。

Lynx SDK主要負責渲染，在渲染完成時會拋出一個回調函數，所以Lynx首屏渲染完成時 = Lynx的首屏回調函數執行時。

此數值監測了用戶從點擊到看到頁面首屏的耗時，是目前業務場景中最核心關注的指標之一。

計算公式：容器首屏時間 = Lynx****首屏渲染完成時 - Bullet****的router攔截時

Lynx首屏時間🌟🌟🌟🌟

在Lynx頁面加載的總體鏈路，Bullet容器負責了Lynx頁面的完整加載鏈路。而Lynx首屏則表明了Lynx容器側的總體渲染表現。當總體鏈路耗時較久時，咱們能夠經過對比Bullet容器首屏與Lynx首屏時間，找到鏈路的耗時點。

計算公式：Lynx首屏時間 = Lynx****首屏渲染完成時 - Lynx****初始化開始時

本地資源攔截成功率🌟🌟🌟

Lynx產物在實際生產環境中，是利用資源分發平臺Gecko進行提早下發。下發的策略是，在合適的時機，提早緩存在App中，實現資源資源的離線化加載，這也是Lynx在性能上表現優異的緣由之一。

Bullet容器在資源加載時，優先嚐試加載本地資源。在某些異常場景，好比網絡異常或是資源分發平臺Gecko異常時，會存在本地資源加載失敗的狀況，此時Bullet會去嘗試拉取遠程的CDN資源。

本地資源攔截成功率這一指標主要監控Gecko以及Bullet在資源加載環節的穩定性。是否成功到攔截本地資源，對於全鏈路的耗時有着比較大的影響，所以該指標能夠用於分析全鏈路的耗時問題。

計算公式：本地資源攔截成功率 = 從本地加載Lynx資源成功量 / 路由解析總量

頁面降級率🌟🌟🌟

前面的小節提到過，Bullet針對Lynx頁面鏈路上的異常狀況會進行兜底的fallback處理，降級至web場景。一般狀況降低級web後，頁面總體的體驗和首屏加載時長都會差於Lynx場景。咱們對這一數值進行監控，同時確保此數值極低，保障極致的用戶體驗。

計算公式：頁面降級率 = 進入fallbackPipeline的總量 / 路由解析總量

【終極指標】自定義TTI🌟🌟🌟🌟

在實際的業務場景中，咱們一般會在首屏加載骨架屏。除了極少數純靜態的展現頁面外，用戶可交互的首屏都至少依賴於一個API接口的數據。

因爲每一個業務場景對頁面可交互的定義都不一樣，所以TTI的結束時間點沒法統一衡量。在與Bullet側同窗溝通後，Bullet容器在Hybrid場景注入了一個containerInitTime值，用於表明用戶點擊的時間。

抖音音樂的場景中，對於用戶點擊到落地頁面的音頻首幀起播的時長是最關注的。

所以抖音音樂榜場景播放的TTI值 = 音樂播放開始時間點 - containerInitTime。

計算公式：自定義TTI = 自定義時間節點 - containerInitTime

錯誤監控

在性能監控上，目前咱們主要關注了用戶從首屏到可交互的耗時，以及一些Lynx加載鏈路上的核心階段的耗時和資源加載的穩定性。

在錯誤指標上，咱們則聚焦在頁面運行時的一些異常問題上，保障頁面運行的穩定性。

頁面加載失敗率🌟🌟🌟🌟🌟

儘管Bullet在Lynx的整個加載鏈路中作了不少的兜底策略，但以防黑天鵝事件，Bullet頁面的加載失敗率監控仍然是很是有必要的。這個指標也是衡量Lynx鏈路穩定性的核心指標之一。

計算公式：Bullet頁面加載失敗率 = 頁面加載失敗量 / 路由解析總量

JS錯誤/JSB錯誤/API請求錯誤/引擎層錯誤🌟🌟🌟🌟

頁面運行時，咱們全面監控了各種錯誤狀況。包括JS錯誤、JSB錯誤、發送的API請求錯誤以及容器（引擎）層的錯誤。

數據分析&監控上報

數據日報

針對上述的監控指標，咱們經過開發飛書的機器人，在相關的業務同步羣中，每日同步業務場景的數據指標，如下是某個抖音音樂場景在某日的數據指標卡片。

閾值設定

21年抖音的春節項目使用的就是lynx技術棧，依據春節總結的指標，咱們制定了一份閾值標準。

	性能閾值
	點擊首屏	lynx首屏	降級H5率	本地資源攔截率
IOS	500ms	200ms	0.0001	99%
Android	800ms	680ms	0.0001	99%

	錯誤閾值
	jsb錯誤率	js錯誤率	引擎層NA錯誤率	API接口錯誤率
IOS	0.0001	0.001	0.001	0.015
Android	0.0001	0.001	0.001	0.01

實時報警

目前抖音中的Hybrid相關的埋點監控數據都是實時上報監控平臺，監控平臺會進行實時的數據清洗工做。

利用監控平臺的定時檢測能力，咱們對於異常錯誤，設置了每半個小時進行一次數據檢測。當相關錯誤的閾值超過設置的閾值時，就會觸發報警。（監控平臺的報警能力鏈接了飛書，報警時飛書會發送一條加急消息）

錯誤治理

目前經過這套監控方案，咱們已經發現和治理了不少的線上問題。目前推動解決的問題主要有如下幾類：

場景1：推動關鍵頁面的首屏性能優化&關鍵接口瘦身

經過每日的性能數據監控，在音樂人的看見音樂計劃活動期間，發現了活動頁面的性能表現低於預期，活動頁面的Bullet容器首屏時間在安卓側超過1s，Lynx首屏時間超過800ms，同時頁面的首屏TTI也超過3.5s。

對Lynx渲染鏈路進一步分析，發現了首屏時間主要耗費在資源包加載上。

Lynx渲染鏈路耗時示意圖

因而對資源包進行體積壓縮優化，經過首屏頁面第一屏切割，靜態圖片壓縮方式，將資源包提體積從1134KB，縮小至416KB，包體積瘦身63.32%，頁面的首屏時間也下降了38.75%。

產物資源包體積變化

針對活動頁面首屏TTI過大的問題，經過對接口數據瘦身、縮短獲取路徑方式，接口響應耗時減小將近1s。

首屏接口響應時間耗時

場景2：推動解決Lynx底層的代碼優化

經過對Lynx引擎層的錯誤監控，咱們發現了一些Lynx底層一些代碼問題，好比代碼中的各種判空問題等。經過Lynx側負責同窗的及時修復處理，提升了線上業務的容錯性和穩定性。

Lynx底層的各種判空兼容問題

總結&將來規劃

以上就是抖音音樂目前在抖音內的跨端監控實踐。現階段，咱們只監控了頁面核心一些數據指標，相對於web場景的完善的監控指標來講，Lynx場景的監控還相差較多。好比缺乏頁面的流暢度、LCP、FID等等指標。

同時在數據分析維度，目前還不夠細化，好比針對不一樣評分的機型，須要設定不一樣閾值的標準。針對端錯誤場景引入錯誤等級制度，將上報的錯誤進行歸類細化，以對用戶的實際影響，將錯誤分爲fatal類錯誤（頁面加載錯誤）、serious類錯誤（用戶沒法正常交互）、warning類錯誤（影響用戶體驗），幫助業務開發同窗更好的評估和處理頁面的錯誤。

在將來，咱們還但願創建一套全面的完善的Hybrid性能&錯誤評估體系，可以將web、lynx、native三個場景進行數據對焦，幫助開發同窗在技術選型時，可以從數據維度清晰的、全面的對比3種技術棧的優劣。

道阻且長，行則將至，行而不輟，將來可期。

【招聘信息】

咱們是抖音音樂研發團隊，咱們須要支撐的產品有抖音這款數億日活用戶的產品。團隊業務的願景是打造「全球最具影響力的音樂平臺，讓每一個人更好地發現和交流，讓音樂人更好地創做和成長」。

咱們的現有業務：

一、音樂中臺-爲抖音等字節的業務提供投稿、消費、分發等音樂場景的支持。

二、中國音樂-抖音內音樂消費的嘗試&音樂價值論證。

三、音樂人-音樂創做者平臺。

咱們的招聘職位包括服務端、前端、客戶端、測試，面向社招、校招以及實習生同窗。Base地在上海、深圳。

歡迎加入咱們！簡歷請投遞alice.shi@bytedance.com.

參考文獻

歡迎關注「字節前端 ByteFE 」

簡歷投遞聯繫郵箱「tech@bytedance.com」

抖音音樂在跨端性能及異常監控上的實踐

背景