HarmonyOS 7 新特性1：闪控窗——轻规划里的专注倒计时，跟着你走出应用

HarmonyOS 7 新特性1：闪控窗------轻规划里的专注倒计时，跟着你走出应用

文章目录

[HarmonyOS 7 新特性1：闪控窗------轻规划里的专注倒计时，跟着你走出应用](#HarmonyOS 7 新特性1：闪控窗——轻规划里的专注倒计时，跟着你走出应用)
- - - 1、引言
    - 2、效果展示与项目结构
    - 3、Kit能力与核心API深度解析
    - - [3.1 先选型：离开应用还能看到进度，有三条路](#3.1 先选型：离开应用还能看到进度，有三条路)
      - [3.2 floatView 全生命周期 API 面](#3.2 floatView 全生命周期 API 面)
    - 4、逻辑流梳理
    - 5、项目实战
    - - [5.1 相位机与线程投递](#5.1 相位机与线程投递)
      - [5.2 创建链路与取消路径](#5.2 创建链路与取消路径)
      - [5.3 外部审查揪出的三个真问题](#5.3 外部审查揪出的三个真问题)
      - [5.4 真机三场景实测](#5.4 真机三场景实测)
    - 6、避坑指南
    - - [6.1 引擎回调直写 @State 不刷新](#6.1 引擎回调直写 @State 不刷新)
      - [6.2 @Builder 按值传参冻结](#6.2 @Builder 按值传参冻结)
      - [6.3 首次授权后悬浮窗静默缺席](#6.3 首次授权后悬浮窗静默缺席)
      - [6.4 创建期间结束专注 → 孤儿悬浮窗](#6.4 创建期间结束专注 → 孤儿悬浮窗)
    - 7、总结

1、引言

我的日规划应用「轻规划」里，专注模式是使用频率最高的功能：从今日任务里挑一条，点开始专注，倒计时一转就是二十五分钟。但它有个我一直没忍的老毛病------倒计时只活在应用里。上周写周报，专注到一半切回微信回条消息，顺手刷了两下，再回来看不到剩余时间，心里完全没底：这轮到底还剩多少？是继续还是作废？

放到系统层面看，这是个经典诉求：离开应用主界面，状态还得盯得住 。常驻通知刷新不及时，占着通知位体验也差。HarmonyOS 7.0 (API 26) 的发布说明里新增了一个正好对症的能力------闪控窗（floatView），官方描述是「悬浮在桌面/应用界面上的小型窗口」，支持创建控制器、启动、更新、停止，退到后台后仍可在前台显示。

这篇就是把它搬进轻规划专注模式的完整记录：从悬浮方案选型、API 面解析，到相位机与线程投递的工程化实现；外加两段真刀真枪的排错------一层引擎回调线程直写状态不刷新的响应式坑，和一个首次授权后的时序竞态------全部带真机实测证据。

2、效果展示与项目结构

先交代载体。本篇用一个「轻规划（特性版）」工程承载特性：以我自己的轻规划为蓝本搭产品骨架------今日 / 专注 / 统计 / 我的四个 Tab，任务与统计数据走 Mock；专注执行页是全应用唯一真实功能链路，真实接入闪控窗。Mock 与真实的边界在代码里是物理隔离的：假数据集中在一个 model 文件，真链路全部收在专注页。

今日页长这样，每条任务都可以直接「开始专注」：

切到专注页，启动前会如实显示探测与授权状态（下图是刚重置权限后的未授权态，绿色/黄色状态行是排查时的第一现场）：

点「开始专注」，系统弹窗申请 FLOAT_VIEW 授权，允许之后引擎回调确认 STARTED，悬浮专注卡就出现了------任务名、剩余时间、进度、引擎状态四行实时跟随：

工程结构增量如下，闪控窗相关的都收在 sparkwindow 目录，专注页只表达业务意图：

text 复制代码

entry/src/main/ets/
├── pages/Index.ets                       // 四 Tab 主框架，@StorageLink 同步跨页切 Tab
├── pages/SparkFloatCard.ets              // 悬浮窗 @Entry 薄壳（路径必须与 main_pages.json 一致）
└── features/
    ├── model/PlanMock.ets                // Mock 数据层（任务/统计，物理隔离）
    ├── focus/FocusView.ets               // 专注执行页：计时状态机 + 闪控窗真链路
    └── sparkwindow/
        ├── FloatCardView.ets             // 悬浮专注卡内容（跨窗口读 AppStorage）
        └── model/SparkErrorMap.ets       // 官方错误码/状态/停止原因的可读映射

3、Kit能力与核心API深度解析

3.1 先选型：离开应用还能看到进度，有三条路

动手前我先把「离开应用还能看到状态」的可行路径摆一遍，结论直接决定了后面的工作量：

方案	版本与权限	能否实时刷新	主要代价
闪控窗 floatView	26.0.0 新增；`ohos.permission.FLOAT_VIEW`，user_grant，运行时申请即可，不需要 ACL 证书	能，自绘页面随便画	要自己管生命周期、回调与降级
全局悬浮窗 `TYPE_FLOAT`	老能力；`ohos.permission.SYSTEM_FLOAT_WINDOW`，受控开放，须在 AGC 申请 ACL 权限证书，且仅 PC/2in1	能	未申请证书却声明权限，应用直接安装失败；手机端不可用
常驻通知	全版本可用；无特殊权限	不能实时刷新文本	只能展示静态摘要，点按跳转后还是要回应用看

我的场景是手机上的专注倒计时，逐秒刷新、跟随整个专注周期。全局悬浮窗在手机上直接出局；通知刷新不了秒级倒计时。在本文比较的三种方案内，闪控窗是同时满足「手机可用 + 无需证书审批 + 实时自绘」的选择------尤其它属于 user_grant 权限，不卡 AGC 证书排期，这点对我这种独立开发者非常友好。

要注意一个容易混淆的点：闪控窗和全局悬浮窗虽然都叫「悬浮」，但它们是两套独立的 API、两种不同的权限模型，官方文档里分属不同章节，混着查会走弯路。

3.2 floatView 全生命周期 API 面

闪控窗挂在 @kit.ArkUI 里，起始版本 26.0.0，系统能力为 SystemCapability.Window.SessionManager（建议先 canIUse 判断），仅 Stage 模型。核心调用链按生命周期走：

isFloatViewEnabled(): boolean ------ 能力开关查询，探测的第一道闸
create(config: FloatViewConfiguration): Promise<FloatViewController> ------ config 里的 context 必须是有效 UIAbilityContext
controller.setUIContext(path) ------ 挂内容页，path 必须与 main_pages.json 注册的 src 完全一致，否则 1300016
getFloatViewLimits(templateType) ------ 取尺寸上下限，单位是 px 不是 vp
controller.setWindowSize(size) ------ 官方建议先取 limits 再设置
controller.start() ------ 返回不等于成功，必须等 onStateChange 收到 STARTED 才算真正启动
controller.stop() ------ 停止后同样靠回调确认
on/offStateChange、on/offRectChange、on/offLimitsChange ------ 三个回调对应状态、矩形、限制变化，off 要成对释放

状态枚举 FloatViewState 有六个值：STARTED、HIDDEN、STOPPED、IN_SIDEBAR（侧边栏暂存）、IN_FLOATING_BALL（切为闪控球）、ERROR。停止时携带 stopReason，我实测收到了 TITLE_BAR_STOP_CLICK（用户点标题栏 × 关闭）------外部关闭的路径系统会主动通知，应用侧必须把这个状态接住。

几个硬约束直接写进了错误码，开发前最好背下来：

错误码	含义
201	FLOAT_VIEW 未授权
801	设备不支持该能力
1300016	模板类型/页面路径/窗口尺寸非法
1300030	重复操作（重复注册回调、重复启停）
1300031	当前状态不支持该操作
1300032	恢复主窗失败（要求 STARTED 且用户曾点击过闪控窗）
1300033	同应用只能启动一个闪控窗
1300034	与闪控球/画中画冲突

以上 API 面与错误码逐条对照官方《API 参考 js-apis-floatview》与对应开发指导（26.0.0），均可回溯。

4、逻辑流梳理

把整个专注周期和闪控窗生命周期叠在一张图上，箭头上的每一步我在真机日志里都能对上一条记录：
#mermaid-svg-IBepSMy6ZOorsihv{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-IBepSMy6ZOorsihv .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-IBepSMy6ZOorsihv .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-IBepSMy6ZOorsihv .error-icon{fill:#552222;}#mermaid-svg-IBepSMy6ZOorsihv .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-IBepSMy6ZOorsihv .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-IBepSMy6ZOorsihv .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-IBepSMy6ZOorsihv .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-IBepSMy6ZOorsihv .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-IBepSMy6ZOorsihv .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-IBepSMy6ZOorsihv .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-IBepSMy6ZOorsihv .marker{fill:#333333;stroke:#333333;}#mermaid-svg-IBepSMy6ZOorsihv .marker.cross{stroke:#333333;}#mermaid-svg-IBepSMy6ZOorsihv svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-IBepSMy6ZOorsihv p{margin:0;}#mermaid-svg-IBepSMy6ZOorsihv .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-IBepSMy6ZOorsihv .cluster-label text{fill:#333;}#mermaid-svg-IBepSMy6ZOorsihv .cluster-label span{color:#333;}#mermaid-svg-IBepSMy6ZOorsihv .cluster-label span p{background-color:transparent;}#mermaid-svg-IBepSMy6ZOorsihv .label text,#mermaid-svg-IBepSMy6ZOorsihv span{fill:#333;color:#333;}#mermaid-svg-IBepSMy6ZOorsihv .node rect,#mermaid-svg-IBepSMy6ZOorsihv .node circle,#mermaid-svg-IBepSMy6ZOorsihv .node ellipse,#mermaid-svg-IBepSMy6ZOorsihv .node polygon,#mermaid-svg-IBepSMy6ZOorsihv .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-IBepSMy6ZOorsihv .rough-node .label text,#mermaid-svg-IBepSMy6ZOorsihv .node .label text,#mermaid-svg-IBepSMy6ZOorsihv .image-shape .label,#mermaid-svg-IBepSMy6ZOorsihv .icon-shape .label{text-anchor:middle;}#mermaid-svg-IBepSMy6ZOorsihv .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-IBepSMy6ZOorsihv .rough-node .label,#mermaid-svg-IBepSMy6ZOorsihv .node .label,#mermaid-svg-IBepSMy6ZOorsihv .image-shape .label,#mermaid-svg-IBepSMy6ZOorsihv .icon-shape .label{text-align:center;}#mermaid-svg-IBepSMy6ZOorsihv .node.clickable{cursor:pointer;}#mermaid-svg-IBepSMy6ZOorsihv .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-IBepSMy6ZOorsihv .arrowheadPath{fill:#333333;}#mermaid-svg-IBepSMy6ZOorsihv .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-IBepSMy6ZOorsihv .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-IBepSMy6ZOorsihv .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-IBepSMy6ZOorsihv .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-IBepSMy6ZOorsihv .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-IBepSMy6ZOorsihv .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-IBepSMy6ZOorsihv .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-IBepSMy6ZOorsihv .cluster text{fill:#333;}#mermaid-svg-IBepSMy6ZOorsihv .cluster span{color:#333;}#mermaid-svg-IBepSMy6ZOorsihv div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-IBepSMy6ZOorsihv .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-IBepSMy6ZOorsihv rect.text{fill:none;stroke-width:0;}#mermaid-svg-IBepSMy6ZOorsihv .icon-shape,#mermaid-svg-IBepSMy6ZOorsihv .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-IBepSMy6ZOorsihv .icon-shape p,#mermaid-svg-IBepSMy6ZOorsihv .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-IBepSMy6ZOorsihv .icon-shape .label rect,#mermaid-svg-IBepSMy6ZOorsihv .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-IBepSMy6ZOorsihv .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-IBepSMy6ZOorsihv .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-IBepSMy6ZOorsihv :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 否
是
否
拒绝
允许
是
创建期间点了结束
每个 await 后校验
STARTED
STOPPED
ERROR
开始专注 startFocus
探测 probeOk?
显式降级：专注照常
已授权?
requestPermissionsFromUser
phase = CREATING
create
setUIContext
setWindowSize
start
stopRequested = true
abortCreating：stop + 释放
onStateChange
悬浮跟随：每秒写 AppStorage
释放控制器，phase = IDLE
专注结束 finishFocus
stop

图上有两条经验值得单独说，都是真机踩出来的：

第一，引擎回调线程直写 @State 会绕过 ArkUI 的观察。 onStateChange 的回调不保证在 UI 线程，我在真机上实测：回调里直接改 @State，日志数组确实追加了，界面纹丝不动。所以全链路用一个固定模式：所有回调里的状态写入先入队，经 emitter 投回主线程统一消费。

第二，@Builder 按值传参时状态变化不触发刷新。 修复第一个坑之后日志能动了，状态行还是冻的------因为我把状态行抽成了 @Builder 并按值传参。最后把状态相关的 UI 全部内联进 build() 才彻底解决。这两个坑叠加起来，构成了「界面看起来活了但只活了一半」的假象，排查时很容易被第一层修复迷惑。

5、项目实战

环境声明：HarmonyOS 7.0.0.107 (API 26) 正式版，DevEco Studio 26.0.0.821，Mate 60 Pro（ALN-AL80，麒麟 9000S）。

5.1 相位机与线程投递

闪控窗的启动是异步链路，专注又有自己的暂停/结束节奏，两个状态机交叉如果裸奔，重入问题会非常难查。我用一个相位字符串把引擎生命周期串行化：

ets 复制代码

// 相位机：串行化 ensureFloat / stopFloat，杜绝并发重入
const PHASE_IDLE = 'Idle';        // 无悬浮窗，可发起创建
const PHASE_CREATING = 'Creating'; // 创建链路进行中
const PHASE_STARTED = 'Started';  // 回调确认 STARTED
const PHASE_STOPPING = 'Stopping'; // 停止进行中，不再叠加请求

// 引擎回调线程的状态写投回 UI 线程（直写 @State 真机实测绕过 ArkUI 观察）
private ui(run: () => void): void {
  this.uiActions.push(run);
  emitter.emit({ eventId: EVENT_FOCUS_UI });
}

Trade-off 在注释里说清楚了：入队再投递比直接改多一次跳转，但换来的是所有状态变化都在主线程可预测地发生------这个代价值得。

5.2 创建链路与取消路径

创建链路是本篇最核心的一段。以下为核心摘录：上下文符号与辅助方法在工程内定义，省略处均已注释------每个 await 之后都要校验「专注还在不在」：

ets 复制代码

private async ensureFloat(): Promise<void> {
  if (!this.probeOk) { this.log('悬浮窗降级：探测未通过，专注不受影响'); return; }
  if (this.phase !== PHASE_IDLE) { return; } // 已在创建/已启动，跟随即可
  if (!this.permGranted) {
    // 关键：用 await 的返回值判定授权结果，读 @State 会撞上异步竞态（见 6.3）
    const ok = await this.requestPermission();
    if (!ok) { return; }
  }
  this.phase = PHASE_CREATING;
  this.stopRequested = false;
  try {
    if (this.controller === null) {
      const config: floatView.FloatViewConfiguration = {
        context: ctx, // 必须是有效 UIAbilityContext
        templateType: floatView.FloatViewTemplateType.ROUNDED_RECTANGLE
      };
      this.controller = await floatView.create(config);
      this.registerCallbacks(); // Trade-off：创建后立刻注册，宁可多收一条 STOPPED 也不漏 STARTED
    }
    await this.controller.setUIContext(FLOAT_CARD_PAGE); // 路径错一位就是 1300016
    const limits = floatView.getFloatViewLimits(floatView.FloatViewTemplateType.ROUNDED_RECTANGLE);
    await this.controller.setWindowSize(limits.maxSize); // px，先取 limits 再设
    // 每个耗时 await 之后都要问一句：专注还在吗？（create/setUIContext 返回后的同款校验
    // 与 abortCreating 实现均已省略：语义为 stop + 释放控制器 + 相位复位，注释保留原语义）
    if (this.stopRequested || !this.isRunning) { await this.abortCreating(); return; }
    await this.controller.start(); // 返回≠成功，等 STARTED 回调确认
  } catch (e) {
    const err = e as BusinessError;
    this.log(`悬浮窗启动失败 ${err.code}：${SparkErrorMap.describe(err.code)}（专注不受影响）`);
    this.releaseController(); // 三个 off 各自独立 try，防泄漏
    this.phase = PHASE_IDLE;  // 复位后允许下一次专注重建
  }
}

降级哲学在这里落地：悬浮窗起不起来，专注都要能跑完。探测失败、授权拒绝、创建报错，三条路全部汇入「显式降级 + 日志留证」，专注主流程一秒都不被打断。

5.3 外部审查揪出的三个真问题

代码写完我跑了一轮多视角审查，揪出的三个问题都属于「旧控制台验证不到的新集成面」：

授权时序竞态：授权结果经异步队列写回 @State，创建链路 await 之后同步去读，读到的还是过期值------首次授权后悬浮窗会静默缺席。修法是让 requestPermission 返回 Promise<boolean>，用返回值判定。
孤儿悬浮窗：创建进行到一半时点了「结束专注」，旧的停止逻辑遇到非 STARTED 状态直接返回，悬浮窗创建完成后就成了没主孤儿。修法是 stopRequested 标志 + 每个 await 后校验 + STARTED 回调补检 isRunning，三道保险。
运行中换任务状态分裂：专注中回今日页换任务，界面立刻显示新任务、计时还跑着旧任务，完成日志会记错分钟。修法是开始专注瞬间把任务快照进本地状态，本轮所有展示与日志都以快照为准。

这三处修复全部真机复验过，下一节的证据就是修复后的行为。

5.4 真机三场景实测

场景一：首次授权。 用系统工具把 FLOAT_VIEW 重置为未授权，再造完整的首次路径：弹窗 → 允许 → 日志打出「授权完成」→ 当轮 STARTED → 悬浮卡实时跟随。修复前这个场景会静默失败，修复后一次通过。

场景二：创建期取消。 创建链路真机实测小于 1 秒，常规手速很难命中创建窗口。我的办法是借授权弹窗拖慢时序：点「允许」后立刻连发「结束」，第一击落在创建期内。日志完整记录了三道保险的接力：

时间线读出来就是：创建中收到停止请求 → STARTED 回调补检 → stop() → APP_STOP → 状态复位，最终回到待开始、无悬浮窗残留。

场景三：运行中换任务。 写产品周报（25 分钟）专注到 24:54 时回今日页换了 15 分钟的任务，计时 24:22 继续递减、悬浮卡和任务卡仍显示写产品周报------快照生效，本轮语义完整：

实测数据汇总：setWindowSize 上限实测 1134×851 px（圆角矩形模板）；悬浮窗实际窗口矩形占屏幕约 $60,705$ -- $1200,1436$ ，确实会盖住应用内同区域控件；跨应用存活在图库分享面板上得到意外验证------专注卡悬在其他应用之上持续走秒。剩余假设：以上均为麒麟 9000S + 7.0.0.107 正式版上基于当前设备与固件的最可能推断，2in1/平板/折叠形态未验证（待验证），后续拿到设备会补测。

6、避坑指南

6.1 引擎回调直写 @State 不刷新

现象：日志数组在回调里确实追加，界面列表纹丝不动。
根因：onStateChange 回调不在 UI 线程，直写 @State 绕过了 ArkUI 的观察机制，值变了、渲染树不知道。
方案对比：直接改（省事但不可靠）／TaskPool+回调拆分（重）／emitter 投回主线程（轻、可预测）。
最佳实践 ：所有引擎回调的状态写统一走 ui(run) 入队 + emitter 投递，主线程消费。
验证：真机专注一个完整周期，日志、状态行、悬浮卡三处时间戳一致。

6.2 @Builder 按值传参冻结

现象：修完 6.1 日志动了，状态行还是冻的。
根因：@Builder 按值传参，内部不建立对源状态的观察，状态变化传不进去。
方案对比：@Builder 传对象引用（依赖实现细节，不稳）／内联进 build()（冗长但确定）。
最佳实践：状态相关的 UI 直接内联 build()，@Builder 只用于静态片段。
验证：切模板、停止、恢复主窗三个操作后状态行即时更新。

6.3 首次授权后悬浮窗静默缺席

现象：第一次授权成功，当轮专注却没有悬浮窗；第二轮又正常。
根因：授权结果经异步队列写 permGranted，ensureFloat await 后同步读，读到过期 false，创建被跳过且无任何日志。
方案对比：轮询等待状态（丑）／Promise 返回值判定（直接、可测）。
最佳实践：requestPermission 返回 Promise<boolean>，await 返回值作为唯一裁决依据。
验证：重置权限后首次专注，当轮即出悬浮窗（真机已复现修复前后差异）。

6.4 创建期间结束专注 → 孤儿悬浮窗

现象：开始专注后立刻结束，悬浮窗在几秒后自己冒出来。
根因：停止逻辑遇到非 STARTED 状态直接返回，创建链路继续走完 start。
方案对比：只在 STARTED 后允许停止（漏掉创建期）／stopRequested 标志 + await 后校验 + STARTED 补检（三道保险）。
最佳实践：取消意图先落标志，创建链路每个 await 后校验，回调确认时再补检一次。
验证：借授权弹窗拖慢时序命中创建期，日志接力链完整、无残留（见 5.4 场景二）。

另记一个体验坑：悬浮窗拉起后会遮挡应用内控制区，我在场景二里就被它吃掉过一次点击。改进项已列入计划：STARTED 后自动调用 setFloatViewVisibilityInApp(false) 让路。

7、总结

这篇把「专注倒计时跟着你走出应用」从想法落成了真机可跑的完整链路：选型上闪控窗以「手机可用 + user_grant 免证书 + 实时自绘」胜出；实现上用相位机串行化异步链路、用 emitter 投递统一线程模型；质量上靠外部审查揪出授权竞态、孤儿悬浮窗、状态分裂三个集成面问题并全部真机复验。最大的心得是那两层响应式坑：修 bug 时界面「活了一半」比完全不动更迷惑，排查要一次问到底。

已知边界（都写进了代码注释与产品文案）：进程被杀后专注状态不持久化；应用退后台后 setInterval 可能被系统挂起（实测进程跨 90 分钟存活但计时暂停）；闪控窗仅前台可启动、同应用单实例；restoreMainWindow 要求用户曾点击过闪控窗，否则 1300032。