SwiftUI 系列 07｜从 UIKit 转到 SwiftUI，需要先改变哪些思维方式？

很多 UIKit 开发者第一次转 SwiftUI，最痛苦的地方并不是不会写语法，而是总觉得：

• 明明 API 也不复杂
• 但为什么写起来总不顺

原因往往不是技术点没学会，而是底层思维模式还没切过来。

因为 UIKit 默认是在问：

• 我现在要创建哪个 view
• 我什么时候更新它
• 我怎么手动保持它和数据一致

而 SwiftUI 更像是在问：

• 当前状态是什么
• 在这种状态下界面应该长什么样
• 当状态变化时，界面应该如何自然重组

这两个思路不是简单替换关系，而是控制权位置发生了变化。

一、第一件要放下的，是“界面更新主要靠我手动驱动”

UIKit 里很多经验都围绕这个展开：

• 哪个时机 reload
• 哪个时机 setNeedsLayout
• 哪个回调里改某个 subview

SwiftUI 当然也需要你管理状态，但它希望你做的是：

• 管理状态来源
• 管理状态边界
• 管理状态如何映射成 UI

而不是继续把心力主要放在“我该怎么手动刷新界面”。

如果这个习惯不改，后面最容易出现的情况就是：

• SwiftUI 写法看起来是声明式
• 但脑子里还是 UIKit 的命令式驱动

最后代码会变成两种思维混着写，既没吃到 SwiftUI 的优势，也丢了 UIKit 的明确控制感。

二、第二件要放下的，是把 View 当成稳定对象

这是 UIKit 背景开发者最容易默认带进来的习惯。

在 UIKit 里，你很自然会把一个页面或 cell 看成：

• 一个被创建出来的对象
• 后续不断被更新

但 SwiftUI 的 View 更像一种状态描述。
它不是“一个我长期抓着改的对象”，而更像“当前状态下界面的结构表达”。

这意味着你如果始终从“这个 View 会一直在，我只要继续改它”出发，后面会很容易在：

• 生命周期判断
• 状态存放位置
• 异步任务绑定

这些问题上频繁踩坑。

三、第三件要放下的，是过度依赖局部 patch 修 UI

UIKit 开发里很常见的路径是：

• 先把 view 摆出来
• 哪里不对就改哪里
• 某个控件偏一点就局部 patch 一下

这种方式在 SwiftUI 里也不是完全不能用，但如果你一直这样做，页面很容易变成：

• modifier 堆很多
• 结构层次不清
• 一处小修引发另一处布局变化

因为 SwiftUI 更鼓励你先把结构表达清楚，再让局部修饰附着其上。
如果结构本身就不稳，局部 patch 会把问题越修越碎。

四、第四件要改变的是：少从“控件”，多从“状态流”思考

UIKit 思维里，很多页面组织都是以控件为中心的：

• 这个 label 显示什么
• 这个按钮是否禁用
• 这个 tableView 什么时候 reload

SwiftUI 更鼓励你从状态流出发：

• 页面现在是什么状态
• 这个状态应该映射出哪些 UI 片段
• 某个动作后状态如何演进

这个变化很关键，因为它会直接影响：

• 你怎么设计 ViewModel
• 你怎么拆组件
• 你怎么判断哪些状态该共享，哪些不该共享

五、第五件要改变的是：别急着把所有 UIKit 经验都翻译成 SwiftUI 对应写法

很多人学 SwiftUI 时会下意识这样问：

• 这个相当于 UIKit 里的什么
• 这个生命周期对应哪个回调
• 这个行为是不是等于 reloadData

这类映射在入门时有帮助，但如果长期依赖，会形成一个问题：

• 你一直在找 UIKit 对应物
• 却没真正接受 SwiftUI 是另一套组织方式

真正用顺手的转折点，通常不是“我终于找到了所有对应关系”，而是：

我开始直接用 SwiftUI 的问题意识去思考页面，而不是先翻译回 UIKit 再做决定。

六、一个更实用的过渡方式：不要追求“立刻完全换脑”，先把几个高频问题问法改掉

我觉得最有帮助的不是逼自己一夜切换思维，而是先把下面这些问题问法改掉：

把：

• 我什么时候刷新这个 view

改成：

• 什么状态变化应该驱动这个区域更新

把：

• 这个控件该在哪个时机改

改成：

• 这个值应该归谁拥有

把：

• 这个页面出现一次还是多次

改成：

• 这段任务该和什么状态或生命周期绑定

这种问法变化看起来小，但它会慢慢把你的默认思维往 SwiftUI 那边拉。

七、结论：从 UIKit 转到 SwiftUI，最重要的不是记住新语法，而是把控制权思维重新摆位

如果只用一句话总结，我会说：

从 UIKit 转到 SwiftUI，真正需要改变的不是“代码写法”，而是从“我来手动驱动界面”转向“我来定义状态和边界，让界面跟着状态成立”。

一旦这件事开始发生，很多原本觉得“SwiftUI 怎么这么别扭”的地方，反而会慢慢变得自然。