Hippy 与 Bugly Hippy 监控：从 JS 错误到页面性能的全链路质量监控指南

• 跨平台
• 移动开发
• 前端

Bugly Hippy 监控是面向基于 Hippy 框架的跨平台应用提供的全链路质量监控方案，覆盖 JS 错误、CGI 接口、静态资源、页面性能、页面访问与自定义监控等维度，并统一支持 iOS、Android、Ohos 三端。本文以 Hippy 官方文档 bugly-hippy-monitor.md 为主线，介绍监控能力全貌、ShiplyCS-HippyAegis SDK 的接入要点与控制台的使用方法，并结合 Hippy 源码中的性能打点实现（performance模块）说明“页面打开慢”为何可以被分解、追溯与优化。

一、核心监控能力

Bugly Hippy 监控深度整合 Hippy 框架特性，为开发者提供六个维度的监控能力，下文逐项说明其监控对象与价值。

1. JS 错误监控

• 全面捕获 JavaScript 执行时的异常和错误；
• 支持异步错误和 Promise rejection 监控；
• 提供完整的错误堆栈信息和上下文数据。

在 Hippy 应用里，JS 代码运行在独立的 JS 引擎（如 V8、Hermes 等）中，JS 崩溃不一定表现为原生 Crash，因此独立于 Native 崩溃之外的 JS 错误通道对定位“白屏”“逻辑异常”类问题尤为关键。

2. CGI 监控

• 监控网络请求的成功率、响应时间和错误率；
• 支持 HTTP/HTTPS 请求的详细性能分析。

Hippy 应用的网络请求通常走原生 Network 模块（参见 Network.js），监控层可以从框架侧直接关联到具体接口与耗时分布。

3. 静态资源监控

• 监控图片、样式表等静态资源的加载性能；
• 统计资源加载成功率和加载时长；
• 识别资源加载失败和超时问题。

4. 页面性能监控

• 精确测量页面加载时间、渲染性能；
• 监控首屏渲染时间和交互响应时间；
• 提供页面级别的性能瓶颈分析。

页面性能是 Hippy 框架最有辨识度的监控维度，因为它直接对应 Hippy 从“引擎初始化到首帧绘制”的完整启动链路。源码层面的打点依据见下文“页面性能指标如何产生”一节。

5. 页面访问监控

• 统计页面 PV/UV 等访问指标；
• 分析用户行为流和转化路径。

6. 自定义监控功能

• 自定义事件：支持业务特定场景的埋点监控；
• 自定义测速：针对关键业务操作进行性能测量。

二、功能特色

结合官方文档描述，Bugly Hippy 监控的特色可归纳为六点：

其中“支持 React 和 Vue 两种上层框架”与 Hippy 生态的现状一致：Hippy 通过 hippy-react 与 hippy-vue、hippy-vue-next 等包分别支撑 React 与 Vue 开发范式，监控方案对两种范式提供统一的数据视图。

三、SDK 接入：ShiplyCS-HippyAegis

ShiplyCS-HippyAegis是 Shiply、Bugly、Hippy 团队共建、基于 Aegis-Core 底层、专门针对 Hippy 监控场景优化的 SDK。它与通用 APM SDK 的核心差异在于：

1. 支持 Hippy 团队制定的页面性能官方标准——即按照 Hippy 框架定义的启动/渲染阶段口径（Native 引擎初始化、JS 加载、业务执行、DOM 创建、首帧绘制等）采集与展示性能数据，而不是简单套用 Web 侧指标；
2. 支持区分 Hippy 网络耗时和 Bridge 耗时——Hippy 的请求链路中包含 JS 引擎与原生侧之间的 Bridge 调用，通用 SDK 无法把“Bridge 开销”从“网络开销”中剥离，而该 SDK 可以分别度量这两部分，帮助判断耗时到底发生在通信层还是服务端。

完整的依赖引入、初始化参数与上报配置步骤，请参考 Bugly 官方站点上的《Bugly Hippy 监控 SDK 接入指引》（官方文档站查阅，非本仓库内文件）。

重要提醒：Bugly 专业版的 Hippy 监控能力在官方描述中处于灰度发布阶段，如需申请试用需联系腾讯 Bugly 客服开通。接入前建议先确认账号已获得相应权限，以避免集成后无数据上报的问题。

四、页面性能指标如何产生：源码级印证

控制台“页面性能”维度之所以能展示 FP、FCP 以及“Native 引擎初始化 → JS 加载 → 业务执行 → DOM 创建 → 首帧绘制”的完整链路，是因为 Hippy 框架自身就内置了一套对齐 W3C Performance API 的内部性能打点实现，位于 driver/js/include/driver/performance 与 driver/js/src/performance。

1. 导航/启动阶段打点

performance_navigation_timing.h 定义了PerformanceNavigationTiming，其字段正好对应文档描述的关键阶段：

// driver/js/include/driver/performance/performance_navigation_timing.h (L57-L67) DEFINE_SET_AND_GET_METHOD(HippyNativeInitStart, TimePoint, hippy_native_init_start_) DEFINE_SET_AND_GET_METHOD(HippyNativeInitEnd, TimePoint, hippy_native_init_end_) DEFINE_SET_AND_GET_METHOD(HippyJsEngineInitStart, TimePoint, hippy_js_engine_init_start_) DEFINE_SET_AND_GET_METHOD(HippyJsEngineInitEnd, TimePoint, hippy_js_engine_init_end_) DEFINE_SET_AND_GET_METHOD(HippyRunApplicationStart, TimePoint, hippy_run_application_start_) DEFINE_SET_AND_GET_METHOD(HippyRunApplicationEnd, TimePoint, hippy_run_application_end_) DEFINE_SET_AND_GET_METHOD(HippyDomStart, TimePoint, hippy_dom_start_) DEFINE_SET_AND_GET_METHOD(HippyDomEnd, TimePoint, hippy_dom_end_) DEFINE_SET_AND_GET_METHOD(HippyFirstFrameStart, TimePoint, hippy_first_frame_start_) DEFINE_SET_AND_GET_METHOD(HippyFirstFrameEnd, TimePoint, hippy_first_frame_end_) DEFINE_SET_AND_GET_METHOD(HippyFirstContentfulPaintEnd, TimePoint, hippy_first_contentful_paint_end_)

从源码结构看，一条页面打开链路被切分为：HippyNativeInit（Native 引擎初始化）→HippyJsEngineInit（JS 引擎初始化）→HippyRunApplication（业务执行）→HippyDom（DOM 创建）→HippyFirstFrame/HippyFirstContentfulPaint（首帧 / 首次内容绘制）。DEFINE_SET_AND_GET_METHOD宏在写入时间戳的同时自动维护start_time_（取最早阶段起点）与duration_（取最大跨度），保证总耗时口径稳定。

该类还维护了按 Bundle 维度记录加载耗时的结构：

// driver/js/include/driver/performance/performance_navigation_timing.h (L35-L39) struct BundleInfo { string_view url_; TimePoint execute_source_start_; TimePoint execute_source_end_; };

这正是 SDK“区分网络耗时与执行耗时”的数据基础：每个 JS Bundle 的加载/执行区间都可单独度量。

2. 首帧与 FCP 打点

performance_paint_timing.h 定义了PerformancePaintTiming，类型枚举只含两种：

// driver/js/include/driver/performance/performance_paint_timing.h (L34-L36) enum class Type { kFirstPaint, kFirstContentfulPaint };

对应控制台里的FP（First Paint）与FCP（First Contentful Paint）指标。相关的对外模块（PerformanceModule、PerformanceNavigationTimingModule、PerformancePaintTimingModule、PerformanceResourceTimingModule等）见 driver/js/src/modules/performance，资源加载耗时（静态资源监控、CGI 监控的时间数据来源之一）则由PerformanceResourceTiming提供。

换句话说，Bugly Hippy 监控展示的“页面打开慢”链路，其时间戳源头就是上述框架内建打点，监控平台做的是聚合、对比与告警，而非重新造一套采集口径。

五、控制台使用指引

Bugly Hippy 监控为应用提供从 JS 错误、CGI 接口、静态资源到页面性能、访问流量的全景式监控，所有监控维度遵循一体化数据分析体验。下文按官方文档的六个步骤聚焦“页面性能”维度的使用方式。

1. 配置采样率

为满足应用不同生命周期的管理需求，监控配置支持“部署前置”与“线上调控”相结合：部署阶段预设监控范围，上线后可通过管理台实时调整采样率，从而实现成本与效果的精准平衡。

2. 分析指标变化

Bugly Hippy 监控不仅提供灵活的搜索分析，更对关键操作进行全链路打点。以页面打开速度为例：你不仅能看到 FP、FCP 结果，还能清晰分析从 Native 引擎初始化、JS 加载、业务执行到 DOM 创建、首帧绘制的每一个关键阶段耗时——这与上文源码中PerformanceNavigationTiming的阶段字段一一对应，让“页面打开慢”的问题变得可分解、可追溯；结合指标的实时概览与历史趋势，优化工作可以有的放矢。

3. 关注重要阶段耗时

耗时分析模块通过瀑布图，将页面加载过程中各核心阶段的执行顺序、依赖关系与耗时长短直观呈现。这不仅让总耗时一目了然，更能让开发者快速识别出是哪个阶段发生了阻塞，从而精准定位性能瓶颈的根源。

4. 多维下钻指标

多维下钻功能支持从不同视角切分与对比业务数据。例如，可以轻松分析“不同页面加载策略”在“不同网络运营商”条件下的表现，从而精准评估策略有效性及网络环境对核心指标（如业务入口执行耗时、Native 引擎初始化耗时）的影响。

5. 分析上报日志

官方提供了从聚合分析到明细数据的闭环排查能力：所有监控项的原始上报数据均在日志模块中完整保存。当多维分析提示异常时，只需点击「查看日志」即可直达相关日志，通过原始信息快速定位问题根因。

6. 配置异常告警

Bugly Hippy 监控提供实时监控和告警能力，允许开发者灵活配置告警条件，及时发现业务异常。

六、适用前提与注意事项

• 可用性前提：Hippy 监控在 Bugly 专业版中处于灰度发布阶段（以官方文档描述为准），使用前需要申请开通，未开通时集成 SDK 也可能收不到数据；
• 框架版本：文中源码证据来自当前仓库中的 Hippy 性能打点实现（driver/js性能模块），对应 Hippy 3.0 架构下的 JS Driver 层；不同版本框架的阶段口径若有调整，以所用 Hippy 版本的performance模块实现为准；
• 指标口径：FP/FCP 等指标由框架内建打点产生（见第四节点名），解读瀑布图时应结合具体页面类型（本地 Bundle / 远程 Bundle、是否命中缓存）判断“JS 加载”阶段耗时的构成；
• 采样与成本：采样率可在管理台实时调整，灰度期建议从小采样率起步，验证数据完整性后再逐步放大。

综合来看，Hippy 侧提供标准化的阶段打点，Bugly Hippy 监控（ShiplyCS-HippyAegis）提供三端统一的采集、聚合、下钻与告警能力，二者组合构成了 Hippy 跨平台应用从“发现问题”到“定位瓶颈”的完整质量保障链路。

• 跨平台
• 移动开发
• 前端