子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学"明白"，也用"到位"
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
-
- 引言
- 一个必须先拆开的误区
- App：页面驱动，一次只关心一小段时间
- 游戏：帧和调度，才是第一公民
- [PC 应用：文档比页面活得久](#PC 应用：文档比页面活得久)
- 三种形态，核心关注点完全不同
- 为什么"一套架构通吃"一定会失败
- 更现实的结论：能力可以共用，模型不能
- 一个简单但很实用的判断问题
- 总结
引言
只要你做 HarmonyOS 做得够久，一定听过类似的话：
一套架构，多端复用App、游戏、PC 都能覆盖
HarmonyOS 天生统一
听起来很美，但真落到工程里，你很快会发现：
- App 写着写着，越来越像"页面工程"
- 游戏写着写着，全是调度和时序
- PC 应用写着写着，状态根本收不住
于是你开始怀疑：
是不是我的架构抽象还不够好？
但真相往往更残酷一点：
问题不在"够不够抽象"，而在"目标是否一致"。
一个必须先拆开的误区
HarmonyOS 的"统一"，很多时候被误解成：
应用架构也应该统一。
但系统统一，和应用模型统一，其实是两件完全不同的事。
HarmonyOS 统一的是：
- 能力调用方式
- 分布式协同基础
- 安全与权限模型
但应用真正面对的，是：
- 使用节奏
- 生命周期
- 状态形态
- 用户关注点
而这四件事，在 App、游戏、PC 应用里，完全不一样。
App：页面驱动，一次只关心一小段时间
典型移动 App 的核心假设是：
- 页面是入口
- 页面生命周期短
- 用户一次只专注一件事
所以你会看到非常自然的结构：
ts
onPageLoad() {
loadData()
}
onPageDestroy() {
release()
}状态往往是：
- 跟着页面走
- 跟着路由走
- 跟着用户跳转走
这在 App 场景里是高度合理的。
App 的目标不是"长期稳定存在"，而是快速响应 + 快速释放。
游戏：帧和调度，才是第一公民
在游戏里，最重要的不是页面，而是：
时间。
- 逻辑必须对齐帧
- 渲染必须稳定
- 输入不能阻塞
- 状态必须连续
典型游戏主循环是这样的：
ts
function gameLoop(delta) {
update(delta)
render()
}在这个模型里：
- 页面只是承载容器
- 生命周期几乎是"常驻"
- 状态是连续演进的
你如果试图把"页面销毁 = 状态结束"套进游戏：
基本等于自找麻烦。
PC 应用：文档比页面活得久
在 PC 场景下，用户真正关心的是：
- 正在处理的内容
- 是否被保存
- 是否能恢复
- 是否能多窗口同时操作
也就是说：
文档，是第一公民。
页面只是文档的一个视图。
ts
Document
├─ 状态
├─ 生命周期
├─ 版本
└─ 持久化页面只是：
ts
Page -> bind(Document)如果你把 PC 应用写成 App 的页面模型，最终一定会走向我们前面说的那种"失控"。
三种形态，核心关注点完全不同
把这三类应用放在一起看，会非常清晰：
| 形态 | 核心对象 | 关注重点 |
|---|---|---|
| App | 页面 | 路由、交互、瞬时状态 |
| 游戏 | 帧 / 时间 | 调度、性能、连续性 |
| PC 应用 | 文档 | 状态持久化、多窗口 |
它们不是"复杂度不同"，而是关注点根本不一样。
为什么"一套架构通吃"一定会失败
当你试图强行统一架构，通常会发生三件事：
第一，抽象层越来越厚
为了兼容所有场景，你会不断加：
- 通用生命周期
- 通用状态容器
- 通用调度接口
最后的结果是：
所有人都要为"不是自己场景的能力"买单。
第二，真正重要的东西被弱化
- 游戏的帧节奏，被抽象成"更新回调"
- PC 的文档生命周期，被塞进页面模型
- App 的轻量特性，被拖成重结构
每一端，都在妥协。
第三，代码可读性急剧下降
当一个新人看到代码时，很难回答一句话：
这个应用，到底围绕什么在转？
这是架构失效最直观的信号。
更现实的结论：能力可以共用，模型不能
真正可行的做法，其实是：
底层能力统一，上层模型分化。
可以共用的包括：
- 网络
- 存储
- 日志
- 分布式能力
- 安全机制
但不该强行共用的，是：
- 生命周期模型
- 状态组织方式
- 调度核心
这些必须服务于具体形态。
一个简单但很实用的判断问题
当你在设计架构时，可以先问一句：
如果删掉所有 UI，这个应用最核心的对象还剩什么？
- 如果答案是"页面" → App
- 如果答案是"时间 / 帧" → 游戏
- 如果答案是"内容 / 文档" → PC 应用
这个应该直接决定你的架构中心。
总结
在 HarmonyOS 上，统一的是系统能力，
而不是应用架构。
App、游戏、PC 应用：
- 面向不同使用节奏
- 服务不同核心对象
- 承担不同稳定性责任
强行共用一套架构，看似优雅，最终往往只会带来复杂和失控。
真正成熟的工程选择，是：
接受差异，而不是掩盖差异。