laoyang
88fa38ecf9
导航修复：加系统地理编码拿坐标，改用 openLink 拉起高德
## 用户反馈
「智橙的导航那个地方功能不好用，跳转到高德，说是高德提示说什么不支持。
我记得同步日历它那个是支持的，所以你看一下同步日历是怎么实现的。」
## 对照 SyncCalendar（实测能用）找出两个致命差异
| 环节 | SyncCalendar | 我们原来的实现 |
|---|---|---|
| 拿坐标 | `geoLocationManager.getAddressesFromLocationName()` | 无（只能从地点文字正则抠） |
| 坐标系 | WGS84 → GCJ02 本地转换 | 无 |
| 高德 URI | `amapuri://route/plan/`（**带尾斜杠**） | `amapuri://route/plan`（无斜杠） |
| 无坐标时 | 仍给 dname 尽力而为 | 退到 `amapuri://poi?keyword=` |
| 拉起方式 | `ctx.openLink()` | `startAbility({uri})` 隐式 Want |
**为什么高德报「不支持」：**
1. **没有坐标**。`route/plan` 的 `dlat/dlon` 是**必填**，
我们只在"用户恰好把坐标粘进地点文字"时才给 ⇒ 绝大多数情况给不出。
2. **退路 `amapuri://poi?keyword=` 在新版高德已废弃** ——
那正是「不支持」的直接来源。
3. URI 少了尾斜杠（`route/plan` vs `route/plan/`）。
## 另外：原文件有一条未经验证的错误结论
原文写着：
「拉起方式用 startAbility 的隐式 Want，而不是 openLink：
openLink 走的是 App Linking，会报 16000019 No matching ability is found」
但 SyncCalendar **就是用 openLink 拉起高德的**，而且它的 `module.json5`
**根本没声明 `querySchemes`** —— 说明 openLink 不需要那套声明。
原结论是推断、未经实测，本次改用 openLink。
## 改动
### FbNav.ets
- 新增 `geocodeBySystem()` —— 系统正向地理编码拿 WGS84 坐标
- 新增 `wgs84ToGcj02()` —— 火星坐标转换（**必须转**，否则偏 100~700 米，
而且不报错，只是位置不对，比"打不开"更难排查）
- 新增 `openLinkWithFallback()` —— openLink 优先，失败退 startAbility
- `fbOpenNavigation()` 改为 async：先求坐标，再依次试各家地图
- 高德 URI 修正：`amapuri://route/plan/?sourceApplication=FamilyBook&dlat=..&dlon=..&dname=..`
- 关键字退路改成 `route/plan/?dname=` 形式（旧 `poi?keyword=` 已废弃）
### 两个调用方补 catch
`fbOpenNavigation` 变 async 了，不接住 rejection 会报未处理异常。
## 不需要新权限
`getAddressesFromLocationName()` 是「地址→坐标」换算，不是读设备位置，
不需要 `ohos.permission.LOCATION`。SyncCalendar 也没声明，实测可用。
## 验证
- 编译：`build_hap debug` → BUILD SUCCESSFUL
- **真机验证未做**（设备未连接）。需要确认：
· 点地点能否直接进高德**路线规划页**（不是搜索页）
· 目的地是否**位置准确**（验证 GCJ02 转换生效）
· 没装高德时是否正常降级到下一家 / 复制地点
## 保留
多地图探测（高德/百度/花瓣/腾讯）、复制地点兜底、
「坐标失败 → 关键字重试」的链都保留。
2026-11-03 10:28:28 +08:00
..
2026-11-03 10:28:28 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00
2026-10-11 22:07:48 +08:00