主线程本身无标准空闲率指标，其“空闲”实为消息循环中等待新消息的时长占比，需通过Hook Looper（Android）或监控run loop状态（iOS）间接统计，并结合卡顿率与FPS综合分析。
主线程本身没有“空闲率”这一标准指标，JVM 和操作系统层面不提供主线程空闲时间的直接统计。所谓“主线程空闲”，实际反映的是 UI 线程（Android 主线程）或事件循环线程（如 iOS 的 main run loop、JavaFX 的 Application Thread）在单位时间内未执行任务的时间占比——这需通过间接方式推算，且仅在具备消息循环机制的系统中可操作。
核心思路：基于消息循环周期反推空闲时间
Android 和 iOS 的主线程都依赖 Looper/Run Loop 机制分发消息。主线程“空闲”本质是 Looper 处于 等待新消息（queue.next() 阻塞） 的状态。因此，监控的关键不是“空闲多久”，而是：
- 测量两次消息处理之间的间隔时长（即“空闲窗口”）
- 统计单位时间内所有空闲窗口的总和，再除以总时长
- 需排除因 ANR、死锁、长时间同步阻塞等导致的伪空闲
Android 实操：Hook Looper.loop + BlockCanary
主流方案是利用 BlockCanary（开源库）或自定义 Looper Printer：
- 在
Looper.myLooper().setMessageLogging()中设置自定义Printer - 记录每次
dispatchMessage开始与结束的时间戳 - 当某次 dispatch 耗时 > 10ms，记为一次卡顿；若连续多次 dispatch 间隔 16ms 且无 dispatch，则视为有效空闲窗口
- 汇总 1 秒内所有空闲窗口时长，即可得该秒空闲率（例如：空闲 420ms → 42%）
iOS 实操：监控 main run loop 的休眠周期
iOS 没有公开 API 直接暴露 run loop 空闲时间，但可通过以下方式逼近：
- 使用
CADisplayLink或mach_absolute_time()定期采样当前 run loop 状态（如CFRunLoopIsWaiting()） - 结合
dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER)在主线程定时检查是否处于 wait 状态 - 避免轮询开销：只在关键路径（如页面展示后）开启短时采样（如 5 秒），统计 wait 状态出现频次与时长比例
- 注意：iOS 的 run loop 可能因 GCD barrier、dispatch_sync 到 main queue 等行为被人为唤醒，需过滤非自然空闲
生产环境落地建议
不建议将“主线程空闲率”作为独立告警指标，因其波动大、业务耦合深。更实用的做法是：
- 用空闲率辅助解释卡顿率（如空闲率高但卡顿率也高 → 存在非 Looper 路径的阻塞，如信号量、文件 I/O）
- 与帧率（FPS）联动分析：空闲率 > 80% 且 FPS
- 在灰度发布阶段对比空闲率分布变化，识别新代码是否引入隐式主线程抢占（如不当的 KVO、通知中心监听）
- 服务端无需关注此指标——主线程概念仅存在于客户端 UI 框架层
