外观
2026-10-28 · 第二轮对照试用增量
默认工作台与原生报告现在使用应用CPU（整机100%）：原始cpuUsage / 样本显式CPUCount。这是展示派生presentation.process.cpu.device_capacity，版本process-cpu-device-capacity.presentation.v1，不是第67项Registry 指标，也不是频率/大小核算力加权。原始metricID与单核100%数值保留；非有限/负值、缺失或非法核数显示为空，缺失不补0，不按参考工具差值乘经验系数。默认均值是规范化产品序列有效点算术均值，含候选计数；Collector高频统计另列且不替代默认均值。GUI/原生CSV/PDF/历史摘要共享转换。旧逐事件CSV v4追加容量CPU、核数、原始刻度及逐点来源，原列不改。统计同义并不证明精度校准。
正式55/66、11项暂停不变。本批软件/主机证据不是新增真机验收。第二轮方案与实现。
APP CPU（目标进程 CPU 使用率）
2026-10-26 · 当前状态与CPU报告解释
进程CPU历史已验结论按Owner决定沿用，正式55/66、11项暂停；下方G132等是10月7日参考路线快照，不是当前锁定指标。500Hz双API参考五组成本1.25795%–1.34210%超原1%门，只证明该参考路线未准入，不能推断产品CPU错误或硬件不可实现。
本指标采用单核100%的进程累计时间口径，多核可超过100%；对比整机容量份额须核同窗有效核心数再归一化，不能假定所有设备都是6核。报告1Hz采样均值与Collector来源Stat先分别核窗口、点数和质量；用户试用反馈的CPU/内存统计差异与跨工具全面比对尚待逐源完成，当前不改数值或独立精度结论。计算对象与窗口 · 验收现状 · 月度实验复盘。
10月7日参考路线快照（保留历史数字）
2026-10-07 G132当前：目标App CPU为首项锁定，未验收交付前不转内存。旧ARM参考完整成本仍超1%，读取墙钟不当线程CPU成本，独立准确性及五轮0/5仍未完成；本批只复核旧数据及串行调度规则，未新增校准。记录。以下批次为历史。
2026-10-07 G130当前：ARM原生参考五组仍超1%且四组有漏点，CPU暂停同路径重复；基础内存来源下一，54完整仍0/54，Mac130保持。记录。
2026-10-07 G129当前：fresh隔离A/B各五组仍超原1%，前并发控制不是失败必要条件；原双API500与误差保持，下一ARM成本另立diagnostic而非host准入通过。CPU与54正式仍未验。记录。
2026-10-07 G128当前：完整原生双接口500Hz候选中位降低12.75%，但五组1.82265–2.07135%仍超原1%，未合入/设备准入；下一工具进程隔离，不放宽误差。CPU与54正式仍未验。记录。
2026-10-07 G127当前：公开RUSAGE_INFO为Mach ticks/recount同族；host五组500Hz全1000点/0miss、完整成本1.08915–1.1166%仍超1%，设备参考未准入。CPU与54正式仍未验。记录。
2026-10-07 G126当前：公开processclock为getrusage同源包装，host603观察/1000诊断点不证独立准确性；不准入新参考，下一真正聚合API资格。CPU与54正式仍未验。记录。
2026-10-07 G125当前：实际目标8component/1fullcandidate完成，differentQoS 完整成本1.4023%超原1%，参考仍未准入；下一processclock仅语义资格，非CPU数值已验。记录。
2026-10-07 G124当前：完整私有buffer候选仅0.306476% host收益，未实施、不调用设备；实际参考原成本仍拒绝，CPU数值与正式五轮仍未验。记录。
2026-10-07 G123当前：工具UI隔离/stop后copy已修，实际五组new完整但成本1.3431–1.47525%超原1%；仍未证明产品CPU准确或五轮通过。记录。
2026-10-07 G122当前：目标Observer首次因工具UI隔离缺陷/64MiB硬门停止，new500未执行；只自身退出与config恢复，下一修工具隔离，不推CPU数值可信或五轮通过。记录。
2026-10-07 G121当前：host默认QoS候选1.9841%仍超1%，不实施该修复；host x86_64结果不替代真实ARM64设备扰动，下一专用observer成本测试保持原1%，尚不采产品指标。记录。
2026-10-07 G120当前：完整高密参考开销较冻结调度约减半，但1.88–2.12%仍超1%，未上手机；27/288工具与取消收尾通过只属E2参考准备，原产品CPU/54五轮门未关。记录。
2026-10-07 G119当前：默认关闭的高密整数参考功能E2通过，但完整writer开销3.47–3.94%超1%门，未上手机；不证明产品数值错误或已可信。130保持，下一低开销调度修复，原54/五轮100%不变。记录。
2026-10-07 G118当前：内部130已修CPU来源停止仍旧candidate的质量缺陷；每条独立真实source最多发布一次、超3I或无新观察明确missing 。此不是连续100%或数值校准通过；原500ms/54/5%和真实读点门不变。记录。
2026-10-07 G117当前：b129新同life对照固定240/240数值候选不等于新来源连续100%；9000双API参考55/253源窗相容、读点/参考精度未准入。实际hostprojector在sourcequiet合成30/600s仍旧CPUcandidate，质量expiry/token缺陷已证；原始cpuUsage公式、scope、单位与冻结5%门不变。记录。
当前共享采集源（2026-10-07 G84）：产品 SysmontapRawAdapter._make_stream 先用同一个 pymobiledevice3 原生 DeviceInfo 查询时钟与支持列，再用原生 Sysmontap 构造器建立完整14消费者固定依赖闭包（11进程列、3系统列）；默认 intervalMs=500、ur=500 ms、sampleInterval=500000000 ns，保留CPU元数据与原生时钟。必需列缺失、非法类型或重复时明确失败，不以减少指标、补值或旧值续点降级。此为采集配置修复，不改变本页数值公式、scope、单位、质量/候选标签与独立误差门；完整54项与正式五轮仍待验，源码/安装验证不等于本指标数值校准。方案与验证。
作用域属性：[进程级 · 目标 App 专属]（Process Scope ）
APP CPU 衡量的是目标被测应用进程的 CPU 使用率，采用多核未归一化累加口径：单个 CPU 满载份额约为 100%，多个 CPU 上并发执行时数值可以超过 100%。该指标严格经过目标 PID 过滤，但仅凭这一个数值不能定位到具体线程或代码路径，需要结合调用栈、Instruments Time Profiler 等证据。
一、 指标核心规范
| 属性项 | 规范定义 |
|---|---|
| metricID | ios.process.cpu.non_normalized |
| 界面显示名 | APPCpu |
| 作用域 (Scope) | process（目标进程专属，排他性统计） |
| 测量单位 (Unit) | percent（百分比 %） |
| 底层系统服务 | com.apple.instruments.server.services.sysmontap (DVT DTX 传输通道) |
| 底层来源字段 | Processes[target_pid].cpuUsage |
| definitionVersion | 2（当前 Registry；直接原生 gauge，校准仍 pending） |
| 多核计算口径 | 传统多核未归一化累加口径（单核满载为 100%，多核并发可超过 100%） |
二、 为什么 iOS APP CPU 可以超过 100%（以及不能由此得出什么结论）
- 单个 CPU 满载份额约为 100%：在当前未归一化统计口径中，一个 CPU 持续满载可贡献约 100% 的使用率。这里描述的是统计口径，不是“芯片算力”的物理单位。
- 多核并发累加：若 App 的多个线程同时在多个 CPU 上持续执行，APP CPU 可以出现约 200%、300% 等数值；若设备有 6 个有效 CPU，聚合值在极端情况下可以接近 600%。这说明统计口径允许超过 100%，不代表异常，也不表示不同核心性能完全等价。
以下两种常见解读都不是可以直接下的结论，只是需要交叉验证的候选方向：
- APP CPU 恰好在 100% 附近形成平直横线：可能提示某个单一线程（含主线程）被计算占满，是候选的单核瓶颈信号，但需要结合线程级证据（Thread Count、调用栈）确认具体是哪个线程，不能仅凭这条横线断定"主线程死锁"。
- APP CPU 超过 100%（如 150%~250%）：不能直接解读为"App 正在良好利用 GCD 多线程并发"——也可能是无效并发（过度加锁导致的忙等、冗余重复计算、未加限流的并发任务）。是否"良好利用"取决于业务预期与实际吞吐，不能仅凭数值本身判断。
三、 双级背离诊断指南（APP CPU vs TotalCPU）
排查性能问题时，建议将 进程级 APP CPU 与 设备级 TotalCPU 对照分析：
| 观测组合 | 进程级 APP CPU | 设备级 TotalCPU | 候选原因（需交叉验证，不是确诊） | 测试建议与处理动作 |
|---|---|---|---|---|
| 代码过载候选 | 持续极高（如 180%） | 持续高位 | 提示 App 自身 CPU 使用率高，可能是后台并发、密集正则或循环；仅凭 CPU 不能定位到具体线程或代码路径。 | 导出 Session，用 Time Profiler / 调用栈证据定位热点函数后再提单。 |
| 环境干扰候选 | 很低（如 10%） | 持续满载（如 95%） | 提示系统或其他进程负载较高（如相册分析、iCloud 备份），但不能排除同窗内被测 App 之外的其他因素。 | 清理后台、复测，比较同场景历史分布后再下结论。 |
| 单核瓶颈候选 | 恒定在 100% 左右 | 中等（如 120% / 6核机） | 提示某类计算可能持续占用约一个 CPU 满载份额；Per-CPU 数据是 device scope，不能直接证明是目标 App 的哪个线程。 | 结合线程级证据或 Time Profiler 确认后再判定优先级。 |
| 热压力影响候选 | 相对不高（如 40%） | 居高不下伴随帧率明显下降 | 提示热状态变化可能参与性能下降，但 Thermal Status 也不等价于“已经发生具体降频”。 | 检查 Thermal Status（证据可信时）并在冷却后复测对比。 |
四、 怎样建立团队自己的 CPU 回归基线
Perfowl 不提供跨 App、跨设备通用的 CPU Pass / Warn / Fail 数字。更可靠的方法是固定设备、iOS、构建类型、业务脚本和运行条件，重复执行足够轮次后保存 APP CPU 的 P50 / P95 / 峰值、持续时间与质量状态分布。
- 静置场景：关注是否相对历史基线出现新的持续后台计算，并结合 Wakeup / Thread Count 判断是否存在新的周期任务。
- 滑动与动画：关注 APP CPU 与 FrameTime / FPS 是否在同一时间窗出现新的相关性，而不是用一个百分比阈值直接判断好坏。
- 计算/加载场景：关注高负载持续时间、任务完成时间和吞吐是否一起变化；更高 CPU 也可能是在更短时间完成更多工作。
- 正式 SLA：如果团队需要阈值，应从自己的稳定历史分布、设备矩阵和事故数据冻结，并记录适用范围与版本，而不是把经验数字当作 iOS 物理标准。
五、 底层采集与身份保护机制
- 目标身份绑定：Perfowl 通过
ProcessControl与DeviceInfo.proclist解析所选应用的真实 PID，核对可执行文件路径，避免同名进程混淆； - 进程重启代际隔离：若被测 App 崩溃重启导致 PID 变化，Perfowl 重置代际（Generation）序列，不跨进程代际混算 CPU 时间；
- 零值与缺失区分：目标 App 确实处于完全静止无计算状态时，数值合法为 0；若目标进程丢失或未识别，输出为
missing（不写 0）。
六、 采集技术溯源与数据质量（十要素）
| 要素维度 | 详细规范与技术证据 |
|---|---|
| 定义与概念 | 衡量目标被测应用进程的 CPU 使用率；采用多核未归一化口径，仅凭该值不能定位到具体代码路径 |
| metricID / scope / 单位 (unit) | ios.process.cpu.non_normalized / process（进程级）/ percent（百分比，单核 100%） |
| 底层系统服务与通信通道 | 系统服务 com.apple.instruments.server.services.sysmontap，通过 DTX 通道 |
| 采集命令与调用实现 | pymobiledevice3 原生 Sysmontap(provider, process_attributes, system_attributes, interval_ms=intervalMs) 调用；MacApp/Sidecar/perfowl_collector_core/metric_engine.py::MetricEngine._process_metrics 按目标 PID 过滤读取 cpuUsage 字段（第 332 行） |
| 计算方式与精确公式 | APPCpu = row.cpuUsage（sysmontap 已按进程聚合的瞬时 gauge，Perfowl 不做二次求和） |
| 数据质量语义 (含 missing) | 身份/来源版本核同、有限非负数、独立新source token与hostreceipt年龄≤1.5s才为candidate；重复/过期/无源/非法值输出null与missing等原因质量，不补0；未证device读点，candidate不代表独立准确 |
| 当前校准状态与证据等级 | 依附于 CPU 联合采集会话获得多轮真机数据，证据等级 E2/E4 混合，尚无以本指标单独为核心的专项 E4 校准批次 |
七、 独立累计 CPU 窗口对照（2026-10-04，局部证据）
产品仍直接保留 sysmontap cpuUsage，不因对照结果缩放它或补源缺值。自有 Fixture 默认关闭的验收模式记录 50Hz getrusage 与 TASK_ABSOLUTETIME_INFO，每个累计读值 C_i 带真实设备 Mach 读取区间 [b_i,e_i]、返回码和 timebase；不是商店 App 内嵌 SDK，也不是产品 CPU 来源。
对源窗口 [a,z]，仅接受同一自身进程/代际与实测时钟、有限单调累计值：
L(t)= 最后一个e_i ≤ t的累计值；U(t)= 首个b_i ≥ t的累计值；两侧实际间隔须 ≤60ms，否则参考为unknown。d = (z-a) × numer / denom / 10^9秒；getrusage微秒/10^6，TASK ticks×timebase/10^9。- CPU 区间 =
100 × [max(0,L(z)-U(a)), U(z)-L(a)] / d。不插值、不按名义槽造样本。 - 区间宽度仍须 ≤中点×5%；但源值落在向外扩大5%的范围只是旧诊断，不足以验收。冻结容差a=5e-7个百分点、q=0.05，对所有可能参考r∈[L,U]要求
abs(x-r) ≤ max(a,q*r)；等价于源值在[U-max(a,q*U), L+max(a,q*L)]的交集内，交集空则不通过。零负载须实上下界均0，源缺值不补0。两个API各自判定，不把API一致当全部场景真值。 - G37记录Double域与UInt64/timebase差分采用精确有理数/等价整数比值，不插值；记录值域不证明内核量化误差或未取证的身份/时钟/API语义。工具明确
physicalCalibrationPassed=false，完整测量窗与独立物理校准仍另验。
2026-10-04历史两轮（当时旧宽判据）分别 119/141、126/139 个源窗口满足双 API 窄区间候选；仍有源缺值及参考不确定窗。本指标完整测量窗、五轮100%及其它指标的独立校准仍未通过。这比 1Hz 近邻比较更有边界，但不是调整产品数值迎合参考。方案/失败与结果
2026-10-05 G37参考准入收紧（产品CPU值不变）
原G14A140来源配对/9000独立参考全部保留：旧工具反事实复算双API可接受窗117，新判据116，仅一个来源窗撤回，1个缺值与所有不通过窗仍在分母。合成10.59的原可接受范围可能产生约7%误差，现按冻结5%和绝对容差的交集拒绝；这修的是验收工具，不证明真实产品CPU错。历史数字/报告不回改，原设备的全五轮100%与独立精度仍未过。原理、资源与证据边界。
八、 版本历史
| 版本 | 日期 | 修订要点 |
|---|---|---|
| v8（当前） | 2026-10-07 | G118 CPU独立6FIFO/3I/原source token一次发布，拒sourcequiet伪续点；内部130安装E3，公式/definitionVersion2与独立误差不变，校准仍pending。批次。 |
| v7 | 2026-10-05 | G37独立参考准入合并不确定性与冻结误差门；整数比值保持精确；definitionVersion按真实Registry更正为2，产品值与旧数据不改。 |
| v6 | 2026-10-04 | 增加独立累计CPU保守上下界与50Hz参考质量；仅局部候选对照，未升级整体校准。 |
| v5 | 2026-09-18 | 审计收口：删除示例百分比阈值表，改为同设备/同系统/同脚本历史分布基线与团队 SLA 冻结方法。 |
| v4 | 2026-09-18 | 清理文件中重复/损坏的历史段落；修正“良好利用 GCD”等确定性因果表述为候选解释；补充精确源码引用与 definitionVersion。 |
| v3 | 2026-09-15 | 全面转向性能测试工程师实战视角：补充大小核调度概念、双级背离诊断表、测试防干扰要求与 QA 缺陷提单基线。 |
| v2 | 2026-09-08 | 统一指标注册表与数据流定义。 |
| v1 | 2026-09-04 | 首次发布 APP CPU 指标定义与底层采集规范。 |
采集源版本更新 · 2026-10-07
G84将SDK全列factory改为固定共享11+3列、输出与采样节拍一致；原生服务/DTX通道不变，支持列仍由SDK查询，传输及指标转换为Perfowl适配层，SDK来源和自研计算分开。初missing、counter warmup/reset、VM近似质量等原边界保留，不外推其他设备/场景持续100%。来源批次。
来源新鲜度与独立参考边界 · 2026-10-07（G117）
当前129的共享配置请求250ms采集/500ms发布（G104），原G84的500/500条为历史；实际频率须看Raw，参数不是保证。CPU snapshot从原cache读取，当前没有独立CPU源token/过期拒绝，来源停止仍可能长期candidate；因此不能只依据出现数值来证明可用或连续100%。一次同life9000双API新参考与253Raw窗比较只有55同时相容，50Hz端点区间过宽与真实CPUaccounting读点未证分别登记；不将不确定性失配称为数值必错，也不放宽5%误差。
| sourcequiet质量缺陷/参考未准入（G117） | 2026-10-07 | E2真实projector反例；E4仅一次新life/9000参考，240numeric非100%可信；父子结果文件名碰撞partial保留，正式0/5。记录。 |
发布来源保全更新 · 2026-10-07（G118）
数值仍APPCpu=row.cpuUsage、process/percent/definitionVersion2；CPU自身6FIFO与内存互不共享消费token，(目标/来源epoch/reconnect/sequence/hostreceipt)严格准入，原receipt age≤3×500ms=1.5s含边界。真实0合法，null/Boolean/非有限/负值拒绝；过期/重复/错误绑定/无新Raw绝不继承旧CPUcandidate。原Raw/derived数字不改，CPUwire新增cpu-usage-source-freshness.v1并保存原source token/receipt及丢弃计数，deviceReadPointProven=false。E2反例/130专项组合/1703复核与历史回放、E3内部130唯一签名安装；未新增真机同窗参考，独立精度与五轮100%仍pending。记录。
独立参考资格更新 · 2026-10-07（G119）
参考以真实整数累计CPU与Mach readbrackets计算上下界（公式同§2合同），旧Oracle误差不改。新默认OFF500Hz参考功能已E2检验，但完整writer每组1%扰动门失败、未准入真实手机校准；不改变APPCpu来源/公式/质量版本，也不把合成一致当精度。来源。
独立参考资格更新 · 2026-10-07（G120）
短命Mach绝对等待降低真实完整writer成本，但仍超每组1%，没有进入设备校准。原getrusage整数与task ticks/readbrackets/Oracle公式/5%容差、产品APPCpu公式/质量版本均不变。参考能力与真实指标精度/连续性须分开，当前accepted0/54。来源。
独立参考资格更新 · 2026-10-07（G121）
host成本与实际目标设备扰动应分列；本次不同QoS完整candidate仍1.9841%拒，未校准CPU指标。下一只Observer真实目标对照仍要求500Hz/每组1%，不提高预算或降低独立误差；此前host失败保留，产品公式/来源/质量版本不变。来源。
独立参考资格更新 · 2026-10-07（G122）
实际目标observer仅观察到首old件，硬内存门停止、新500未执行；工具界面额外渲染未被专用模式隔离，须先修工具，不把失败当产品CPU必错或已校准。产品CPU公式/来源/质量算法不变，完整54与固定窗口误差/连续有效目标仍未验。来源。
独立参考资格更新 · 2026-10-07（G123）
自有Observer隔离与取证已修，五组10真实文件full reader过、RSS低于原64MiB，但new完整processCPU/原2s为1.3431–1.47525%超1%，参考成本资格仍拒绝；样本1000/997/997/997/997、真实漏槽0/3/3/3/3，不把完整文件当连续真值。产品公式/质量口径不改，无产品数值准入或正式轮完成。来源。
独立参考准备更新 · 2026-10-07（G124）
完整定长buffer候选原数学/reader控制合格但host实测不足预设收益门，未实施/未调用设备；不得据此宣称产品CPU改善或平台不可达。实际旧APIwall/handlerwall仅时长计数，不是CPU排他归因。现有数值公式/质量口径、全部54和100%目标不变。来源。
独立参考成本诊断 · 2026-10-07（G125）
真实组件不相加CPU归因；静态idle0.04465%、differentQoS full1.4023%仍超原1%，未更新产品算法或已准入参考。SDK processCPUclock声明不等于runtime或精度、来源独立性证明。普通CPU公式/质量不变，全部54与原误差/固定窗口五轮目标未通过。来源。
来源独立性澄清 · 2026-10-07（G126）
SDK纳秒格式/availability/clock_getres不等于真实精度或设备支持；已取回公开Apple Libc的processclock直接包装RUSAGE_SELF，不能作为独立于rusage的第二真值。host完整idle/单worker/双worker均一致不证产品准确；0.9156%仅open后诊断成本，不完整原门准入。原产品公式/误差/54/正式五轮目标保持。来源。
参考单位与独立性 · 2026-10-07（G127）
公开XNU RUSAGE_INFO的CPU整数并非名字暗示的纳秒：原release taskpower/recount链为Mach ticks，先完整timebase整数换算、溢出拒。getrusage/task/proc共recount家族，交叉API不作为独立底层仪器；独立于产品collector的参考须另证scope/读点/误差。host五组完整dual仍>1%，未准入设备，不改产品CPU公式/质量或原54五轮门。来源。
参考实现与证据密度保全 · 2026-10-07（G128）
原self getrusage/task两个实际入口仍每点500Hz；候选只私有C ABI/原子取消/定长buffer/更宽保守bracket。原完整reader/27+288通过不代表全部产品窗口通过；12.75%改善仍超1%，未修改产品或准入参考，不放宽原5%/54/正式五轮。来源。
工具状态与目标硬件区分 · 2026-10-07（G129）
相同sampler/CABI的新fresh实验仍超1%，不能把前控线程当已证唯一根因、扣CPU或以host推断ARM必然失败。原host资格维持FAIL、下一真实ARM仅另立成本诊断，原reference两个实际入口500Hz/5%窗口与指标公式不变。来源。
真实ARM参考成本限制 · 2026-10-07（G130）
自有App双API原生500Hz五组完整成本仍1.25795–1.34210%超1%，四组实际miss2，未准入CPU参考，更不是产品数据已校准。只增加默认OFF成本诊断，不修改原CPU公式。暂停同路径重复、转基础内存来源；新机制证据再恢复CPU。来源。
版本历史增量：2026-10-26，澄清历史验收沿用、参考工具成本与报告统计对象；E1文档复盘，公式和实现不变。
版本历史增量：2026-10-28，第二轮内部试用口径、来源及报告边界更新；E2/E3与待测E4分列。第二轮方案与实现。