简介《基于iOS平台的天气App应用设计与实现》文献综述文档面向计算机软件毕业设计及移动应用方向论文写作适用于准备撰写开题报告、需求分析或文献综述章节的本科生与研究生。文档从信息时代关键技术成熟、人们通过移动设备获取信息的大趋势切入引出天气App成为智能手机必备应用的需求背景随后系统梳理了移动互联网的定义、发展现状与五个基本特点并结合天气App应用案例引用移动用户规模、智能手机保有量、App Store下载量等数据说明移动应用市场的高速增长以及用户首选客户端应用的行为变化。同时内容还从用户体验、数据获取、功能集成、个性化设置、安全性、技术创新等角度总结了天气App设计时应关注的关键要点为后续系统实现提供了较为完整的理论依据。资源共1个doc文件大小48KB全文章节层次分明便于直接阅读、引用与二次整理。已有215人学习可作为毕业设计文献综述写作的参考范本也能帮助快速建立移动应用类论文的研究框架。1. 基于 iOS 的天气 App 毕业设计为什么要先从文献综述读起做计算机软件毕业设计的人最容易踩的第一个坑不是不会写代码而是把范围想得太大。这篇基于 iOS 平台的天气 App 设计与实现文献综述看标题像是一份论文资料实际上它把移动互联网背景、天气 App 的六个核心功能、Objective-C 语言、GCD 并发和 HTTP 请求全部梳理了一遍等于帮你把毕业设计的范围提前圈好了。与其从网上下载一份源码直接跑我更建议先读这类综述把功能模块、数据来源、技术选型的原因弄清楚后面写代码时才不会一直改需求。本文会沿着这份综述的脉络拆解出一份能直接照着做的 iOS 天气 App 开发路径。2. 移动互联网与天气 App 的选型逻辑2.1 移动互联网现状对 App 产品设计的真实约束文献综述里引用了大量历史数据比如移动互联网用户增长、智能手机保有量、App Store 下载量等。这些数字放在今天看并不新但背后那条逻辑仍然成立用户越来越习惯通过移动终端获取实时信息而天气恰好是刚需。你在做天气 App 时不需要把报告里的所有结论都搬进需求文档只需要提炼出三条影响设计原则的结论。第一条是用户体验至上。天气信息的核心价值是“快”所以首屏要把当前温度、天气状况、最高最低温放在最显眼的位置而不是先展示广告或城市列表。第二条是业务创新决定竞争力。市面上的天气 App 很多如果没有差异化功能比如生活指数、降雨提醒、多城市切换用户没有理由留下来。第三条是移动端网络环境比 PC 更复杂弱网、断网、运营商劫持都会出现所以请求层要能处理超时和失败重试。我把这些结论直接转化成功能优先级先做“查看当日天气”和“多城市管理”再做趋势图和生活指数。这样规划出来的版本既能满足综述里提到的功能要求又不会在中期阶段陷入边做边改的困境。2.2 天气 App 的六个核心功能模块与优先级文献综述列出了天气 App 的六个主要功能选择城市、添加多个城市、删除所选城市、查看当日天气详情、查看未来一周天气趋势、查看生活指数。这六个功能正好对应一个最小可用版本的完整闭环。功能模块用户场景数据字段优先级选择城市首次进入 App 定位或搜索城市城市名、城市 ID、经纬度P0添加多个城市关注多地天气一键切换城市列表本地持久化P0删除所选城市移除不关注城市保持列表整洁城市列表索引P1当日天气详情查看实时温度、风向、湿度、日期温度、天气码、湿度、风向P0未来一周趋势图了解未来几天气温变化规划出行每日最高/最低温、天气码P1生活指数查看穿衣、洗车、运动建议指数类型、级别、建议文案P1这里要注意P0 不是简单地把页面堆出来而是要先确定数据模型。一个城市的完整信息由基础字段城市名、城市 ID、更新时间和天气字段实时温度、天气码、湿度、风向、未来趋势数组组成。建议把城市信息和天气信息拆成两个模型CityModel 负责城市列表WeatherModel 负责天气数据这样网络请求返回后只需要更新天气模型不会跟城市列表的操作耦合在一起。2.3 平台选型iOS 与 Objective-C 的取舍文档里选择 Objective-C但 iOS 开发现在的主流语言早已转向 Swift。如果学校没有强制指定语言我更推荐用 Swift 来做交互和 UI 部分但网络层和模型层的设计思路仍然可以参考 Objective-C 的写法。原因在于很多老牌天气接口 SDK 和面试题里依然会问 Objective-C 的语法和内存管理如果你能看懂这篇综述里的代码片段再对照 Swift 写一遍理解会更扎实。选型时还要考虑 iOS 版本兼容。天气 App 需要定位用户当前位置这必然要接触 CoreLocation。下面这段代码是 iOS 端请求定位权限的常见写法#import CoreLocation/CoreLocation.h - (void)startCityLocation { CLLocationManager *locationManager [[CLLocationManager alloc] init]; locationManager.desiredAccuracy kCLLocationAccuracyKilometer; // 天气场景不需要高精度定位 if ([locationManager respondsToSelector:selector(requestWhenInUseAuthorization)]) { [locationManager requestWhenInUseAuthorization]; // iOS 8 之后必须显式请求 } [locationManager startUpdatingLocation]; }这段代码里有一个容易踩的坑desiredAccuracy设置为kCLLocationAccuracyKilometer而不是kCLLocationAccuracyBest是因为天气服务只需要城市级别的位置信息高精度会加大耗电和定位回调频率。另外requestWhenInUseAuthorization只在系统版本支持时才会去调用如果你的 App 最低支持版本低于 iOS 8需要先判断方法是否存在否则会直接崩溃。还要记得在 Info.plist 里添加NSLocationWhenInUseUsageDescription缺少这个描述文案时定位授权不会弹窗。这些细节在文献综述里不会写但真正上线或答辩演示时一定会遇到。3. Objective-C 与 MVC天气 App 的骨架设计3.1 MVC 分层在天气 App 中的实际意义文献综述提到系统采用 MVC 设计模式将视图层、模型层和控制层用不同组件实现降低系统内各部分之间的耦合性。这句话看起来像套话但放到天气 App 里非常具体。View 层只负责展示比如温度标签、天气图标、趋势曲线Model 层负责管理城市和天气数据Controller 层承担两者之间的调度。打个比方如果直接把网络请求写进 TableViewCell那么刷新数据时你要在 Cell 里改逻辑切换城市时又要处理重复请求代码很快会变成一坨。正确的分工是Cell 只接收一个 WeatherModel 对象调用configureWithModel:更新 UIViewController 负责创建模型、发起请求、在回调里刷新表格Model 只做数据解析和存取不引用 UIKit 里面的任何东西。这样才能保证你在替换数据源、增加新接口时不需要大范围修改视图层。Objective-C 在这套体系里还有一层特点它基于消息传递机制而不是像 C 那样直接调用方法。举个例子[cityModel updateTime]实际上是在向 cityModel 发送一条消息。这种风格在写代理方法时特别自然比如CLLocationManagerDelegate的回调就是典型的消息传递。初学 iOS 的人容易忽略这层区别但写网络层回调时消息传递和 block 捕获机制会直接影响内存管理。3.2 从文献综述到代码CityModel 的落地写法文献综述里虽然没有给出具体类定义但根据功能描述城市模型至少需要包含城市名、省份、城市 ID、更新时间四个字段。很多新手会把所有字段堆在一个类里我一般会先建一个干净的模型层方便后续 HTTP 解析和本地存档复用。// CityModel.h #import Foundation/Foundation.h interface CityModel : NSObject property (nonatomic, copy) NSString *cityName; property (nonatomic, copy) NSString *province; property (nonatomic, assign) NSInteger cityId; property (nonatomic, strong) NSDate *updateTime; - (instancetype)initWithDictionary:(NSDictionary *)dict; end // CityModel.m #import CityModel.h implementation CityModel - (instancetype)initWithDictionary:(NSDictionary *)dict { self [super init]; if (self) { _cityName dict[city] ?: ; _province dict[province] ?: ; _cityId [dict[id] integerValue]; // 常见做法是先把时间字段转成 NSDate避免在 View 层做字符串截取 if ([dict[updatetime] isKindOfClass:[NSString class]]) { NSDateFormatter *fmt [[NSDateFormatter alloc] init]; fmt.dateFormat yyyy-MM-dd HH:mm; _updateTime [fmt dateFromString:dict[updatetime]]; } } return self; } end这段代码的重点在initWithDictionary:的防御式写法。dict[city] ?: 的意思是如果字典里没有 city 字段就赋值为空字符串避免 UI 上出现(null)。isKindOfClass:判断是为了防止接口突然返回 NSNull 导致崩溃这类问题在真实天气接口里很常见。时间字段处理上不要在 View 层直接去截取字符串而是统一转成 NSDate这样后面做“更新时间排序”或“今天/明天显示”时可以直接用系统日历 API。3.3 控制器层的多城市管理套路多城市管理是天气 App 最核心的交互。文献综述里写了添加、删除、切换三个操作实现这三个操作时控制器需要负责事件转发和本地持久化。控制器方法对应操作涉及模型说明addCityWithName:添加城市CityModel创建模型后插入数组刷新表格removeCityAtIndex:删除城市CityModel更新数组和本地存档reloadWeatherAtCurrentCity:切换城市WeatherModel发起网络请求接到回调后刷新首屏控制器拿到用户输入的城市名后不应该自己直接去拼请求参数而是先构造 CityModel再交给网络层。这样可以保证“城市列表”和“天气详情”两个页面共享同一份数据。本地持久化我一般用NSUserDefaults存 JSON 字符串或者用NSKeyedArchiver归档模型列表。天气 App 的数据量很小不需要上 CoreData用归档反而简单清晰。4. GCD 与 HTTP天气数据请求的并发处理4.1 GCD 为什么适合天气 App 这种 IO 型应用文献综述里重点介绍了 GCD说它比线程更简单高效会根据系统负载自动增减线程数。这个结论放到持有天气类 App 上依然成立。天气 App 的典型场景是用户进入首页后同时请求当前城市天气和未来三天趋势图再往下拉还会请求生活指数。如果每个接口都单独开一个线程线程的创建销毁开销会非常明显。GCD 的核心概念是队列。主队列负责 UI 更新全局并发队列负责耗时操作。你不需要关心具体创建了多少线程系统会根据 CPU 核心数和当前负载来调度。这里要特别注意一个常识性问题NSURLSession 的 completionHandler 默认在后台线程执行所以拿到数据后必须手动切回主队列刷新标签否则会引发 UI 更新冲突严重时直接闪退。4.2 用 dispatch_group 批量刷新多城市天气多城市管理意味着用户可能添加了五六个城市。如果每次只刷新当前城市用户可以接受但如果用户进入 App 后想一次性看到所有城市的天气摘要就需要并发刷新。使用dispatch_group是常见做法它能等所有网络请求全部结束后再统一更新界面。- (void)refreshAllCitiesWithArray:(NSArrayCityModel * *)cityList { dispatch_group_t group dispatch_group_create(); for (CityModel *city in cityList) { dispatch_group_enter(group); // 进入组计数加一 [self fetchWeatherForCity:city completion:^(WeatherModel *model, NSError *error) { if (model) { city.weather model; // 把天气结果挂到城市模型上 } dispatch_group_leave(group); // 离开组计数减一 }]; } dispatch_group_notify(group, dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0), ^{ // 所有请求结束后回到主线程刷新 dispatch_async(dispatch_get_main_queue(), ^{ [self.tableView reloadData]; }); }); }这段代码的逻辑是在发起每个请求前调用dispatch_group_enter让组计数器加一请求回调无论成功失败都调用dispatch_group_leave计数器减一。dispatch_group_notify会在所有计数归零后执行所以它会等待所有城市的天气请求完成再刷新表格。这里有一个容易漏掉的细节如果某个请求永久卡住计数器永远不会归零刷新不会执行。因此网络层必须设置 timeout或者用NSURLSessionConfiguration的timeoutIntervalForRequest来控制不给 GCD 组留下悬空计数。4.3 HTTP 请求参数与常见状态码排查天气数据来自服务端接口文献综述说了 HTTP 请求是从客户端到服务器端的请求消息包含请求方法、资源标识符和协议版本。但实际调试时你更需要关心状态码和字段容错。下面这份排查表是我自己总结的适用于大多数天气类接口状态码含义常见原因处理建议200请求成功正常返回解析 JSON刷新数据304未修改命中缓存使用本地缓存配合 ETag 判断400请求参数错误cityid 格式不对检查参数拼写和类型401未授权appkey 无效重新配置请求头500服务端异常数据服务不稳定展示上次缓存提示稍后重试响应参数层面天气接口通常包含cityid、date、temp、humidity、wind等字段。你可以在请求 URL 里显式传入cityid来避免每次都走定位流程。定位失败时兜底方案是使用用户上次选择的城市缓存。很多天气接口的免费版本有时会返回空数据所以模型层的字段最好都做成可空的前端 UI 再根据是否有值来决定显示真实数据还是占位符。习惯性把接口返回的所有字段都用强转类型接住后续接口升级时你的 App 才不会因为一个字段类型变化就崩溃。5. 从综述到实现天气 App 的优化与验证方法5.1 用本地 JSON 先跑通 UI 与数据流写天气 App 最容易卡住的环节是接口不稳定。你还没有写完 UI后端接口先挂掉了整个调试过程会非常痛苦。我的习惯是开发阶段先用本地 JSON 文件模拟接口数据把 UI 和模型层全部跑通再切换到真实接口。你可以在 Xcode 工程里放一个weather_sample.json然后写一个以文件名为参数的MockWeatherService让网络层和 Mock 层实现同一个协议。id json [NSJSONSerialization JSONObjectWithData:data options:0 error:nil]; WeatherModel *model [[WeatherModel alloc] initWithDictionary:json];这样切换接口时只需要改一行注入代码不用动 View 和 Controller。本地 JSON 跑通后再去验证弱网和接口异常排查难度会小很多。5.2 从文献综述提炼一份验收清单文献综述列出的功能点其实可以直接转换成答辩演示时的测试用例。表格里每一行都是一个验证维度这也是评审老师最关注的方面。测试项操作步骤预期结果多城市添加点击加号输入北京和上海城市列表出现两个条目天气能切换城市删除进入编辑状态删除上海主界面回到北京天气网络异常打开飞行模式点击刷新App 不崩溃显示上次缓存和提示文案趋势图展示进入趋势页能看出一周温度走向无绘制错乱生活指数展示下拉刷新生活指数指数与天气条件匹配文案不出现空值如果你用的是 iOS 14 以上系统开发时可以直接在 Xcode 模拟器里测试多城市切换没必要一开始就上真机。唯一要注意的是模拟器默认没有定位数据需要手动设置模拟器位置。等所有功能在模拟器上验证通过后再拿到真机上用开发者模式运行重点看定位和网络权限是否正常弹出。5.3 答辩前必须做的一次数据层审查无论功能做得多完整答辩时被问最多的还是数据层。比如“城市列表存在哪里”“天气接口返回的日期格式怎么处理”“多城市并发请求的线程安全如何保证”。建议你在答辩前把 CityModel 和 WeatherModel 的字段挨个检查一遍凡是 UI 上展示的数据都必须有默认值凡是网络字段都必须做类型判断。最好再补两个单元测试一个验证 JSON 解析能处理缺失字段一个验证城市模型能正确写进本地文件。这两个小测试写完你对整套代码的掌控感会完全不同回答问题时也不会心虚。本文还有配套的精品资源点击获取
从文献综述到代码：iOS天气App设计与实现全攻略
简介《基于iOS平台的天气App应用设计与实现》文献综述文档面向计算机软件毕业设计及移动应用方向论文写作适用于准备撰写开题报告、需求分析或文献综述章节的本科生与研究生。文档从信息时代关键技术成熟、人们通过移动设备获取信息的大趋势切入引出天气App成为智能手机必备应用的需求背景随后系统梳理了移动互联网的定义、发展现状与五个基本特点并结合天气App应用案例引用移动用户规模、智能手机保有量、App Store下载量等数据说明移动应用市场的高速增长以及用户首选客户端应用的行为变化。同时内容还从用户体验、数据获取、功能集成、个性化设置、安全性、技术创新等角度总结了天气App设计时应关注的关键要点为后续系统实现提供了较为完整的理论依据。资源共1个doc文件大小48KB全文章节层次分明便于直接阅读、引用与二次整理。已有215人学习可作为毕业设计文献综述写作的参考范本也能帮助快速建立移动应用类论文的研究框架。1. 基于 iOS 的天气 App 毕业设计为什么要先从文献综述读起做计算机软件毕业设计的人最容易踩的第一个坑不是不会写代码而是把范围想得太大。这篇基于 iOS 平台的天气 App 设计与实现文献综述看标题像是一份论文资料实际上它把移动互联网背景、天气 App 的六个核心功能、Objective-C 语言、GCD 并发和 HTTP 请求全部梳理了一遍等于帮你把毕业设计的范围提前圈好了。与其从网上下载一份源码直接跑我更建议先读这类综述把功能模块、数据来源、技术选型的原因弄清楚后面写代码时才不会一直改需求。本文会沿着这份综述的脉络拆解出一份能直接照着做的 iOS 天气 App 开发路径。2. 移动互联网与天气 App 的选型逻辑2.1 移动互联网现状对 App 产品设计的真实约束文献综述里引用了大量历史数据比如移动互联网用户增长、智能手机保有量、App Store 下载量等。这些数字放在今天看并不新但背后那条逻辑仍然成立用户越来越习惯通过移动终端获取实时信息而天气恰好是刚需。你在做天气 App 时不需要把报告里的所有结论都搬进需求文档只需要提炼出三条影响设计原则的结论。第一条是用户体验至上。天气信息的核心价值是“快”所以首屏要把当前温度、天气状况、最高最低温放在最显眼的位置而不是先展示广告或城市列表。第二条是业务创新决定竞争力。市面上的天气 App 很多如果没有差异化功能比如生活指数、降雨提醒、多城市切换用户没有理由留下来。第三条是移动端网络环境比 PC 更复杂弱网、断网、运营商劫持都会出现所以请求层要能处理超时和失败重试。我把这些结论直接转化成功能优先级先做“查看当日天气”和“多城市管理”再做趋势图和生活指数。这样规划出来的版本既能满足综述里提到的功能要求又不会在中期阶段陷入边做边改的困境。2.2 天气 App 的六个核心功能模块与优先级文献综述列出了天气 App 的六个主要功能选择城市、添加多个城市、删除所选城市、查看当日天气详情、查看未来一周天气趋势、查看生活指数。这六个功能正好对应一个最小可用版本的完整闭环。功能模块用户场景数据字段优先级选择城市首次进入 App 定位或搜索城市城市名、城市 ID、经纬度P0添加多个城市关注多地天气一键切换城市列表本地持久化P0删除所选城市移除不关注城市保持列表整洁城市列表索引P1当日天气详情查看实时温度、风向、湿度、日期温度、天气码、湿度、风向P0未来一周趋势图了解未来几天气温变化规划出行每日最高/最低温、天气码P1生活指数查看穿衣、洗车、运动建议指数类型、级别、建议文案P1这里要注意P0 不是简单地把页面堆出来而是要先确定数据模型。一个城市的完整信息由基础字段城市名、城市 ID、更新时间和天气字段实时温度、天气码、湿度、风向、未来趋势数组组成。建议把城市信息和天气信息拆成两个模型CityModel 负责城市列表WeatherModel 负责天气数据这样网络请求返回后只需要更新天气模型不会跟城市列表的操作耦合在一起。2.3 平台选型iOS 与 Objective-C 的取舍文档里选择 Objective-C但 iOS 开发现在的主流语言早已转向 Swift。如果学校没有强制指定语言我更推荐用 Swift 来做交互和 UI 部分但网络层和模型层的设计思路仍然可以参考 Objective-C 的写法。原因在于很多老牌天气接口 SDK 和面试题里依然会问 Objective-C 的语法和内存管理如果你能看懂这篇综述里的代码片段再对照 Swift 写一遍理解会更扎实。选型时还要考虑 iOS 版本兼容。天气 App 需要定位用户当前位置这必然要接触 CoreLocation。下面这段代码是 iOS 端请求定位权限的常见写法#import CoreLocation/CoreLocation.h - (void)startCityLocation { CLLocationManager *locationManager [[CLLocationManager alloc] init]; locationManager.desiredAccuracy kCLLocationAccuracyKilometer; // 天气场景不需要高精度定位 if ([locationManager respondsToSelector:selector(requestWhenInUseAuthorization)]) { [locationManager requestWhenInUseAuthorization]; // iOS 8 之后必须显式请求 } [locationManager startUpdatingLocation]; }这段代码里有一个容易踩的坑desiredAccuracy设置为kCLLocationAccuracyKilometer而不是kCLLocationAccuracyBest是因为天气服务只需要城市级别的位置信息高精度会加大耗电和定位回调频率。另外requestWhenInUseAuthorization只在系统版本支持时才会去调用如果你的 App 最低支持版本低于 iOS 8需要先判断方法是否存在否则会直接崩溃。还要记得在 Info.plist 里添加NSLocationWhenInUseUsageDescription缺少这个描述文案时定位授权不会弹窗。这些细节在文献综述里不会写但真正上线或答辩演示时一定会遇到。3. Objective-C 与 MVC天气 App 的骨架设计3.1 MVC 分层在天气 App 中的实际意义文献综述提到系统采用 MVC 设计模式将视图层、模型层和控制层用不同组件实现降低系统内各部分之间的耦合性。这句话看起来像套话但放到天气 App 里非常具体。View 层只负责展示比如温度标签、天气图标、趋势曲线Model 层负责管理城市和天气数据Controller 层承担两者之间的调度。打个比方如果直接把网络请求写进 TableViewCell那么刷新数据时你要在 Cell 里改逻辑切换城市时又要处理重复请求代码很快会变成一坨。正确的分工是Cell 只接收一个 WeatherModel 对象调用configureWithModel:更新 UIViewController 负责创建模型、发起请求、在回调里刷新表格Model 只做数据解析和存取不引用 UIKit 里面的任何东西。这样才能保证你在替换数据源、增加新接口时不需要大范围修改视图层。Objective-C 在这套体系里还有一层特点它基于消息传递机制而不是像 C 那样直接调用方法。举个例子[cityModel updateTime]实际上是在向 cityModel 发送一条消息。这种风格在写代理方法时特别自然比如CLLocationManagerDelegate的回调就是典型的消息传递。初学 iOS 的人容易忽略这层区别但写网络层回调时消息传递和 block 捕获机制会直接影响内存管理。3.2 从文献综述到代码CityModel 的落地写法文献综述里虽然没有给出具体类定义但根据功能描述城市模型至少需要包含城市名、省份、城市 ID、更新时间四个字段。很多新手会把所有字段堆在一个类里我一般会先建一个干净的模型层方便后续 HTTP 解析和本地存档复用。// CityModel.h #import Foundation/Foundation.h interface CityModel : NSObject property (nonatomic, copy) NSString *cityName; property (nonatomic, copy) NSString *province; property (nonatomic, assign) NSInteger cityId; property (nonatomic, strong) NSDate *updateTime; - (instancetype)initWithDictionary:(NSDictionary *)dict; end // CityModel.m #import CityModel.h implementation CityModel - (instancetype)initWithDictionary:(NSDictionary *)dict { self [super init]; if (self) { _cityName dict[city] ?: ; _province dict[province] ?: ; _cityId [dict[id] integerValue]; // 常见做法是先把时间字段转成 NSDate避免在 View 层做字符串截取 if ([dict[updatetime] isKindOfClass:[NSString class]]) { NSDateFormatter *fmt [[NSDateFormatter alloc] init]; fmt.dateFormat yyyy-MM-dd HH:mm; _updateTime [fmt dateFromString:dict[updatetime]]; } } return self; } end这段代码的重点在initWithDictionary:的防御式写法。dict[city] ?: 的意思是如果字典里没有 city 字段就赋值为空字符串避免 UI 上出现(null)。isKindOfClass:判断是为了防止接口突然返回 NSNull 导致崩溃这类问题在真实天气接口里很常见。时间字段处理上不要在 View 层直接去截取字符串而是统一转成 NSDate这样后面做“更新时间排序”或“今天/明天显示”时可以直接用系统日历 API。3.3 控制器层的多城市管理套路多城市管理是天气 App 最核心的交互。文献综述里写了添加、删除、切换三个操作实现这三个操作时控制器需要负责事件转发和本地持久化。控制器方法对应操作涉及模型说明addCityWithName:添加城市CityModel创建模型后插入数组刷新表格removeCityAtIndex:删除城市CityModel更新数组和本地存档reloadWeatherAtCurrentCity:切换城市WeatherModel发起网络请求接到回调后刷新首屏控制器拿到用户输入的城市名后不应该自己直接去拼请求参数而是先构造 CityModel再交给网络层。这样可以保证“城市列表”和“天气详情”两个页面共享同一份数据。本地持久化我一般用NSUserDefaults存 JSON 字符串或者用NSKeyedArchiver归档模型列表。天气 App 的数据量很小不需要上 CoreData用归档反而简单清晰。4. GCD 与 HTTP天气数据请求的并发处理4.1 GCD 为什么适合天气 App 这种 IO 型应用文献综述里重点介绍了 GCD说它比线程更简单高效会根据系统负载自动增减线程数。这个结论放到持有天气类 App 上依然成立。天气 App 的典型场景是用户进入首页后同时请求当前城市天气和未来三天趋势图再往下拉还会请求生活指数。如果每个接口都单独开一个线程线程的创建销毁开销会非常明显。GCD 的核心概念是队列。主队列负责 UI 更新全局并发队列负责耗时操作。你不需要关心具体创建了多少线程系统会根据 CPU 核心数和当前负载来调度。这里要特别注意一个常识性问题NSURLSession 的 completionHandler 默认在后台线程执行所以拿到数据后必须手动切回主队列刷新标签否则会引发 UI 更新冲突严重时直接闪退。4.2 用 dispatch_group 批量刷新多城市天气多城市管理意味着用户可能添加了五六个城市。如果每次只刷新当前城市用户可以接受但如果用户进入 App 后想一次性看到所有城市的天气摘要就需要并发刷新。使用dispatch_group是常见做法它能等所有网络请求全部结束后再统一更新界面。- (void)refreshAllCitiesWithArray:(NSArrayCityModel * *)cityList { dispatch_group_t group dispatch_group_create(); for (CityModel *city in cityList) { dispatch_group_enter(group); // 进入组计数加一 [self fetchWeatherForCity:city completion:^(WeatherModel *model, NSError *error) { if (model) { city.weather model; // 把天气结果挂到城市模型上 } dispatch_group_leave(group); // 离开组计数减一 }]; } dispatch_group_notify(group, dispatch_get_global_queue(QOS_CLASS_USER_INITIATED, 0), ^{ // 所有请求结束后回到主线程刷新 dispatch_async(dispatch_get_main_queue(), ^{ [self.tableView reloadData]; }); }); }这段代码的逻辑是在发起每个请求前调用dispatch_group_enter让组计数器加一请求回调无论成功失败都调用dispatch_group_leave计数器减一。dispatch_group_notify会在所有计数归零后执行所以它会等待所有城市的天气请求完成再刷新表格。这里有一个容易漏掉的细节如果某个请求永久卡住计数器永远不会归零刷新不会执行。因此网络层必须设置 timeout或者用NSURLSessionConfiguration的timeoutIntervalForRequest来控制不给 GCD 组留下悬空计数。4.3 HTTP 请求参数与常见状态码排查天气数据来自服务端接口文献综述说了 HTTP 请求是从客户端到服务器端的请求消息包含请求方法、资源标识符和协议版本。但实际调试时你更需要关心状态码和字段容错。下面这份排查表是我自己总结的适用于大多数天气类接口状态码含义常见原因处理建议200请求成功正常返回解析 JSON刷新数据304未修改命中缓存使用本地缓存配合 ETag 判断400请求参数错误cityid 格式不对检查参数拼写和类型401未授权appkey 无效重新配置请求头500服务端异常数据服务不稳定展示上次缓存提示稍后重试响应参数层面天气接口通常包含cityid、date、temp、humidity、wind等字段。你可以在请求 URL 里显式传入cityid来避免每次都走定位流程。定位失败时兜底方案是使用用户上次选择的城市缓存。很多天气接口的免费版本有时会返回空数据所以模型层的字段最好都做成可空的前端 UI 再根据是否有值来决定显示真实数据还是占位符。习惯性把接口返回的所有字段都用强转类型接住后续接口升级时你的 App 才不会因为一个字段类型变化就崩溃。5. 从综述到实现天气 App 的优化与验证方法5.1 用本地 JSON 先跑通 UI 与数据流写天气 App 最容易卡住的环节是接口不稳定。你还没有写完 UI后端接口先挂掉了整个调试过程会非常痛苦。我的习惯是开发阶段先用本地 JSON 文件模拟接口数据把 UI 和模型层全部跑通再切换到真实接口。你可以在 Xcode 工程里放一个weather_sample.json然后写一个以文件名为参数的MockWeatherService让网络层和 Mock 层实现同一个协议。id json [NSJSONSerialization JSONObjectWithData:data options:0 error:nil]; WeatherModel *model [[WeatherModel alloc] initWithDictionary:json];这样切换接口时只需要改一行注入代码不用动 View 和 Controller。本地 JSON 跑通后再去验证弱网和接口异常排查难度会小很多。5.2 从文献综述提炼一份验收清单文献综述列出的功能点其实可以直接转换成答辩演示时的测试用例。表格里每一行都是一个验证维度这也是评审老师最关注的方面。测试项操作步骤预期结果多城市添加点击加号输入北京和上海城市列表出现两个条目天气能切换城市删除进入编辑状态删除上海主界面回到北京天气网络异常打开飞行模式点击刷新App 不崩溃显示上次缓存和提示文案趋势图展示进入趋势页能看出一周温度走向无绘制错乱生活指数展示下拉刷新生活指数指数与天气条件匹配文案不出现空值如果你用的是 iOS 14 以上系统开发时可以直接在 Xcode 模拟器里测试多城市切换没必要一开始就上真机。唯一要注意的是模拟器默认没有定位数据需要手动设置模拟器位置。等所有功能在模拟器上验证通过后再拿到真机上用开发者模式运行重点看定位和网络权限是否正常弹出。5.3 答辩前必须做的一次数据层审查无论功能做得多完整答辩时被问最多的还是数据层。比如“城市列表存在哪里”“天气接口返回的日期格式怎么处理”“多城市并发请求的线程安全如何保证”。建议你在答辩前把 CityModel 和 WeatherModel 的字段挨个检查一遍凡是 UI 上展示的数据都必须有默认值凡是网络字段都必须做类型判断。最好再补两个单元测试一个验证 JSON 解析能处理缺失字段一个验证城市模型能正确写进本地文件。这两个小测试写完你对整套代码的掌控感会完全不同回答问题时也不会心虚。本文还有配套的精品资源点击获取
