普通视图

发现新文章,点击刷新页面。
昨天以前首页

SwiftUI 如何使用 UIKit 组件

2026年3月31日 10:06

先理解问题是什么

现实情况是:SwiftUI 原生组件不够用。很多组件SwiftUI 自己没有直接提供,但 UIKit 里有。

那怎么办?苹果提供了一个"桥接协议":UIViewRepresentable


UIViewRepresentable 是什么

它是一个协议(Protocol) ,作用是:

把一个 UIKit 的 UIView包装成 SwiftUI 能认识的 View

你可以把它理解成一个翻译官,SwiftUI 和 UIKit 说的不是同一种语言,UIViewRepresentable 负责在中间翻译。

SwiftUI 世界          翻译官                    UIKit 世界
─────────────    ──────────────────────    ──────────────────
  some View  ←→  UIViewRepresentable  ←→   UIView(任意)

它要求你实现两个方法

protocol UIViewRepresentable {
    // 方法一:创建 UIKit 视图(只调用一次)
    func makeUIView(context: Context) -> 某种UIView
    
    // 方法二:更新 UIKit 视图(状态变化时调用)
    func updateUIView(_ uiView: 某种UIView, context: Context)
}

就这两个,不多(有没有想到什么,OC的NSProxy 是不是也是实现两个方法,虽然八杆子打不着,但是突然想到了)。

  • makeUIView → 负责初始化,相当于 viewDidLoad,只跑一次
  • updateUIView → 负责同步状态,SwiftUI 的数据变了,你要在这里手动更新 UIKit 视图

我写了一个BlurView,早期SwiftUI background不支持毛玻璃效果

struct BlurView: UIViewRepresentable {
    let style: UIBlurEffect.Style   // ← 从 SwiftUI 传进来的参数
    
    // 第一步:创建真实的 UIKit 视图
    func makeUIView(context: Context) -> some UIView {
        let view = UIView(frame: .zero)
        view.backgroundColor = .clear
        
        // 这才是核心:UIKit 的毛玻璃视图
        let blurEffect = UIBlurEffect(style: style)
        let blurView = UIVisualEffectView(effect: blurEffect)
        
        // 用 AutoLayout 让它撑满父视图
        blurView.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(blurView)
        NSLayoutConstraint.activate([
            blurView.heightAnchor.constraint(equalTo: view.heightAnchor),
            blurView.widthAnchor.constraint(equalTo: view.widthAnchor)
        ])
        
        return view  // ← 把这个 UIKit 视图交给 SwiftUI 管理
    }
    
    // 第二步:状态更新时同步(这里暂时不需要做任何事)
    func updateUIView(_ uiView: UIViewType, context: Context) {
        // 如果 style 会动态变化,就在这里更新
    }
}

重点理解makeUIView 返回的那个 UIView,之后就由 SwiftUI 的布局系统接管了。你不需要手动设置 frame,SwiftUI 会帮你处理尺寸。


然后 View Extension 做了什么

extension View {
    func blurBackground(style: UIBlurEffect.Style) -> some View {
        ZStack {
            BlurView(style: style)  // ← UIKit 毛玻璃,铺在底层
            self                    // ← 原来的 SwiftUI 视图,叠在上层
        }
        //两个方法都行
        //self.background(BlurView(style: style))
    }
}

BlurView 在这里和任何 SwiftUI 原生 View 完全没有区别,可以直接放进 ZStack。这就是 UIViewRepresentable 的意义:让 UIKit 视图假装自己是 SwiftUI 视图


整体调用链是这样的

.blurBackground(style: .systemMaterial)
        ↓
    ZStack 叠加
   ┌────────────┐
   │  BlurView  │ ← UIViewRepresentable 在这里翻译
   │   (UIKit)  │   makeUIView() 被 SwiftUI 自动调用
   └────────────┘
        ↑
   self(原 SwiftUI 视图)叠在上面

什么时候用 UIViewRepresentable(有些SwfitUI 现在自己已经有了)

场景 推荐方案
毛玻璃、特效 UIVisualEffectViewUIViewRepresentable
地图 MKMapView → 或直接用 SwiftUI 的 Map
网页 WKWebViewUIViewRepresentable
富文本编辑 UITextViewUIViewRepresentable
相机预览 AVCaptureVideoPreviewLayerUIViewRepresentable
SwiftUI 能搞定的 直接用 SwiftUI,别绕弯子

还有一个兄弟协议:UIViewControllerRepresentable

如果你要包装的不是 UIView,而是整个 UIViewController(比如系统的图片选择器、分享弹窗),用这个:

struct ImagePickerView: UIViewControllerRepresentable {
    func makeUIViewController(context: Context) -> UIImagePickerController {
        return UIImagePickerController()
    }
    
    func updateUIViewController(_ uiViewController: UIImagePickerController, context: Context) {
        // 同上,同步状态用
    }
}

逻辑完全一样,只是把 UIView 换成了 UIViewController


总结

UIViewRepresentable 本质上就是:

实现两个方法(创建更新),让 SwiftUI 知道怎么驾驭一个 UIKit 视图

它解决的核心问题是:SwiftUI 和 UIKit 生命周期不同,这个协议负责在两套系统之间搭桥

BlurView 是一个非常标准的使用案例——SwiftUI 没有,UIKit 有,包一下,用上。

ViewModifier 和 圆角以及渐变色

2026年3月30日 11:31

ViewModifier

是什么

把一组样式或 UI 结构打包成可复用的东西,用 .modifier() 链式调用贴到任意 View 上。

类比 UIKit

UIKit 里你会封装一个函数来复用样式:

func styleToolButton(_ button: UIButton) {
    button.titleLabel?.font = .systemFont(ofSize: 25)
    button.setTitleColor(.white, for: .normal)
    button.frame.size = CGSize(width: 30, height: 30)
}

ViewModifier 干的是同一件事,但它不只能改属性,还能在原有 View 外面包一层新的 View 结构,这是普通函数做不到的:

struct BadgeModifier: ViewModifier {
    func body(content: Content) -> some View {
        ZStack(alignment: .topTrailing) {
            content  // 原来的 View 原封不动
            Text("99")
                .background(Color.red)
                .clipShape(Circle())
                .offset(x: 10, y: -10)
        }
    }
}

Image(systemName: "bell").modifier(BadgeModifier())
Image(systemName: "message").modifier(BadgeModifier())

本质

本质就是一个语法糖,功能上等价于自定义一个 View 然后把其他 View 塞进去,但它能融入 SwiftUI 的链式调用语法,用起来跟 .font() .foregroundColor() 一模一样。


圆角 + 渐变色 + 描边

是什么

SwiftUI 没有 UIKit 那样直接设置 layer.borderWidth 的属性,填充和描边需要两个图层叠加来实现。

类比 UIKit

UIKit 两行搞定:

view.layer.borderWidth = 4
view.layer.borderColor = UIColor.green.cgColor

SwiftUI 必须用 ZStack 叠两个 RoundedRectangle:

.background(
    ZStack {
        RoundedRectangle(cornerRadius: 20)
            .stroke(model.color, style: StrokeStyle(lineWidth: 4))
        RoundedRectangle(cornerRadius: 20)
            .fill(gradientStyle)
    }
)

为什么先 stroke 再 fill

stroke(描边)默认居中描边,线宽一半在内一半在外。fill 只填充内部区域,所以 fill 会覆盖 stroke 内侧的那一半。先画 stroke 再盖 fill,能让 stroke 外侧的一半露出来,边框视觉上更完整。反过来的话内侧边框线被盖住,边框显得细一半。

本质

这块 UIKit 确实更直观,SwiftUI 的声明式思路在这个场景下反而绕了一圈


本质

SwiftUI 没有 layer,只有 Shape + 绘制规则


fill 和 stroke 的区别

操作 本质
fill 填充 Shape 内部
stroke 沿路径画边

stroke 的问题

.stroke(lineWidth: 4)

👉 描边在路径两侧(内 + 外)


推荐方案(更精准)

.strokeBorder(lineWidth: 4)

👉 描边完全在内部


推荐结构

.fill(...)
.overlay(stroke)

👉 语义清晰:先填充,再叠加边框

ViewModifier

本质是 (View) -> View,不是修改 View,而是生成新 View


Modifier 顺序

顺序不是语法问题,而是 View 树结构

描边本质

边框不是属性,而是绘制结果(Shape + stroke)


ObservableObject @Published @ObservedObject那些事

2026年3月26日 16:27

先理解这三个为什么要一起讲

它们是一套组合拳,缺一不可:

角色 是什么
ObservableObject 一个协议,贴在 class 上,宣告"我是可被观察的数据源"
@Published 一个 Property Wrapper,贴在属性上,宣告"这个属性变化时要通知订阅者"
@ObservedObject 一个 Property Wrapper,贴在 View 的属性上,宣告"我订阅这个数据源,它变化我就刷新"

为什么需要这套东西?@State 不够用吗?

@State 适合简单的值类型,但现实中你的数据模型往往是一个 class,有很多属性和方法,且需要被多个平级 View 共享

// 一个用户信息模型,多个页面都要用
class UserModel {
   var name: String = "Tom"
   var age: Int = 18
   var score: Int = 0
   // ... 还有很多方法
}

把这个 class 塞进 @State 是行不通的——@State 是为值类型设计的,对 class 的引用地址变化不敏感,属性改了 UI 也不会刷新。


三件套的用法

// 第一步:让你的 class 遵守 ObservableObject 协议
class UserModel: ObservableObject {
   // 第二步:在需要触发 UI 刷新的属性上加 @Published
   @Published var name: String = "Tom"
   @Published var score: Int = 0
   var internalCache: String = ""  // 不加 @Published,改它不会刷新 UI
}

// 第三步:在 View 里用 @ObservedObject 订阅这个模型
struct ProfileView: View {
   @ObservedObject var user: UserModel

   var body: some View {
       VStack {
           Text(user.name)
           Text("\(user.score)")
           Button("加分") {
               user.score += 1   // 改 @Published 属性 → 触发 UI 刷新
           }
       }
   }
}

// 使用:顶层 View 用 @StateObject 持有并创建模型
struct ContentView: View {
   @StateObject var user = UserModel()

   var body: some View {
       ProfileView(user: user)
   }
}

三件套的本质

@Published 本质上是:

@propertyWrapper
public struct Published<Value> {
   // 每次 wrappedValue 被 set,就通过 objectWillChange 发出通知
   public var wrappedValue: Value
   // $score 拿到的是一个 Combine Publisher,可以接链式操作
   public var projectedValue: Publisher
}

ObservableObject 协议本质上是:

public protocol ObservableObject: AnyObject {
   // 编译器会自动合成这个,你的 @Published 属性改变时,它会发出信号
   var objectWillChange: ObservableObjectPublisher { get }
}

@ObservedObject 本质上是:View 订阅了 user.objectWillChange,只要它 emit,SwiftUI 就重新计算这个 View 的 body。

整个流程: user.score += 1@Published 的 setter 触发 → user.objectWillChange.send() → 订阅了它的 @ObservedObject 感知到 → SwiftUI 重新渲染对应的 View


@ObservedObject vs @StateObject

这是一个非常容易踩的坑:

@ObservedObject @StateObject
数据归属 不拥有,由外部传入 拥有,由这个 View 创建和持有
生命周期 跟随外部,不负责销毁 跟随 View,View 消失时销毁
典型场景 子 View 接收父 View 传来的模型 根 View 或顶层 View 创建模型

经验法则:谁创建,谁用 @StateObject;谁接收,谁用 @ObservedObject


使用时需要关心的问题

  1. 只有 class 能用ObservableObjectAnyObject 的子协议,struct 和 enum 无法遵守,这套机制天生是为引用类型设计的。

  2. @Published 要精准:不是所有属性都需要 @Published,只给真正需要驱动 UI 的属性加,滥加会导致不必要的 View 重渲染,影响性能。

  3. objectWillChange 是"将要改变":SwiftUI 在属性改变之前就会收到通知,你通常不需要手动调用它,但在某些手动控制的场景可以用 objectWillChange.send() 主动触发刷新。

@Binding 的那些事

2026年3月26日 16:25

先理解 @Binding 解决什么问题

@State 的时候,状态归属于某一个 View。但子 View 怎么修改父 View 的状态?

struct ParentView: View {
    @State var isOn: Bool = false

    var body: some View {
        ToggleView(isOn: isOn) // ❌ 子 View 拿到的只是一个值的拷贝
    }
}

你把 isOn 传给子 View,子 View 改了它自己的拷贝,父 View 毫不知情,UI 也不会更新。


@Binding 就是用来解决这个问题的

@Binding 不是一份数据的拷贝,而是一条双向通道,指向原始数据的存储位置。 读它,读的是原始值;写它,写的是原始存储,父 View 会同步感知并刷新。

// 父 View:状态归属于这里
struct ParentView: View {
    @State var isOn: Bool = false

    var body: some View {
        // 用 $ 前缀把 @State 转成 Binding 传下去
        ToggleView(isOn: $isOn)
    }
}

// 子 View:不拥有状态,只拿到一条"通道"
struct ToggleView: View {
    @Binding var isOn: Bool  // 声明为 Binding,表示"我不拥有这个数据"

    var body: some View {
        Button("切换") {
            isOn.toggle()   // 写的是父 View 里的原始 @State,触发父 View 刷新
        }
    }
}

@Binding 的本质

@propertyWrapper
public struct Binding<Value> {
    // 你平时用 isOn 读写的就是这个
    public var wrappedValue: Value { get nonmutating set }

    // 你用 $isOn 拿到的还是 Binding 自身,可以继续往下传
    public var projectedValue: Binding<Value> { get }
}

@Binding 内部存的不是值本身,而是一对 getter + setter 闭包,分别指向上层 @State(或其他数据源)的读写操作。所以写 isOn = true 时,实际上是调用了那个 setter 闭包,最终改变的是父 View 的 @State


使用 @Binding 时需要关心的问题

  1. 数据归属权问题@Binding 的原则是"我不拥有数据,我只是一个读写通道"。如果一个 View 需要拥有状态,用 @State;如果只是借用和修改上层的状态,用 @Binding

  2. 单向来源原则(Single Source of Truth):一条 @Binding 链条最终必须溯源到某个真实的数据存储(比如 @State@StateObject 中的属性),不要出现 Binding 套 Binding 套 Binding 的迷宫,链条越短越清晰。

  3. $ 符号的含义$isOn 拿到的是 projectedValue,对 @State 来说它是一个 Binding<Bool>,这就是为什么父 View 传 $isOn,而子 View 声明 @Binding var isOn,类型是对得上的。

  4. 不要在 body 外部调用:和 @State 一样,对 @Binding 属性的读写应发生在 bodybody 调用的方法中,以确保 SwiftUI 能正确追踪依赖。

@state的一些琐事

2026年3月25日 20:49

先理解 Property Wrapper 是什么

@propertyWrapper 就是让你可以自定义 @ 修饰符的机制。 @State@Binding 这些不是Swift内置的魔法,它们本质上就是普通的 struct,只不过被 @propertyWrapper 修饰了,所以才能用 @ 语法来用。 能理解吗?是不是还是很难理解,没事我写一个例子你就能理解了

假设你有一个属性,每次读取它都想打印一条日志:
var age: Int = 18
var age: Int = 18 { 
    didSet { print("age 变了,新值是 \(age)") }
}
但如果你有 100 个属性都需要这个功能呢?你要写 100 次 `didSet`?

Property Wrapper 就是用来解决这个问题的

你可以把"通用的包装逻辑"封装起来,然后像帖标签一样贴到任何属性上。

// 第一步:定义一个 Property Wrapper
@propertyWrapper
struct Logged {
    private var value: Int
    // initialValue 参数后面可以跟很多参数,自定义
    init(initialValue: Int) {
        self.value = initialValue
    }
    
    var wrappedValue: Int {
    //这里的get 和set 我们可以自定义任何我们想要的操作,比如有多个参数我们可以把这些参数拼接起来返回等等
        get { value }
        set {
            print("值变了,新值是 \(newValue)")  // 通用逻辑写在这里
            value = newValue
        }
    }
}

// 第二步:像贴标签一样使用它
@Logged var age = 18
@Logged var score = 100

// 现在 age 和 score 改变时,都会自动打印日志
age = 20   // 打印:值变了,新值是 20
score = 99 // 打印:值变了,新值是 99

所以 @propertyWrapper 本质上就是

把"对属性的操作逻辑"打包成一个 struct,然后用 @ 语法贴到属性上,让这个属性自动拥有那些逻辑。

回到 @State

@State 干的事情无非就是:

@propertyWrapper
public struct State<Value> {  
    // 1. 让你能直接赋初始值
    public init(initialValue value: Value)   
    // 2. 你平时用 brain 读写的就是这个 (这里set 之后苹果偷偷的去给你刷新了UI)
    public var wrappedValue: Value { get nonmutating set }    
    // 3. 你用 $brain 拿到的就是这个(一个 Binding)
    public var projectedValue: Binding<Value> { get }
}

@State 非常适合 struct 或者 enum 这样的值类型,它可以自动为我们完成从状态 到 UI 更新等一系列操作。但是它本身也有一些限制,我们在使用 @State 之前,对 于需要传递的状态,最好关心和审视下面这两个问题:

  1. 这个状态是属于单个 View 及其子层级,还是需要在平行的部件之间传递和使 用?@State 可以依靠 SwiftUI 框架完成 View 的自动订阅和刷新,但这是有 条件的:对于 @State 修饰的属性的访问,只能发生在 body 或者 body 所调 用的方法中。你不能在外部改变 @State 的值,它的所有相关操作和状态改变 都应该是和当前 View 挂钩的。如果你需要在多个 View 中共享数据,@State 可能不是很好的选择;如果还需要在 View 外部操作数据,那么 @State 甚至 就不是可选项了。
  2. 状态对应的数据结构是否足够简单?对于像是单个的 Bool 或者 String, @State 可以迅速对应。含有少数几个成员变量的值类型,也许使用 @State 也还不错。但是对于更复杂的情况,例如含有很多属性和方法的类型,可能其 中只有很少几个属性需要触发 UI 更新,也可能各个属性之间彼此有关联,那 么我们应该选择引用类型和更灵活的可自定义方式。
❌
❌