AIDishRecognition 启动与初始化整体流程梳理

1. 目标

本文档用于梳理当前项目从应用启动，到配置准备、初始化执行、人员/人脸同步、后台保活，再到最终进入 MainActivity 的完整流程。

目标是保证以下事项在项目移植后闭环成立：

2. 核心入口

2.1 启动入口

应用冷启动时，系统会先拉起 LaunchActivity。

2.2 Application 初始化入口

Application.onCreate() 中完成：

  1. 初始化 PreferenceUtils
  2. 注册 CrashHandler
  3. 初始化 OkHttpClient
  4. 启动 WorkScheduler
  5. 启动 CustomMqttService

这意味着即使还未完成前台页面初始化，后台同步链路和 MQTT 服务已经具备启动条件。

3. 启动前需要具备的配置

3.1 基础配置入口

配置页面：

3.2 启动必需配置

LaunchActivity.checkConfig() 会校验以下配置：

  1. 服务端地址 CUSTOMER_BASE_URL
  2. 配对码 PAIR_CODE
  3. 至少开启一种支付方式
  4. 如果开启刷脸，还必须存在人脸激活码 SETTING_FACE_ACTIVATION_CODE

3.3 配对成功后写入的设备信息

通过 SettingsBasicFragment.syncPairInfo() 调用配对接口后，会落地以下关键数据：

对应记录逻辑在：

4. 启动主流程

4.1 权限检查

LaunchActivity.onCreate() 后先执行权限检查：

全部通过后进入 next()。

4.2 配置完整性判断

next() -> checkConfig()

4.3 人员列表同步

LaunchActivity.syncUserList() 调用：

其中 type 规则：

首启标记：

4.4 人员列表落地

同步结果进入：

该阶段会做两件事：

  1. 将人员列表保存到本地 customer.db
  2. 对带有人脸特征的人员，同步更新到 FaceApi 人脸库

相关类：

4.5 是否继续做人脸初始化

LaunchActivity.checkFaceConfig()：

5. 人脸初始化链路

5.1 激活判断与激活

类：

流程：

  1. 读取 SETTING_FACE_ACTIVATION_CODE
  2. 持久化到百度 SDK 偏好
  3. 调用 ActivationFaceSDK.isActivated() 判断是否已激活
  4. 若未激活，则执行在线激活 activation()

5.2 模型初始化

类：

作用：

5.3 人脸数据库初始化

类：

作用：

5.4 人脸数据同步

完成 DB 初始化后，LaunchActivity.requestFaceDataSync() 调用：

类：

处理逻辑：

状态约定：

5.5 初始化完成

FaceDataUpdaters.updateSuccess() 回调后：

  1. 设置 FIRST_INIT_FINISH_TAG = true
  2. 跳转 MainActivity

到此，前台启动初始化完成。

6. 运行期后台同步链路

6.1 WorkScheduler

入口：

启动时会注册三类任务：

  1. 历史订单上传 UploadOrderWorker
  2. 订单清理 OrderDeleteWorker
  3. 人脸增量同步 UpdateFaceWorker
  4. 心跳任务 HeartBeatWorker

6.2 定时人脸增量同步

类：

逻辑：

  1. 判断同步策略是否允许定时增量同步
  2. 判断是否已经完成首启初始化
  3. 判断 DEVICE_CODE 是否存在
  4. 调用 FaceDataUpdaters.performUpdate("0")
  5. 结束后重新调度下一次任务

6.3 心跳机制

类：

逻辑：

  1. 调用 /p/api/heartbeat
  2. 读取返回字段 face_update
  3. 如果 face_update == 1，立即触发一次人脸增量同步
  4. 结束后重新调度下一次心跳

心跳的作用不是直接写库，而是作为“服务端要求刷新人脸库”的触发信号。

7. MQTT 实时同步链路

类：

7.1 服务启动时机

服务由两处触发：

  1. CptApplication.onCreate()
  2. BootCompletedReceiver.onReceive()

7.2 MQTT 初始化前提

CustomMqttService.initMqttConfig() 会先判断：

7.3 订阅主题

会订阅两个 topic：

  1. 设备 P2P topic：DeviceSyncInfoRecorder.getSubscribeTopic()
  2. 公共配置 topic：ALIBABA_CONFIG_TOPIC

7.4 MQTT 消息分类处理

handleArrivedMsg() 按 type 分流：

7.5 人脸消息处理

handleFaceBody()：

  1. 解析 SingleStaffDataBean
  2. 调用 FaceDataUpdaters.saveSingleBeanToDB()
  3. 刷新 FaceApi 内存用户列表
  4. 调用 /p/api/feedback 执行消息反馈

7.6 人员消息处理

handleUserBody()：

  1. 解析 Customer
  2. 调用 CustomerSyncManager.syncCustomerAndFace()
  3. 保存到 customer.db
  4. 如果携带 feature，同步写入人脸库
  5. 刷新 FaceApi 内存用户列表
  6. 调用 /p/api/feedback 执行消息反馈

因此，MQTT 人员消息和人脸消息都能推动数据库与人脸库保持一致。

8. 同步策略说明

类：

当前策略判断较直接：

策略组合说明：

9. 崩溃拦截与恢复

类：

流程：

  1. 任意未捕获异常进入 CrashHandler
  2. 保存 crash 文件到应用目录
  3. 启动 CrashActivity
  4. 用户确认后，通过 AlarmManager + PendingIntent 重新拉起应用

作用：

10. 开机自启流程

类：

系统广播到达后：

  1. 重新调度 WorkScheduler
  2. 启动 CustomMqttService
  3. 拉起应用 Launcher 页面

也就是说，设备重启后会重新走完整启动初始化链。

11. 数据一致性最终保证机制

当前项目人员/人脸一致性由以下几层共同保证：

  1. 启动页人员列表同步
  2. 启动页人脸数据同步
  3. MQTT 单条实时修正
  4. 定时增量同步兜底
  5. 心跳触发增量同步

这五层叠加后，目标状态是：

12. 进入 MainActivity 的完成条件

只有满足以下条件后，才认为启动初始化完成并进入 MainActivity：

  1. 权限通过
  2. 基础配置完整
  3. 人员列表同步完成
  4. 若刷脸关闭：
  5. 若刷脸开启：

13. 当前完整流程简版

  1. 应用进程启动
  2. CptApplication 初始化偏好、崩溃拦截、网络层、后台 Worker、MQTT 服务
  3. LaunchActivity 启动
  4. 检查权限
  5. 检查配置
  6. 配置不完整则跳转设置页
  7. 配置完整则同步人员列表
  8. 人员入 customer.db，带特征人员同时更新人脸库
  9. 若启用刷脸，继续做人脸激活、模型初始化、DB 初始化、人脸数据同步
  10. 设置首启完成标记
  11. 跳转 MainActivity
  12. 运行期由 MQTT、定时任务、心跳持续修正数据

14. 关键文件清单

15. 结论

当前项目已经具备一条完整的“配置 -> 启动 -> 人员同步 -> 人脸初始化 -> 人脸同步 -> 进入主页 -> 运行期持续同步”的闭环链路。

从整体逻辑上看，当前版本已经满足：