背景

做为日活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」

抖音音乐在跨端性能及异常监控上的实践

背景