核心内容摘要
ClawdBot傻瓜式使用方法:手把手教你部署7×24替你用电脑干活的ClawdBot
子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 。
曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑
总结、框架与方案选型思考、行业趋势解读展开。
文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践
总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。
愿我们都能在代码和生活里走得更稳一点 文章目录引言HarmonyOS 项目中为什么要拆「共用层」和「形态模型」
什么是真正的「共用能力层」典型可以下沉为共用层的内容共用层的一个重要原则
什么是「形态专属模型层」不同形态模型关注点完全不同手机 App 模型关心什么PC 模型关心什么游戏 / 强交互形态关心什么
一个推荐的拆分结构真实可用
PC 形态下一个“必须独立”的模型例子PC 文档模型的核心不是内容而是「状态」
一个判断标准这段逻辑该放哪
六、
总结引言HarmonyOS 项目中为什么要拆「共用层」和「形态模型」在 HarmonyOS 项目里真正能复用的东西其实非常有限。
如果你把一个项目跑在手机平板PC甚至游戏窗口 / 多实例你会发现一个很残酷的现实逻辑看起来一样但模型几乎一定不一样。
所以在 HarmonyOS 中正确的拆法不是「这段代码能不能复用」而是先想清楚哪些东西“不该知道设备形态”哪些东西“必须知道自己跑在哪”这就是共用层和形态模型的边界。
什么是真正的「共用能力层」共用能力层只有一个标准它不应该关心屏幕大小窗口是否可缩放是否支持多文档是否存在鼠标 / 键盘是否允许后台常驻典型可以下沉为共用层的内容这几类在 HarmonyOS 上几乎永远成立网络请求API / GraphQL / WebSocket数据持久化KV / RDB / 文件 IO业务计算规则状态派生逻辑非 UI跨设备同步协议权限与能力判断封装共用层的一个重要原则共用层只输出“能力”不输出“行为”。
举个例子错误的共用层设计// 不该出现在共用层exportfunctionopenDocument(id:string){Router.pushUrl({url:pages/editor,params:{id}})}正确的共用层设计// common/document/DocumentRepository.tsexportclassDocumentRepository{asyncload(id:string):PromiseDocument{// 只负责数据}asyncsave(doc:Document){// 只负责持久化}}“怎么打开、在哪打开、能不能多开”——一律不在共用层出现。
什么是「形态专属模型层」这是很多 HarmonyOS 项目最容易偷懒、但后期最痛的地方。
形态模型层解决的不是 UI而是“这个形态下业务是怎么运转的”不同形态模型关注点完全不同手机 App 模型关心什么单页面 / 栈式导航页面切换即上下文切换生命周期频繁强依赖前后台状态PC 模型关心什么多窗口 / 多文档并行文档是否脏dirty是否允许并排视图窗口最小化 ≠ 生命周期结束游戏 / 强交互形态关心什么帧循环输入源多样化状态常驻UI 与逻辑高度解耦你可以共用数据层但你不可能共用模型层。
一个推荐的拆分结构真实可用下面是我在 HarmonyOS PC 项目里比较稳定的一套结构src/ ├── common/ │ ├── network/ │ ├── storage/ │ ├── domain/ │ │ ├── Document.ts │ │ └── User.ts │ └── service/ │ ├── app/ │ ├── model/ │ │ └── AppSessionModel.ts │ └── ui/ │ ├── pc/ │ ├── model/ │ │ ├── WorkspaceModel.ts │ │ └── DocumentWindowModel.ts │ └── ui/ │ └── game/ ├── model/ └── runtime/关键点在于common永远不 import app / pcpc/model可以组合common模型之间允许策略不同不强求一致
PC 形态下一个“必须独立”的模型例子PC 文档模型的核心不是内容而是「状态」// pc/model/DocumentWindowModel.tsexportclassDocumentWindowModel{constructor(privaterepo:DocumentRepository){}document:Document|nullnullisDirty:booleanfalseisActive:booleanfalseasyncopen(id:string){this.documentawaitthis.repo.load(id)this.isDirtyfalse}updateContent(content:string){if(!this.document)returnthis.document.contentcontentthis.isDirtytrue}asyncsaveIfNeeded(){if(this.documentthis.isDirty){awaitthis.repo.save(this.document)this.isDirtyfalse}}}如果你把这个模型强行塞进手机 App页面切换时你会丢状态多文档会变成噩梦后台恢复逻辑会失控不是代码写得不好是模型选错了形态。
一个判断标准这段逻辑该放哪我给你一个非常好用的判断表问题是否是否依赖窗口 / 页面数量形态模型共用层是否依赖输入方式鼠标 / 触控形态模型共用层是否只关心数据正确性共用层形态模型是否涉及生命周期策略形态模型共用层是否希望跨形态完全复用共用层形态模型
六、