子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

如果你已经把 HarmonyOS 应用真正跑到 PC 形态，并且：

• 做了窗口化适配
• 处理了焦点系统
• 统一了输入模型
• 甚至重建了状态架构

你大概率会在某个阶段撞上一堵新的墙：

多窗口看起来已经工作了，但系统始终“不稳定”。

表现通常不是崩溃，而是更隐蔽的东西：

• 有的窗口恢复状态异常
• 有的页面被系统回收却还“自以为活着”
• 有的任务切换后逻辑错乱
• 有的子窗口关闭，主窗口状态却污染

这时候你才会意识到：

HarmonyOS PC 多窗口真正难的，不是界面、不是焦点，而是——生命周期。

这一层，才是桌面化架构里最深的一层。

为什么移动端思维在这里彻底失效

在移动端，我们对生命周期其实已经很熟：

• onCreate
• onStart
• onResume
• onPause
• onStop
• onDestroy

单窗口 + 单任务栈
让生命周期模型天然是线性的。

但到了 PC：

• 多窗口并行存在
• 窗口可随时最小化 / 隐藏 / 覆盖
• 系统可能按资源策略回收任意窗口
• 用户可以随时重建窗口实例

生命周期不再是：

一条时间线

而变成：

一张状态网。

这就是复杂度暴涨的根本原因。

PC 多窗口真正的三层生命周期

如果从架构视角拆开，PC 生命周期其实分成三层。

第一层：Ability 生命周期（系统层）

这是系统调度的：

• create
• foreground
• background
• destroy

这一层你控制不了，只能被动响应。

问题是：

系统生命周期 ≠ 业务生命周期

这是第一个错位点。

第二层：Window 生命周期（容器层）

在 PC 上真正复杂的是 Window 本身的存在状态：

• 可见
• 不可见
• 被遮挡
• 最小化
• 分屏
• 多实例

同一个 Ability：

可能对应多个 Window 实例。

这在移动端几乎不存在。

第三层：Page / State 生命周期

真正决定用户体验的是：

• 页面状态是否正确恢复
• 数据是否同步
• 操作是否连续
• 副作用是否清理

而这一层：

系统完全不会帮你管。

多窗口混乱，本质是三层不同步

你在 PC 上看到的所有“诡异问题”，几乎都可以归因到一句话：

系统层、窗口层、业务层生命周期不同步。

举几个真实工程中高频出现的情况：

情况一：窗口销毁，但状态仍在

onWindowStageDestroy() {
  console.log("window destroyed");
  // 但全局 store 仍然持有旧状态
}

结果：

• 新窗口恢复了旧副作用
• UI 看起来“穿越”

情况二：Ability 还在，但窗口已经换了

onForeground() {
  // Ability 回前台
  // 但此时用户已经打开的是另一个窗口实例
}

如果这里直接恢复 UI：

必然错乱。

情况三：多窗口共享同一状态源

globalStore.currentDocument = docId;

当两个窗口同时编辑：

状态覆盖是必然事件。

真正的难点：生命周期不是“回调问题”，而是“架构问题”

很多人第一反应是：

把生命周期回调处理好就行。

但工程实践会很快证明：

完全不够。

因为 PC 多窗口的问题，本质不是：

• onCreate 写错
• onDestroy 忘清理

而是：

你的架构默认只有一个“活着的世界”。

而 PC：

允许多个世界并存。

正确的工程思路：生命周期分层解耦

真正能解决问题的，不是补回调，而是做三件事：

一、状态必须“窗口作用域化”

不要再用单例全局状态：

//  错误
export const store = new AppStore();

而是：

//  每个窗口独立
export function createWindowStore(windowId: string) {
  return new AppStore(windowId);
}

核心思想：

状态属于窗口，而不是应用。

这一步，是 PC 架构的分水岭。

二、副作用必须绑定生命周期拥有者

所有：

• 定时器
• 订阅
• 网络轮询
• 事件监听

都必须绑定到：

Window 或 Page，而不是全局。

示例：

class WindowController {
  private timer?: number;

  onStart() {
    this.timer = setInterval(() => {
      this.sync();
    }, 5000);
  }

  onStop() {
    clearInterval(this.timer);
  }
}

否则：

幽灵副作用一定出现。

三、恢复逻辑必须可重入

PC 上最重要的一条原则：

任何页面，都必须支持“随时被杀，再随时复活”。

示例：

async function restoreState(windowId: string) {
  const cache = await storage.get(windowId);
  if (!cache) return createDefault();

  return rebuildFromCache(cache);
}

注意这里的关键不是“缓存”，而是：

重建能力。

为什么这一层决定 PC 体验上限

当生命周期真正被你掌控后，会发生几个质变：

体验变稳定

• 切窗口不乱
• 恢复不穿越
• 多实例不冲突

架构变清晰

• 状态有边界
• 副作用可追踪
• 销毁可验证

能力才真正接近桌面级应用

这一步完成前：

你只是“能跑在 PC 上的移动应用”。

完成之后：

你才是真正的 PC 应用。

总结

为什么很多 HarmonyOS PC 多窗口应用：

越做越复杂，却始终不稳定？

答案其实很简单：

因为还停留在移动端生命周期思维里。

而 PC 要求的是：

• 多实例并存
• 生命周期解耦
• 状态作用域化
• 副作用可回收

这不是优化问题，这是：

架构层级的跃迁。