简介：面向Android开发者的百度地图导航功能实现项目，完整覆盖了从SDK集成、权限声明、用户定位、起终点设置到路线规划与导航引导的典型流程，适合需要接入地图导航能力的移动应用开发者作为工程参考。压缩包为rar格式，共1343个文件，大小22.55MB，以xml布局与地图配置、png图标资源、json数据、class与jar库文件为主，同时包含aidl接口定义、gradle构建脚本及可直接安装的app-debug.apk调试包，目录结构清晰，便于直接运行与二次开发。已有514人学习，可结合源码和可执行APK快速核验百度地图API的LocationClient定位、RoutePlanSearch路线计算、Overlay路线绘制等关键环节，降低自行集成与排错成本。阅读代码还能了解AndroidManifest权限动态申请、多出行方式规划策略和导航过程中语音提示与视角更新的实现思路，适合用于功能预研、课设仿真或实际项目移植。 做 Android 导航功能，很多人第一反应是“直接调地图 SDK 不就行了”，但真正落到自己项目里，尤其是要做车机导航、室内导览、外业巡检这种定制化场景时，事情远没有想的那么简单。市面上高德、百度、腾讯的地图 SDK 确实成熟，接一个 Demo 可能一下午就搞定，但到了生产环境，定位漂移、路线偏航、引导播报、功耗控制、弱网兜底这些问题就会一个个冒出来。
我最近刚好把一个导航模块从零到一完整做了下来，从方案选型到定位、地图、路线、引导、踩坑，整个过程收获挺多。这篇就把我的实现思路、关键环节和排查实录完整分享出来，希望对正在做或者准备做 Android 导航功能的朋友有帮助。内容偏工程实践，不会讲太多 SDK 的 API 流水账，重点放在“为什么这么做”以及“坑在哪里”。
1. 方案选型与整体设计思路
1.1 技术选型对比：为什么不自研地图
在做导航功能前，第一个绕不开的问题就是地图引擎从哪来。自研地图渲染引擎成本极高，光是地图数据的获取、切片、路网拓扑、行政区划层级这套东西，就不是一个小团队能短期搞定的；而且还要持续维护数据更新和纠偏机制。对绝大多数业务来说，直接用成熟的地图服务商 SDK 是性价比最高的方案。
市面上主流的可选方案大致是这三类。
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 高德地图 SDK | 国内路网数据最全，导航引导能力最强，文档齐全 | SDK 体积较大，部分高级能力收费 | 国内正式商用项目首选 |
| 百度地图 SDK | 生态完善，POI 数据丰富，个性化地图样式支持好 | 坐标系采用 BD-09，和 GPS 坐标转换要多一层 | 对百度生态依赖较强的产品 |
| 开源方案（osmdroid + 自绘路由） | 完全可控，无商业限制，可深度定制 | 路网数据需要自己处理，导航引导算法需自研，成本极高 | 离线场景、特殊行业定制 |
我这次选的是高德地图 SDK。理由很直接：国内导航场景下，高德在路径规划和实时路况方面积累最扎实，而且导航 SDK 自带转向提示、语音播报、电子眼提醒这些成熟能力，可以省掉大量从零造轮子的时间。另一个隐性优势是它的坐标系 GCJ-02 在国内是事实标准，和 GPS 原始坐标的转换有现成方案，后面做定位纠偏会省很多事。
1.2 架构设计：把导航能力拆成三层
不管用什么地图 SDK，工程上都不建议把业务代码直接堆在 Activity 或 Fragment 里，否则后期维护会非常痛苦。我采用的是三层结构，分离得很干净。
第一层是数据层，负责定位数据、路线规划结果、导航状态这些原始数据的获取与缓存。第二层是业务层，封装导航状态机、偏航判断、到达判断、语音播报触发这些核心逻辑，对上层只暴露简洁的接口。第三层是展示层，包括地图、路线绘制、导航引导 UI、悬浮窗这些纯视觉相关的组件。
这样一个模块化的好处是，后续如果要替换地图 SDK，只需要改数据层和部分业务层；如果要做车机版本，只需要换展示层的交互方式，核心逻辑可以完整复用。我实际开发中把导航状态机抽成了一个独立的类，里面用枚举管理空闲、规划中、导航中、偏航、到达这些状态，上层 UI 全部通过回调感知状态变化，代码清晰了很多。
1.3 定位方案：GPS不是唯一选项
导航的第一步是“知道自己在哪”。很多新手会默认用 GPS，但实际在室内、高架下、隧道里 GPS 信号会直接丢失。我的做法是融合定位：优先用 GPS，信号弱的时候切到基站和 Wi-Fi 辅助定位。高德的定位 SDK 自带融合能力，但有个细节需要注意——它的定位回调默认是单次定位，切到连续定位后要留意功耗问题，我一般根据场景动态调整定位频率，导航中每 2 秒一次足够了，不需要跑到每秒钟一次。
另外，定位权限是 Android 6.0 之后必须动态申请的，而且是精确定位权限，不能只申请粗略定位。这个后面踩坑部分会细说。
2. 地图能力搭建：导航的基础设施
2.1 地图初始化与基础配置
高德地图的初始化不算复杂，但有几个容易忽略的点。首先是 AndroidManifest 里要正确配置 Key，这个 Key 是和包名、SHA1 签名绑定的，调试签名和正式签名要分别申请，否则会出现“鉴权失败，地图无法显示”的诡异问题。
其次是<meta-data>标签里要声明com.amap.api.v2.apikey，这个经常被漏掉。写代码时onCreate里要先调用MapsInitializer.initialize(context)，等初始化完成后再设置地图属性，不然某些机型上会出现MapView空白。
地图加载完成后，我通常会先关闭一些默认交互，比如旋转、倾斜，只在特定场景放开，不然在导航过程中用户一个误操作地图就转晕了。地图 UI 的个性化样式可以用UiSettings控制，比如隐藏默认的缩放按钮、指南针，让整个界面更干净。
2.2 轨迹绘制：用 Marker 和 Polyline 画出行车轨迹
导航过程中把走过的路画出来，这个功能虽然简单但很实用。实现的思路是维护一个坐标点列表，每次定位回调把新坐标加进去，然后用Polyline更新绘制。
这里有一个性能陷阱：如果每一个定位点都走一次polyline.setPoints()，当点多了之后 UI 会明显卡顿。我的优化方案是分批次更新，比如每累计 20 个点才刷新一次Polyline，中间的点先缓存在内存里。绘制的时候给Polyline设置了宽度和颜色，让它看起来更像实际的行驶轨迹。
Marker 用来标记当前车辆位置，这个 Marker 的方向要随着航向角一起旋转，否则看起来会非常奇怪。高德的定位 SDK 返回的经纬度里带bearing字段，直接用这个做 Marker 的旋转角度即可。
2.3 电子围栏与关键点播报
除了基础的地图展示，导航场景里经常会遇到“到了某个区域提醒一下”的需求。比如车队管理里快到目的地了要通知调度，或者巡检场景里到了特定点位要自动打卡。这个功能我用的是高德的Geofence围栏接口，注册一个中心点和半径，进入和离开都会触发回调。
这里有个容易踩的坑：围栏回调在部分机型上延迟比较严重，尤其是息屏状态下。后来我在业务层加了一个兜底逻辑，每次定位回调时手动计算当前点与目标点的距离，小于阈值就直接触发进入逻辑，不再等围栏回调，实测可靠性高了很多。
3. 路线规划与导航引导引擎
3.1 路线规划：算出路之前先算好参数
路线规划是导航的核心输入。高德提供了驾车、步行、骑行等多种路径规划接口，我这次做的场景是驾车导航，用的是RouteSearch的DriveRouteQuery。
构造路径规划请求时，有几个参数值得认真调：
strategy策略：有速度优先、费用优先、距离优先等选项，默认是速度优先。实际用下来，如果是城市内通勤，考虑实时路况的速度优先体验最好；如果是跨城长途，费用优先可能更符合用户预期。waypoints途经点：最多支持 16 个，需要注意途经点的顺序会影响规划结果。avoidRoad避让道路：有时候施工管制或者临时封路，需要动态传入。
路径规划的回调是异步的，回调里拿到RouteResult后，我做了两件事：一是把整条路线用Polyline画到地图上；二是把路线解析成一个个导航路段保存下来，供后续引导使用。
这里还有一个坐标系问题容易踩坑：起点和终点如果是用户在地图上点的，那一定是 GCJ-02 坐标；如果是从 GPS 拿的，那是 WGS-84。直接混合使用会出现起点终点不在路线上的情况。我自己封装了一个坐标转换工具类，统一在传参前转成 GCJ-02，这个问题就彻底解决了。
3.2 导航引导状态机
路线规划做完，接下来就是导航引导。高德直接提供了AMapNavi这个类，支持模拟导航和真实导航两种模式。模拟导航很有用，开发调试的时候不需要真的开车出去，在地图上拖一下就够用了。
真正上线后我用的是真实导航模式。AMapNavi启动后，需要注册监听器来感知导航事件，核心的事件有几个：
onNaviInfoUpdate：导航信息更新，包括剩余距离、剩余时间、当前路段、下一路段、转向类型等，这是最核心的回调，我做了一个专用的NaviInfoModel来包装这些数据。onArrivedDestination：到达目的地，到这里要清理状态、结束导航、释放资源。onReCalculateRoute：偏航重算，这是导航中很关键的事件。
导航状态机的核心逻辑我画成了一个枚举流转，用NaviState记录当前状态。状态流转的触发条件都放在一个统一的NaviStateMachine里，UI 层只监听状态变化，不直接做判断，这样后续加新状态或者改逻辑只动这一处。
注意：实测发现高德导航 SDK 在部分 Android 版本上，
AMapNavi实例必须是单例，重复创建容易导致内存泄漏或者状态错乱。我在项目的 DI 容器里把它注册成了单例。
3.3 偏航判断与重新规划
偏航是导航过程中最影响体验的环节。高德默认会在偏航时自动重新规划路线，但回调触发有延迟，而且有时候用户只是在高架下短暂失锁，立刻重算反而会让路线“神经质”地变来变去。
我踩过几次坑之后，自定义了一层偏航保护逻辑：定位点偏离原定路线超过 50 米且持续 8 秒，才触发重算。这里用了一个滑动窗口计数法，每 2 秒检测一次，连续 4 次都偏离才确认偏航。这个策略在实测中大幅减少了无谓的重算，用户体感明显更好。
另外，偏航重算之后，要主动再去获取一次最新定位作为新路线的起点，避免规划接口拿到的还是旧坐标。
3.4 语音播报的接入细节
导航语音播报是高德自带的能力，默认用的是在线 TTS，需要网络。我这次做的是一个外业巡检场景，经常去偏远地区，网络不稳定，所以我换成了内置语音播报，把TTSController的语音类型设置为内置，这样播报不依赖网络，但音质比在线 TTS 稍弱，胜在稳定可用。
还有一个细节：语音播报的“叮咚”提示音和语音内容在部分手机上会互相干扰。我最后的处理是把提示音和语音内容分开调度，先播提示音，等提示音播完再调 TTS 播报正文，避免混音。
4. 常见问题与排查技巧实录
4.1 地图白屏/加载不出来
地图初始化黑屏或者白屏，90% 是 Key 鉴权问题。排查路径很固定：第一，确认 AndroidManifest 里的com.amap.api.v2.apikey和代码里的一致；第二，确认 Key 对应的 SHA1 是当前签名文件的，用 Android Studio 的 Gradle 面板里的signingReport任务可以直接输出；第三，确认包名和申请 Key 时填写的一致，包括 debug 包和 release 包的差异。
我当时踩过一个隐蔽的坑：用 Android Studio 默认的 debug 签名调试，后来切到 release 构建时忘了换 Key，地图依然白屏。后来在混淆配置里也发现com.amap.api的 keep 规则没有加全，release 包直接崩溃了。解决方案是把高德官方文档里的混淆规则原样拷贝过来，并且保证混淆后 SDK 的类名不被重写。
4.2 定位权限申请后依然拿不到定位
高德定位 SDK 在 Android 12 及以上版本上，需要额外申请ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION两个权限，缺一不可。Android 10 及以上高版本还需要在代码里判断定位开关是否打开，如果系统定位服务没开，SDK 拿到的错误码会是ERROR_CODE_LOCATION_SWITCH_OFF，这时候要引导用户去设置里打开定位。
另外，定位权限中有一个很容易忽略的点：如果应用的目标 SDK 是 Android 10 以上，申请定位权限时系统弹窗里会明确区分“仅使用期间允许”和“每次询问”。用户如果选了“仅使用期间”，在应用退到后台再回前台时，权限可能已经失效，要重新申请。实测在导航这种需要长时间前台运行的场景下，这个问题不常见，但后台保活时会暴露。
4.3 路线偏移和 GPS 漂移
路线偏移最常见的原因有两个：一是坐标系没做转换，二是定位精度本身不高。坐标系的问题在 3.1 里提过了，这里重点说定位精度。
GPS 在城市峡谷环境（两边高楼林立）下误差是很大的，偏移几十米很正常。高德的定位 SDK 有setLocationMode方法，可选 Hight_Accuracy、Battery_Saving、Device_Sensors 三种模式，我默认用高精度模式。但高精度模式下系统会频繁调用 GPS，发热和耗电都比较明显。
我的处理是做了一个精度门槛：回调里拿到Accuracy，如果大于 30 米就丢弃这个点，不参与轨迹绘制和位置更新。这样虽然丢失了一部分点，但留下的点基本是可信的。配合 4.2 里的偏航保护，整体的导航体感正常很多。
4.4 SDK 版本冲突与依赖兼容
高德地图 SDK 的com.amap.api系列依赖之间很容易出现版本冲突，比如3dmap和location的版本更新节奏不一样，如果不指定版本，Gradle 会拉最新的，但传输不同步的时候就会出现类找不到。我的做法是在build.gradle里把所有高德依赖统一固定在一个经过验证的版本组合上，不随意升级。换版本前先在分支里完整跑一遍导航流程，确认没有回归再合入主干。
4.5 常见问题速查表
| 现象 | 可能原因 | 解决方式 |
|---|---|---|
| 地图白屏 | Key 鉴权失败、SHA1 不匹配 | 核对包名、SHA1、Key，确认 meta-data 配置 |
| 定位失败 | 定位服务未开启、权限不足 | 动态申请精确定位权限，引导用户开启系统定位 |
| 路线偏移大 | 坐标系混用、定位精度差 | 统一切到 GCJ-02，Accuracy 大于 30m 丢弃点 |
| 偏航频繁重算 | 高架下 GPS 跳变 | 增加持续偏离判断，50 米 + 8 秒才触发重算 |
| Release 崩溃 | 混淆规则缺失 | 引入高德官方混淆 keep 规则 |
| 导航语音无声 | 内置语音包缺失 | 确认 assets 目录完整，或改用在线 TTS |
| 导航SDK内存泄漏 | AMapNavi 重复创建 | 全局单例管理，退出时调用 destroy |
5. 实操记录：一个最小可运行的导航流程
前面讲了很多设计思路和坑，这一节我把最小可运行的导航流程完整串一遍。从工程创建到跑起来导航，大概需要以下几个步骤。
5.1 环境准备与依赖引入
在build.gradle里加入高德地图和定位的依赖。
implementation 'com.amap.api:3dmap:9.8.0' implementation 'com.amap.api:location:6.4.0' implementation 'com.amap.api:search:9.7.0' implementation 'com.amap.api:navi-3dmap:9.8.0'版本号以官方最新为准，但记住一点——四个库的版本尽量保持同一发布周期，这样可以减少兼容问题。
5.2 基础初始化流程
Application 里做初始化：
public class NaviApplication extends Application { @Override public void onCreate() { super.onCreate(); // 地图引擎初始化 MapsInitializer.initialize(this); // 定位客户端初始化 LocationManager.getInstance().init(this); // 导航引擎初始化 AMapNavi.setPackageName(this, getPackageName()); } }AMapNavi.setPackageName这一步很多人会漏掉，不设置的话导航功能在部分机型上会随机失败。
5.3 导航启动完整流程
导航从启动到进入引导页，核心逻辑分几步。
第一步，创建AMapNavi的实例，注册导航监听器。
AMapNavi navi = AMapNavi.getInstance(context); navi.addAMapNaviListener(naviListener);第二步，起点和终点的经纬度准备好后，发起驾车路径规划。
int strategy = AMapNavi.DRIVING_AVOID_CONGESTION | AMapNavi.DRIVING_AVOID_HIGHWAY | AMapNavi.DRIVING_AVOID_COST | AMapNavi.DRIVING_DEFAULT; navi.calculateDriveRoute(start, end, null, strategy);这里 strategy 我一般统一加上 AVOID_CONGESTION，国内城市路况你懂的。
第三步，路径规划成功回调后，直接启动导航。
@Override public void onCalculateRouteSuccess(int[] ids) { navi.startNavi(AMapNavi.GPSNaviMode); }这里要留意，GPSNaviMode是真实导航，EMULATOR_NAVI_MODE是模拟导航。开发调试阶段用模拟导航就好，方便演示和测试。
第四步，导航信息更新回调里刷新 UI。
@Override public void onNaviInfoUpdate(NaviInfo info) { updateRemainDistance(info.getPathRemainDistance()); updateRemainTime(info.getPathRemainTime()); updateNextTurnIcon(info.getIconType()); updateNextRoad(info.getNextRoadName()); }实测中onNaviInfoUpdate回调频率大概每秒 1~2 次，直接拿来刷新进度条和剩余里程是够用的。
第五步，结束导航时释放资源。这里最容易出问题的地方是监听器没有移除，导致内存泄漏。规范写法是：
navi.removeAMapNaviListener(naviListener); navi.stopNavi(); AMapNavi.destroy();5.4 模拟导航的连线调试技巧
用一个真实项目落地的时候，我比较推荐先引入模拟导航联调 UI，不急着上路实测。高德支持的模拟导航需要构造模拟坐标点，可以用路径规划结果里的坐标点直接作为模拟源。
navi.setEmulatorNaviSpeed(60); // 模拟速度，单位 km/h navi.startNavi(AMapNavi.EmulatorNaviMode);这样开发机上直接跑，不需要真实 GPS 就能完整走完导航流程，方便检查和验证 UI 展示、语音播报、到达判断等核心逻辑。
6. 导航体验的细节打磨
导航功能跑通不难，但要做得好用，真正拉开差距的是细节。这里分享我实际打磨的几个点，未必每个项目都需要，但很值得参考。
6.1 剩余时间和剩余距离的刷新策略
onNaviInfoUpdate回调每秒触发一次，但如果 UI 层每次回调都去刷新，页面会比较闪烁。我的处理是只保留整秒刷新，且只在数值变化超过一定阈值时才更新显示。比如剩余距离只在变化超过 100 米时刷新，剩余时间只在变化超过 1 分钟时刷新。这样 UI 稳定很多，用户看着也不焦虑。
6.2 导航状态栏和悬浮窗
导航场景下用户经常会切到其他应用，这时候一个悬浮窗显示导航信息非常实用。实现方式是用WindowManager添加一个悬浮窗 View，实时把剩余距离、转向提示显示出来。这个功能需要SYSTEM_ALERT_WINDOW权限，国内 ROM 上还需要引导用户去设置里手动授权，这是一个天然的权限门槛，产品上要想清楚要不要做。
6.3 多目的地连续导航
巡检和物流场景经常需要一次导航多个点位。我的做法是把目的地列表维护一个数组，每到达一个点自动播报“已到达”，然后自动取下一个点重新规划和导航。这个功能基于前面说的状态机和到达判断逻辑，实现起来不算复杂，但对稳定性要求更高，尤其是连续导航多小时后内存吃紧的问题，建议在每次重新规划前主动释放上一次的路线数据。
6.4 低功耗模式
长时间导航对手机电量是巨大考验。我的优化方案是：在前台导航时保持 2 秒一次的定位频率；屏幕熄灭后降为 5 秒一次；到达目的地或暂停导航时停掉定位。实测同样的路线，低功耗模式下续航比默认模式提升接近一倍。
7. 写在最后的体会
把 Android 导航功能完整做一遍之后，我最大的感受是：地图 SDK 的接入只是整个工作的冰山一角，真正耗时的是在真实场景下处理各种边界情况。定位数据不可靠怎么办、偏航怎么判断、网络中断怎么兜底、播报延迟怎么处理，这些才是决定导航功能能不能用的关键。
如果一开始就从架构上把这些因素考虑进去，后续迭代会顺畅很多。很多项目之所以导航模块越改越乱，就是因为一开始把导航简单等同于调 SDK，等覆盖到真机场景时再打补丁，到处都是临时逻辑。
我这次分享的这套设计思路，不是一个“标准答案”，但它是一套在真实项目中跑过环境的可行方案。如果你在做的项目正好也需要导航功能，不妨先从方案选型、定位策略和偏航保护这三个方向入手，大概率能把前期的大部分坑提前排掉。
本文还有配套的精品资源，点击获取
