做一个旅游类Android项目听起来是个很常见的毕业设计方向但真正动手之后你会发现难的不是“会用某某组件”而是怎么把“智能旅游管家”这五个字拆成一个个能落地、能演示、能讲清楚的功能模块。这篇文章我会把一套完整的《基于Android智能旅游管家的设计与实现》课程项目拆开来讲从需求收敛、技术选型、数据层设计到推荐算法、路线规划、地图定位集成再到真机测试和打包答辩的经验。如果你正准备做类似题目或者想自己动手做一个带“智能感”的旅游App这篇文章应该能帮你省不少试错时间。1. 为什么最后选了“智能旅游管家”这个题目1.1 一开始我就是从游客的抱怨里立题的每次到了假期总能看到有人在朋友圈吐槽查攻略查到眼花、景点之间怎么串不知道怎么安排、到了景区门口才知道今天闭馆、明明站在文物前面却不知道看什么。这些抱怨叠加在一起其实指向一个很明确的需求游客需要的不是更多信息而是一个能把信息整理好、按场景推送给他的“旅行助手”。传统旅游App做得最多的是“信息展示”搜景点、看评论、买门票游客自己还是要花大量时间做行程编排。而“管家”这个词的核心价值恰恰是把“编排”这件事接过去。所以这个项目的立意很简单做一个Android端App能根据用户兴趣推荐景点能根据当前位置和时间自动规划一日游路线能在到达景点附近时主动播放语音讲解顺便把收藏、搜索、行程记录这些基础能力补齐。1.2 功能边界守住“管家”砍掉想当然的需求立题之后最容易犯的错误就是什么都想塞进去。我见过不少同学一开始列出一大堆功能社交分享、在线支付、AR识别、直播景点……最后多半做不完或者每个功能都只是个空壳。我当时给自己的原则是核心功能必须能闭环演示非核心功能一律砍掉。最终锁定的功能清单是这样的功能模块具体能力优先级用户系统注册、登录、偏好标签设置、退出登录高景点推荐基于兴趣标签、距离、热度、天气的综合排序高地图定位显示当前位置、周边景点、地图选点高路线规划根据当前时间与位置生成一日游顺序高语音导览进入景点附近时朗读讲解词高收藏与搜索关键词搜索、标签筛选、收藏列表中社区、支付、AR全部砍掉无砍功能的原因很直白课程项目周期一般就两三个月一个人开发与其做十个半成品不如把五个功能做得能真机流畅跑通。尤其地图和定位属于“不点到具体接口就不知道有多少坑”的模块必须预留足够的时间调通。1.3 “智能”怎么体现不堆AI模型把规则讲清楚“智能旅游管家”这个名字最容易被老师问的问题是智能在哪里这里要提前想清楚一个问题课程项目里所谓的“智能”不等于训练一个深度学习模型。大多数学校的环境不具备这个条件而且模型效果不可控演示风险很大。我的方案是用“规则 打分”的方式做轻智能化推荐模块用户选择偏好标签自然风光、人文历史、亲子、美食等景点也打上对应标签然后通过一个加权评分公式计算每个景点的推荐分按分值排序展示。路线规划模块不是做全局最优解而是用“贪心 时间窗口”算法从当前位置出发每次选择“距离近且当前可入场”的景点作为下一站。语音导览模块基于定位距离触发讲解不依赖任何语音识别能力。这套设计的好处是逻辑可解释、代码量可控、演示效果好。老师在听到“我的推荐分是由标签匹配度、距离接近度、热度和天气修正四项加权得到的”时会立刻明白你真的理解了自己做的东西。2. 技术栈与工程骨架原生Android、Kotlin和MVVM2.1 跨平台框架看着高效为什么我还是选了原生接到题目后我第一轮纠结的是技术栈。Flutter、React Native这些跨平台方案对前端背景的同学很友好一套代码双端运行听起来效率翻倍。但仔细想过之后我还是选了原生Android原因有三点第一地图和定位是旅游App的核心模块跨平台框架虽然也有地图插件但一遇到权限配置、Key校验、机型适配问题调试链路会变得特别长。原生环境里这些能力都是系统级API踩坑求助时信息密度更高。第二课程项目的评测和答辩通常跑在Android真机上原生App在启动速度、系统控件交互、地图滑动流畅度上更占便宜至少不会出现“界面卡一下”这种观感减分。第三Kotlin Android Jetpack这套组合本身已经很成熟开发效率并不低。后面我实际做下来从建工程到核心功能跑通大概用了三周比预想快。2.2 Kotlin MVVM 协程的默契配合如果还在用Java写新项目我会建议认真考虑Kotlin。这个项目里Kotlin带来的实际收益非常明显空安全机制旅游App里有大量“用户没填”“定位没开”“数据还没加载完”的空值场景Kotlin的?符号让编译器帮我把一半的空指针拦截在了编码阶段。协程处理异步数据库初始化、网络请求、定位回调都是异步操作用协程写起来比回调嵌套清爽太多。我只需要在ViewModel里launch一个协程再切到主线程更新UI。数据类data class配合Room和JSON解析很舒服不用写一堆getter/setter模板代码。架构上我采用了MVVMActivity/Fragment只负责界面渲染和交互事件ViewModel持有界面状态Repository层封装数据来源。这样一个简单的好处是列表页旋转屏幕数据不会丢另一个隐藏好处是以后想接真实后端只需要改Repository的实现类UI层完全不用动。2.3 工程结构怎么分依赖清单怎么定工程我把包名规划成四个部分没有用网上那些特别复杂的multi-module结构uiActivity、Fragment、Adapter所有界面相关代码。viewmodel各页面对应的ViewModel。data数据库、JSON解析、本地数据源和远程数据源接口。util定位工具、TTS工具、推荐算法工具类。依赖方面我用的都是Android生态里比较常见的东西选型的标准就两条官方维护、社区案例多。具体清单如下用途方案为什么选它数据库Room官方ORM配合协程和Flow很顺手建表升级都有配套方案图片加载Glide内存缓存和占位图处理成熟列表滑动不卡顿网络请求Retrofit OkHttp虽然本项目数据以本地预置为主但接口层预留了这两套生命周期组件ViewModel LiveData官方MVVM组件避免内存泄漏状态持久性好地图国内某常用地图开放平台SDK在国内定位偏差小中文POI数据全社区讨论多语音系统TextToSpeech无需额外SDK离线也能用中文音色可接受2.4 一个重要原则数据先本地化接口层留好后路课程项目最大的坑是“依赖某个在线服务”因为服务器的生命周期往往撑不到答辩那天。我见过有同学做App依赖某个免费云数据库结果临答辩前服务凉了整个App直接瘫痪。所以我在设计数据流时定了一条原则所有核心数据预先准备一份本地版本冷启动和日常使用时都从本地读取网络接口只作为可选的升级路径。景点数据预置在assets/目录的JSON文件里App第一次启动时解析进数据库之后所有页面都从Room里读。这样即使演示现场没网整个App依然可以完整跑通这一点在答辩时真的会救命。3. 数据库设计和“用户数据流”Room、JSON预置、登录态3.1 五张表的关系设计以及我做的“妥协”旅游App的数据库表设计一开始我照着正规项目去设计景点和标签做多对多关联表用户和收藏做关联表行程和景点也做关联表……但实际写代码时发现对于课程项目来说表太多反而会让查询变得很重而且演示场景的数据量很小根本不需要那么复杂。最终的Room库只保留了五张表关系上做了一些“妥协”用户表userid、用户名、密码MD5加盐、昵称、偏好标签、注册时间。景点表attractionid、名称、简介、图片地址、经纬度、标签、开放时间、建议游玩时长、热度值。标签表tagid、名称、分类。收藏表favoriteid、用户id、景点id、收藏时间。行程表itineraryid、用户id、景点id列表、行程日期、顺序编号。其中“景点标签”这个字段我直接在attraction表里存了一个用逗号分隔的字符串比如自然,亲子而不是单独建关联表。选这条路的直接原因是查询推荐时只需要判断“用户选中的标签是否出现在这个字符串里”一句SQL LIKE就能完成而走关联表需要JOIN三张表代码复杂度高很多。用逗号分隔字符串虽然不符合第三范式但在这个数据规模下性能和可维护性都完全够用。做项目要懂得在“正确”和“合适”之间做选择。3.2 景点预置数据从assets到Room的初始化流程预置数据我存储在assets/attractions.json里结构大概是这样的[ { id: 101, name: 湖畔公园, desc: 城市中心的大型湿地公园适合散步和亲子活动, imageUrl: asset://lake_park.jpg, lat: 30.123456, lng: 120.654321, tags: 自然,亲子, openTime: 06:00-22:00, duration: 120, hot: 87 }, { id: 102, name: 城市博物馆, desc: 展示本地历史文化的综合性博物馆, imageUrl: asset://museum.jpg, lat: 30.223456, lng: 120.754321, tags: 人文,室内, openTime: 09:00-17:00, duration: 150, hot: 92 } ]首次启动流程是这样的启动页里通过协程启动一个initializeData()函数。检查Room数据库的景点表是否有数据。如果没有从assets读取JSON用Gson解析成对象列表。逐条插入数据库完成后把“已初始化”标记写入SharedPreferences。要特别注意的是这个初始化千万别放在主线程。虽然只有几十条数据但解析JSON和插入数据库加起来也要几百毫秒放主线程会让启动页卡顿。3.3 登录注册本地模拟登录但接口逻辑按真实后端写很多课程项目会选BaaS平台或者云数据库做用户系统这确实省事但上面说了我不喜欢把核心流程绑在外部服务上。我采用的方案是本地模拟登录但代码结构按“可替换真实后端”的方式写。具体做法注册时在user表里插入一条记录密码用MD5加盐后存储。登录时根据用户名查库比对密码摘要。登录成功后用Repository层返回一个User对象ViewModel收到后保存到SharedPreferences。关键在Repository层的抽象我定义了一个IUserDataSource接口现在只有LocalUserDataSource这个实现但接口签名就是login(username, password): User这样的网络请求风格。以后如果真想接后端写一个RemoteUserDataSource再把依赖注入处换掉就行。这个小设计在答辩时是加分项因为老师能从这里看出你有工程化的思维。3.4 SharedPreferences里那点事登录态、偏好标签与启动跳转登录态存储我用SharedPreferences而不是数据库因为它的定位就是轻量键值对适合存这种全局状态。我存了三个关键字段is_logged_in布尔值判断是否需要跳转登录页。user_id当前登录用户ID。prefer_tags用户最近一次选择的偏好标签逗号分隔。启动页的逻辑读is_logged_in。如果没有登录跳转登录页。如果已登录直接跳转首页同时把user_id和prefer_tags传过去。用户在“我的”页面里修改偏好标签后重新写回SharedPreferences并且下一次推荐立即生效。这里有个容易忽略的小细节退出登录不只是清空登录态还应该清除“以该用户身份缓存的其他数据”比如首页的推荐缓存在内存里的部分。不然会出现A用户退出后B用户还能看到A的收藏列表这种尴尬问题。4. “智能”模块的落地方案推荐打分、贪心路线与TTS导览4.1 推荐算法一个能当着老师面讲清原理的打分公式这个项目的“智能感”很大程度来自推荐列表。我没有用协同过滤因为课程项目没有大量用户行为数据而是设计了一个加权评分公式推荐分 标签匹配度 * 0.5 距离接近度 * 0.2 热度值 * 0.2 天气修正 * 0.1四个维度的计算方式标签匹配度用户选中标签与景点标签的交集数量除以用户标签数量。比如用户选了三类标签景点命中了其中两类匹配度就是2/3≈0.67。距离接近度基于当前定位1 - (当前点与景点距离 / 20公里)距离超过20公里按0计算。热度值景点数据里的hot字段归一化我这里先除以100得到一个0到1之间的值。天气修正是一个条件变量晴天给户外景点加0.1雨天给室内景点加0.1其它情况为0。核心代码Kotlin大概是这样的fun score(userTags: ListString, attraction: Attraction, distance: Float, weather: String): Double { val tagMatch userTags.count { attraction.tags.contains(it) }.toDouble() / userTags.size val distanceScore 1.0 - minOf(distance, 20000f) / 20000f val hotScore attraction.hot / 100.0 val weatherScore when { weather sunny 户外 in attraction.tags - 0.1 weather rainy 室内 in attraction.tags - 0.1 else - 0.0 } return tagMatch * 0.5 distanceScore * 0.2 hotScore * 0.2 weatherScore * 0.1 }这样算完之后在首页展示时按分数倒序排列。每个景点的卡片上甚至可以把这几个子分数显示出来比如“标签匹配度83%”会让整个“智能推荐”变得非常直观。这个算法的好处是每个维度都有明确业务含义老师让你解释任何一项你都能说出“为什么这么算”而不是一句“模型训练的”糊弄过去。4.2 一日游路线规划贪心选择 时间窗口约束推荐只解决“去哪里”的问题路线规划解决的是“按什么顺序去”。这个功能我实现了一个基于贪心思想的路线生成器。输入参数有三个用户当前定位、候选景点列表通常来自收藏或推荐页勾选、出发时间默认为当前时间。算法步骤把候选景点按距离当前点的远近排序。计算每个景点的“可进入时间窗口”也就是景点开放时间。设定一个当前时间和当前位置循环执行在所有未访问且当前时间落在开放时间内的景点中选择距离最近的一个作为下一站。访问完一个景点后当前时间累加该景点的建议游玩时长当前位置更新到该景点坐标。如果发现下一个景点在闭馆前赶不到就跳过它继续找下一个可行的。这里要提一个真实的性能问题如果候选景点数量超过8个贪心算法的结果可能不是最优顺序但对于一日游场景8个以内是常态贪心得到的路线在体验上已经够好。而且贪心算法的讲解成本低一句话就能说明白“每次选最近且时间上可行的那个。”如果想验证路线合理性我建议把每段距离、每个景点的游玩时长都打印出来看一眼。我跑了多组模拟数据发现最常出现的坑是“把两个离得很远但评分都很高的景点排进了同一天”这种情况在算法层面容易防住但用户对距离的感知其实很敏感后续可以给路线总距离设一个上限。4.3 语音导览TextToSpeech与定位触发逻辑语音导览功能我一开始以为很简单就是调个TTS播报实际做的时候发现触发逻辑才是重点。系统自带的TextToSpeech初始化代码量不大关键是两点设置中文语言tts.setLanguage(Locale.CHINESE)。设置语速tts.setSpeechRate(0.9f)默认1.0稍微有点快放慢一点更适合景点讲解。触发逻辑上我用的方法是后台通过LocationManager每5秒拿一次定位计算当前位置到各景点的距离如果进入某个景点半径200米范围并且该景点的“已导览”标记为false就通过tts.speak()播放对应的讲解词同时把标记置为true避免用户站在原地反复听同一段讲解。讲解词的存储也是一个JSON文件字段包括景点id和讲解文本。这样做的好处是内容管理与代码分离以后想增加多语言版本只需要再建一个JSON文件。实际测试发现触发半径设200米比较合理设太大容易在开车经过时误触发设太小会导致用户走到景点跟前还没反应过来。另外TTS引擎初始化是异步的建议在进入地图页前就初始化好不然第一次进入景点范围可能出现半秒延迟。4.4 搜索、筛选、收藏普通功能也可以做得流畅虽然说“智能”是亮点但基础功能的体验也会影响整体评价。搜索我用的是Room里的模糊查询LIKE %关键词%去匹配景点名称和简介。收藏功能的实现上有个细节值得说收藏按钮的“选中态”如果直接通过查询数据库返回每次列表滚动都会触发一堆SQL请求。我是在进入列表页时一次性查出当前用户所有收藏的景点id放进一个内存Set里判断按钮状态就查这个Set点了之后才写数据库并更新Set。筛选功能我做了三组条件标签、距离、游玩时长。标签是Chip组件距离是滑杆时长是下拉选。这样筛选和推荐可以组合使用推荐页给的是智能排序筛选页给的是精确条件两者不冲突。5. 地图与定位集成权限、Key、Marker与路线绘制5.1 动态权限申请这关难点在版本差异地图和定位是旅游管家App里绕不开的坎而权限申请是第一个“劝退点”。Android 6.0以后定位权限变成了运行时权限不能只在manifest里声明了事必须在代码里用requestPermissions()弹窗申请。代码本身不难难的是不同版本的系统行为不一样Android 6.0API 23首次申请时直接弹系统弹窗。Android 10API 29如果App在后台获取定位需要额外申请ACCESS_BACKGROUND_LOCATION权限否则位置会在后台被冻结。Android 12API 31之后定位权限细化成“精确位置”和“大致位置”用户在弹窗里可以直接选“仅大致位置”这时App拿到的坐标精度会明显下降。我当时的适配策略是前台定位只申请ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION不申请后台权限因为我们的使用场景就是用户拿着手机看景点不需要后台持续定位。申请弹窗里用一个说明性的文案告诉用户“导游功能需要获取当前位置方便为您推荐周边景点”。另外要记住用户拒绝过一次后第二次申请时系统弹窗会变“不自动弹出”这时候要引导用户去设置页手动打开。我写了一个onRequestPermissionsResult的分支检测到永久拒绝时弹出对话框里面放“去设置开启”按钮直接跳应用详情页。5.2 地图SDK接入从申请Key到显示地图的完整链路我选的是国内主流的某个地图开放平台SDK。接入流程非常成熟无非四步注册开发者账号创建一个应用获取API Key。把Key绑定到App的包名和签名SHA1值。在Gradle依赖里引入SDK。在AndroidManifest.xml里配置Key并申请相关权限。这里最坑的是Key校验调试签名和发布签名的SHA1不一致如果你用签名包调试Key就会验证失败。我当时用debug包调试一切正常一打release包地图就白屏排查了半天才发现是SHA1换了重新在开放平台后台加了一个release签名的Key才解决。另外地图SDK的体积动辄一二十兆建议开启Gradle的minifyEnabled时注意混淆规则。地图SDK一般都会提供官方混淆配置我直接复制了文档里的proguard片段也没有遇到奇怪的问题。5.3 路线怎么画Polyline、Marker与定位联动地图页承载三个功能显示用户当前位置、展示周边景点、绘制规划路线。用户当前位置的显示用SDK的定位层组件就行一般地图SDK都有专门显示小蓝点的支持它会自己处理定位和地图联动。景点展示就是往地图上添加Marker图标我用的是本地自定义的图片这样比默认图钉好看很多。路线绘制用的是Polyline也就是折线。需要说明的是我没有接入真实导航SDK所以路线是用起始点、途经点和终点的坐标直接连起来的直线段。到这一步整个App的核心体验链就通了推荐页看到景点 - 收藏几个感兴趣的点 - 点击“一键规划”生成今日路线 - 地图上显示Marker和路线 - 跟着路线走 - 接近某个景点时自动语音讲解。演示到这一步项目完整性已经能打90分了。6. 测试、打包与答辩演示那些“最后一公里”的经验6.1 真机测试里很容易翻车的几个坑整个开发过程里我被下面几个问题坑过写出来当个提醒第一模拟器的地理位置和真实世界偏差很大。我在模拟器里测推荐明明选的标签是“自然”出来的推荐排序却跟距离关系更大后来发现是模拟器把定位设到了某个固定坐标导致所有景点都被算成了几十公里外。最后我还是老老实实用了真机调试。第二定位权限弹窗一旦用户选了“仅大致位置”地图App的Marker和路线绘制会有明显偏移。我加了一个检测逻辑如果拿到定位的精度半径超过某阈值就在地图页顶部提示“当前定位精度较低”。第三Room数据库升级表结构时必须写Migration。我在开发中给收藏表加了一个字段偷懒用了fallbackToDestructiveMigration()结果老用户升级后数据被清空。课程项目演示倒是无所谓但这是一个非常不专业的行为正式写法还是应该写Migration迁移。6.2 性能优化的小手段图片、列表、数据库与地图一些细节优化对App的整体流畅度影响很大图片加载统一走Glide景点图片在列表页用固定宽高并且加了centerCrop避免每张图尺寸不一致导致RecyclerView重新计算布局。SQL查询全部放到协程里Room本身支持返回Flow我让列表页面观察Flow变化任何收藏变动都会自动刷新界面不需要手动notifyDataSetChanged()。地图Marker批量添加时不要一个一个add先把所有MarkerOptions收集到一个列表再一次性添加。否则20个Marker以上时地图明显卡顿。启动闪屏页不加载真实数据只做数据库初始化和登录态判断其余数据等到进入首页后由ViewModel异步加载启动速度能控在2秒内。6.3 签名打包、隐私声明和答辩演示的实用建议打包release版本的时候记得在Gradle的signingConfigs里配置一个独立的keystore文件密码不要写进代码库。我建议建一个keystore.properties文件在构建时读取这样既不会被Git追踪也能保证签名信息不泄露。隐私方面也要提前准备应用会申请定位权限、读取存储权限使用第三方地图SDK还会访问网络状态信息。现在的应用市场上架要求都要求提供隐私政策我写了一份比较简洁的核心是说明“定位仅用于推荐附近景点和语音导览触发不会上传用户位置数据”并且在App的“关于”页面里放了完整版本。答辩演示时我的经验是准备一份固定的演示账号预先设置好偏好标签不要现场去点标签节省时间。把演示用的景点数据保持在一个“一看就很合理”的集合两三个自然类、两三个人文类、一个亲子类。真机连接电脑时如果演示现场要投影提前把屏幕方向锁定为横屏或竖屏避免翻来翻去影响观感。把“一键规划”的入口放在收藏页显眼位置演示时先手动选几个景点再点一键规划路线从无到有这个过程最有说服力。最后说点个人体会。做完这个项目我最大的收获不是“会用了地图SDK”或者“写了几百行Room查询”而是学会了把“智能”这种模糊的词翻译成具体可计算的公式和规则。如果你也在做类似题目我建议动手写代码之前先拿一张纸把推荐分怎么算、路线怎么选下一站、语音什么时候触发这三件事画清楚。想清楚了再写代码整个过程会顺很多。
做一个旅游类Android项目听起来是个很常见的毕业设计方向但真正动手之后你会发现难的不是“会用某某组件”而是怎么把“智能旅游管家”这五个字拆成一个个能落地、能演示、能讲清楚的功能模块。这篇文章我会把一套完整的《基于Android智能旅游管家的设计与实现》课程项目拆开来讲从需求收敛、技术选型、数据层设计到推荐算法、路线规划、地图定位集成再到真机测试和打包答辩的经验。如果你正准备做类似题目或者想自己动手做一个带“智能感”的旅游App这篇文章应该能帮你省不少试错时间。1. 为什么最后选了“智能旅游管家”这个题目1.1 一开始我就是从游客的抱怨里立题的每次到了假期总能看到有人在朋友圈吐槽查攻略查到眼花、景点之间怎么串不知道怎么安排、到了景区门口才知道今天闭馆、明明站在文物前面却不知道看什么。这些抱怨叠加在一起其实指向一个很明确的需求游客需要的不是更多信息而是一个能把信息整理好、按场景推送给他的“旅行助手”。传统旅游App做得最多的是“信息展示”搜景点、看评论、买门票游客自己还是要花大量时间做行程编排。而“管家”这个词的核心价值恰恰是把“编排”这件事接过去。所以这个项目的立意很简单做一个Android端App能根据用户兴趣推荐景点能根据当前位置和时间自动规划一日游路线能在到达景点附近时主动播放语音讲解顺便把收藏、搜索、行程记录这些基础能力补齐。1.2 功能边界守住“管家”砍掉想当然的需求立题之后最容易犯的错误就是什么都想塞进去。我见过不少同学一开始列出一大堆功能社交分享、在线支付、AR识别、直播景点……最后多半做不完或者每个功能都只是个空壳。我当时给自己的原则是核心功能必须能闭环演示非核心功能一律砍掉。最终锁定的功能清单是这样的功能模块具体能力优先级用户系统注册、登录、偏好标签设置、退出登录高景点推荐基于兴趣标签、距离、热度、天气的综合排序高地图定位显示当前位置、周边景点、地图选点高路线规划根据当前时间与位置生成一日游顺序高语音导览进入景点附近时朗读讲解词高收藏与搜索关键词搜索、标签筛选、收藏列表中社区、支付、AR全部砍掉无砍功能的原因很直白课程项目周期一般就两三个月一个人开发与其做十个半成品不如把五个功能做得能真机流畅跑通。尤其地图和定位属于“不点到具体接口就不知道有多少坑”的模块必须预留足够的时间调通。1.3 “智能”怎么体现不堆AI模型把规则讲清楚“智能旅游管家”这个名字最容易被老师问的问题是智能在哪里这里要提前想清楚一个问题课程项目里所谓的“智能”不等于训练一个深度学习模型。大多数学校的环境不具备这个条件而且模型效果不可控演示风险很大。我的方案是用“规则 打分”的方式做轻智能化推荐模块用户选择偏好标签自然风光、人文历史、亲子、美食等景点也打上对应标签然后通过一个加权评分公式计算每个景点的推荐分按分值排序展示。路线规划模块不是做全局最优解而是用“贪心 时间窗口”算法从当前位置出发每次选择“距离近且当前可入场”的景点作为下一站。语音导览模块基于定位距离触发讲解不依赖任何语音识别能力。这套设计的好处是逻辑可解释、代码量可控、演示效果好。老师在听到“我的推荐分是由标签匹配度、距离接近度、热度和天气修正四项加权得到的”时会立刻明白你真的理解了自己做的东西。2. 技术栈与工程骨架原生Android、Kotlin和MVVM2.1 跨平台框架看着高效为什么我还是选了原生接到题目后我第一轮纠结的是技术栈。Flutter、React Native这些跨平台方案对前端背景的同学很友好一套代码双端运行听起来效率翻倍。但仔细想过之后我还是选了原生Android原因有三点第一地图和定位是旅游App的核心模块跨平台框架虽然也有地图插件但一遇到权限配置、Key校验、机型适配问题调试链路会变得特别长。原生环境里这些能力都是系统级API踩坑求助时信息密度更高。第二课程项目的评测和答辩通常跑在Android真机上原生App在启动速度、系统控件交互、地图滑动流畅度上更占便宜至少不会出现“界面卡一下”这种观感减分。第三Kotlin Android Jetpack这套组合本身已经很成熟开发效率并不低。后面我实际做下来从建工程到核心功能跑通大概用了三周比预想快。2.2 Kotlin MVVM 协程的默契配合如果还在用Java写新项目我会建议认真考虑Kotlin。这个项目里Kotlin带来的实际收益非常明显空安全机制旅游App里有大量“用户没填”“定位没开”“数据还没加载完”的空值场景Kotlin的?符号让编译器帮我把一半的空指针拦截在了编码阶段。协程处理异步数据库初始化、网络请求、定位回调都是异步操作用协程写起来比回调嵌套清爽太多。我只需要在ViewModel里launch一个协程再切到主线程更新UI。数据类data class配合Room和JSON解析很舒服不用写一堆getter/setter模板代码。架构上我采用了MVVMActivity/Fragment只负责界面渲染和交互事件ViewModel持有界面状态Repository层封装数据来源。这样一个简单的好处是列表页旋转屏幕数据不会丢另一个隐藏好处是以后想接真实后端只需要改Repository的实现类UI层完全不用动。2.3 工程结构怎么分依赖清单怎么定工程我把包名规划成四个部分没有用网上那些特别复杂的multi-module结构uiActivity、Fragment、Adapter所有界面相关代码。viewmodel各页面对应的ViewModel。data数据库、JSON解析、本地数据源和远程数据源接口。util定位工具、TTS工具、推荐算法工具类。依赖方面我用的都是Android生态里比较常见的东西选型的标准就两条官方维护、社区案例多。具体清单如下用途方案为什么选它数据库Room官方ORM配合协程和Flow很顺手建表升级都有配套方案图片加载Glide内存缓存和占位图处理成熟列表滑动不卡顿网络请求Retrofit OkHttp虽然本项目数据以本地预置为主但接口层预留了这两套生命周期组件ViewModel LiveData官方MVVM组件避免内存泄漏状态持久性好地图国内某常用地图开放平台SDK在国内定位偏差小中文POI数据全社区讨论多语音系统TextToSpeech无需额外SDK离线也能用中文音色可接受2.4 一个重要原则数据先本地化接口层留好后路课程项目最大的坑是“依赖某个在线服务”因为服务器的生命周期往往撑不到答辩那天。我见过有同学做App依赖某个免费云数据库结果临答辩前服务凉了整个App直接瘫痪。所以我在设计数据流时定了一条原则所有核心数据预先准备一份本地版本冷启动和日常使用时都从本地读取网络接口只作为可选的升级路径。景点数据预置在assets/目录的JSON文件里App第一次启动时解析进数据库之后所有页面都从Room里读。这样即使演示现场没网整个App依然可以完整跑通这一点在答辩时真的会救命。3. 数据库设计和“用户数据流”Room、JSON预置、登录态3.1 五张表的关系设计以及我做的“妥协”旅游App的数据库表设计一开始我照着正规项目去设计景点和标签做多对多关联表用户和收藏做关联表行程和景点也做关联表……但实际写代码时发现对于课程项目来说表太多反而会让查询变得很重而且演示场景的数据量很小根本不需要那么复杂。最终的Room库只保留了五张表关系上做了一些“妥协”用户表userid、用户名、密码MD5加盐、昵称、偏好标签、注册时间。景点表attractionid、名称、简介、图片地址、经纬度、标签、开放时间、建议游玩时长、热度值。标签表tagid、名称、分类。收藏表favoriteid、用户id、景点id、收藏时间。行程表itineraryid、用户id、景点id列表、行程日期、顺序编号。其中“景点标签”这个字段我直接在attraction表里存了一个用逗号分隔的字符串比如自然,亲子而不是单独建关联表。选这条路的直接原因是查询推荐时只需要判断“用户选中的标签是否出现在这个字符串里”一句SQL LIKE就能完成而走关联表需要JOIN三张表代码复杂度高很多。用逗号分隔字符串虽然不符合第三范式但在这个数据规模下性能和可维护性都完全够用。做项目要懂得在“正确”和“合适”之间做选择。3.2 景点预置数据从assets到Room的初始化流程预置数据我存储在assets/attractions.json里结构大概是这样的[ { id: 101, name: 湖畔公园, desc: 城市中心的大型湿地公园适合散步和亲子活动, imageUrl: asset://lake_park.jpg, lat: 30.123456, lng: 120.654321, tags: 自然,亲子, openTime: 06:00-22:00, duration: 120, hot: 87 }, { id: 102, name: 城市博物馆, desc: 展示本地历史文化的综合性博物馆, imageUrl: asset://museum.jpg, lat: 30.223456, lng: 120.754321, tags: 人文,室内, openTime: 09:00-17:00, duration: 150, hot: 92 } ]首次启动流程是这样的启动页里通过协程启动一个initializeData()函数。检查Room数据库的景点表是否有数据。如果没有从assets读取JSON用Gson解析成对象列表。逐条插入数据库完成后把“已初始化”标记写入SharedPreferences。要特别注意的是这个初始化千万别放在主线程。虽然只有几十条数据但解析JSON和插入数据库加起来也要几百毫秒放主线程会让启动页卡顿。3.3 登录注册本地模拟登录但接口逻辑按真实后端写很多课程项目会选BaaS平台或者云数据库做用户系统这确实省事但上面说了我不喜欢把核心流程绑在外部服务上。我采用的方案是本地模拟登录但代码结构按“可替换真实后端”的方式写。具体做法注册时在user表里插入一条记录密码用MD5加盐后存储。登录时根据用户名查库比对密码摘要。登录成功后用Repository层返回一个User对象ViewModel收到后保存到SharedPreferences。关键在Repository层的抽象我定义了一个IUserDataSource接口现在只有LocalUserDataSource这个实现但接口签名就是login(username, password): User这样的网络请求风格。以后如果真想接后端写一个RemoteUserDataSource再把依赖注入处换掉就行。这个小设计在答辩时是加分项因为老师能从这里看出你有工程化的思维。3.4 SharedPreferences里那点事登录态、偏好标签与启动跳转登录态存储我用SharedPreferences而不是数据库因为它的定位就是轻量键值对适合存这种全局状态。我存了三个关键字段is_logged_in布尔值判断是否需要跳转登录页。user_id当前登录用户ID。prefer_tags用户最近一次选择的偏好标签逗号分隔。启动页的逻辑读is_logged_in。如果没有登录跳转登录页。如果已登录直接跳转首页同时把user_id和prefer_tags传过去。用户在“我的”页面里修改偏好标签后重新写回SharedPreferences并且下一次推荐立即生效。这里有个容易忽略的小细节退出登录不只是清空登录态还应该清除“以该用户身份缓存的其他数据”比如首页的推荐缓存在内存里的部分。不然会出现A用户退出后B用户还能看到A的收藏列表这种尴尬问题。4. “智能”模块的落地方案推荐打分、贪心路线与TTS导览4.1 推荐算法一个能当着老师面讲清原理的打分公式这个项目的“智能感”很大程度来自推荐列表。我没有用协同过滤因为课程项目没有大量用户行为数据而是设计了一个加权评分公式推荐分 标签匹配度 * 0.5 距离接近度 * 0.2 热度值 * 0.2 天气修正 * 0.1四个维度的计算方式标签匹配度用户选中标签与景点标签的交集数量除以用户标签数量。比如用户选了三类标签景点命中了其中两类匹配度就是2/3≈0.67。距离接近度基于当前定位1 - (当前点与景点距离 / 20公里)距离超过20公里按0计算。热度值景点数据里的hot字段归一化我这里先除以100得到一个0到1之间的值。天气修正是一个条件变量晴天给户外景点加0.1雨天给室内景点加0.1其它情况为0。核心代码Kotlin大概是这样的fun score(userTags: ListString, attraction: Attraction, distance: Float, weather: String): Double { val tagMatch userTags.count { attraction.tags.contains(it) }.toDouble() / userTags.size val distanceScore 1.0 - minOf(distance, 20000f) / 20000f val hotScore attraction.hot / 100.0 val weatherScore when { weather sunny 户外 in attraction.tags - 0.1 weather rainy 室内 in attraction.tags - 0.1 else - 0.0 } return tagMatch * 0.5 distanceScore * 0.2 hotScore * 0.2 weatherScore * 0.1 }这样算完之后在首页展示时按分数倒序排列。每个景点的卡片上甚至可以把这几个子分数显示出来比如“标签匹配度83%”会让整个“智能推荐”变得非常直观。这个算法的好处是每个维度都有明确业务含义老师让你解释任何一项你都能说出“为什么这么算”而不是一句“模型训练的”糊弄过去。4.2 一日游路线规划贪心选择 时间窗口约束推荐只解决“去哪里”的问题路线规划解决的是“按什么顺序去”。这个功能我实现了一个基于贪心思想的路线生成器。输入参数有三个用户当前定位、候选景点列表通常来自收藏或推荐页勾选、出发时间默认为当前时间。算法步骤把候选景点按距离当前点的远近排序。计算每个景点的“可进入时间窗口”也就是景点开放时间。设定一个当前时间和当前位置循环执行在所有未访问且当前时间落在开放时间内的景点中选择距离最近的一个作为下一站。访问完一个景点后当前时间累加该景点的建议游玩时长当前位置更新到该景点坐标。如果发现下一个景点在闭馆前赶不到就跳过它继续找下一个可行的。这里要提一个真实的性能问题如果候选景点数量超过8个贪心算法的结果可能不是最优顺序但对于一日游场景8个以内是常态贪心得到的路线在体验上已经够好。而且贪心算法的讲解成本低一句话就能说明白“每次选最近且时间上可行的那个。”如果想验证路线合理性我建议把每段距离、每个景点的游玩时长都打印出来看一眼。我跑了多组模拟数据发现最常出现的坑是“把两个离得很远但评分都很高的景点排进了同一天”这种情况在算法层面容易防住但用户对距离的感知其实很敏感后续可以给路线总距离设一个上限。4.3 语音导览TextToSpeech与定位触发逻辑语音导览功能我一开始以为很简单就是调个TTS播报实际做的时候发现触发逻辑才是重点。系统自带的TextToSpeech初始化代码量不大关键是两点设置中文语言tts.setLanguage(Locale.CHINESE)。设置语速tts.setSpeechRate(0.9f)默认1.0稍微有点快放慢一点更适合景点讲解。触发逻辑上我用的方法是后台通过LocationManager每5秒拿一次定位计算当前位置到各景点的距离如果进入某个景点半径200米范围并且该景点的“已导览”标记为false就通过tts.speak()播放对应的讲解词同时把标记置为true避免用户站在原地反复听同一段讲解。讲解词的存储也是一个JSON文件字段包括景点id和讲解文本。这样做的好处是内容管理与代码分离以后想增加多语言版本只需要再建一个JSON文件。实际测试发现触发半径设200米比较合理设太大容易在开车经过时误触发设太小会导致用户走到景点跟前还没反应过来。另外TTS引擎初始化是异步的建议在进入地图页前就初始化好不然第一次进入景点范围可能出现半秒延迟。4.4 搜索、筛选、收藏普通功能也可以做得流畅虽然说“智能”是亮点但基础功能的体验也会影响整体评价。搜索我用的是Room里的模糊查询LIKE %关键词%去匹配景点名称和简介。收藏功能的实现上有个细节值得说收藏按钮的“选中态”如果直接通过查询数据库返回每次列表滚动都会触发一堆SQL请求。我是在进入列表页时一次性查出当前用户所有收藏的景点id放进一个内存Set里判断按钮状态就查这个Set点了之后才写数据库并更新Set。筛选功能我做了三组条件标签、距离、游玩时长。标签是Chip组件距离是滑杆时长是下拉选。这样筛选和推荐可以组合使用推荐页给的是智能排序筛选页给的是精确条件两者不冲突。5. 地图与定位集成权限、Key、Marker与路线绘制5.1 动态权限申请这关难点在版本差异地图和定位是旅游管家App里绕不开的坎而权限申请是第一个“劝退点”。Android 6.0以后定位权限变成了运行时权限不能只在manifest里声明了事必须在代码里用requestPermissions()弹窗申请。代码本身不难难的是不同版本的系统行为不一样Android 6.0API 23首次申请时直接弹系统弹窗。Android 10API 29如果App在后台获取定位需要额外申请ACCESS_BACKGROUND_LOCATION权限否则位置会在后台被冻结。Android 12API 31之后定位权限细化成“精确位置”和“大致位置”用户在弹窗里可以直接选“仅大致位置”这时App拿到的坐标精度会明显下降。我当时的适配策略是前台定位只申请ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION不申请后台权限因为我们的使用场景就是用户拿着手机看景点不需要后台持续定位。申请弹窗里用一个说明性的文案告诉用户“导游功能需要获取当前位置方便为您推荐周边景点”。另外要记住用户拒绝过一次后第二次申请时系统弹窗会变“不自动弹出”这时候要引导用户去设置页手动打开。我写了一个onRequestPermissionsResult的分支检测到永久拒绝时弹出对话框里面放“去设置开启”按钮直接跳应用详情页。5.2 地图SDK接入从申请Key到显示地图的完整链路我选的是国内主流的某个地图开放平台SDK。接入流程非常成熟无非四步注册开发者账号创建一个应用获取API Key。把Key绑定到App的包名和签名SHA1值。在Gradle依赖里引入SDK。在AndroidManifest.xml里配置Key并申请相关权限。这里最坑的是Key校验调试签名和发布签名的SHA1不一致如果你用签名包调试Key就会验证失败。我当时用debug包调试一切正常一打release包地图就白屏排查了半天才发现是SHA1换了重新在开放平台后台加了一个release签名的Key才解决。另外地图SDK的体积动辄一二十兆建议开启Gradle的minifyEnabled时注意混淆规则。地图SDK一般都会提供官方混淆配置我直接复制了文档里的proguard片段也没有遇到奇怪的问题。5.3 路线怎么画Polyline、Marker与定位联动地图页承载三个功能显示用户当前位置、展示周边景点、绘制规划路线。用户当前位置的显示用SDK的定位层组件就行一般地图SDK都有专门显示小蓝点的支持它会自己处理定位和地图联动。景点展示就是往地图上添加Marker图标我用的是本地自定义的图片这样比默认图钉好看很多。路线绘制用的是Polyline也就是折线。需要说明的是我没有接入真实导航SDK所以路线是用起始点、途经点和终点的坐标直接连起来的直线段。到这一步整个App的核心体验链就通了推荐页看到景点 - 收藏几个感兴趣的点 - 点击“一键规划”生成今日路线 - 地图上显示Marker和路线 - 跟着路线走 - 接近某个景点时自动语音讲解。演示到这一步项目完整性已经能打90分了。6. 测试、打包与答辩演示那些“最后一公里”的经验6.1 真机测试里很容易翻车的几个坑整个开发过程里我被下面几个问题坑过写出来当个提醒第一模拟器的地理位置和真实世界偏差很大。我在模拟器里测推荐明明选的标签是“自然”出来的推荐排序却跟距离关系更大后来发现是模拟器把定位设到了某个固定坐标导致所有景点都被算成了几十公里外。最后我还是老老实实用了真机调试。第二定位权限弹窗一旦用户选了“仅大致位置”地图App的Marker和路线绘制会有明显偏移。我加了一个检测逻辑如果拿到定位的精度半径超过某阈值就在地图页顶部提示“当前定位精度较低”。第三Room数据库升级表结构时必须写Migration。我在开发中给收藏表加了一个字段偷懒用了fallbackToDestructiveMigration()结果老用户升级后数据被清空。课程项目演示倒是无所谓但这是一个非常不专业的行为正式写法还是应该写Migration迁移。6.2 性能优化的小手段图片、列表、数据库与地图一些细节优化对App的整体流畅度影响很大图片加载统一走Glide景点图片在列表页用固定宽高并且加了centerCrop避免每张图尺寸不一致导致RecyclerView重新计算布局。SQL查询全部放到协程里Room本身支持返回Flow我让列表页面观察Flow变化任何收藏变动都会自动刷新界面不需要手动notifyDataSetChanged()。地图Marker批量添加时不要一个一个add先把所有MarkerOptions收集到一个列表再一次性添加。否则20个Marker以上时地图明显卡顿。启动闪屏页不加载真实数据只做数据库初始化和登录态判断其余数据等到进入首页后由ViewModel异步加载启动速度能控在2秒内。6.3 签名打包、隐私声明和答辩演示的实用建议打包release版本的时候记得在Gradle的signingConfigs里配置一个独立的keystore文件密码不要写进代码库。我建议建一个keystore.properties文件在构建时读取这样既不会被Git追踪也能保证签名信息不泄露。隐私方面也要提前准备应用会申请定位权限、读取存储权限使用第三方地图SDK还会访问网络状态信息。现在的应用市场上架要求都要求提供隐私政策我写了一份比较简洁的核心是说明“定位仅用于推荐附近景点和语音导览触发不会上传用户位置数据”并且在App的“关于”页面里放了完整版本。答辩演示时我的经验是准备一份固定的演示账号预先设置好偏好标签不要现场去点标签节省时间。把演示用的景点数据保持在一个“一看就很合理”的集合两三个自然类、两三个人文类、一个亲子类。真机连接电脑时如果演示现场要投影提前把屏幕方向锁定为横屏或竖屏避免翻来翻去影响观感。把“一键规划”的入口放在收藏页显眼位置演示时先手动选几个景点再点一键规划路线从无到有这个过程最有说服力。最后说点个人体会。做完这个项目我最大的收获不是“会用了地图SDK”或者“写了几百行Room查询”而是学会了把“智能”这种模糊的词翻译成具体可计算的公式和规则。如果你也在做类似题目我建议动手写代码之前先拿一张纸把推荐分怎么算、路线怎么选下一站、语音什么时候触发这三件事画清楚。想清楚了再写代码整个过程会顺很多。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
