uni-app无法直接获取CPU占用率，只能通过原生插件桥接（如iOS调用host_processor_info）或间接指标（如FPS、内存警告、console.time）推测；需注意系统限频干扰与采样合理性。
uni-app 里没法直接调用 navigator.hardwareConcurrency 或系统 API 获取 CPU 占用率
这是最常被误解的一点：uni-app 是跨端框架，App 端（iOS/Android）运行在 WebView + 原生容器中，而 Web 标准里没有提供实时 CPU 占用接口；H5 端更不可能拿到宿主设备的 CPU 使用率。所谓“获取 CPU 占用”，实际只能通过间接指标推测或依赖原生能力桥接。
- Web 标准中
navigator.hardwareConcurrency只返回逻辑 CPU 核心数，不是实时占用率 -
performance.memory在 H5 中多数浏览器已废弃或不可用，App 端也不暴露该字段 - uni-app 官方
@dcloudio/uni-stat和内置uni.getSystemInfoSync()都不包含 CPU 占用字段 - 真正能拿到 CPU 数据的，只有 iOS/Android 原生层（如 iOS 的
host_processor_info、Android 的Debug.getMemoryInfo+ActivityManager），必须走原生插件桥接
想监控 App 端 CPU，必须用原生插件 + JSBridge 方式接入
uni-app 官方性能监控模块（如 uni.getPerformance）目前仅支持页面渲染耗时、首屏时间等前端指标，CPU / 内存占用需自行封装原生能力。以 iOS 为例，你需要：
- 在 iOS 原生插件中调用
host_processor_info获取当前进程的 CPU 使用百分比（注意：需换算为 0–100 的整数） - 通过
uni.requireNativePlugin加载插件，并用callMethod触发采集 - 避免高频轮询：iOS 系统限制后台进程采样频率，建议间隔 ≥2s，否则可能被系统限频甚至拒绝响应
- 不要在
onShow或滚动中无节制调用——一次采集耗时约 3–8ms，叠加后会反向拖慢主线程
示例调用（假设插件名为 cpu-monitor）：
const cpuPlugin = uni.requireNativePlugin('cpu-monitor')
cpuPlugin.getCpuUsage({ interval: 3000 }, res => {
console.log('当前 CPU 占用:', res.percent + '%') // 如 { percent: 24 }
})
替代方案：用可量化指标「倒推」CPU 压力是否异常
与其执着于数字本身，不如盯住 uni-app 更易获取、且与 CPU 负载强相关的实际表现指标。这些数据开箱即用，无需原生开发：
-
uni.getPerformance().getFPS()：若 FPS 持续低于 50，尤其伴随卡顿，大概率是 JS 主线程过载（CPU 瓶颈） - 监听
uni.onMemoryWarning：内存告警往往伴随 CPU 高负载（GC 频繁触发） - 用
console.time包裹关键逻辑（如长列表 diff、图片 base64 解析），若单次 >50ms 就已构成阻塞 - 配合
uni.getSystemInfoSync().platform === 'ios'做平台判断，在 iOS 26 上特别关注Liquid Glass动效是否引发帧抖动（此时 GPU 负载高，但 CPU 也可能被拖累）
iOS 26 下监控要绕开 Adaptive Power 模式的干扰
iOS 26 的 Adaptive Power 模式会在电池温度高、电量低或后台任务多时，主动降频 CPU/GPU。这时你看到的“CPU 占用低”，可能是系统强制限频的结果，而非应用真地变轻量了。
- 测试前先检查设置 → 电池 → 低电量模式是否关闭；再进「设置 → 隐私与安全性 → 分析与改进 → 共享 iPhone 分析」打开，方便后续查
sysdiagnose日志 - 对比基线务必在同一台设备、同一系统状态（重启后 2 小时内、电量 >80%、无其他 App 后台运行）下采集
- 别只看平均值：用插件连续采样 30 秒，观察波动幅度——如果从 12% 突跳到 95% 再跌回 8%，说明存在短时密集计算（比如某个页面 onLoad 里做了未分片的数组遍历）
真正难的不是“怎么取数”，而是区分：这个 CPU 高，是业务逻辑真复杂，还是写了死循环、没做防抖、图片解码塞主线程？——数据只是镜子，照出问题，不代替排查。
