callable仅负责异步清洗数据,不参与聚合;真正聚合由clustermanager执行,需将清洗后的myitem列表传入additems(),且必须在地图加载完成回调中调用并触发状态更新。

直接在地图聚合点的经纬度清洗与交互流程中使用 Callable 抓取带位置注解的 DTO,并不能自动完成聚合——Callable 本身只是 Java 并发接口,用于异步执行并返回结果,它不参与地图渲染、坐标计算或聚合逻辑。真正起作用的是聚合管理器(如 ClusterManager)和数据准备阶段的清洗处理。
明确职责边界:Callable 不做聚合,只辅助数据准备
在百度或高德地图 SDK 中,点聚合由 ClusterManager 控制,它依赖已清洗、结构合规的 MyItem(或你自定义的带 @LatLng 注解的 DTO)。Callable 可用于:
- 异步加载原始地址列表(如从数据库/HTTP 接口批量获取)
- 并发调用地理编码服务(如高德 API),将模糊地址转为标准经纬度
- 对返回的 DTO 批量校验、去重、过滤无效坐标(如
lat=0.0, lng=0.0或超界值) - 将清洗后的 DTO 列表作为最终输入交给
clusterManager.addItems()
DTO 需显式支持位置信息,注解本身不自动解析
假设你定义了如下 DTO:
public class LocationPoint {
private String id;
private String name;
@Latitude private double lat;
@Longitude private double lng;
// getter/setter
}
但仅加注解不会让 SDK 识别坐标——你必须在实现 ClusterItem 接口时主动读取这些字段:
public class MyItem implements ClusterItem {
private LocationPoint data;
public MyItem(LocationPoint data) { this.data = data; }
@Override
public LatLng getPosition() {
return new LatLng(data.getLat(), data.getLng());
}
// 其他方法...
}
清洗环节若发现 lat/lng 异常,应在 Callable 的 call() 方法中直接跳过或修正,而非依赖注解“自动修复”。
典型清洗+聚合流程示例
以从地址列表生成聚合点为例:
- 用
ExecutorService.submit(new Callable<list>>(){...})</list>异步执行以下操作: - 遍历原始地址 → 调用高德地理编码接口 → 解析 JSON 得到
location="116.40,39.96" - 拆分字符串,校验数值范围(如纬度必须 ∈ [-90, 90])、剔除空/零值
- 封装为
MyItem实例,加入结果列表 - 主线程拿到清洗后列表,调用
mClusterManager.addItems(resultList)
注意聚合触发时机
清洗再快,若未等地图加载完成就添加聚合点,也不会显示。必须确保:
-
addItems()在OnMapLoadedCallback内执行 - 调用后需触发一次地图状态更新(如
setMapStatus(...)),否则聚合簇不生效 - 避免在
Callable中直接操作 UI 或地图对象(线程不安全)










