开销归因:可以量化的阻塞、路径差异与未知

可测的是实际占用的时间区间,不是“相同轨迹原本能多执行几个动作”的反事实。普通动作数量下降8.754%/16.401%,不能与prepare占预算2.949%/13.447%相减,再把差值称为页面开销比例。

A类:可确认的GUITaboo直接阻塞

semantic_prepare主调用链总墙钟由开始和prepare返回界定;其provider_wait是call.awaitUntil(deadline)前后System.nanoTime差,剩下是prepare本地/线程调度。每条审核满足prepare=evidence+await+other,且prepare+post=整体elapsed。全部Run日志的此守恒检查通过。计时本身是墙钟,不是CPU profiler。

App 条件 60分内prepare并集秒 占3600秒 accepted await秒 accepted本地秒 未被prepare占用的正常/未知秒
ODK Collect StartLux 10.736 0.298% 9.873 0.863 3589.264
ODK Collect Jev 73.686 2.047% 70.811 2.875 3526.314
Wikipedia StartLux 39.578 1.099% 35.369 4.210 3560.422
Wikipedia Jev 39.012 1.084% 35.008 4.005 3560.988
Scarlet Notes StartLux 150.822 4.189% 109.616 41.206 3449.178
Scarlet Notes Jev 1342.467 37.291% 1273.566 69.869 2257.533
Omni Notes StartLux 141.593 3.933% 114.423 27.170 3458.407
Omni Notes Jev 180.303 5.008% 152.592 27.711 3419.697
ActivityDiary StartLux 188.063 5.224% 146.559 41.504 3411.937
ActivityDiary Jev 784.973 21.805% 699.014 86.464 2815.027

“直接阻塞”不代表其中每一毫秒都可通过某个优化无损消除,也不代表每个等待都没有探索价值。Witness/Evidence复用所需成本与功能新颖性需结合决策报告判断。

B类:有证据的不同GUI路径工作

  1. Omni SL的7次异常与Pure/Jev各1次不同,且stack证明涉及takeVideo数字解析和exact alarm权限。恢复时长无完成边界,不能量化异常损失。
  2. Activity SL访问设置后触发4次超范围数字异常,而Jev没有崩溃;路径不同,不能把SL异常借用于解释Jev等待。
  3. 每条Run有不同FUZZ批次数、不同页面类、不同导航路径。FUZZ envelope和导航均可量出,但它们是粗区间且可能与审核重叠,不等于独立新增开销。
  4. Probe之后动作到GUI确认区间可定位,但可能包含FUZZ、页面等待、下一轮观测/选择及恢复。这个envelope不能全叫Probe绑定或执行CPU成本。

仍无法独立归因

导航特别口径

明确PROBE_NAVIGATION_SELECTED链接:SL20、Jev32路径。它们证明实际存在含Probe目标的导航事件,不能从Remote Greedy全部计数替代。路径可能同时含普通目标;没有反事实说明去掉Probe后该路径一定不会执行。probe_only、entry_id、start/end step、成功/失败、原始行号均保留于navigation-cost.csv。没有end回执的路径耗时应为NA,不能默认0。

为什么不做完整3600秒饼图

prepare是独立主线区间集合;其await/local是子区间。导航横跨动作与GUI;FUZZ→下一输入包住多个内部事件;动作→下次确认又覆盖执行和GUI;异常恢复可能包含在以上任意一个区间。把所有列相加会重复累计。唯一完整守恒表述是:prepare并集 + 3600减该并集 = 3600;后者必须标为普通执行与未细分工作,不能挪成“其它GUITaboo成本”。

来源:详细计时守恒验证、每分钟上下界、导航、FUZZ envelope、异常。