iOS天气应用：页面状态初始化应选AppDelegate还是UIPageViewController？

嘿，作为iOS开发者，我刚好处理过类似的天气应用场景，来给你分享下我的思路：

一、UIPageViewController初始页面的初始化位置 #

我的建议是把初始页面的恢复逻辑放在UIPageViewController自身内部，而不是AppDelegate，原因如下：

• 职责分离更清晰：AppDelegate主要负责应用级别的生命周期事件（比如启动、后台切换），页面级别的状态恢复属于控制器自己的职责，放在一起会导致代码耦合度高，后期不好维护。
• 控制器自身管理状态更灵活：UIPageViewController可以在viewDidLoad（首次启动）或者viewWillAppear（从后台返回时也能触发）中读取保存的页码，直接恢复页面。

举个Swift代码示例：

class WeatherPageViewController: UIPageViewController {
    // 假设你的数据源数组是这个
    private var cityViewControllers: [UIViewController] = []
    
    override func viewDidLoad() {
        super.viewDidLoad()
        setupDataSource()
        restoreCurrentPage()
    }
    
    private func restoreCurrentPage() {
        // 从UserDefaults读取之前保存的页码
        let savedIndex = UserDefaults.standard.integer(forKey: "CurrentWeatherPageIndex")
        // 确保索引在合法范围内，避免越界
        guard savedIndex >= 0 && savedIndex < cityViewControllers.count else {
            // 如果索引无效，默认显示第一个页面
            setViewControllers([cityViewControllers[0]], direction: .forward, animated: false, completion: nil)
            return
        }
        // 恢复到保存的页面
        setViewControllers([cityViewControllers[savedIndex]], direction: .forward, animated: false, completion: nil)
    }
    
    // 别忘了在页面切换完成时保存当前页码
    func pageViewController(_ pageViewController: UIPageViewController, didFinishAnimating finished: Bool, previousViewControllers: [UIViewController], transitionCompleted completed: Bool) {
        guard completed, let currentVC = pageViewController.viewControllers?.first else { return }
        if let currentIndex = cityViewControllers.firstIndex(of: currentVC) {
            UserDefaults.standard.set(currentIndex, forKey: "CurrentWeatherPageIndex")
        }
    }
}

如果你的应用支持后台返回后也需要保持页面状态，把restoreCurrentPage()移到viewWillAppear里会更稳妥，因为viewDidLoad只会执行一次。

二、本地城市经纬度列表与网络数据刷新的建议 #

针对本地存储+网络刷新的场景，我整理了几个关键要点：

1. 本地存储的选择 #

• 如果城市数量不多（比如10个以内），用UserDefaults配合Codable序列化就足够简单方便；
• 如果城市数量较多或者需要更复杂的查询（比如按城市名筛选），建议用Core Data或者Realm来做结构化存储，性能和扩展性更好；
• 无论用哪种方式，都要把经纬度和对应的城市名一起保存，避免后续展示时还要额外请求地理编码。

示例：用Codable序列化城市模型

struct CityLocation: Codable {
    let name: String
    let latitude: Double
    let longitude: Double
}

// 保存到UserDefaults
func saveCityLocations(_ locations: [CityLocation]) {
    do {
        let data = try JSONEncoder().encode(locations)
        UserDefaults.standard.set(data, forKey: "SavedCityLocations")
    } catch {
        print("保存城市数据失败：\(error)")
    }
}

// 从UserDefaults读取
func loadSavedCityLocations() -> [CityLocation]? {
    guard let data = UserDefaults.standard.data(forKey: "SavedCityLocations") else { return nil }
    do {
        return try JSONDecoder().decode([CityLocation].self, from: data)
    } catch {
        print("读取城市数据失败：\(error)")
        return nil
    }
}

2. 网络数据刷新策略 #

• 先展示缓存，再异步刷新：应用启动时，先读取本地缓存的城市数据，快速生成对应的ViewController并展示（避免空界面），然后在后台发起网络请求获取最新天气数据，更新UI和本地缓存；
• 控制刷新频率：可以设置刷新间隔（比如每30分钟刷新一次），或者只在用户主动下拉刷新、进入应用时刷新，避免频繁请求给服务器和用户流量造成压力；
• 处理网络异常：如果网络请求失败，不要清空本地缓存，继续展示旧数据，并给用户弹出友好的提示（比如“网络不佳，展示本地缓存数据”）；
• 同步城市列表变化：如果用户修改了城市列表（比如新增/删除），要及时更新UIPageViewController的数据源数组，并调整当前页面（比如原来的索引超出新数组范围时，默认切换到第一个页面）。

3. 性能优化小技巧 #

• 网络请求时可以批量获取多个城市的天气数据，减少请求次数；
• 对天气数据做本地缓存（比如按城市纬度纬度作为key），避免同一城市短时间内重复请求；
• 如果UIPageViewController的页面数量较多，考虑用懒加载的方式创建ViewController，避免启动时一次性创建所有页面导致内存过高。

内容的提问来源于stack exchange，提问作者user5759526