简介本资源为基于 Android 平台的某景点移动端旅游软件系统设计与实现类毕业设计/课程设计参考文档面向计算机相关专业学生及移动应用开发入门者可用于选题借鉴、论文框架搭建与 Android 项目实战学习。压缩包内共 1 个 pdf 文件约 2.96MB内容为一份结构完整的论文文档涵盖绪论、国内外研究现状、Android 原生开发与地图 API 等相关技术、需求分析与三层架构设计、功能模块实现与性能优化以及基于 LoadRunner 的功能与并发性能测试等章节重点讲解旅游信息展示、天气预报、地图导航与系统管理等功能并涉及 HashMap 资源缓存、百度地图 API 集成等实现思路。目前已有 1088 人浏览学习适合在撰写同类旅游类移动端系统论文或搭建 Android 项目时对照参考快速理清从需求分析到系统测试的完整开发脉络。1. 景区 App 为什么不是“把网页套个壳”——Android 端的取舍旺季早上八点游客挤在山门闸机口打开 App信号只剩一格首页还在转圈——这是景区类移动端最常见的事故现场。问题往往不在服务端而在于移动端把所有内容都当成“必须联网才能看”景点介绍走实时接口、导览图走原图直出、列表滚动时还在主线程里等网络。把景点信息、导览地图、门票预订、语音讲解收进一个 Android 包本质上是在设计一套“弱网优先、离线可读”的信息系统而不是给官网加个壳。这篇适合三类人做课程设计或毕设、需要一份能跑起来的模块划分与数据表接了文旅或景区外包、要评估工期和技术风险已经在写 Android、想把生命周期、缓存、性能这些散点串成一条工程线。接下来的顺序是工程骨架、数据链路、性能优化、签名与验收每一段都落到可抄的 Gradle 配置、Room 表结构和 adb 命令。像 android 应用签名 sha1 值这类验收环节才会暴露的坑以及 android 进度条在分页列表里的正确用法都会在对应位置给具体做法。2. 用 Android Studio 搭出景点 App 的可运行骨架2.1 从建项到模块划分Android Studio 里的第一步不该是写 Activity在 Android Studio 里用 Empty Views Activity 模板建项包名按com.组织.scenic约定minSdk 建议 24能覆盖绝大多数在售机型compileSdk 和 targetSdk 跟随当前稳定版 SDK 平台即可不必为了追新把 targetSdk 提到预览版那会让权限行为和后台限制提前生效调试成本陡增。建完项之后先别急着往app模块里堆代码。景点类应用页面多、数据来源杂单模块写法三个月后就会变成“谁都不敢改”的状态。常见做法是按职责拆四个模块scenic-app/ ├── app/ # 壳工程Application、MainActivity、底部导航、路由表 ├── core-ui/ # 通用 UI加载态、错误页、图片加载封装、主题色 ├── data/ # 网络层、Room、Repository、DTO 与 Entity 映射 └── feature-scenic/ # 景点列表、详情、导览、门票页与对应 ViewModel模块主要职责允许依赖:app启动入口、导航图、变体配置全部 feature、core-ui:core-ui无业务的通用控件与资源基础库不依赖任何 feature:dataRetrofit 接口、Room 表、缓存策略基础库不依赖 UI:feature-scenic景点相关页面与状态管理:data、:core-ui依赖方向单向core-ui和data都不许反向依赖app。这条约束的意义在于以后要把门票模块单独拆出去或者做多端复用改动被限制在一个模块内。2.2 Gradle 依赖与参数只引真正用得上的库壳工程的依赖清单控制在十几行以内用版本目录统一管理版本避免各模块各写一套// app/build.gradle.kts dependencies { implementation(project(:feature-scenic)) implementation(project(:core-ui)) implementation(libs.androidx.core.ktx) implementation(libs.androidx.appcompat) implementation(libs.material) implementation(libs.androidx.navigation.fragment.ktx) // 网络抓包工具只在 debug 变体引入release 包里不存在 debugImplementation(libs.chucker) }段说明implementation而不是api是为了把依赖锁在模块内部减少编译期的传递暴露debugImplementation保证抓包、日志这类工具不会进正式包也顺带省掉几十 KB 到几百 KB 的体积。数据库和网络库放在:data模块里声明UI 模块只依赖:data暴露出来的 Repository 接口不直接碰 Retrofit 和 Room。构建参数上还有两个容易忽略的点android.buildFeatures.viewBinding true可以彻底告别findViewById和 Kotlin 合成视图android.nonTransitiveRClass true能让每个模块只生成自己的 R 类大型工程下能明显缩短增量编译时间。2.3 景点数据模型与 Room 表把“能离线看”写进结构里数据结构的第一个决定是主键用什么。景点名称会改、会重名不能用名称做主键服务端下发的spotId才是稳定标识。票价用整型存“分”而不是浮点避免出现 0.10.2 这类精度问题在收银台前爆雷。Entity(tableName scenic_spot) data class SpotEntity( PrimaryKey val spotId: String, // 与服务端一致的稳定 ID val name: String, val summary: String, val coverUrl: String, val latitude: Double, val longitude: Double, val openTime: String, val ticketPrice: Int, // 单位分 val updatedAt: Long // 服务端数据版本时间戳用于判断缓存是否过期 ) Dao interface SpotDao { Query(SELECT * FROM scenic_spot ORDER BY updatedAt DESC) fun observeAll(): FlowListSpotEntity Upsert suspend fun upsertAll(spots: ListSpotEntity) Query(SELECT MAX(updatedAt) FROM scenic_spot) suspend fun latestVersion(): Long? }Flow返回值让列表页订阅到数据变化后自动刷新不需要手动通知 AdapterUpsert在 SQLite 层做“有则更新、无则插入”比先查后写少一次往返也不会有并发写冲突。latestVersion()是给后面缓存策略用的它决定要不要再去请求服务端。经纬度这一列建议在建表时就加上索引导览页按“离我最近”排序时全表扫描在几千条景点数据上还撑得住一旦加上餐饮、厕所、停车场这些 POI就会明显变慢。加索引的方式是在实体上标注Entity(indices [Index(latitude, longitude)])。2.4 首页骨架CoordinatorLayout 配 Banner 与加载态景点首页的经典结构是“顶部可折叠大图 下方列表”用CoordinatorLayout加AppBarLayout的组合最省事滚动联动由appbar_scrolling_view_behavior自动接管不需要自己写滚动监听。androidx.coordinatorlayout.widget.CoordinatorLayout ... com.google.android.material.appbar.AppBarLayout ... com.google.android.material.appbar.CollapsingToolbarLayout app:layout_scrollFlagsscroll|exitUntilCollapsed androidx.viewpager2.widget.ViewPager2 android:idid/bannerPager ... / com.google.android.material.appbar.MaterialToolbar app:layout_collapseModepin ... / /com.google.android.material.appbar.CollapsingToolbarLayout /com.google.android.material.appbar.AppBarLayout androidx.recyclerview.widget.RecyclerView app:layout_behaviorstring/appbar_scrolling_view_behavior ... / com.google.android.material.progressindicator.CircularProgressIndicator android:idid/loading ... / /androidx.coordinatorlayout.widget.CoordinatorLayoutBanner 用ViewPager2时自动轮播不要用裸Handler.postDelayed页面切到后台还在跑会白耗电。绑定生命周期更稳// 页面 RESUMED 时才开始轮播退到后台自动停止 lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.RESUMED) { while (true) { delay(BANNER_INTERVAL_MS) val next (bannerPager.currentItem 1) % bannerAdapter.itemCount bannerPager.setCurrentItem(next, true) } } }参数上BANNER_INTERVAL_MS取 3000 到 5000 之间比较合适低于 3000 用户刚看清标题就滑走了高于 5000 又等于没有轮播。轮播只对图片数量大于 1 的情况启用单张图还自动翻页会很怪。3. 景点数据链路Retrofit Room 的离线优先读取3.1 接口分层与 DTO 到 Entity 的映射网络层的第一原则是接口定义和数据表结构解耦。服务端字段命名习惯和数据库列名几乎不可能一直一致直接拿 DTO 当实体用一次字段改名就意味着一轮数据库迁移风险极高。interface ScenicApi { GET(api/v1/spots) suspend fun getSpots( Query(page) page: Int, Query(size) size: Int, Query(version) version: Long? // 带上本地版本服务端可判断是否需要下发全量 ): ApiResponseSpotPageDto } data class SpotDto( val id: String, val name: String, SerializedName(cover) val coverUrl: String, val lat: Double, val lng: Double, SerializedName(open_time) val openTime: String, SerializedName(price_cent) val priceCent: Int, SerializedName(updated_at) val updatedAt: Long ) fun SpotDto.toEntity() SpotEntity( spotId id, name name, summary summary, coverUrl coverUrl, latitude lat, longitude lng, openTime openTime, ticketPrice priceCent, updatedAt updatedAt )SerializedName承担的是“服务端下划线风格到客户端驼峰风格”的翻译工作把差异集中在映射函数里。version参数是可选优化服务端可以据此返回“无更新”而不用传完整列表流量在弱网环境下会省得很明显。3.2 离线优先的读取顺序与缓存时效读数据的顺序决定用户的第一印象。正确的顺序是“先给本地已有的、再后台刷新”而不是“先转圈等网络”。Repository 是把这件事收敛到一个地方的关键class SpotRepository( private val api: ScenicApi, private val dao: SpotDao ) { // UI 只订阅这个 Flow本地库一变列表就刷新 fun spots(): FlowListSpotEntity dao.observeAll() suspend fun refresh(force: Boolean false): ResultUnit runCatching { val localVersion dao.latestVersion() ?: 0L if (!force !isStale(localVersion)) returnrunCatching val remote api.getSpots(page 1, size PAGE_SIZE, version localVersion) .data.items dao.upsertAll(remote.map { it.toEntity() }) } private fun isStale(lastUpdated: Long): Boolean System.currentTimeMillis() - lastUpdated CACHE_TTL_MS }CACHE_TTL_MS默认设 6 小时比较合理景点介绍、开放时间这类内容一天内基本不变6 小时足以覆盖一次游玩行程。如果页面里有演出场次、临时闭园通知这类强时效内容把 TTL 调到 5 分钟并在下拉刷新时传force true跳过时效判断。不同场景下的读取策略值得列清楚进入时机数据来源用户看到什么失败时怎么处理首次安装进入本地空库 → 网络骨架屏 → 列表错误页带重试按钮二次进入本地库先回显 → 后台静默刷新秒开列表无感更新静默失败保留本地数据无网络仅本地库列表加“离线数据”角标不弹 Toast 打断浏览第三行是最容易被做错的很多应用一断网就弹一个全屏错误页把本地明明已经缓存好的景点介绍也一起挡掉了用户只会觉得这 App 特别“脆”。3.3 分页列表与 android 进度条的状态机景点列表随着 POI 增多会越来越长用 Paging 3 做分页比自己写滚动监听省心得多PagingSource负责加载UI 只消费状态class SpotPagingSource(private val api: ScenicApi) : PagingSourceInt, SpotEntity() { override suspend fun load(params: LoadParamsInt): LoadResultInt, SpotEntity { val page params.key ?: 1 return try { val resp api.getSpots(page, params.loadSize, null) LoadResult.Page( data resp.data.items.map { it.toEntity() }, prevKey if (page 1) null else page - 1, nextKey if (resp.data.items.isEmpty()) null else page 1 ) } catch (e: IOException) { LoadResult.Error(e) // 交给 UI 展示重试而不是让异常冒泡崩溃 } } override fun getRefreshKey(state: PagingStateInt, SpotEntity) null }UI 侧的进度显示必须区分两种加载态这是 android 进度条最常见的误用点下拉刷新用refresh状态滚到底部用append状态共用一个布尔值就会出现“滑动过程中底部进度条乱闪”。adapter.loadStateFlow .distinctUntilChanged() .collect { state - // 顶部下拉刷新中用 LinearProgressIndicator binding.refreshBar.isVisible state.refresh is LoadState.Loading // 底部加载更多中用列表尾部的小 CircularProgressIndicator binding.appendProgress.isVisible state.append is LoadState.Loading // 错误态单独给重试入口 binding.retryButton.isVisible state.refresh is LoadState.Error || state.append is LoadState.Error }IOException单独捕获并转成LoadResult.Error的原因是景区弱网、地铁隧道、山区信号盲区都会产生这类异常它们属于预期内的失败不应该被当成程序缺陷上报到崩溃平台否则真正的线上问题会被淹没在噪声里。4. 移动端性能优化启动、列表、包体积三条线4.1 冷启动耗时定位从 Application 到首帧冷启动是用户对 App 的第一感知也是移动端性能优化里收益最直接的一项。先量再改别凭感觉。用 adb 命令反复测几次取中位数# 杀掉进程模拟冷启动-W 会打印耗时 adb shell am force-stop com.example.scenic adb shell am start -W -n com.example.scenic/.ui.MainActivity输出里的TotalTime是最接近用户感知的数值代表从进程启动到 Activity 首帧绘制完成WaitTime包含系统调度开销通常略大于TotalTime。同一台设备连测 5 次取中位数比单次结果可靠得多。定位之后常见的三个优化动作一是把Application.onCreate里跟首屏无关的初始化挪走地图 SDK、统计埋点、推送注册全部延迟到首帧之后或者用 App Startup 库显式声明依赖顺序二是首屏接口不要在onCreate里同步阻塞改成先渲染骨架屏三是检查主题里是否配置了启动窗口背景缺了它会出现一段白屏。4.2 RecyclerView 掉帧与图片加载参数列表滑动掉帧十有八九出在onBindViewHolder里干了重活。三条硬性约束不要在绑定过程中读数据库或文件不要每次都重新创建ViewHolder的点击监听放在初始化时创建一次图片必须按控件实际尺寸解码而不是原图直出。Glide.with(holder.image) .load(spot.coverUrl) .placeholder(R.drawable.ic_spot_placeholder) .override(720, 480) // 按控件尺寸解码别按原图分辨率 .centerCrop() .diskCacheStrategy(DiskCacheStrategy.AUTOMATIC) .into(holder.image)override(720, 480)的效果在景点大图上最明显服务端为了适配平板可能存了 2000 像素宽的封面图手机端按原尺寸解码一张图就是十几 MB 的位图内存列表快速滑动时必然抖动甚至 OOM。另外记得recyclerView.setHasFixedSize(true)当 item 高度固定时它能让 RecyclerView 跳过重新测量的步骤。如果要做严肃的帧率验证用 Macrobenchmark 跑基准测试或者开发者选项里的“GPU 渲染模式分析”关注柱状图里超过绿线16.6ms的帧。4.3 包体积与资源瘦身包体积直接影响下载转化率尤其是景区场景下用户在弱网中扫码下载的时候。先看现状用 Build 菜单里的 Analyze APK或者直接跑一次正式构建./gradlew :app:assembleRelease然后按收益排序处理前两项通常能砍掉大头手段典型收益风险与注意开启 R8 代码压缩与资源压缩20% 到 40%反射调用的类要写 keep 规则按 ABI 拆包每去掉一个 ABI 省 15% 到 25%需确认在售机型覆盖WebP 替换 PNG 大图图片体积降 30% 以上检查低版本设备兼容移除未使用的语言资源视情况而定用resConfigs限定语种对应配置android { buildTypes { release { isMinifyEnabled true isShrinkResources true proguardFiles( getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro ) } } splits { abi { isEnable true reset() include(arm64-v8a, armeabi-v7a) isUniversalApk false } } }isShrinkResources true必须在isMinifyEnabled true的前提下才生效单独打开没有作用这是最常见的配置错误。开启压缩后一定要跑一遍完整的功能回归尤其是靠反射和 JSON 反序列化工作的模块缺 keep 规则会在运行时才抛ClassNotFoundException。5. 签名、SHA1 获取与真机验收清单正式包签名是发布前最后一道门槛。用 keytool 可以看到证书的完整信息其中就包括地图、推送这类三方 SDK 需要绑定的 SHA1# 查看发布证书信息输出中的 SHA1 即三方平台需要填写的值 keytool -list -v -keystore release.jks -alias scenic -storepass ****** # 或者在 Gradle 里一次性拿到所有变体的签名信息 ./gradlew :app:signingReport必须记住的是debug 和 release 用的是两套证书SHA1 值完全不同。开发阶段三方 SDK 后台填的是 debug 的 SHA1上线前忘了换成 release 的会出现“调试机好好的、正式包地图一片空白”这种只在发布后才暴露的问题。稳妥做法是在 SDK 后台把两个 SHA1 都登记上发布时再清理掉 debug 那条。验收阶段建议按下面这张清单逐项过一遍都是真机上才跑得出来的结论检查项操作方式通过标准冷启动adb shell am start -W连测 5 次中位数在团队定的阈值内弱网表现开发者选项或抓包工具限制带宽有本地缓存时秒开无缓存时给骨架屏断网浏览飞行模式下进详情页已看过的景点仍可阅读分页边界快速滑到底部再回顶进度条不闪烁、不重复请求后台恢复切后台 10 分钟后切回列表位置保留不重新加载全量进程被杀adb shell am kill后重进登录态与缓存数据恢复正常调试类命令值得单独留意比如adb shell am kill com.example.scenic只杀后台进程、不触发 force-stop更接近系统内存紧张时的真实表现比强行停止更能暴露状态恢复的缺陷。还有一个容易被跳过的小技巧把首次进入的缓存写入放在Dispatchers.IO上、用withContext明确切线程然后在真机上开 StrictMode 的磁盘读写检测跑一遍主流程。凡是主线程上的磁盘操作都会在日志里报出来这比事后靠用户反馈定位“偶发卡顿”高效得多。景点类应用的首屏通常要在 1 秒内出内容把这条线守住后面加再多功能都不会显得慢。本文还有配套的精品资源点击获取 
长河君 · 2026/9/20 4:51:12 · 阅读 1.2k Android景区App开发：离线优先、性能优化与SHA1签名验收
简介本资源为基于 Android 平台的某景点移动端旅游软件系统设计与实现类毕业设计/课程设计参考文档面向计算机相关专业学生及移动应用开发入门者可用于选题借鉴、论文框架搭建与 Android 项目实战学习。压缩包内共 1 个 pdf 文件约 2.96MB内容为一份结构完整的论文文档涵盖绪论、国内外研究现状、Android 原生开发与地图 API 等相关技术、需求分析与三层架构设计、功能模块实现与性能优化以及基于 LoadRunner 的功能与并发性能测试等章节重点讲解旅游信息展示、天气预报、地图导航与系统管理等功能并涉及 HashMap 资源缓存、百度地图 API 集成等实现思路。目前已有 1088 人浏览学习适合在撰写同类旅游类移动端系统论文或搭建 Android 项目时对照参考快速理清从需求分析到系统测试的完整开发脉络。1. 景区 App 为什么不是“把网页套个壳”——Android 端的取舍旺季早上八点游客挤在山门闸机口打开 App信号只剩一格首页还在转圈——这是景区类移动端最常见的事故现场。问题往往不在服务端而在于移动端把所有内容都当成“必须联网才能看”景点介绍走实时接口、导览图走原图直出、列表滚动时还在主线程里等网络。把景点信息、导览地图、门票预订、语音讲解收进一个 Android 包本质上是在设计一套“弱网优先、离线可读”的信息系统而不是给官网加个壳。这篇适合三类人做课程设计或毕设、需要一份能跑起来的模块划分与数据表接了文旅或景区外包、要评估工期和技术风险已经在写 Android、想把生命周期、缓存、性能这些散点串成一条工程线。接下来的顺序是工程骨架、数据链路、性能优化、签名与验收每一段都落到可抄的 Gradle 配置、Room 表结构和 adb 命令。像 android 应用签名 sha1 值这类验收环节才会暴露的坑以及 android 进度条在分页列表里的正确用法都会在对应位置给具体做法。2. 用 Android Studio 搭出景点 App 的可运行骨架2.1 从建项到模块划分Android Studio 里的第一步不该是写 Activity在 Android Studio 里用 Empty Views Activity 模板建项包名按com.组织.scenic约定minSdk 建议 24能覆盖绝大多数在售机型compileSdk 和 targetSdk 跟随当前稳定版 SDK 平台即可不必为了追新把 targetSdk 提到预览版那会让权限行为和后台限制提前生效调试成本陡增。建完项之后先别急着往app模块里堆代码。景点类应用页面多、数据来源杂单模块写法三个月后就会变成“谁都不敢改”的状态。常见做法是按职责拆四个模块scenic-app/ ├── app/ # 壳工程Application、MainActivity、底部导航、路由表 ├── core-ui/ # 通用 UI加载态、错误页、图片加载封装、主题色 ├── data/ # 网络层、Room、Repository、DTO 与 Entity 映射 └── feature-scenic/ # 景点列表、详情、导览、门票页与对应 ViewModel模块主要职责允许依赖:app启动入口、导航图、变体配置全部 feature、core-ui:core-ui无业务的通用控件与资源基础库不依赖任何 feature:dataRetrofit 接口、Room 表、缓存策略基础库不依赖 UI:feature-scenic景点相关页面与状态管理:data、:core-ui依赖方向单向core-ui和data都不许反向依赖app。这条约束的意义在于以后要把门票模块单独拆出去或者做多端复用改动被限制在一个模块内。2.2 Gradle 依赖与参数只引真正用得上的库壳工程的依赖清单控制在十几行以内用版本目录统一管理版本避免各模块各写一套// app/build.gradle.kts dependencies { implementation(project(:feature-scenic)) implementation(project(:core-ui)) implementation(libs.androidx.core.ktx) implementation(libs.androidx.appcompat) implementation(libs.material) implementation(libs.androidx.navigation.fragment.ktx) // 网络抓包工具只在 debug 变体引入release 包里不存在 debugImplementation(libs.chucker) }段说明implementation而不是api是为了把依赖锁在模块内部减少编译期的传递暴露debugImplementation保证抓包、日志这类工具不会进正式包也顺带省掉几十 KB 到几百 KB 的体积。数据库和网络库放在:data模块里声明UI 模块只依赖:data暴露出来的 Repository 接口不直接碰 Retrofit 和 Room。构建参数上还有两个容易忽略的点android.buildFeatures.viewBinding true可以彻底告别findViewById和 Kotlin 合成视图android.nonTransitiveRClass true能让每个模块只生成自己的 R 类大型工程下能明显缩短增量编译时间。2.3 景点数据模型与 Room 表把“能离线看”写进结构里数据结构的第一个决定是主键用什么。景点名称会改、会重名不能用名称做主键服务端下发的spotId才是稳定标识。票价用整型存“分”而不是浮点避免出现 0.10.2 这类精度问题在收银台前爆雷。Entity(tableName scenic_spot) data class SpotEntity( PrimaryKey val spotId: String, // 与服务端一致的稳定 ID val name: String, val summary: String, val coverUrl: String, val latitude: Double, val longitude: Double, val openTime: String, val ticketPrice: Int, // 单位分 val updatedAt: Long // 服务端数据版本时间戳用于判断缓存是否过期 ) Dao interface SpotDao { Query(SELECT * FROM scenic_spot ORDER BY updatedAt DESC) fun observeAll(): FlowListSpotEntity Upsert suspend fun upsertAll(spots: ListSpotEntity) Query(SELECT MAX(updatedAt) FROM scenic_spot) suspend fun latestVersion(): Long? }Flow返回值让列表页订阅到数据变化后自动刷新不需要手动通知 AdapterUpsert在 SQLite 层做“有则更新、无则插入”比先查后写少一次往返也不会有并发写冲突。latestVersion()是给后面缓存策略用的它决定要不要再去请求服务端。经纬度这一列建议在建表时就加上索引导览页按“离我最近”排序时全表扫描在几千条景点数据上还撑得住一旦加上餐饮、厕所、停车场这些 POI就会明显变慢。加索引的方式是在实体上标注Entity(indices [Index(latitude, longitude)])。2.4 首页骨架CoordinatorLayout 配 Banner 与加载态景点首页的经典结构是“顶部可折叠大图 下方列表”用CoordinatorLayout加AppBarLayout的组合最省事滚动联动由appbar_scrolling_view_behavior自动接管不需要自己写滚动监听。androidx.coordinatorlayout.widget.CoordinatorLayout ... com.google.android.material.appbar.AppBarLayout ... com.google.android.material.appbar.CollapsingToolbarLayout app:layout_scrollFlagsscroll|exitUntilCollapsed androidx.viewpager2.widget.ViewPager2 android:idid/bannerPager ... / com.google.android.material.appbar.MaterialToolbar app:layout_collapseModepin ... / /com.google.android.material.appbar.CollapsingToolbarLayout /com.google.android.material.appbar.AppBarLayout androidx.recyclerview.widget.RecyclerView app:layout_behaviorstring/appbar_scrolling_view_behavior ... / com.google.android.material.progressindicator.CircularProgressIndicator android:idid/loading ... / /androidx.coordinatorlayout.widget.CoordinatorLayoutBanner 用ViewPager2时自动轮播不要用裸Handler.postDelayed页面切到后台还在跑会白耗电。绑定生命周期更稳// 页面 RESUMED 时才开始轮播退到后台自动停止 lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.RESUMED) { while (true) { delay(BANNER_INTERVAL_MS) val next (bannerPager.currentItem 1) % bannerAdapter.itemCount bannerPager.setCurrentItem(next, true) } } }参数上BANNER_INTERVAL_MS取 3000 到 5000 之间比较合适低于 3000 用户刚看清标题就滑走了高于 5000 又等于没有轮播。轮播只对图片数量大于 1 的情况启用单张图还自动翻页会很怪。3. 景点数据链路Retrofit Room 的离线优先读取3.1 接口分层与 DTO 到 Entity 的映射网络层的第一原则是接口定义和数据表结构解耦。服务端字段命名习惯和数据库列名几乎不可能一直一致直接拿 DTO 当实体用一次字段改名就意味着一轮数据库迁移风险极高。interface ScenicApi { GET(api/v1/spots) suspend fun getSpots( Query(page) page: Int, Query(size) size: Int, Query(version) version: Long? // 带上本地版本服务端可判断是否需要下发全量 ): ApiResponseSpotPageDto } data class SpotDto( val id: String, val name: String, SerializedName(cover) val coverUrl: String, val lat: Double, val lng: Double, SerializedName(open_time) val openTime: String, SerializedName(price_cent) val priceCent: Int, SerializedName(updated_at) val updatedAt: Long ) fun SpotDto.toEntity() SpotEntity( spotId id, name name, summary summary, coverUrl coverUrl, latitude lat, longitude lng, openTime openTime, ticketPrice priceCent, updatedAt updatedAt )SerializedName承担的是“服务端下划线风格到客户端驼峰风格”的翻译工作把差异集中在映射函数里。version参数是可选优化服务端可以据此返回“无更新”而不用传完整列表流量在弱网环境下会省得很明显。3.2 离线优先的读取顺序与缓存时效读数据的顺序决定用户的第一印象。正确的顺序是“先给本地已有的、再后台刷新”而不是“先转圈等网络”。Repository 是把这件事收敛到一个地方的关键class SpotRepository( private val api: ScenicApi, private val dao: SpotDao ) { // UI 只订阅这个 Flow本地库一变列表就刷新 fun spots(): FlowListSpotEntity dao.observeAll() suspend fun refresh(force: Boolean false): ResultUnit runCatching { val localVersion dao.latestVersion() ?: 0L if (!force !isStale(localVersion)) returnrunCatching val remote api.getSpots(page 1, size PAGE_SIZE, version localVersion) .data.items dao.upsertAll(remote.map { it.toEntity() }) } private fun isStale(lastUpdated: Long): Boolean System.currentTimeMillis() - lastUpdated CACHE_TTL_MS }CACHE_TTL_MS默认设 6 小时比较合理景点介绍、开放时间这类内容一天内基本不变6 小时足以覆盖一次游玩行程。如果页面里有演出场次、临时闭园通知这类强时效内容把 TTL 调到 5 分钟并在下拉刷新时传force true跳过时效判断。不同场景下的读取策略值得列清楚进入时机数据来源用户看到什么失败时怎么处理首次安装进入本地空库 → 网络骨架屏 → 列表错误页带重试按钮二次进入本地库先回显 → 后台静默刷新秒开列表无感更新静默失败保留本地数据无网络仅本地库列表加“离线数据”角标不弹 Toast 打断浏览第三行是最容易被做错的很多应用一断网就弹一个全屏错误页把本地明明已经缓存好的景点介绍也一起挡掉了用户只会觉得这 App 特别“脆”。3.3 分页列表与 android 进度条的状态机景点列表随着 POI 增多会越来越长用 Paging 3 做分页比自己写滚动监听省心得多PagingSource负责加载UI 只消费状态class SpotPagingSource(private val api: ScenicApi) : PagingSourceInt, SpotEntity() { override suspend fun load(params: LoadParamsInt): LoadResultInt, SpotEntity { val page params.key ?: 1 return try { val resp api.getSpots(page, params.loadSize, null) LoadResult.Page( data resp.data.items.map { it.toEntity() }, prevKey if (page 1) null else page - 1, nextKey if (resp.data.items.isEmpty()) null else page 1 ) } catch (e: IOException) { LoadResult.Error(e) // 交给 UI 展示重试而不是让异常冒泡崩溃 } } override fun getRefreshKey(state: PagingStateInt, SpotEntity) null }UI 侧的进度显示必须区分两种加载态这是 android 进度条最常见的误用点下拉刷新用refresh状态滚到底部用append状态共用一个布尔值就会出现“滑动过程中底部进度条乱闪”。adapter.loadStateFlow .distinctUntilChanged() .collect { state - // 顶部下拉刷新中用 LinearProgressIndicator binding.refreshBar.isVisible state.refresh is LoadState.Loading // 底部加载更多中用列表尾部的小 CircularProgressIndicator binding.appendProgress.isVisible state.append is LoadState.Loading // 错误态单独给重试入口 binding.retryButton.isVisible state.refresh is LoadState.Error || state.append is LoadState.Error }IOException单独捕获并转成LoadResult.Error的原因是景区弱网、地铁隧道、山区信号盲区都会产生这类异常它们属于预期内的失败不应该被当成程序缺陷上报到崩溃平台否则真正的线上问题会被淹没在噪声里。4. 移动端性能优化启动、列表、包体积三条线4.1 冷启动耗时定位从 Application 到首帧冷启动是用户对 App 的第一感知也是移动端性能优化里收益最直接的一项。先量再改别凭感觉。用 adb 命令反复测几次取中位数# 杀掉进程模拟冷启动-W 会打印耗时 adb shell am force-stop com.example.scenic adb shell am start -W -n com.example.scenic/.ui.MainActivity输出里的TotalTime是最接近用户感知的数值代表从进程启动到 Activity 首帧绘制完成WaitTime包含系统调度开销通常略大于TotalTime。同一台设备连测 5 次取中位数比单次结果可靠得多。定位之后常见的三个优化动作一是把Application.onCreate里跟首屏无关的初始化挪走地图 SDK、统计埋点、推送注册全部延迟到首帧之后或者用 App Startup 库显式声明依赖顺序二是首屏接口不要在onCreate里同步阻塞改成先渲染骨架屏三是检查主题里是否配置了启动窗口背景缺了它会出现一段白屏。4.2 RecyclerView 掉帧与图片加载参数列表滑动掉帧十有八九出在onBindViewHolder里干了重活。三条硬性约束不要在绑定过程中读数据库或文件不要每次都重新创建ViewHolder的点击监听放在初始化时创建一次图片必须按控件实际尺寸解码而不是原图直出。Glide.with(holder.image) .load(spot.coverUrl) .placeholder(R.drawable.ic_spot_placeholder) .override(720, 480) // 按控件尺寸解码别按原图分辨率 .centerCrop() .diskCacheStrategy(DiskCacheStrategy.AUTOMATIC) .into(holder.image)override(720, 480)的效果在景点大图上最明显服务端为了适配平板可能存了 2000 像素宽的封面图手机端按原尺寸解码一张图就是十几 MB 的位图内存列表快速滑动时必然抖动甚至 OOM。另外记得recyclerView.setHasFixedSize(true)当 item 高度固定时它能让 RecyclerView 跳过重新测量的步骤。如果要做严肃的帧率验证用 Macrobenchmark 跑基准测试或者开发者选项里的“GPU 渲染模式分析”关注柱状图里超过绿线16.6ms的帧。4.3 包体积与资源瘦身包体积直接影响下载转化率尤其是景区场景下用户在弱网中扫码下载的时候。先看现状用 Build 菜单里的 Analyze APK或者直接跑一次正式构建./gradlew :app:assembleRelease然后按收益排序处理前两项通常能砍掉大头手段典型收益风险与注意开启 R8 代码压缩与资源压缩20% 到 40%反射调用的类要写 keep 规则按 ABI 拆包每去掉一个 ABI 省 15% 到 25%需确认在售机型覆盖WebP 替换 PNG 大图图片体积降 30% 以上检查低版本设备兼容移除未使用的语言资源视情况而定用resConfigs限定语种对应配置android { buildTypes { release { isMinifyEnabled true isShrinkResources true proguardFiles( getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro ) } } splits { abi { isEnable true reset() include(arm64-v8a, armeabi-v7a) isUniversalApk false } } }isShrinkResources true必须在isMinifyEnabled true的前提下才生效单独打开没有作用这是最常见的配置错误。开启压缩后一定要跑一遍完整的功能回归尤其是靠反射和 JSON 反序列化工作的模块缺 keep 规则会在运行时才抛ClassNotFoundException。5. 签名、SHA1 获取与真机验收清单正式包签名是发布前最后一道门槛。用 keytool 可以看到证书的完整信息其中就包括地图、推送这类三方 SDK 需要绑定的 SHA1# 查看发布证书信息输出中的 SHA1 即三方平台需要填写的值 keytool -list -v -keystore release.jks -alias scenic -storepass ****** # 或者在 Gradle 里一次性拿到所有变体的签名信息 ./gradlew :app:signingReport必须记住的是debug 和 release 用的是两套证书SHA1 值完全不同。开发阶段三方 SDK 后台填的是 debug 的 SHA1上线前忘了换成 release 的会出现“调试机好好的、正式包地图一片空白”这种只在发布后才暴露的问题。稳妥做法是在 SDK 后台把两个 SHA1 都登记上发布时再清理掉 debug 那条。验收阶段建议按下面这张清单逐项过一遍都是真机上才跑得出来的结论检查项操作方式通过标准冷启动adb shell am start -W连测 5 次中位数在团队定的阈值内弱网表现开发者选项或抓包工具限制带宽有本地缓存时秒开无缓存时给骨架屏断网浏览飞行模式下进详情页已看过的景点仍可阅读分页边界快速滑到底部再回顶进度条不闪烁、不重复请求后台恢复切后台 10 分钟后切回列表位置保留不重新加载全量进程被杀adb shell am kill后重进登录态与缓存数据恢复正常调试类命令值得单独留意比如adb shell am kill com.example.scenic只杀后台进程、不触发 force-stop更接近系统内存紧张时的真实表现比强行停止更能暴露状态恢复的缺陷。还有一个容易被跳过的小技巧把首次进入的缓存写入放在Dispatchers.IO上、用withContext明确切线程然后在真机上开 StrictMode 的磁盘读写检测跑一遍主流程。凡是主线程上的磁盘操作都会在日志里报出来这比事后靠用户反馈定位“偶发卡顿”高效得多。景点类应用的首屏通常要在 1 秒内出内容把这条线守住后面加再多功能都不会显得慢。本文还有配套的精品资源点击获取