Hybrid App里怎么监控WebView页面的性能？

混合开发监控确实是个坑，特别是安卓机碎片化太严重，performance.timing 在某些 WebView 内核里就是摆设，字段全是 0 的情况我也遇到过不少。单纯靠 JS 层去算时间肯定不准，因为 JS 运行环境和 Native 线程的时间戳对齐很难搞。咱们得换个思路，采用 Native + JS 混合埋点的方案，把 Native 作为时间基准。

第一步，解决时间对齐问题。不要在 JS 里用 Date.now() 去算绝对时间，而是让 Native 在 WebView 初始化加载 URL 之前，把当前的时间戳注入到 JS 的全局变量里。这样 WebView 里所有的计算都基于这个 Native 给的基准时间，这样算出来的耗时才是真实的端到端耗时。

你可以试着在 Cordova 的插件层或者 WebViewClient 的 onPageStarted 里注入这段代码：

// Native 注入的代码，假设 native_timestamp 是 Native 传过来的毫秒时间戳

window.__native_start_time__ = native_timestamp;

第二步，针对首屏时间。既然 performance.timing 不靠谱，咱们就用更现代的 PerformanceObserver API，去监听 LCP (Largest Contentful Paint) 和 FCP (First Contentful Paint)。这个 API 在现在的安卓 WebView 上支持度比 timing 好很多。如果实在不支持，就只能退回到 Vue 的 mounted 钩子里手动打点，但那个只是 DOM 渲染完的时间，不包含图片加载，仅供参考。

代码大概是这样写的：

if (window.PerformanceObserver) {

    const observer = new PerformanceObserver((list) => {

        const entries = list.getEntries();

        const lastEntry = entries[entries.length - 1];

        // 算出相对于 Native 开始时间的耗时

        const lcpTime = lastEntry.startTime - (window.__native_start_time__ ? 0 : performance.timing.navigationStart);

        

        // 上报数据

        reportToBackend({

            metric: 'LCP',

            value: lcpTime,

            url: window.location.href

        });

    });

    observer.observe({ entryTypes: ['largest-contentful-paint'] });

}

第三步，关于滑动卡顿。JS 层其实很难捕捉到真正的渲染掉帧，因为 JS 运行在主线程，如果 JS 堵塞了，RAF (requestAnimationFrame) 也会跟着停，数据就不准了。但咱们可以做一个简化的 FPS 监控，通过计算两帧之间的时间差来估算。如果两帧间隔超过 16.6ms，大概率是卡了。虽然不如 Native 层的 Choreographer 监控准，但在 H5 里也能凑合用。

这里有个简单的 FPS 监控类：

class FPSMonitor {

    constructor() {

        this.lastTime = performance.now();

        this.frames = 0;

        this.timer = null;

    }



    start() {

        this.loop();

    }



    loop() {

        const now = performance.now();

        this.frames++;

        

        if (now - this.lastTime >= 1000) {

            const fps = Math.round((this.frames * 1000) / (now - this.lastTime));

            // 如果 FPS 低于 24 或者 30，记录一次卡顿

            if (fps < 24) {

                reportToBackend({

                    metric: 'JANK',

                    value: fps,

                    page: window.location.pathname

                });

            }

            

            this.frames = 0;

            this.lastTime = now;

        }

        

        requestAnimationFrame(() => this.loop());

    }

}



new FPSMonitor().start();

最后是数据上报这块。千万别每产生一个数据就发一次请求，那样会把用户带宽跑死，而且后端压力也大。你在前端搞个队列，攒够一定数量或者隔个几秒批量发一次。到了数据库层面，建议用时序数据库（比如 InfluxDB）或者 ES 存这些指标，因为这种监控数据查询模式通常是按时间线看趋势，或者算分位数（P95、P99），MySQL 处理这种高写入和聚合查询会有点吃力。

这套方案虽然麻烦点，但胜在数据相对真实，能覆盖大部分机型。如果是特别关键的页面，建议再结合 Native 的 onPageFinished 和 WebView 的渲染回调做二次校验。