第15章 进入实战，开发一个天气预报App

本页对应第3版正式结构中的 第15章 进入实战，开发一个天气预报App。课程不复制原文，而是按出版社电子书目录逐节点独立重构平台机制与工程实践，目标是把需求、Git、MVVM、城市搜索、天气展示、刷新切换、图标和签名发布串成可交付App。每个示例都必须说明目标API、设备、生命周期、线程、状态来源和失败条件。

可验收学习目标

首要陷阱是“只复刻成功截图，没有需求边界、错误状态、缓存、密钥管理、测试、签名与可重复发布”。先预测再运行；任何“能跑”结论都要经过生命周期、失败输入、安全、资源释放和目标SDK迁移检查。

先建立直觉

在《第15章 进入实战，开发一个天气预报App》中，先把生命周期看成系统与应用之间的时序合同，再把版本边界看成这份合同的坐标。API 名称只是入口；真正要追踪的是输入由谁接收、状态由谁保存、任务由谁取消，以及失败后用户看到什么。

《第15章 进入实战，开发一个天气预报App》的直觉检验只改变一个条件：旋转、进程重建、拒绝权限、断网或目标 SDK。若结果随隐藏缓存或旧对象身份漂移，就回到状态所有者和平台合同定位首个分叉，而不是继续堆补丁。

最小可执行切片

先把状态与副作用分离，示例只表达可恢复合同：

sealed interface UiState {
    data object Loading : UiState
    data class Ready(val itemId: String) : UiState
    data class Failed(val retryable: Boolean) : UiState
}
 
fun reduce(state: UiState, event: UserEvent): UiState = nextState(state, event)

固定环境并从命令行保留可复现证据：

./gradlew clean test assembleDebug
adb install -r app/build/outputs/apk/debug/app-debug.apk
adb shell am force-stop example.package
adb shell monkey -p example.package 1
adb logcat -d -v threadtime > run.log

验收在操作前写出故障条件：

Given a pinned JDK, SDK, Gradle build, device API, locale, and seed
When the component is recreated after state saving or process death
Then user-visible state is restored from durable facts
And cancelled work cannot update a destroyed owner
And denied permission, offline input, and malformed data remain recoverable

在《第15章 进入实战，开发一个天气预报App》中，三段代码分别承担状态模型、环境重放和行为断言。真实工程还需静态检查、单元测试、仪器测试、截图或无障碍检查，以及发布构建验证；不要用日志输出代替断言，也不要让测试依赖本机IDE缓存。

线程、状态与资源边界

每个实现列出五张表：入口来自哪里，执行在哪个线程，状态保存在哪里，资源由谁关闭，失败怎样呈现与重试。在《第15章 进入实战，开发一个天气预报App》中，网络重试必须有上限、退避和幂等；数据库升级必须覆盖所有受支持旧版本；文件和媒体句柄在取消与异常路径释放；组件回调不持有超过生命周期的View或Context。

性能以用户任务衡量。在《第15章 进入实战，开发一个天气预报App》中，启动不仅看首帧，还要检查可交互时刻；列表不仅看平均帧率，还要检查滚动卡顿和绑定分配；后台工作不仅看是否完成，还要检查电量、约束与系统调度；网络不仅看成功耗时，还要检查超时、取消和错误恢复。每次比较固定设备温度、构建类型、数据规模与网络条件。

在《第15章 进入实战，开发一个天气预报App》中，版本迁移分两步：先在Android 10/Kotlin语境下还原书中机制，再对目标compileSdk、targetSdk和设备API查询当前官方合同。一次只迁移一个变化，例如存储、权限、通知、后台启动、发布仓库或已弃用库；保存编译警告、运行差异和回滚。新API更现代不代表自动正确，旧API能编译也不代表仍符合平台政策。

本章回顾

本页从“第15章 进入实战，开发一个天气预报App”覆盖到“15.9 你还可以做的事情”，共10个正式节点。闭环是先明确生命周期、所有者与状态源，再执行“从空仓库实现天气App，注入无网、慢网、空数据、城市切换、进程重建和签名配置差异完成端到端验收”，最后以需求与风险表、分层依赖图、离线/错误状态、端到端测试、签名产物与发布清单证明功能在正常、重建、失败和版本迁移场景下可重放、可恢复、可发布。

← 上一页：第14章 继续进阶，你还应该掌握的高级技巧 · 下一页：第16章 编写并发布一个开源库，PermissionX →

原版目录概念补充核对

以下条目补齐官方目录中容易被示例主线掩盖的概念。它们不重复罗列目录，而是明确每项概念的机制、适用边界和验收证据。

15.1 功能需求及技术可行性分析：机制、边界与证据

第15章 进入实战，开发一个天气预报App中的15.1 功能需求及技术可行性分析要在 Android 10/Kotlin 基线中写清用户任务、平台合同、状态 owner、线程与资源释放，再单列现代 targetSdk 差异。用正常、拒绝和生命周期重建三类样本核对最终行为。

15.2 Git时间：将代码托管到GitHub上：机制、边界与证据

第15章 进入实战，开发一个天气预报App中的15.2 Git时间：将代码托管到GitHub上要在 Android 10/Kotlin 基线中写清用户任务、平台合同、状态 owner、线程与资源释放，再单列现代 targetSdk 差异。用正常、拒绝和生命周期重建三类样本核对最终行为。

15.3 搭建MVVM项目架构：机制、边界与证据

第15章 进入实战，开发一个天气预报App中的15.3 搭建MVVM项目架构要在 Android 10/Kotlin 基线中写清用户任务、平台合同、状态 owner、线程与资源释放，再单列现代 targetSdk 差异。用正常、拒绝和生命周期重建三类样本核对最终行为。

15.4 搜索全球城市数据：机制、边界与证据

第15章 进入实战，开发一个天气预报App中的15.4 搜索全球城市数据要定义数据模式、事务、升级和失败恢复，成功写入一次不能证明旧版本或异常中断安全。保存迁移前后数据、事务结果与查询输出，注入磁盘/解析失败或跨版本升级验证。

15.5 显示天气信息：机制、边界与证据

第15章 进入实战，开发一个天气预报App中的15.5 显示天气信息要明确请求输入、超时/取消、解析、缓存与错误呈现。以可控响应复现成功、慢网、断网和畸形数据，核对请求日志、持久状态、重试上限及界面恢复。

15.6 手动刷新天气和切换城市：机制、边界与证据

第15章 进入实战，开发一个天气预报App中的15.6 手动刷新天气和切换城市要明确请求输入、超时/取消、解析、缓存与错误呈现。以可控响应复现成功、慢网、断网和畸形数据，核对请求日志、持久状态、重试上限及界面恢复。

15.7 制作App的图标：机制、边界与证据

第15章 进入实战，开发一个天气预报App中的15.7 制作App的图标要在 Android 10/Kotlin 基线中写清用户任务、平台合同、状态 owner、线程与资源释放，再单列现代 targetSdk 差异。用正常、拒绝和生命周期重建三类样本核对最终行为。

15.8 生成正式签名的APK文件：机制、边界与证据

第15章 进入实战，开发一个天气预报App中的15.8 生成正式签名的APK文件要定义数据模式、事务、升级和失败恢复，成功写入一次不能证明旧版本或异常中断安全。保存迁移前后数据、事务结果与查询输出，注入磁盘/解析失败或跨版本升级验证。