---

每日一句正能量

松弛不是懈怠，而是一种自我调节的能力。
很多人不敢放松，怕一松就滑向懒惰。松弛是主动调节，不是被动滑落。

标记：参与方向三「毕业季 · 鸿蒙同行」文章投稿。

---

一、选题背景：把“装几个传感器”升级成完整看护闭环

在校企合作课程中，智慧养老是很受学生欢迎的毕业设计方向，但它也最容易出现两个问题。

第一个问题是“设备堆叠”。学生把门磁、温湿度、人体红外、烟雾、心率手环接入系统，页面上展示一排数值，就认为完成了智慧看护。实际上，独居老人看护的关键不是采集多少数据，而是能否在尽量不打扰老人、不过度收集隐私的前提下，把多设备事件转化为可理解、可确认、可追踪的风险提示。

第二个问题是“单端应用”。所有数据只显示在一部手机上，没有充分体现 HarmonyOS 的多设备协同价值。真实家庭环境往往同时存在老人手机、家庭平板、中控屏、可穿戴设备、门磁和环境传感器；异地家属又需要在自己的手机上查看状态。毕业设计应该回答：这些设备如何发现、如何协作、如何在网络不稳定时降级、如何把告警同步给家属，又如何避免一条误报直接升级成最高级别事件。

因此，本项目把题目定义为：

以老人家庭为本地看护域，以手机或家庭中控屏为协同中枢，聚合手机内置传感器、可穿戴设备和外接 IoT 传感器；在本地完成初步融合和风险判断，再将必要的事件摘要同步到家属端，形成“采集—融合—判断—确认—升级—归档”的完整闭环。

这个选题既能体现 HarmonyOS 的设备发现、应用跨设备连接、通知和 ArkUI 能力，也能训练学生对隐私、安全、异常状态机和系统边界的理解。

---

二、项目目标与创新点

2.1 基础目标

系统需要完成以下功能：

• 采集家庭设备的活动、门磁、环境和穿戴数据；
• 展示设备在线状态与最近活动；
• 识别长时间静止、异常开门、烟雾或燃气风险；
• 在老人侧进行本地语音或页面确认；
• 将需要关注的事件同步到家属端；
• 支持家属联系老人、确认安全和升级联系人；
• 保存事件时间线和处理结果；
• 网络异常时保留本地告警与待同步队列。

2.2 HarmonyOS 创新应用

本项目不是简单的云端 IoT 看板，而是突出三类跨设备能力：

1. 家庭设备协同：老人手机、家庭平板或中控屏处于可信设备环境时，可进行设备发现、应用连接和状态同步。
2. 多端界面分工：老人端强调大字号、少操作和语音确认；家庭平板强调全屋状态；家属手机强调事件摘要和确认闭环。
3. 协同与远程同步分层：家庭局域网中的可信设备使用跨设备协同；异地家属端通过加密业务服务和通知触达，避免把公网远程通信误写为任意设备直连。

2.3 毕设创新点

• 多源事件融合，而不是单传感器阈值判断；
• 本地优先判定，减少原始数据外传；
• 四级告警与人工确认机制；
• 家庭设备协同与异地同步采用不同链路；
• 离线队列和恢复补传；
• 明确医疗、安全与隐私边界。

---

三、技术边界：哪些数据来自 Sensor Service Kit，哪些来自外接设备

这是整篇文章最重要的技术边界之一。

HarmonyOS 的 Sensor Service Kit 可以用于订阅设备自身支持的传感器数据，例如加速度、陀螺仪、方向、光线等。它适合判断手机是否移动、设备姿态变化和端侧交互场景。

但门磁、烟雾、燃气、床垫压力、人体存在等设备通常是外接 IoT 传感器，并不会自动成为手机的系统传感器。它们需要通过以下方式接入：

• 设备厂商提供的 SDK；
• 家庭网关协议；
• 蓝牙、Wi-Fi 或局域网协议；
• 统一物联网业务服务；
• 学生毕设中的模拟设备数据接口。

因此，项目把采集层抽象为统一的 CareSensorAdapter，上层业务不关心数据来自系统传感器、可穿戴设备还是外接 IoT 设备。

---

四、系统总体架构

系统采用“家庭本地看护域 + 业务同步服务 + 异地家属端”的三段式架构。

4.1 家庭本地看护域

家庭侧包含：

• 老人手机；
• 家庭平板或中控屏；
• 可穿戴设备；
• 门磁传感器；
• 人体存在传感器；
• 烟雾或燃气传感器。

其中手机或中控屏作为看护中枢，负责：

• 聚合事件；
• 本地缓存；
• 规则融合；
• 告警分级；
• 语音或大按钮确认；
• 跨设备状态同步；
• 网络恢复后的事件补传。

4.2 业务同步服务

业务服务不持续接收所有原始传感器流，而是主要接收：

• 事件摘要；
• 风险等级；
• 发生时间；
• 设备在线状态；
• 家属确认结果；
• 必要的上下文。

这种设计可以减少隐私暴露和网络消耗。

4.3 异地家属端

家属端展示：

• 当前安全状态；
• 最近活动；
• 设备在线情况；
• 待确认告警；
• 事件时间线；
• 联系老人；
• 标记已确认安全；
• 按预案升级联系人。

---

五、工程目录设计

推荐工程目录如下：

entry/src/main/ets/
├── entryability/
│   └── EntryAbility.ets
├── pages/
│   ├── ElderHomePage.ets
│   ├── FamilyDashboardPage.ets
│   ├── AlertDetailPage.ets
│   ├── DevicePage.ets
│   └── PrivacyPage.ets
├── model/
│   ├── SensorEvent.ets
│   ├── CareAlert.ets
│   ├── DeviceStatus.ets
│   └── CareProfile.ets
├── sensor/
│   ├── CareSensorAdapter.ets
│   ├── SystemMotionAdapter.ets
│   ├── WearableAdapter.ets
│   └── IoTGatewayAdapter.ets
├── service/
│   ├── EventFusionService.ets
│   ├── RiskRuleEngine.ets
│   ├── AlertOrchestrator.ets
│   ├── DistributedCareService.ets
│   ├── FamilySyncService.ets
│   └── NotificationService.ets
├── repository/
│   ├── EventRepository.ets
│   ├── AlertRepository.ets
│   └── DeviceRepository.ets
└── common/
    ├── Logger.ets
    ├── Result.ets
    └── Constants.ets

这个结构把采集、融合、判定、同步和 UI 分开，便于课堂讲解，也方便替换真实设备和模拟数据源。

---

六、核心数据模型

6.1 统一传感器事件

export type SensorEventType =
  'MOTION' |
  'DOOR_OPEN' |
  'DOOR_CLOSE' |
  'PRESENCE' |
  'SMOKE' |
  'GAS' |
  'HEART_RATE' |
  'EMERGENCY_BUTTON' |
  'DEVICE_OFFLINE'

export interface SensorEvent {
  id: string
  deviceId: string
  type: SensorEventType
  value: number | string | boolean
  timestamp: number
  quality: number
  source: 'SYSTEM_SENSOR' | 'WEARABLE' | 'IOT_GATEWAY' | 'SIMULATOR'
  room?: string
}

quality 表示数据质量或可信度，范围可定义为 0～1。外接设备离线恢复后的旧事件、抖动事件或低电量设备事件，可以降低质量分。

6.2 告警模型

export type AlertLevel = 'GREEN' | 'YELLOW' | 'ORANGE' | 'RED'

export type AlertStatus =
  'CREATED' |
  'LOCAL_PROMPTED' |
  'WAITING_CONFIRM' |
  'FAMILY_NOTIFIED' |
  'ACKNOWLEDGED' |
  'ESCALATED' |
  'CLOSED'

export interface CareAlert {
  id: string
  level: AlertLevel
  status: AlertStatus
  title: string
  description: string
  evidence: SensorEvent[]
  createdAt: number
  expireAt: number
  acknowledgedBy?: string
  acknowledgedAt?: number
  resolution?: string
}

告警中保留支持判断的证据事件，答辩时可以解释“系统为什么触发”，避免黑盒评分。

---

七、采集系统传感器数据

下面示例展示如何把系统加速度传感器数据转换成统一事件。接口名称和枚举应以实际安装的 API 23 SDK 为准。

import { sensor } from '@kit.SensorServiceKit'

export interface CareSensorListener {
  onEvent(event: SensorEvent): void
  onError(message: string): void
}

export class SystemMotionAdapter {
  private lastEmitAt: number = 0
  private readonly minInterval: number = 1000

  constructor(private listener: CareSensorListener) {}

  start(): void {
    sensor.on(
      sensor.SensorId.ACCELEROMETER,
      (data: sensor.AccelerometerResponse) => {
        const now = Date.now()
        if (now - this.lastEmitAt < this.minInterval) {
          return
        }

        const magnitude = Math.sqrt(
          data.x * data.x +
          data.y * data.y +
          data.z * data.z
        )

        this.listener.onEvent({
          id: `motion_${now}`,
          deviceId: 'elder_phone',
          type: 'MOTION',
          value: magnitude,
          timestamp: now,
          quality: 0.9,
          source: 'SYSTEM_SENSOR',
          room: '随身设备'
        })
        this.lastEmitAt = now
      },
      {
        interval: 200_000_000
      }
    )
  }

  stop(): void {
    sensor.off(sensor.SensorId.ACCELEROMETER)
  }
}

这里没有直接把每个加速度点上传到服务器，而是先在端侧进行节流和活动判断。实际项目还需要根据设备性能、功耗和系统后台限制调整采样策略，不能长期以高频模式运行。

---

八、接入外部 IoT 设备

外接设备统一通过适配器转换为 SensorEvent：

export interface GatewayMessage {
  deviceId: string
  productType: string
  eventName: string
  payload: Record<string, string | number | boolean>
  timestamp: number
}

export class IoTGatewayAdapter {
  constructor(private listener: CareSensorListener) {}

  onGatewayMessage(message: GatewayMessage): void {
    const event = this.convert(message)
    if (event) {
      this.listener.onEvent(event)
    }
  }

  private convert(message: GatewayMessage): SensorEvent | null {
    if (message.productType === 'door_sensor') {
      const opened = message.payload['opened'] as boolean
      return {
        id: `${message.deviceId}_${message.timestamp}`,
        deviceId: message.deviceId,
        type: opened ? 'DOOR_OPEN' : 'DOOR_CLOSE',
        value: opened,
        timestamp: message.timestamp,
        quality: 0.95,
        source: 'IOT_GATEWAY',
        room: '入户门'
      }
    }

    if (message.productType === 'presence_sensor') {
      return {
        id: `${message.deviceId}_${message.timestamp}`,
        deviceId: message.deviceId,
        type: 'PRESENCE',
        value: message.payload['present'] as boolean,
        timestamp: message.timestamp,
        quality: 0.9,
        source: 'IOT_GATEWAY',
        room: message.payload['room'] as string
      }
    }

    if (message.productType === 'smoke_sensor') {
      return {
        id: `${message.deviceId}_${message.timestamp}`,
        deviceId: message.deviceId,
        type: 'SMOKE',
        value: message.payload['level'] as number,
        timestamp: message.timestamp,
        quality: 0.98,
        source: 'IOT_GATEWAY',
        room: message.payload['room'] as string
      }
    }

    return null
  }
}

毕业设计中没有真实设备时，可以先实现 SimulatorAdapter，通过按钮或脚本模拟门磁、静止和烟雾事件，但必须在文章与答辩中明确标注为模拟数据。

---

九、多源融合：不要让单个传感器决定高风险告警

单传感器规则很容易误报。例如人体存在传感器 30 分钟没有活动，可能只是老人午睡；门磁打开后长时间没有关闭，可能只是取快递；可穿戴设备离线，可能只是忘记充电。

因此，系统采用多源融合。

9.1 长时间静止规则

触发橙色告警需要同时满足：

• 家庭中存在传感器在设定时间内无活动；
• 门磁没有显示老人已离家；
• 可穿戴设备仍在家或最后位置未变化；
• 当前不在睡眠时段；
• 设备在线质量达到最低要求。

export interface CareContext {
  now: number
  sleepStartHour: number
  sleepEndHour: number
  lastMotionAt?: number
  lastDoorOpenAt?: number
  elderAway: boolean
  wearableOnline: boolean
  presenceSensorOnline: boolean
}

export class RiskRuleEngine {
  evaluateInactivity(context: CareContext): AlertLevel {
    if (context.elderAway) {
      return 'GREEN'
    }

    const hour = new Date(context.now).getHours()
    const inSleepWindow =
      hour >= context.sleepStartHour ||
      hour < context.sleepEndHour

    if (inSleepWindow) {
      return 'GREEN'
    }

    if (!context.presenceSensorOnline) {
      return 'YELLOW'
    }

    const lastMotionAt = context.lastMotionAt ?? context.now
    const inactiveMinutes = (context.now - lastMotionAt) / 60_000

    if (inactiveMinutes >= 60 && context.wearableOnline) {
      return 'ORANGE'
    }

    if (inactiveMinutes >= 30) {
      return 'YELLOW'
    }

    return 'GREEN'
  }
}

这里的阈值只是教学示例，真实系统必须结合老人作息、设备误差和试运行数据个性化调整。

9.2 烟雾和燃气规则

环境安全事件可以比活动异常更快升级，但仍要考虑设备质量和重复上报：

export class EnvironmentRiskRule {
  evaluateSmoke(events: SensorEvent[]): AlertLevel {
    const recent = events
      .filter(item => item.type === 'SMOKE')
      .filter(item => Date.now() - item.timestamp < 30_000)
      .filter(item => item.quality >= 0.8)

    const highCount = recent.filter(item => Number(item.value) >= 80).length
    if (highCount >= 2) {
      return 'RED'
    }

    if (recent.some(item => Number(item.value) >= 50)) {
      return 'ORANGE'
    }

    return 'GREEN'
  }
}

高风险环境事件在老人侧应立即发出本地声光提示，并同步家属；是否联系消防、物业或急救机构必须按照真实部署机构的预案执行，而不是由毕业设计原型直接自动拨号。

---

十、四级告警与人工确认机制

系统将风险分为四级：

等级	含义	建议动作
绿色	正常	持续监测，不打扰
黄色	轻度异常或设备问题	本地记录，等待活动恢复
橙色	需要人工确认	老人侧提示，同时通知家属
红色	经规则与人工确认后的高风险	家属按预案联系社区、物业或专业机构

10.1 告警状态机

export class AlertStateMachine {
  private static allowed: Map<AlertStatus, AlertStatus[]> = new Map([
    ['CREATED', ['LOCAL_PROMPTED', 'CLOSED']],
    ['LOCAL_PROMPTED', ['WAITING_CONFIRM', 'ACKNOWLEDGED']],
    ['WAITING_CONFIRM', ['FAMILY_NOTIFIED', 'ACKNOWLEDGED']],
    ['FAMILY_NOTIFIED', ['ACKNOWLEDGED', 'ESCALATED']],
    ['ACKNOWLEDGED', ['CLOSED']],
    ['ESCALATED', ['CLOSED']],
    ['CLOSED', []]
  ])

  static canTransfer(from: AlertStatus, to: AlertStatus): boolean {
    return this.allowed.get(from)?.includes(to) ?? false
  }
}

10.2 告警合并

同一事件在短时间内重复上报时，不应让家属收到十几条通知：

export class AlertMergeService {
  merge(current: CareAlert, incoming: CareAlert): CareAlert {
    const sameCategory = current.title === incoming.title
    const inWindow = incoming.createdAt - current.createdAt < 5 * 60_000

    if (!sameCategory || !inWindow) {
      return incoming
    }

    return {
      ...current,
      level: this.maxLevel(current.level, incoming.level),
      description: incoming.description,
      evidence: [...current.evidence, ...incoming.evidence].slice(-20),
      expireAt: Math.max(current.expireAt, incoming.expireAt)
    }
  }

  private maxLevel(a: AlertLevel, b: AlertLevel): AlertLevel {
    const score: Record<AlertLevel, number> = {
      GREEN: 0,
      YELLOW: 1,
      ORANGE: 2,
      RED: 3
    }
    return score[a] >= score[b] ? a : b
  }
}

---

十一、家庭内跨设备协同

HarmonyOS 的分布式设备管理能力可用于发现和选择可信设备；应用跨设备连接能力可在设备之间建立会话并发送消息或数据。

本项目中，家庭平板可以接收老人手机或中控屏发出的状态摘要：

import {
  abilityConnectionManager,
  distributedDeviceManager
} from '@kit.DistributedServiceKit'

export interface CareStateSummary {
  level: AlertLevel
  lastActivityAt: number
  onlineDeviceCount: number
  pendingAlertCount: number
}

export class DistributedCareService {
  private deviceManager?: distributedDeviceManager.DeviceManager
  private sessionId: number = -1

  async init(bundleName: string): Promise<void> {
    this.deviceManager =
      distributedDeviceManager.createDeviceManager(bundleName)
  }

  async connectToHomeDisplay(networkId: string): Promise<void> {
    const session = abilityConnectionManager.createAbilityConnectionSession()
    this.sessionId = session.sessionId

    session.on('message', (data) => {
      // 接收家庭显示设备返回的确认或状态消息
    })

    await session.connect({
      networkId,
      bundleName: 'com.example.eldercare',
      moduleName: 'entry',
      abilityName: 'EntryAbility'
    })
  }

  async sendSummary(summary: CareStateSummary): Promise<void> {
    if (this.sessionId < 0) {
      throw new Error('跨设备会话尚未建立')
    }

    const payload = JSON.stringify(summary)
    await abilityConnectionManager.sendMessage(this.sessionId, payload)
  }
}

兼容性提示：分布式接口的会话创建方式、回调和权限要求可能随 SDK 版本变化，正式编译时应以 API 23 的 DistributedServiceKit 文档和类型声明为准。

---

十二、异地家属端同步：不要把公网通信写成设备直连

家属通常不在老人家庭局域网中，因此异地同步建议通过业务服务完成：

1. 家庭中枢生成告警摘要；
2. 对摘要签名并上传；
3. 服务端校验设备、账号和时间戳；
4. 保存必要事件；
5. 通过推送或轮询通知家属端；
6. 家属确认结果写回；
7. 家庭中枢接收确认并关闭或升级事件。

12.1 同步对象

export interface AlertSyncPayload {
  alertId: string
  familyId: string
  elderAlias: string
  level: AlertLevel
  title: string
  summary: string
  createdAt: number
  expireAt: number
  nonce: string
  signature: string
}

不建议上传持续音频、持续视频或完整高频传感器流。家属真正需要的是“发生了什么、何时发生、风险多高、应该做什么”。

12.2 离线队列

export class PendingSyncQueue {
  private queue: AlertSyncPayload[] = []

  enqueue(payload: AlertSyncPayload): void {
    const existed = this.queue.some(item => item.alertId === payload.alertId)
    if (!existed) {
      this.queue.push(payload)
    }
  }

  async flush(sender: (item: AlertSyncPayload) => Promise<boolean>): Promise<void> {
    const remained: AlertSyncPayload[] = []

    for (const item of this.queue) {
      if (item.expireAt < Date.now()) {
        continue
      }

      const success = await sender(item)
      if (!success) {
        remained.push(item)
      }
    }

    this.queue = remained
  }
}

家庭断网时，本地提示不能失效；待同步队列在网络恢复后再补传。

---

十三、通知与家属确认闭环

告警通知应该展示必要信息，但不能在锁屏上暴露过多隐私。

import { notificationManager } from '@kit.NotificationKit'

export class CareNotificationService {
  async publishAlert(alert: CareAlert): Promise<void> {
    const request: notificationManager.NotificationRequest = {
      id: this.hashCode(alert.id),
      content: {
        notificationContentType:
          notificationManager.ContentType.NOTIFICATION_CONTENT_BASIC_TEXT,
        normal: {
          title: this.toTitle(alert.level),
          text: alert.description,
          additionalText: '点击查看并确认'
        }
      }
    }

    await notificationManager.publish(request)
  }

  private toTitle(level: AlertLevel): string {
    if (level === 'RED') {
      return '高风险事件需要人工处理'
    }
    if (level === 'ORANGE') {
      return '请确认老人当前状态'
    }
    return '看护状态提醒'
  }

  private hashCode(value: string): number {
    let result = 0
    for (let index = 0; index < value.length; index++) {
      result = (result * 31 + value.charCodeAt(index)) & 0x7fffffff
    }
    return result
  }
}

对于家属端，通知点击后进入事件详情页，提供三个明确动作：

• 联系老人；
• 标记已确认安全；
• 按家庭预案升级联系人。

---

十四、老人端 ArkUI：大字号、少步骤和可撤销

老人端首页不应该展示复杂图表，而应突出：

• 当前是否安全；
• 设备是否正常；
• 是否有需要确认的提示；
• “我没事”大按钮；
• 联系家属；
• 紧急按钮说明。

@Entry
@Component
struct ElderHomePage {
  @State level: AlertLevel = 'GREEN'
  @State lastActivityText: string = '2 分钟前'
  @State message: string = '当前状态正常'

  build() {
    Column({ space: 24 }) {
      Text('居家看护')
        .fontSize(32)
        .fontWeight(FontWeight.Bold)
        .width('100%')

      Column({ space: 12 }) {
        Text(this.message)
          .fontSize(28)
          .fontWeight(FontWeight.Bold)
          .fontColor(this.level === 'GREEN' ? '#2B7A46' : '#A34B36')

        Text(`最近活动：${this.lastActivityText}`)
          .fontSize(20)
          .fontColor('#667085')
      }
      .padding(24)
      .borderRadius(24)
      .width('100%')

      if (this.level === 'ORANGE' || this.level === 'RED') {
        Button('我没事，确认安全')
          .height(64)
          .fontSize(24)
          .width('100%')
          .onClick(() => {
            this.confirmSafe()
          })
      }

      Button('联系家属')
        .height(60)
        .fontSize(22)
        .width('100%')
        .onClick(() => {
          this.openContactPage()
        })

      Text('本系统仅用于生活状态辅助提醒，身体不适请及时联系家人或专业机构。')
        .fontSize(16)
        .fontColor('#7A8499')
        .width('100%')
    }
    .padding(24)
    .width('100%')
    .height('100%')
  }

  private confirmSafe(): void {
    this.level = 'GREEN'
    this.message = '已确认安全'
    // 将确认结果写入 AlertOrchestrator 并同步家属端
  }

  private openContactPage(): void {
    // 打开预设联系人页面
  }
}

还应补充：

• 读屏描述；
• 合理焦点顺序；
• 大字号适配；
• 高对比度；
• 按钮防误触；
• 撤销与二次确认；
• 语音提示可关闭。

---

十五、安全与隐私架构

15.1 最小采集

优先采集事件而不是持续录音录像。例如记录“客厅检测到活动”，而不是上传一段客厅视频。

15.2 端侧优先

能在家庭中枢完成的活动判断和告警合并尽量在端侧完成。跨端主要同步摘要。

15.3 明确授权

老人需要知道：

• 哪些设备在采集；
• 家属可以看到什么；
• 数据保存多久；
• 如何暂停看护；
• 如何撤回授权。

15.4 密钥与签名

同步服务需要：

• 设备身份；
• 账号绑定；
• 请求时间戳；
• 随机数；
• 签名或消息认证；
• 传输加密；
• 重放防护；
• 密钥安全存储。

密钥不应硬编码在 ArkTS 源码中，可使用系统密钥管理能力保护设备侧密钥。

15.5 审计日志

记录：

• 谁查看了告警；
• 谁确认了安全；
• 谁修改了阈值；
• 谁增加了家属联系人；
• 谁暂停了设备；
• 何时发生同步失败。

---

十六、降低误报：毕业设计最应该展示的难点

误报比“没有告警”更容易在短期演示中被忽略，但它决定系统是否可用。

16.1 去抖动

门磁在关闭瞬间可能产生多次开关事件，需要在短时间窗口内合并。

16.2 作息自适应

午睡和夜间睡眠不能按普通静止阈值判断。阈值应根据老人作息配置。

16.3 设备质量

存在传感器离线时，不能继续把“没有活动”当作可靠证据。

16.4 多源佐证

静止告警至少结合门磁、存在、穿戴和时间段中的两到三类信息。

16.5 人工反馈回流

家属标记“误报”后，应记录原因，例如：

• 老人在午睡；
• 设备掉线；
• 出门忘记带穿戴设备；
• 阈值过短。

后续可以根据这些数据调整规则，但毕业设计不应夸大成医疗级 AI。

---

十七、测试方案

17.1 功能测试

• 正常活动；
• 老人外出；
• 午睡；
• 长时间静止；
• 门磁反复抖动；
• 烟雾设备高值；
• 穿戴设备离线；
• 家庭网络断开；
• 家属确认安全；
• 事件升级与关闭。

17.2 跨设备测试

• 发现家庭平板；
• 建立应用会话；
• 发送状态摘要；
• 对端断开；
• 自动重连；
• 消息重复；
• 消息乱序；
• 同一告警多设备确认。

17.3 弱网与离线测试

• 家庭断网；
• 服务端超时；
• 家属手机离线；
• 网络恢复补传；
• 过期事件不补传；
• 本地存储空间不足。

17.4 隐私测试

• 未绑定家属不能查看；
• 解绑后令牌立即失效；
• 锁屏通知不展示敏感详情；
• 日志脱敏；
• 暂停看护后停止业务采集；
• 删除账户后清理本地与云端数据。

17.5 无障碍测试

• 屏幕朗读；
• 大字体；
• 高对比度；
• 单手操作；
• 误触恢复；
• 按钮语义描述；
• 关键动作二次确认。

---

十八、教学样例性能结果

在教学样例中，每个场景执行 20 轮后记录平均耗时：

场景	优化前	优化后	主要优化
本地事件判定	260 ms	95 ms	规则预计算、事件索引
家庭设备同步	420 ms	180 ms	摘要消息、连接复用
家属端收到摘要	1380 ms	620 ms	合并请求、通知链路优化
误报确认闭环	2100 ms	980 ms	页面直达、动作简化

这些数据只用于教学样例，不代表真实养老产品、运营网络或所有 HarmonyOS 设备的通用表现。

---

十九、系统演示视频设计

建议录制 60 秒演示视频：

1. 展示设备拓扑和家庭平板看护首页；
2. 模拟客厅人体存在事件，家庭平板同步变为“最近活动”；
3. 模拟 45 分钟无活动并保持门磁关闭；
4. 老人端出现橙色提示；
5. 家属端收到事件摘要；
6. 家属点击“联系老人”；
7. 老人点击“我没事”；
8. 家属端事件变为“已确认”；
9. 模拟家庭断网，告警保留在本地队列；
10. 网络恢复后补传事件；
11. 展示安全声明和隐私设置页。

配套分镜脚本已单独输出为 Markdown 文件。

---

二十、开发难点与改进建议

难点一：分布式能力与远程同步容易混淆

问题：把异地家属手机写成可以直接通过设备发现连接家庭传感器。

解决：家庭可信设备使用分布式设备管理和应用连接；异地家属端通过业务服务和通知同步。

难点二：外接传感器接口不统一

问题：不同厂家协议不同。

解决：统一 CareSensorAdapter 接口，业务层只处理 SensorEvent。

难点三：误报影响可信度

问题：单传感器阈值过于简单。

解决：多源融合、作息窗口、设备质量和人工反馈回流。

难点四：隐私展示过度

问题：为了“功能丰富”采集持续音视频。

解决：默认事件化采集，原始数据端侧处理，跨端只同步必要摘要。

难点五：告警升级逻辑不清

问题：一次静止事件直接触发最高级告警。

解决：四级告警、老人确认、家属确认和人工预案升级。

---

二十一、答辩展示主线

五分钟答辩可以按以下逻辑展开：

第一分钟：真实痛点

说明独居老人看护需要的是低打扰、可确认的异常提醒，而不是全天视频监控。

第二分钟：系统架构

展示设备拓扑，说明家庭协同域和异地家属端采用不同通信链路。

第三分钟：核心技术

展示统一传感器事件、多源融合规则和四级告警状态机。

第四分钟：跨设备演示

展示家庭平板同步、家属端通知、老人确认和离线补传。

第五分钟：安全边界

强调最小采集、端侧判断、授权撤回、非医疗定位和人工确认机制。

---

二十二、成果总结与后续方向

本项目最终可以形成：

• HarmonyOS 老人端应用；
• 家庭平板看护端；
• 家属端看板；
• 分布式设备协同模块；
• 传感器模拟器；
• 规则引擎；
• 告警状态机；
• 离线同步队列；
• 测试报告；
• 技术文章；
• 演示视频脚本。

后续可继续迭代：

1. 接入更多真实 IoT 设备；
2. 增加设备电量与故障预测；
3. 接入社区服务人员工作台；
4. 增加药物提醒和日程提醒，但不做医疗诊断；
5. 引入端侧趋势分析，识别生活规律变化；
6. 增加多位家属的值守和交接班；
7. 对高风险事件接入机构级人工坐席；
8. 完善权限、密钥轮换和数据生命周期管理。

---

二十三、总结

“基于分布式能力的独居老人看护系统”非常适合作为 HarmonyOS 毕业设计，因为它不是单一页面或单一硬件案例，而是一个涉及设备协同、传感器适配、事件融合、告警状态机、离线同步、通知触达、隐私保护和无障碍设计的完整工程。

项目最有价值的地方不是“检测老人是否跌倒”这样容易夸大的口号，而是建立可信的生活状态辅助看护闭环：家庭设备各司其职，本地中枢尽量完成初步判断，家属只接收必要事件；每次异常都有证据、有等级、有确认、有升级、有归档；网络中断时保留本地能力，数据同步时遵循最小化原则。

从校企合作教学角度看，它能让学生真正理解 HarmonyOS 的分布式能力并不是“所有设备自动互联”，而是可信设备发现、应用连接、数据协作和业务同步的组合。只有把技术边界、安全边界和人的确认流程设计清楚，这个毕业设计才不仅能完成答辩，也能成为一份有责任感、有工程深度的作品集案例。

---

转载自：https://blog.csdn.net/u014727709/article/details/163000871
欢迎 👍点赞✍评论⭐收藏，欢迎指正