table2 raw events · 原始数据快速可视化工具

table2原始事件交互式时间轴

横轴是时间(毫秒精度,默认展示全部数据范围,滚轮缩放到任意粒度),背景浅色带是基于 日出日落动态划分的8时段(late_night/dawn/morning/forenoon/noon/afternoon/evening/night, 仅内置演示数据有,本地导入的文件没有预算好的城市坐标,背景色带会跳过不画)。 纵轴从上到下10行:通知(10空心/12实心点)、 锁屏区间(17→18,黑色块)、息屏区间 (16→15,灰色块)、悬浮窗(19→20, app同色块)、前台1/暂停2/退出23三行都是原始事件时刻点图(不做合并), 推测前台使用(跟build_v6.R的v9算法完全同步的JS移植版:page配对 只用own自己的1→own下一个2,23完全不参与——23经常被系统延迟触发, 触发时机跟"此刻屏幕上是不是它"无关,只有2才是可靠、及时的"失去前台"信号。窗口 (own-1, own-2]内如果被息屏/锁屏(A)、别的app的genuine 1(B)、同一个app 别的page的genuine 1(D)三类候选中最早发生的抢先插入,就提前截止;此外,如果这个候选 own2其实在下一次同page own-1打开之后才到,说明它早被"下一次打开"抢先了(E, 占比约0.03%),当前这次不消费它,留给后面那次own-1去认领。own事件不做任何 "整行去重"、并列时间戳也不做人为打散——原始日志写了几条1就当几次独立的开, 顺序完全信任原始写入顺序(真实案例验证过:整行去重会把系统桌面Launcher"1,2,1" 三连同一毫秒里第二次真实24秒的使用吞掉)。own自己的2如果压根没触发(不是延迟, 是真的没有),原本会被判E_superseded/F_无own2——这时候退而求其次找own自己的23 当窗口右边界(23虽然经常被系统延迟触发、不适合当主配对依据,但至少比"下一次 重开"这种明显不相关的东西可靠),重新走一遍同一套A/B/D窗口搜索,还是没找到才 兜底成C23_own23(小红书NoteDetailActivity真实案例验证:own2从未出现,原逻辑 拉伸到15小时后的重开,修复后正确识别出103.4秒后被系统桌面Launcher接管)。不做 任何合并——"要不要把两段算成一次连续使用"是下游算特征时才需要的700ms阈值, 不属于这一步)、 规则判定(A/B/D/E四条固定子行,各自标出被对应规则截止的段——C(own自己的2) 和C23(own自己的23兜底)两种"没被外部东西截止"的默认情况都不标)、最下一行 ⚠规律冲突只标own2和own23都没有的情况(F_无own2,占比极低),这才是真的 "算法解释不了"、需要人工去查的——通常是数据集尾部边界正常截断,不在尾部才值得 深挖(E跟F不同:E的成因明确——被同page重开取代——所以放在规则判定行,不算规律 冲突)。前台1到own自己的2之间用细虚线连起来(cat=C_own2的才有连线,A/B/D/E/C23 是被别的东西截止/取代或走了23兜底,没有own自己的2可连);2到23的补充连线也保留, 方便看某次2最终对应哪个(经常姗姗来迟的)23。颜色按app名称区分(89种,前30个独立色, 其余长尾统一灰色;主流app用品牌色)。滚轮缩放、拖动平移、下方缩略图快速跳转, 图例可多选叠加高亮对比多个app,键盘可精确导航(见下方提示)。