Androidiot扫地机器人设备详情页地图加载慢卡顿优化方案探鸽设备扫地机器人详情页地图加载慢卡顿优化方案 1. 背景

Androidiot扫地机器人设备详情页地图加载慢卡顿优化方案

1. 背景

1.1 当前探鸽设备详情页存在几个体验问题：

进入设备详情页时地图加载慢。
第一次进入详情页时，操作指引和 loading 展示顺序冲突。
加入地图缓存后，部分场景地图不刷新。
地图管理切换、删除、保存地图后，详情页可能继续读取旧缓存。
快速建图成功后，云端地图生成有延迟，详情页地图没有及时刷新。
清扫中地图缓存刷新可能导致地图跳变。
杀死App后重新进入，地图先显示，禁区后显示，视觉上不同步。
路径数据缓存后，频繁杀 App/重新进入会导致轨迹或机器点跳变。
P2P连接较慢，导致地图、路径、禁区等实时数据到达较晚。
快速切换设备列表和详情页路径和地图会有丢失情况

1.2 本次修改围绕以下目标展开：

- 第一次进入详情页：先显示操作指引，再进入详情页显示一次 loading。

- 第二次及以后进入详情页：不显示 gif loading。

- 地图缓存只用于提升首屏地图显示速度。

- 地图管理、快速建图、保存/删除/切换地图后，缓存必须刷新或失效。

- 清扫中不能因为缓存或地图管理数据导致实时地图跳变。

- 禁区可以缓存，路径不持久化缓存。

- 所有地图相关变更统一走缓存刷新入口，避免散落逻辑导致漏刷新。

-快速切换设备列表和详情页不做5s限制，每次都全量请求数据

2. 此次修改解决了哪些问题

2.1 首次进入详情页操作指引和 loading 顺序问题

原问题

第一次进入设备详情页时：

- 详情页会立即显示 loading。

- 同时固件信息回调里又会弹出 OperationGuidelineActivity。

- 操作指引覆盖了 loading，导致用户看不到加载动画。

- 后续每次进入也可能继续显示 gif loading。

修改后逻辑

目标流程：

第一次进入详情页

-> 显示操作指引

-> 返回详情页

-> 显示一次 gif loading

第二次及以后进入详情页

-> 不显示 gif loading

关键点

使用 pendingShowFirstGifLoading 标记操作指引返回后需要展示 loading。
showGifLoading() 内部通过 HawkUtil.getFirstStartMap() 判断是否为第一次。
第一次显示后立即 HawkUtil.setFirstStartMap(false)。
后续进入详情页直接隐藏 loading。

解决结果

首次进入顺序正确。
后续不再重复显示 gif loading。
避免操作指引覆盖 loading。
避免 loading 每次进入都闪一下。

2.2 地图缓存导致地图管理变更后不刷新的问题

原问题

加了地图缓存后，详情页会先读本地缓存：

进入详情页

-> 读取本地地图缓存

-> 快速显示地图

但以下场景会导致缓存过期：

地图切换成功。
地图删除成功。
删除全部历史地图成功。
地图保存开关变化。
保存/替换地图成功。
快速建图成功。
云端地图无当前使用地图。

如果不清缓存，下次进详情页会看到旧地图。

修改后方案

在 AbstractMapDataFetcher 中封装统一入口：

open fun invalidateCurrentUsedMapCache() {}

open fun reloadCurrentUsedMapCache(delayMillis: Long = 0L) {

getMultiMapsFromCloud()

}

在 TanGeMapImpl 中实现实际逻辑：

override fun reloadCurrentUsedMapCache(delayMillis: Long) {

clearCurrentUsedMapCache()

tanGeDevice.scope.launch {

if (delayMillis > 0) {

delay(delayMillis)

}

getMultiMapsFromCloud()

}

所有地图变更场景都统一调用：

device.mapProxy.reloadCurrentUsedMapCache(...)

覆盖场景

地图切换成功

useMap 成功

-> 清地图缓存

-> 拉云端地图列表

-> 找当前使用地图

-> 更新 currentMap 和缓存

地图删除成功

deleteMap 成功

-> 清地图缓存

-> 拉云端地图列表

-> 有当前地图则写缓存

-> 无当前地图则清 currentMap 和缓存

删除全部历史地图成功

deleteSweeperHistoryData 成功

-> 清缓存

-> 拉云端地图

-> 云端无地图时清 currentMap 和缓存

地图保存开关变化

地图保存开关变化成功

-> 清缓存

-> 拉云端地图

地图保存 / 替换成功

replaceMap 成功

-> 清缓存

-> 拉云端地图

快速建图成功

快速建图比较特殊，成功回调通常只是“命令发送成功”，不是“云端地图已经生成”。

所以使用延迟刷新：

快速建图成功

-> 清缓存

-> 延迟 5 秒

-> 拉云端地图

解决结果

地图管理变更后不会继续读旧缓存。
地图切换、删除、保存、快速建图后都有统一刷新入口。
页面不再直接操作 Hawk 缓存，减少遗漏。

2.3 云端地图回来后自动同步缓存

原问题

缓存只在详情页读取时使用，但云端地图回来后没有形成稳定的缓存更新规则。

修改后逻辑

TanGeMapImpl.getMultiMapsFromCloud() 统一负责：

云端有当前使用地图

-> 更新 currentMap

-> 写入缓存

云端没有当前使用地图

-> currentMap = null

-> 清缓存

解决结果

云端数据成为缓存的权威来源。
缓存不会长期停留在旧状态。
云端地图为空时旧缓存会被清除。

2.4 清扫中地图跳变问题

原问题

清扫过程中，实时地图正在更新。如果此时触发 getMultiMapsFromCloud()，返回的是地图管理中的静态地图。

原逻辑可能直接：

currentMap.postValue(currentUsedMap)

导致：

实时清扫地图

-> 被地图管理静态地图覆盖

-> UI 跳变

另外，清扫中实时地图如果写入“当前使用地图缓存”，下次进入也可能读到临时地图。

修改后原则

清扫中 / 暂停中 / 重定位中：

- 不允许地图管理地图覆盖 currentMap

- 不把实时清扫地图写入当前使用地图缓存

非清扫状态：

- 正常更新 currentMap

- 正常写缓存

修改后逻辑

在 TanGeMapImpl.getMultiMapsFromCloud() 中增加状态判断：

val shouldUpdateCurrentMap = shouldApplyMapManagerMapToCurrentMap()

if (currentUsedMap != null) {

if (shouldUpdateCurrentMap) {

currentMap.postValue(currentUsedMap)

}

cacheCurrentUsedMap(currentUsedMap)

}

在实时地图缓存 hook 中：

override fun onCurrentMapUpdatedByRealtimeData(map: MapEditInfoBean) {

if (!isCleaningOrRelocating()) {

cacheCurrentUsedMap(map)

}

覆盖状态

Smart
Cleaning
Relocating
其他 isWorkingOrPause() 包含的工作/暂停状态

解决结果

清扫中实时地图不会被地图管理静态地图覆盖。
清扫中不会把临时实时地图写入持久化缓存。
避免清扫中地图跳变。
非清扫状态地图管理功能仍然正常。

2.5 禁区数据加载比地图慢的问题

原问题

杀死 App 后重新进入详情页：

地图缓存先显示

禁区数据等设备上报后才显示

导致用户看到：

先有地图

过一会儿禁区才出现

修改后方案

禁区属于相对稳定配置数据，适合缓存。

在 TanGeFunctionality 中增加禁区缓存：

收到禁区数据

-> 解析禁区

-> 更新 forbiddenZone

-> 写入 Hawk 缓存

初始化时：

restoreCachedMapAccessoryData()

-> restoreCachedForbiddenZone()

并且禁区恢复使用同步赋值：

tanGeDevice.forbiddenZone.value = array?.toList().orEmpty()

而不是异步：

postValue()

解决结果

冷启动时可以同步恢复禁区。
禁区和地图缓存展示时机更接近。
后续设备实时上报禁区后仍会覆盖缓存。

2.6 路径缓存导致频繁重进地图跳变的问题

原问题

路径数据一开始也做了缓存：

收到路径数据

-> 写入 Hawk

杀死 App 后重进

-> 恢复旧路径

-> 等新路径上报

-> 从旧路径跳到新路径

清扫中路径是强实时数据，不适合持久化。

修改后方案

路径不再持久化缓存。

当前进程内仍然保留：

currentPathData = extendedData.data

但不写 Hawk：

private fun cachePathData(pathData: ByteArray) {

clearCachedPathData()

}

初始化时也清掉旧路径缓存：

restoreCachedMapAccessoryData()

-> restoreCachedForbiddenZone()

-> clearCachedPathData()

解决结果

杀 App 后不会恢复旧路径。
避免旧路径到新路径的跳变。
当前运行期间仍能正常实时绘制路径。
禁区缓存不受影响。

3. 此次所有修改遇到的问题

3.1 操作指引和 loading 的时机冲突

最初尝试让地图 loading 先显示，再弹操作指引。后来需求调整为：

第一次进入：操作指引 -> 详情页 loading

因此需要把 loading 展示从 onCreate() 中移除，改为操作指引返回后的 onChildResume() 控制。

3.2 地图缓存刷新入口太分散

最开始地图缓存只在 TanGeMapImpl.getMultiMapsFromCloud() 里写入。但地图变化的入口有很多：

详情页保存地图
地图管理切换地图
地图管理删除地图
删除全部历史地图
地图保存开关变化
快速建图

如果每个地方单独处理缓存，容易漏掉。

最终改为统一调用：

reloadCurrentUsedMapCache()

3.3 快速建图成功不等于地图生成完成

快速建图成功回调只是命令发送成功，云端地图可能还没生成。如果立即拉地图，经常还是旧数据。

最终采用：

快速建图成功

-> 延迟 5 秒

-> 再拉云端地图

这个方案能解决大部分情况，但如果云端更慢，仍可能需要轮询增强。

3.4 清扫中地图管理数据和实时地图冲突

地图管理地图是静态当前使用地图。清扫中的地图是实时变化地图。

两者都写 currentMap，会互相覆盖，造成跳变。

最终方案是：

清扫中只允许实时地图刷新 currentMap

地图管理数据只刷新列表和缓存，不覆盖 currentMap

3.5 禁区和路径不能同样缓存

最初路径也尝试缓存，但路径属于实时数据，会导致重进后跳变。最后区分为：

禁区：配置数据，可以缓存

路径：实时数据，不持久化缓存

4. 此次修改引起的新问题及遗留问题

4.1 已发现并解决的新问题

问题一：清扫中地图跳变

原因：

getMultiMapsFromCloud() 返回后覆盖 currentMap

解决：

清扫中不允许地图管理地图覆盖 currentMap

问题二：路径缓存导致重进跳变

原因：

旧路径缓存被恢复，随后新路径覆盖，UI 跳变

解决：

路径不再持久化缓存

问题三：禁区恢复晚于地图

原因：

地图同步 setValue

禁区异步 postValue

解决：

禁区缓存恢复改为同步 value

4.2 当前没有继续保留的高风险问题

以下问题当前已规避：

旧地图缓存长期残留。
删除地图后仍显示旧地图。
切换地图后详情页继续显示旧缓存。
清扫中被静态地图覆盖。
路径缓存导致轨迹跳变。
后续进入详情页重复显示 gif loading。

4.3 仍然存在的遗留问题

遗留问题一：快速建图只延迟刷新一次

当前快速建图逻辑是：

成功回调

-> 延迟 5 秒

-> 拉一次云端地图

如果设备或云端生成地图超过 5 秒，仍可能拉不到最新地图。

更稳的方案是轮询：

快速建图成功

-> 每 5 秒拉一次

-> 最多 3 到 5 次

-> 拉到地图数量变化或当前地图变化后停止

已解决。

现在是：

每 5 秒拉一次

最多 3 次

地图数量变化或当前 mapId 变化后停止

遗留问题二：禁区缓存可能短时间展示旧配置

禁区是配置数据，适合缓存。但如果用户在其他端修改禁区，当前 App 杀死后重进，短时间内会先显示旧禁区，等设备上报后再更新。

这是缓存类方案的通用问题。

可接受原因：

禁区变化频率低。
实时上报会覆盖。
比“地图先出、禁区后出”体验更好。

更稳方案：

禁区缓存增加版本号 / 时间戳 / 地图 ID 绑定

地图 ID 变更时清禁区缓存

现在：

禁区缓存绑定 deviceId + mapId

地图变化时清禁区缓存

云端无当前地图时清禁区缓存

仍然只存在一种理论极端情况：

同一张 mapId 的禁区在其他端被修改

当前 App 离线重进

因为协议里没有禁区版本号/更新时间，客户端无法判断这份缓存是否过期，这种情况只能等设备/P2P 上报后覆盖。

这个不是本次代码能完全消除的问题，除非后端或设备协议提供禁区版本号

遗留问题三：地图缓存和禁区缓存没有强绑定地图 ID

当前缓存 key 是设备维度：

tange_map_cache_deviceId

tange_forbidden_zone_cache_deviceId

如果未来设备支持多地图且不同地图有不同禁区，最好升级为：

tange_forbidden_zone_cache_deviceId_mapId

当前如果禁区本身是设备全局数据，则不用改。

已解决禁区部分。

现在禁区缓存 key 是：

tange_forbidden_zone_cache_deviceId_mapId

地图缓存仍是：

tange_map_cache_deviceId

这是合理的，因为当前使用地图缓存本身就是“当前使用地图”的一份快照，地图切换时会清缓存并重拉，不需要每张地图都持久化一份地图缓存。

5. 当前最终缓存策略

5.1 可以缓存的数据

数据	是否缓存	原因
当前使用地图	是	首屏提速
禁区	是	配置型数据，稳定
云端地图列表	间接刷新	由 `getMultiMapsFromCloud()` 获取
地图管理当前使用地图	是	地图加载
地图保存状态	不单独缓存	设备状态上报即可

5.2 不建议持久化缓存的数据

数据	是否缓存	原因
路径数据	否	强实时，缓存会跳变
机器当前位置	否	强实时，缓存会跳变
定点清扫点	否	临时任务状态
划区清扫区域	否	当前任务状态
选区清扫	否	当前任务状态
清扫面积/时间	不作为地图缓存	实时状态上报即可
电量	不作为地图缓存	状态上报即可

6. 推荐的最终数据流

6.1 进入详情页

init device

-> restoreCachedMapAccessoryData()

-> 恢复禁区缓存

-> 清旧路径缓存

-> showCachedMapFirstIfAvailable()

-> 读取当前使用地图缓存

-> 设置 currentMap

-> mapDataReady = true

-> getMultiMapsFromCloud()

-> 刷新云端地图

-> 非清扫状态更新 currentMap

-> 更新/清理地图缓存

-> P2P 实时数据回来

-> updateMapData()

-> 刷新实时地图

-> 非清扫状态才写地图缓存

-> 禁区上报

-> parseForbidZone()

-> 更新 forbiddenZone

-> 写禁区缓存

-> 路径上报

-> currentPathData = data

-> parseTanGePath()

-> 不写持久化缓存

6.2 地图管理操作

切换 / 删除 / 保存开关变化

-> reloadCurrentUsedMapCache()

-> 清缓存

-> 拉云端地图

-> 更新 currentMap/cache

6.3 快速建图

快速建图成功

-> reloadCurrentUsedMapCache(5000L)

-> 清缓存

-> 延迟 5 秒

-> 拉云端地图

7. 行业内 P2P 连接慢的通用解决方案

P2P 慢通常不是单点问题，而是由以下因素叠加：

设备低功耗休眠。
NAT 穿透慢。
局域网发现慢。
云端中转兜底慢。
TLS/鉴权握手耗时。
App 进入页面才开始连接。
设备端同时连接数限制。
网络弱、路由器隔离、IPv6/IPv4 切换等问题。

行业常见优化方案如下。

7.1 预连接 Pre-connect

思路

在用户进入详情页之前就开始连接设备。

例如：

首页设备列表展示

-> 对可见设备预连接 P2P

-> 用户点击详情页时连接已建立

适用

设备详情页依赖实时视频/地图/P2P 数据。
用户大概率会点击某个设备。

注意

不要对所有设备无限预连接。
要限制数量，例如只预连接最近使用设备或当前可见设备。
避免占用设备连接数。
探鸽sdk预建联最多支持3台设备，所以此方案不可行
如果用户频繁切换首页和详情页，多设备同时全量请求也会有问题

7.2 短时间保活

思路

App 从详情页退出、切后台、锁屏后，不立刻断开 P2P，而是保活一段时间。

你当前代码已有类似思路：

private static final long FOREGROUND_RECONNECT_GRACE_PERIOD_MS = 60_000L;

即 5秒内回到前台，不重新连接。

好处

避免频繁断开/重连。
用户短时间切后台回来，地图/路径可继续快速显示。

注意

保活时间不要太长。
设备低功耗产品要考虑功耗。
后台策略要符合系统限制。

7.3 分层加载：缓存先行，P2P 后补

思路

P2P 慢不可完全避免，因此 UI 不应该完全等 P2P。

这也是本次修改采用的方向。

7.4 连接状态机管理

不要在多个地方直接调用：

connect()

reconnect()

disconnect()

建议统一封装状态机：

Idle

Connecting

Connected

Failed

Retrying

Disconnected

并处理：

避免重复 connect。
避免多个页面同时 reconnect。
失败重试加退避。
超时兜底。
前后台状态统一处理。

7.5 超时与降级

通用策略

P2P 连接 3 秒内成功：展示实时数据

P2P 连接超过 3 秒：继续展示缓存 + loading

P2P 连接超过 8 秒：提示连接失败或弱网

P2P 后续连接成功：自动补齐实时数据

你当前已有：

private static final long P2P_RECONNECT_TIMEOUT_MS = 8_000L;

这是合理的。

7.6 局域网优先，云端中转兜底

行业内常见 P2P 连接路径：

LAN 直连

-> NAT P2P

-> TURN/Relay 云端中转

优化方向：

同 Wi-Fi 下优先 LAN。
NAT 穿透失败快速切 Relay。
不要长时间卡在单一路径。
记录每种路径耗时，做策略优化。

7.7 连接结果缓存和弱网诊断

记录：

最近一次连接成功时间。
最近一次失败错误码。
平均连接耗时。
是否局域网直连。
是否中转。
设备是否低功耗休眠。
当前网络类型 Wi-Fi / 4G / 5G。

用于后续策略：

7.8 数据通道和 UI 解耦

不要让详情页 UI 完全依赖 P2P 首包。

7.9 避免进入页面重复初始化

常见慢的原因之一是：

onCreate

-> init device

-> init functionality

-> query version

-> get cloud maps

-> connect p2p

-> request dp

多个请求同时打出去，反而拖慢。

建议：

设备对象复用。
功能配置只在必要时刷新。
地图云端请求和 P2P 请求并行但互不阻塞。
页面返回后短时间保留设备连接。

7.10 快速失败与重试退避

重试不要固定 1 秒无限重试。

8. 后续建议

8.1 快速建图刷新改成轮询

当前是延迟 5 秒拉一次。

建议升级为：

快速建图成功

-> 清缓存

-> 5 秒后拉地图

-> 如果地图数量/当前地图没变化

-> 再等 5 秒

-> 最多 3 次

这样能覆盖云端生成地图更慢的情况。

8.2 禁区缓存绑定 mapId

如果探鸽设备禁区是每张地图独立的，建议把缓存 key 从：

deviceId

升级为：

deviceId + mapId

避免多地图切换时短暂显示上一张地图的禁区。

行业里做地图/禁区/虚拟墙这类数据，一般不会只靠缓存，也不会只靠 P2P 上报，而是三层数据源：

第 1 层：本地缓存

用于首屏秒开，但不作为最终权威数据。

第 2 层：云端 / 地图管理数据

用于登录后、换设备后、缓存被清后快速恢复配置数据。

第 3 层：P2P / 设备实时上报

作为最终实时校正数据。

也就是说，正确链路应该是：

进入详情页

-> 先读缓存，有就显示

-> 缓存没有，就从地图管理云端数据里的 forbidData 恢复禁区

-> P2P 禁区上报后，再覆盖禁区并写缓存

退出登录清缓存后，重新登录时虽然没有本地缓存，但仍可以从 getMultiMapsFromCloud() 返回的 currentUsedMap.forbidData 里恢复禁区。

8.3 建立统一 MapRuntimeCacheManager

当前缓存逻辑已经统一到 mapProxy，但后续还可以抽象成：

MapRuntimeCacheManager

管理：

当前地图缓存
禁区缓存
缓存版本
mapId 绑定
清扫状态保护
过期策略

这样后续扩展更安全。

9.快速切换设备列表和详情页：

路径和地图数据会缺少，之前的请求设备数据机制限制

由于之前的需求是退到后台5s内断开连接,所以连接还在
但是请求设备全量地图数据有限制，5s内不请求，
如果地图路径在退出详情页之前是10帧，返回首页后绘制到13-15帧，此次如果快速切换在5s内就不会请求地图数据，导致刷新丢失，
5s后又请求了全量数据，所以会刷新，
路径、地图等实时数据都会有跳变不同步问题
解决方法：去掉5s限制，但是可能会有大量数据频繁请求问题，多设备同时请求数据量很大

10.待确定的修改：

退出登录是否清除缓存
若不清除下次登录可能会出现回充中等状态还是之前的缓存地图，
若清除这个地图的显示逻辑是按之前的需求还是新需求有待确定(没有地图之前是显示回充中状态，有地图是显示地图)

11.当前已解决的问题：

退出登录静态清理没有设备 ID 的问题
地图缓存清理
禁区缓存清理
历史路径缓存清理
禁区缓存按 mapId 绑定
快速建图改成轮询刷新
清扫中地图不被地图管理数据覆盖
路径不持久化，避免重进跳变
退出登录禁区数据没有及时刷新显示
遗留问题修改

12.重新登录后缓存数据刷新问题：

行业内通用方案：

行业里做地图/禁区/虚拟墙这类数据，一般不会只靠缓存，也不会只靠 P2P 上报，而是三层数据源：

第 1 层：本地缓存
用于首屏秒开，但不作为最终权威数据。
第 2 层：云端 / 地图管理数据
用于登录后、换设备后、缓存被清后快速恢复配置数据。
第 3 层：P2P / 设备实时上报
作为最终实时校正数据。
也就是说，正确链路应该是：
进入详情页
-> 先读缓存，有就显示
-> 缓存没有，就从地图管理云端数据里的 forbidData 恢复禁区
-> P2P 禁区上报后，再覆盖禁区并写缓存
退出登录清缓存后，重新登录时虽然没有本地缓存，但仍可以从 getMultiMapsFromCloud() 返回的 currentUsedMap.forbidData 里恢复禁区。
提前建立p2p连接方案:

进入设备详情页前把需要的地图、路径、禁区等全量数据提取准备好，这样全量拉取按数据在多个设备会有线程并发和服务器同时请求压力过大，设备响应卡死问题，最多支持3个设备，超过3个设备只取前3个，后面的设备App利用线程池或者协程排队获取，要不然还是会有问题.

13. 总结

此次修改完成了以下核心目标：

修复首次操作指引和 loading 展示顺序。
修复后续重复显示 gif loading。
增加当前使用地图缓存，提高首屏速度。
地图切换、删除、保存、快速建图后统一刷新缓存。
云端地图回来后自动写缓存，无地图时自动清缓存。
清扫中不允许地图管理静态地图覆盖实时地图，避免地图跳变。
禁区数据支持缓存，减少地图先出禁区后出的割裂感。
路径数据取消持久化缓存，避免重进后轨迹跳变。
地图刷新入口统一封装，降低后续漏刷风险。
保留 P2P 实时数据作为最终权威数据，缓存只做首屏体验优化。
清扫中快速切换首页和详情页地图路径丢失，去掉5s内不请求地图数据限制
登录和退出登录缓存问题。
禁区数据缓存做3级缓存处理。
其他问题和场景需要大量测试，根据实际需求修改。
遗留问题修改。
p2p提前建联问题及方案实施验证