- 博客(96)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 基于鸿蒙OS开发静脉输液智能监控系统（22）-部署发布与未来迭代规划
MVP（Minimum Viable Product，最小可行产品）阶段的目标是验证IVGuard的核心产品假设：三角色协同监护模型是否具有临床价值。本章节对MVP的交付状态进行全面审计，明确已实现功能、模拟服务和已知限制，为后续迭代提供清晰的基线。MVP不是最终产品，而是一个经过精心设计的技术验证平台，它在功能完整性和技术可行性之间取得了平衡，使得团队能够在最小的投入下获取最大的用户反馈。
2026-08-07 00:47:38
251
原创 基于鸿蒙OS开发静脉输液智能监控系统（20）-多角色路由与导航框架
位于common/common/ ├─ DataStore.ets ├─ UserRole.ets ├─ RouteParams.ets ← 路由参数接口 ├─ Constants.ets └─ Logger.ets完整的接口定义如下：接口命名规范，其中 PageName 为目标页面的名称去掉 “Page” 后缀。例如对应。字段最小化：每个接口只包含目标页面必需的参数，不传递冗余数据。例如只传medicineId，而非整个对象，详情页自行根据 ID 查询完整数据。基本类型优先。
2026-08-07 00:16:18
346
原创 基于鸿蒙OS开发静脉输液智能监控系统（21）-系统测试与质量保证
ArkTS是HarmonyOS的应用开发语言，在TypeScript基础上施加了严格的静态类型约束。IVGuard项目在开发过程中，使用工具对文件进行静态分析，是确保代码符合ArkTS规范的第一道防线。静态检查能够在编译前快速定位类型违规、语法错误和ArkUI结构性问题，显著降低后期调试成本。是DevEco Studio内置的ArkTS严格模式静态语法与类型检查工具。它能够检测编译器级别的违规行为，包括但不限于、等ArkTS规范规则。该工具返回结构化的诊断结果，按文件、行号、列号和规则标签进行组织。在以下场
2026-08-07 00:15:58
21
1
原创 基于鸿蒙OS开发静脉输液智能监控系统（19）-权限管理与安全设计
在"value": "用于后置摄像头监控输液瓶液位，以便及时预警输液异常"reason 文案规范必须是完整短句，直白、具体、易理解避免被动语态（“被用于” → “用于”）以句号结尾明确说明"用于什么"以及"对用户的好处"该文案会显示在系统授权弹窗中，用户可见"value": "用于读取输液瓶NFC贴纸中的药物信息，快速准确地录入配药数据""value": "用于发送输液异常预警通知，确保您及时了解输液状态变化""value": "用于医院室内导航，帮助您快速找到护士站和医疗设施"
2026-08-06 08:30:03
184
原创 基于鸿蒙OS开发静脉输液智能监控系统（18）-公共组件库设计与封装
经过上述八个组件的设计与实现，我们提炼出以下五大核心设计模式。这些模式不仅适用于 IVGuard 项目，也是 ArkUI 组件化开发的通用最佳实践。
2026-08-06 08:29:20
160
原创 基于鸿蒙OS开发静脉输液智能监控系统（17）-家属端远程监控UI设计
最近预警摘要模块为家属提供了快捷的预警信息浏览，无需跳转到FamilyAlertPage就能看到最近发生的预警。Text(‘最近预警’).fontSize(15).fontWeight(FontWeight.Medium)Row() {Row()})``slice(0, 3)的设计意图信息密度控制：首页是监控面板，不是记录列表。3条预警提供了足够的最近信息，同时不会让页面变得过长认知负荷管理：人在紧张状态下处理信息的能力下降，3条是一个可以快速浏览的数量查看更多的入口。
2026-08-06 08:28:33
191
原创 基于鸿蒙OS开发静脉输液智能监控系统（16）-护士端工作台UI设计
在真实的临床环境中，护士是输液监护的第一责任人与最终执行者。与患者端的被动接收信息不同，护士端面临的是一个高度并发、多线程、高压力的工作场景。理解这一场景，是设计好护士端UI的前提。在典型的中国三甲医院内科病房中，一个护理单元通常配备4-6名护士，负责40-60张床位。其中需要输液的患者占比通常在60%-80%之间，这意味着每名护士在同一时段内需要管理约8-12位输液患者。这些患者的输液状态各不相同：有的刚开始输液、有的即将完成、有的出现了流速异常、有的需要换瓶。传统模式下，护士依靠定时巡视（通常每30-6
2026-08-06 08:28:06
209
原创 基于鸿蒙OS开发静脉输液智能监控系统（15）-患者端UI设计与页面实现
IVGuard患者端面向正在接受静脉输液治疗的住院患者及其家属。这一用户群体的核心特征包括：身体不适导致操作耐心有限、对医疗数据敏感但专业理解不足、可能处于焦虑或紧张状态、年龄跨度大（从年轻患者到老年患者均需覆盖）。因此，患者端的设计必须以"减少焦虑、操作直觉、信息渐进"为三大核心理念，确保用户在最少的认知负担下获取最关键的输液监控信息。"减少焦虑"意味着界面色彩与动效应当避免引起紧张感，预警信息的呈现应当分层次而非一次性冲击；"操作直觉"意味着核心操作路径不超过两步即可触达，按钮语义清晰无需思考；
2026-08-06 08:27:37
201
原创 基于鸿蒙OS开发静脉输液智能监控系统（14）-智能手表联动与跨设备协同
在医疗输液监控场景中，智能手表并非一个可有可无的附属品，而是整个IVGuard系统中不可或缺的"最后一厘米"触达通道。当病房中的输液瓶液位降至危险线以下，或者流速出现异常波动时，患者、陪护家属乃至护士都需要在第一时间感知到这一信息。传统的通知方式——手机推送、病区广播、护士站蜂鸣器——各有其局限性：手机可能静音、广播扰民、蜂鸣器仅覆盖护士站范围。而智能手表以"贴身佩戴、振动感知、即时响应"三大特性，弥补了这些空缺。IVGuard的智能手表联动服务（WatchService）正是基于这一洞察而设计。
2026-08-05 19:06:36
162
原创 基于鸿蒙OS开发静脉输液智能监控系统（13）-医院室内导航系统设计
id: string // 唯一标识符，如 'poi_nurse_1f'name: string // 显示名称，如 '护士站'type: string // POI类型：nurse/infusion/emergency/pharmacy/inpatientfloor: number // 所在楼层：1/2/3x: number // X坐标(px)，地图左上角为原点y: number // Y坐标(px)，地图左上角为原点color: string // 显示颜色，如 '#4CAF50'
2026-08-05 19:05:32
587
原创 基于鸿蒙OS开发静脉输液智能监控系统（11）-通知推送与语音提醒服务
ypescript enum VibrationMode { SHORT, // 短振动：100ms，用于流速异常 LONG, // 长振动：500ms，用于低液位预警 DOUBLE // 双振动：200ms+200ms间隔+200ms，用于输液完成 }})})
2026-08-05 19:02:15
331
原创 基于鸿蒙OS开发静脉输液智能监控系统（10）-AI智能分析与流速异常检测
静脉输液是临床治疗中最常见的给药方式之一，据统计，全球每年有超过150亿次的静脉输液操作。然而，传统输液监控高度依赖人工巡查，护士需要定时巡视病房，逐一检查每床患者的输液状态。痛点具体表现潜在风险反应滞后护士巡房间隔通常30-60分钟，异常发现不及时输液堵塞、回血等危险情况得不到即时处理判断主观依赖护士个人经验判断滴速是否正常经验不足的护士可能遗漏微妙异常信息孤岛药物配伍、流速变化、剩余时间等维度相互割裂无法综合多维度信息做出最优决策AI智能分析模块正是为解决上述痛点而设计。
2026-08-05 19:01:23
483
原创 基于鸿蒙OS开发静脉输液智能监控系统（9）-药物数据库与配伍禁忌检测
在临床输液场景中，药物信息的即时可获取性直接关系到患者安全。IVGuard 作为一款面向护士和患者的智能输液监护应用，其核心价值之一便是为药物添加和费用计算环节提供准确的药品参考数据。离线可用性：医院病区的网络环境往往不稳定。部分老旧病区 Wi-Fi 覆盖存在盲区，地下室输液室信号更是难以保证。在这些场景下，护士需要立即查询药物的配伍禁忌或参考价格，任何因网络延迟或断连导致的信息不可用都是不可接受的。内置数据库确保无论网络状态如何，药物信息均可在毫秒级别完成检索并呈现，为临床决策提供即时支持。即时响应体验。
2026-08-04 19:48:43
243
原创 基于鸿蒙OS开发静脉输液智能监控系统（8）-NFC标签配对与快速绑定
NFC（Near Field Communication，近场通信）贴纸是IVGuard项目中实现输液瓶快速配对的核心物理载体。选择NFC贴纸而非其他识别技术（如蓝牙低功耗BLE标签、RFID标签、二维码），是基于成本、便利性、可靠性三者的综合权衡。成本分析：NFC贴纸的市场价格极为低廉，这是其在大规模医疗场景中得以应用的关键前提。当前市场上主流NFC贴纸的成本如下：以IVGuard场景为例，一家三甲医院日输液量约为2000-3000人次，每张输液瓶需配备一张NFC贴纸，日均消耗量为2000-3000张。按
2026-08-04 19:47:35
286
原创 基于鸿蒙OS开发静脉输液智能监控系统（7）-相机服务与后台持续采集
在IVGuard静脉输液智能监控系统中，相机服务承担着整个系统"眼睛"的职责。它是视觉数据采集的唯一入口，所有关于输液瓶液位的判断、滴速的计数、标记物状态的追踪，归根结底都依赖于相机服务所提供的图像数据。没有相机服务稳定可靠的持续采集，下游的VisionService将无数据可分析，NotificationService将无从触发预警，整个监控链路将从根本上断裂。
2026-08-04 19:45:44
187
原创 基于鸿蒙OS开发静脉输液智能监控系统（6）-视觉识别与贴纸刻度读取算法
VisionResult是IVGuard视觉识别系统的核心数据结构，承载了单次检测的完整结果。其定义位于markerId: string // 贴纸标记IDlevel: number // 识别到的液位百分比confidence: number // 置信度0-1corners: number[] // 角点坐标[x1,y1,x2,y2,x3,y3,x4,y4]OpenCV的ArUco模块提供了多种预定义字典，每种字典由两个参数定义：标记尺寸（n x n比特）和字典大小（可用ID数量）。
2026-08-04 19:44:47
261
原创 基于鸿蒙OS开发静脉输液智能监控系统（5）-数据持久化服务设计
HarmonyOS 为应用开发者提供了多种数据持久化方案，每种方案都有其特定的适用场景和性能特征。在 IVGuard 项目的架构设计阶段，我们需要对这些方案进行深入对比分析，以选择最适合 MVP 阶段的数据持久化技术路线。
2026-08-04 19:38:22
258
原创 基于鸿蒙OS开发静脉输液智能监控系统（4）-数据模型层设计与实现
`变更类型难度是否需要迁移建议新增字段低否默认值+??自动兼容删除字段低否多余字段被自然忽略重命名字段中是需要双字段名读取逻辑修改字段类型高是需要类型转换逻辑修改关联关系高是需要数据重构逻辑核心原则：尽量使用新增字段而非修改/删除现有字段。新增字段的兼容成本最低，是模型演进的首选策略。IVGuard 的数据模型层虽然代码量不大（DataModels.ets 仅 260 行），但蕴含了多个精心选择的设计模式。
2026-08-03 20:02:27
166
原创 基于鸿蒙OS开发静脉输液智能监控系统（2）-开发环境搭建与项目构建
HarmonyOS 生态中存在两个密切相关但定位不同的操作系统版本：OpenHarmony 和 HarmonyOS。理解二者的区别对于项目选型和技术决策至关重要。OpenHarmony 是由开放原子开源基金会（OpenAtom Foundation）托管的开源项目，是 HarmonyOS 的开源基础底座。它具备以下核心特征：HarmonyOS 是华为基于 OpenHarmony 内核打造的商业操作系统，在开源基础上增加了大量华为专有的商业能力和服务：IVGuard 项目选择基于 HarmonyOS 商业版进
2026-08-03 19:59:34
387
原创 基于鸿蒙OS开发静脉输液智能监控系统（1）-项目总览与架构设计
这是系统最核心的数据文件，定义了15 个数据类序号类名用途关键字段1Medicine药物信息2监控会话3液位记录4监控记录5药物相互作用6AlertEvent预警事件7医院兴趣点8IVDrugInfo静脉药物详情9CostItem费用条目10医保政策11费用汇总12应用设置13UserRole用户角色枚举14导航路径15(辅助类型)路由参数等视具体业务定义数据类之间的关系。
2026-08-03 19:58:31
563
原创 基于鸿蒙OS开发打飞机小游戏（30）-设计哲学总结
选择Emoji而非精灵图 → 视觉语言选择Canvas而非组件 → 渲染架构选择30fps而非60fps → 性能策略选择@State+Canvas双轨制 → 状态管理选择11层渲染管线 → 视觉层级选择召唤系统 → 多目标管理选择Phase2 → 阶段转换选择减益系统 → 状态剥夺选择信息封锁 → 认知挑战选择技能继承 → 后期内容生成每一个选择都是"在约束下寻找最优解"的过程，而这些选择的累积构成了EmojiShooter的完整设计。
2026-08-03 19:48:05
374
原创 基于鸿蒙OS开发打飞机小游戏（29）-模拟器调试与性能优化
ArkTS是HarmonyOS基于TypeScript扩展的声明式开发语言。它在TypeScript的基础上引入了更严格的类型约束和性能优化规则，以适应HarmonyOS的运行时环境。
2026-08-02 21:56:39
171
原创 基于鸿蒙OS开发打飞机小游戏（28）-HUD与界面设计
在实时游戏界面设计中，信息的呈现不是简单的"显示所有数据"，而是一个精心设计的层级系统。。这种层级设计确保了玩家的注意力分配与信息的重要性成正比——最关键的信息（L0）直接嵌入游戏画面，最不重要的信息（L3）需要主动操作才能访问。
2026-08-02 21:55:46
222
原创 基于鸿蒙OS开发打飞机小游戏（27）-Canvas渲染管线
EmojiShooter的粒子系统是一个轻量级的视觉反馈系统，用于在关键事件（击杀、受伤、Boss变身、技能释放等）时产生视觉冲击。属性类型说明x, ynumber粒子位置vx, vynumber粒子速度lifenumber剩余生命帧数maxLifenumber初始生命帧数sizenumber粒子半径colorstring粒子颜色颜色语义应用场景深蓝环境/背景棋盘格背景青色玩家/友方玩家弹幕、护盾红色危险/伤害敌方弹幕、激光、受伤反馈紫色。
2026-08-02 21:53:49
285
原创 基于鸿蒙OS开发打飞机小游戏（26）-召唤与变身
EmojiShooter的召唤系统是游戏中后期战斗复杂度的核心驱动力之一。当主Boss存活时，系统会按照固定的时间间隔尝试召唤小型Boss（MiniBoss）加入战场，从而将原本的单目标战斗转变为多目标管理挑战。这一系统的设计精妙之处在于，它并非简单地增加敌人数量，而是通过精心调校的参数将MiniBoss塑造成"密集但脆弱"的干扰型单位，迫使玩家在"清杂保安全"与"集火主Boss"之间做出持续的战略抉择。
2026-08-02 21:50:56
246
原创 基于鸿蒙OS开发打飞机小游戏（25）-暗夜降临技能
阶段时长最优策略次优策略预警(0.8s)短移动到安全位置+记忆Boss位置最后输出几发黑暗(1.5s)长安全点等待+根据弹幕模式微调位置手动盲射渐变恢复(0.5s)短快速定位Boss+开始射击扫描屏幕正常(2s)中高效输出+准备下次暗夜正常战斗暗夜系统的核心哲学是"信息即权力"——在弹幕游戏中，拥有信息优势就是拥有战斗优势。暗夜通过剥夺信息，剥夺了玩家的权力。视觉信息=战斗能力——看不见=打不到位置信息=战略优势——知道Boss在哪=可以精确射击。
2026-08-02 21:49:04
1047
原创 基于鸿蒙OS开发打飞机小游戏（24）-防护墙技能
防护墙技能是EmojiShooter中最复杂、最多层次的空间控制机制。它通过物理障碍、弹飞力学、屏幕外死亡和护盾抗弹飞四个子系统，创造了一个完整的"空间博弈"战斗环境。掏兜动画作为电报系统——60帧动画+70%计时器手出现，提供1-1.8秒预警动态间隔——无墙240帧/有墙360帧，引导拆墙或保留的策略选择三种砌墙策略——初始5环/扩展+5/修复+3，根据墙壁数量动态调整WallBlock——3HP/22px，每方块需3发子弹击毁子弹↔墙碰撞——子弹被阻挡+墙壁受伤，墙壁作为Boss的物理护盾。
2026-08-01 00:37:37
181
原创 基于鸿蒙OS开发打飞机小游戏（23）-回血与血影消耗
180帧的警告期（约3秒）是玩家的"最后机会"窗口。在这3秒内，玩家知道回血即将触发，应该竭尽全力输出伤害。但如果玩家在活跃期的420帧内已经将Boss HP打到了低值，警告期的3秒是否足够完成击杀？剩余HP(X)DPS=3DPS=5DPS=8DPS=105✓(1.7s)✓(1s)✓(0.6s)✓(0.5s)10✗(3.3s)✓(2s)✓(1.3s)✓(1s)15✗(5s)✓(3s)✓(1.9s)✓(1.5s)20✗(6.7s)✗(4s)✓(2.5s)
2026-08-01 00:37:08
183
原创 基于鸿蒙OS开发打飞机小游戏（22）-伪装变形技能
伪装变形技能是EmojiShooter中最具欺骗性的Boss技能。它的核心创新在于信息替换而非信息剥夺——Boss不是消失，而是变成一个看似无害的😊。这种欺骗比隐身更加危险，因为它不仅隐藏了真相，还提供了虚假的表象。双状态循环——伪装（😊）和揭示（真实形态）的循环，伪装是默认状态不对称逃脱惩罚——伪装逃脱-2生命，揭示逃脱0惩罚，引导玩家积极揭示30px揭示阈值——必须将子弹射到Boss中心30px以内才能揭示揭示时垂直传送——Boss被传送到targetY，相当于位置重置漂移速度不对称。
2026-08-01 00:36:38
225
原创 基于鸿蒙OS开发打飞机小游戏（21）-隐身技能
隐身系统创造了一种特殊的信息不对称：Boss知道自己的位置，玩家不知道。但碰撞体积的保留引入了一个"对称点"——虽然信息不对称，但交互是对称的。Boss可以对玩家造成伤害，玩家也可以对Boss造成伤害，无论可见性如何。这种"信息不对称但交互对称"的设计哲学，是EmojiShooter隐身系统的核心创新。它避免了传统隐身机制的"无敌帧"问题，同时保留了隐身的战术威胁感。隐身系统是EmojiShooter中最精巧的技能设计之一。它的核心创新在于信息剥夺与碰撞保留的组合——Boss不可见，但仍然可以被击中。
2026-08-01 00:36:07
163
原创 基于鸿蒙OS开发打飞机小游戏（20）-麻痹锁定技能
被剥夺能力代码实现效果对比其他技能移动能力玩家完全停止移动引力只改变位移方向，不禁止移动射击能力玩家无法射击无敌只阻止伤害，不阻止射击麻痹技能是EmojiShooter中最极端的玩家控制机制——同时剥夺移动和射击两种核心能力，将玩家置于100帧（1.67秒）的完全被动状态。这种"双重剥夺"设计在游戏设计中是高风险的，但通过30帧的护盾预警机制得到了有效补偿。
2026-08-01 00:35:41
211
原创 基于鸿蒙OS开发打飞机小游戏（19）-引力场技能
引力场的90帧激活期是一个"脆弱性窗口"——在这段时间内，玩家的位置控制权被部分剥夺。虽然玩家可以通过对抗引力来减少位移，但完全抵消引力需要消耗所有移动能力，导致玩家无法同时进行其他操作（如精确攻击、收集掉落物）。引力场技能通过"强制位移"将玩家从安全位置拉向危险区域，是一种独特的控制型机制。Boss6的force=4引力配合瞬移产生了方向突变效应，Boss10的force=3引力配合激光和瞬移形成了三技能协同的终极空间压力。
2026-07-31 19:43:30
195
原创 基于鸿蒙OS开发打飞机小游戏（18）-瞬移技能
瞬移技能通过"空间不确定性"为EmojiShooter的Boss战斗增加了第三个难度维度。其20帧的闪现动画（消失10帧+出现10帧）在第10帧执行位置重置，创造了一种"消失-出现"的视觉叙事。位置约束（X: 80~width-80, Y: 80~80+height*0.35）确保了Boss只出现在上方35%的安全区域，避免了不公平的位置偷袭。
2026-07-31 19:42:56
177
原创 基于鸿蒙OS开发打飞机小游戏（17）-无敌护盾技能
无敌技能通过"剥夺输出能力"来增加战斗难度，是一种间接但极其有效的设计手段。Boss3和Boss13代表了无敌技能的两种极端配置——从"温和的时间延长"到"极端的输出限制"——它们的差异不仅体现在数值上，更体现在对玩家心态和策略的深层影响上。Boss3的75%攻击占比使得无敌只是一个"小插曲"，玩家仍然以输出为主；Boss13的52.6%攻击占比则将战斗变成了"以等待为主，输出为辅"的模式，要求玩家在极有限的窗口内最大化输出，同时在漫长的无敌期中保持生存。
2026-07-31 19:42:14
256
原创 基于鸿蒙OS开发打飞机小游戏（16）-激光技能
激光技能是EmojiShooter中最精细设计的Boss技能之一。其三阶段状态机（空闲→蓄力→发射）不仅是一个技术实现，更是一个完整的博弈系统——蓄力期间的实时追踪为玩家提供了影响结果的机会，而发射期间的严格锁定则对玩家的博弈结果进行奖惩。各Boss不同的laserInterval创造了差异化的战斗节奏，Phase2的间隔加速则将博弈推向极限。理解激光技能的状态机、时序、命中检测和视觉系统，是掌握EmojiShooter高端战斗的关键一步。
2026-07-31 19:41:34
224
原创 基于鸿蒙OS开发打飞机小游戏（15）-Boss技能组合论
认知清晰性：玩家面对Boss时，首先需要理解"这个Boss的核心挑战是什么"。如果Boss有多个核心技能，玩家的认知负荷将急剧增加——不仅要理解多个核心挑战，还要理解它们之间的交互关系。单一核心技能确保了认知的清晰性——玩家可以快速识别Boss的核心挑战并制定应对策略。教学效率：每个Boss的核心技能都是一个新的游戏概念。如果Boss同时引入多个新概念，玩家可能无法充分学习任何一个。单一核心技能确保了每个新概念都有足够的"教学空间"——玩家可以在整个Boss战斗中反复练习和掌握这一个概念。设计身份。
2026-07-31 19:40:41
175
原创 基于鸿蒙OS开发打飞机小游戏（14）-后期Boss设计
阶段Boss范围核心挑战威胁模型部件设计预警机制早期B1-7机制学习物理威胁奖励导向无或简单中期B8-10极限博弈心理威胁风险导向精密（30帧/10帧）后期B12-15范式突破范式威胁去工具化按需设计。
2026-07-30 21:33:46
204
原创 基于鸿蒙OS开发打飞机小游戏（13）-中期Boss设计
在EmojiShooter的Boss难度曲线中，中期Boss（Lv.11-21）涵盖了Boss 8至Boss 10三个关卡，对应难度等级Lv.17、Lv.19和Lv.21。这一区间的设计定位是"机制融合与极限化"——在早期Boss建立的基础机制（弹幕、激光、瞬移、无敌、召唤等）之上，中期Boss通过引入三种全新的核心机制——debuff弹幕、麻痹锁定和隐身——将战斗的复杂度和紧张度推向前所未有的高度。。
2026-07-30 21:33:03
251
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人