# acs_yushi

**Repository Path**: Free4K/acs_yushi

## Basic Information

- **Project Name**: acs_yushi
- **Description**: 宇视门禁项目开发，使用Springboot从原企业项目中重新整理出的部分硬件相关代码。
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 2
- **Created**: 2025-07-20
- **Last Updated**: 2025-11-11

## Categories & Tags

**Categories**: Uncategorized

**Tags**: 宇视, 宇视门禁, 门禁, yushi, SpringBoot

## README

# 说明

​        宇视门禁设备开发示例。与宇视的其它网络设备SDK开发不同，宇视门禁是以一个集成了netty服务的springboot项目实现。该代码以官方示例为基础，从原先的一个项目中重新整理了门禁相关的硬件功能。

​        开发可以不用在意netty。代码保留了demo中的全部内容。从原项目中整理了两个类作为参考，放在netty.handle路径下。LapiServerHandler2（为了保留原先的类重命名为2）用来被动处理处理门禁上报的信息，RePersonInfoServiceImpl用于主动对设备下发命令。原LapiServerHandler中72行处理的是设备的上报信息，其jsonObject含有所有上报数据，在此处处理相关业务。

​        两个类中的功能都**只摘取了部分核心硬件操作流程，只保留了硬件操作基本的业务**代码。

开发以官方文档为基础

![](./static/yspsd2.PNG)

目录结构

![](./static/yspsd.PNG)



### 以下是AI对两个类分析生成的功能说明

关于AI生成的潜在问题，根据实际情况可进行忽略/改进。

# LapiServerHandler

## 主要功能

1. **网络通信处理**：作为Netty的ChannelHandler，处理HTTP协议的设备通信
2. **心跳检测**：处理设备的心跳消息，保持长连接
3. **通行记录处理**：接收并处理设备的通行记录(如人脸识别结果)
4. **设备状态管理**：跟踪设备在线/离线状态
5. **业务逻辑处理**：包含体温检测、X酸有效期验证等业务逻辑

## 核心组件

1. **请求处理**：
   - 心跳请求(`HEART_URI`)
   - 通行记录请求(`ACCESS_RECEIVE_URI`)
   - 其他请求转发
2. **响应处理**：
   - 心跳响应
   - 通行记录响应
   - 设备信息显示
   - 开门控制
3. **状态管理**：
   - 设备通道管理(ChannelFactory)
   - 设备在线状态更新

## 主要方法分析

1. `channelRead0` - 核心消息处理方法：
   - 处理心跳消息：保存设备上下文，发送心跳响应，更新在线状态
   - 处理通行记录：解析人脸识别数据，进行业务处理(体温检测等)，发送响应
   - 其他消息转发
2. `showInfoAndOpenDoor` - 人脸识别结果处理：
   - 解析体温、身份证号等信息
   - 检查体温是否在正常范围
   - 检查X酸有效期
   - 根据状态(1-正常，2-异常，3-黑名单)处理
   - 调用显示信息和开门
3. `updateInLine/updateOffLine` - 设备状态更新
4. `openDoor/showInfo` - 设备控制方法
5. 各种Netty生命周期方法：`handlerAdded`, `handlerRemoved`, `channelInactive`等

## 业务逻辑

1. **体温检测**：
   - 从Redis获取配置的体温范围(默认35.5-37.2)
   - 高于或低于阈值会记录告警
2. **X酸有效期检查**：
   - 从Redis获取配置的有效天数(默认7天)
   - 超过有效期会记录告警
3. **人员状态处理**：
   - 状态1：正常(检查X酸)
   - 状态2：异常
   - 状态3：黑名单

## 潜在问题

1. **异常处理不完善**：`showInfoAndOpenDoor`方法中的异常被捕获但没有处理
2. **硬编码值**：部分默认值(如体温范围、X酸天数)硬编码在代码中
3. **事务注释被注释**：`@Transactional`被注释掉，可能导致数据不一致
4. **资源管理**：创建的HTTP客户端没有显示关闭

## 改进建议

1. 完善异常处理和日志记录
2. 将配置值集中管理，减少硬编码
3. 考虑添加事务处理
4. 确保资源正确释放
5. 增加更详细的注释说明业务逻辑

这个处理器是设备通信的核心组件，连接了网络通信层和业务逻辑层，处理了从设备接收到的大部分消息类型。



# PersonInfoService

## 主要功能

1. **人员信息同步**：将人员信息(包括人脸图片)同步到相关设备
2. **增删改操作**：处理人员信息的添加、删除和更新
3. **定时任务**：定期同步未同步的人员信息
4. **图片处理**：将人员照片转换为Base64编码

## 核心组件

1. **依赖服务**：
   - `RePersonInfoMapper`：人员信息数据库操作
   - `IReSitePersonnelRelationService`：人员-场所关系服务
   - `IReMachineService`：设备服务
2. **配置项**：
   - `file.prefix`：文件前缀
   - `file.path`：文件存储路径
3. **同步结果跟踪**：
   - `resultList`：记录本次同步的人员列表

## 主要方法分析

1. **syncTask** - 定时同步任务：
   - 查询所有未同步的人员信息
   - 根据删除标志(`delFlag`)决定是删除还是更新人员信息
2. **insertRePerson** - 添加人员：
   - 根据人员卡号查询关联的场所
   - 获取场所下的所有设备
   - 调用`addPerson`将人员添加到每个设备
3. **deleteRePerson** - 删除人员：
   - 根据ID查询人员信息
   - 找到关联的场所和设备
   - 调用`delPerson`从每个设备删除人员
4. **updateRePerson** - 更新人员：
   - 根据卡号查询人员ID
   - 找到关联的场所和设备
   - 调用`upPerson`(先删除后添加)更新设备中的人员信息
5. **底层操作方法**：
   - `addPerson`：构建人员信息JSON，包括基本信息、身份证信息和照片，发送到设备
   - `delPerson`：发送删除请求到设备
   - `upPerson`：组合操作(先删除后添加)
   - `img_base64`：将图片文件转换为Base64编码

## 业务逻辑

1. **人员-场所-设备关系**：
   - 人员通过卡号关联到场所
   - 场所关联到多个设备
   - 人员变更需要同步到所有关联设备
2. **同步状态管理**：
   - `syncType`字段记录同步结果：
     - "1"：同步成功
     - "2"：同步失败
     - "3"：同步异常
3. **图片处理**：
   - 支持直接传入Base64编码的图片数据
   - 也支持从文件系统读取图片并编码

## 潜在问题

1. **性能问题**：
   - `Thread.sleep(3000)`硬编码等待可能导致性能瓶颈
   - 同步操作是串行执行，设备多时效率低
2. **异常处理**：
   - 多处只打印异常堆栈而没有适当处理
   - 没有重试机制
3. **资源管理**：
   - 文件流没有确保关闭(应使用try-with-resources)
4. **硬编码**：
   - URL路径中的`PeopleLibraries/3`硬编码
   - 睡眠时间硬编码
5. **事务问题**：
   - 没有使用事务管理，可能导致数据不一致

## 改进建议

1. **性能优化**：
   - 移除或减少硬编码的等待时间
   - 考虑并行同步到不同设备
2. **异常处理**：
   - 添加适当的异常处理和日志
   - 实现重试机制
3. **资源管理**：
   - 使用try-with-resources确保资源释放
4. **配置化**：
   - 将硬编码值(如URL路径、等待时间)改为可配置项
5. **事务管理**：
   - 添加事务注解确保数据一致性
6. **代码结构**：
   - 考虑将设备操作部分抽离为单独的服务

这个服务是人员信息与设备同步的核心组件，负责保持设备中的人员信息与系统一致，特别是在人脸识别门禁系统中起着关键作用。