SwiftUI:@State原理解析

@State是SwiftUI的众多支柱之一,一旦理解了它,我们就会理所当然地认为它无处不在,毫不犹豫地使用。但是@State是什么呢?幕后发生了什么?
在本文中,让我们尝试通过重建@State等来回答这些问题。

因为我无法访问实际的swift代码/实现,我们将分析模仿原始@State行为

Property wrapper属性包装

首先,@State是一个属性包装器,简而言之,它是一个具有额外逻辑和存储的高级getter和setter。
让我们先定义我们的状态如下:

@propertyWrapper
struct FSState {

}

属性包装器需要一个wrappedValue,让我们可以读/写相关的值。
因为我们想要模拟@State,所以我们将属性包装器泛型到类型V上,并将原始值存储在内部value属性中:

@propertyWrapper
struct FSState<V> {
  // This is where our value is actually stored.
  var value: V
  
  // And here are our getter/setters.
  var wrappedValue: V {
    get {
      value
    }
    set {
      value = newValue
    }
  }
}

最后,如果我们想提供与@State和所有其他属性包装器相同的语法(例如,@State var x = "hello"@State var x = "hello"),我们需要声明一个特殊的初始化方法:

@propertyWrapper
struct FSState<V> {
  var value: V
  
  var wrappedValue: V {
    ...
  }

  init(wrappedValue value: V) {
    self.value = value
  }
}

有了这个定义,我们现在可以开始在视图中使用@FSState,例如:

struct ContentView: View {
  @FSState var text = "Hello Five Stars"

  var body: some View {
    Text(text)
  }
}
image1.png

nonmutating

到目前为止,我们的定义与在视图本身中直接定义属性没有太大区别。
如果我们从ContentView声明中删除@FSState,一切仍然运行良好:

struct ContentView: View {
  var text = "Hello Five Stars"

  var body: some View {
    Text(text)
  }
}
image1.png

让我们现在尝试用一个按钮来改变text文本,例如:

struct ContentView: View {
  @FSState var text = "Hello Five Stars"

  var body: some View {
    VStack {
      Text(text)

      Button("Change text") {
        text = ["hello", "five", "stars"].randomElement()!
      }
    }
  }
}

不幸的是,这不会build成功:我们会得到一个按钮操作错误提示Cannot assign to property: 'self' is immutable。问题是,分配的文本会改变ContentView

使用结构体,我们可以声明mutating的方法,但不能声明mutating的计算属性(如body),也不能在其中调用mutating的方法。
为了克服这个问题,我们不能改变ContentView,这意味着我们也不能改变FSState,因为我们的属性包装器只是嵌套在视图中的另一个值类型。

首先,让我们声明我们的属性包装器设置为nonmutating,它告诉Swift设置这个值不会改变我们的FSState实例:

@propertyWrapper
struct FSState<V> {
  var value: V
  
  var wrappedValue: V {
    get { ... }
    nonmutating set { // our setter is now nonmutating
      value = newValue
    }
  }

  ...
}

现在我们已经将构建错误Cannot assign to property: 'self' is immutabletext转移到FSStatewrappedValue的setter方法中了。
这是有意义的,因为我们承诺不改变struct实例,但我们设置value = newValue,这是可变的。

这就是Swift引用类型的由来:如果我们用class类型替换FSStatevalue属性,然后在我们的setter方法中更新这个类实例,我们实际上并没有更改FSState(因为FSState只包含对该类的引用,它总是保持不变)。
让我们把"container"定义成class类型:

final class Box<V> {
  var value: V

  init(_ value: V) {
    self.value = value
  }
}

Box是一个泛型类,只有一个函数:拥有和更新我们的值。
让我们利用这个类给@FSState声明一个属性:

@propertyWrapper
struct FSState<V> {
  var box: Box<V>

  var wrappedValue: V {
    get {
      box.value
    }
    nonmutating set {
      box.value = newValue
    }
  }

  init(wrappedValue value: V) {
    self.box = Box(value)
  }
}

更新后buildandrun我们的应用!

image2.gif

我们点击按钮,但没有看到任何变化,如果我们设置断点,我们将看到一切工作:点击按钮可以设置和更新我们的状态,但是SwiftUI并不知道。
没错,我们更新数据,但SwiftUI并不知道它应该监听这些变化,并重新绘制body,让我们接下来解决这个问题。

DynamicProperty

与SwiftUI中已知的基础视图类似,SwiftUI中每个视图都可以根据视图中定义的属性监听这些publisher。
SwiftUI团队在隐藏SwiftUI大量使用Combine方面做了很多的工作:当我们将一个视图属性与@State@ObservedObject等关联起来时,SwiftUI会监听连接到每个属性包装器的所有发布者,然后这些发布者会告诉SwiftUI什么时候重新绘制。

在我们的例子中,我们使用@StateObject来匹配BoxObservableObject。组合关联一个objectWillChangepublisher到所有ObservableObject实例,然后我们可以通过调用send()将事件发送到SwiftUI:

final class Box<V>: ObservableObject {
  var value: V {
    willSet {
      // This is where we send out our "hey, something has changed!" event
      objectWillChange.send()
    }
  }

  init(_ value: V) {
    self.value = value
  }
}

有更简单的方法来声明它,但在本文中,我们试图通过尽可能多地删除“魔法”来了解事情是如何工作的。有更简单的方法来声明它,但在本文中,我们试图通过尽可能多地删除“魔法”来了解事情是如何工作的。

随着Box定义的更新,我们现在可以回到@FSState,并将@StateObject关联到Box属性:

@propertyWrapper
struct FSState<V> {
  @StateObject var box: Box<V>

  var wrappedValue: V {
    ...
  }

  init(wrappedValue value: V) {
    self._box = StateObject(wrappedValue: Box(value))
  }
}

由于每次更新box的值变化:

  • objectWillChange事件被触发
  • box的publisher将会监听到

让我们再次运行我们的应用程序:

image2.gif

不幸的是,我们还没到那一步。当我们的值发生变化时,新的发布者确实会发送事件,但是我们仍然需要告诉SwiftUI:从SwiftUI的角度来看,ContentView有一个类型为FSState<String>text属性,这不是SwiftUI需要关注的。

要改变这一点,我们需要FSState遵守DynamicProperty协议,在文档中描述为An interface for a stored variable that updates an external property of a view.
这正是SwiftUI关注的!通过使FSState遵守DynamicProperty协议, SwiftUI将监听它的事件并在需要时触发重绘。
DynamicProperty只需要一个update()函数的实现,然而SwiftUI已经提供了它的默认实现,我们需要做的就是添加DynamicProperty的一致性,然后就可以了:

@propertyWrapper
struct FSState<V>: DynamicProperty {
  ...
}

通过最后的修改,让我们尝试再次运行我们的应用程序:

image3.gif

终于可以了!尽管添加了与DynamicProperty一致的属性,我们仍然没有明确声明SwiftUI应该监听哪些属性:与view Equatable的工作方式类似,我怀疑SwiftUI使用Swift的反射来迭代所有存储的属性,并寻找要订阅的已知属性包装类型。

Binding

属性包装器的一个可选特性是公开一个投影值:投影值是存储在属性包装器中的值的另一种查看方式,以不同的方式公开。
许多SwiftUI视图使用绑定来引用和潜在地改变其他地方拥有和存储的值。一个例子是TextField,它使用了一个Binding<String>:

struct ContentView: View {
  @FSState var text = ""

  var body: some View {
    VStack {
      TextField("Write something", text: $text) // TextField's text is a binding
    }
  }
}

如上所述,我们可以通过在属性名前加上$来调用关联属性,从而从@State获得绑定,这个符号真正做的是获取投影值而不是包装的值。
因此@State的投影值是@Binding的一个V类型的泛型值,让我们在@FSState中添加相同的投影值:

@propertyWrapper
struct FSState<V>: DynamicProperty {
  @ObservedObject private var box: Box<V>

  var wrappedValue: V {
    ...
  }

  var projectedValue: Binding<V> {
    Binding(
      get: {
        wrappedValue
      },
      set: {
        wrappedValue = $0
      }
    )
  }

  ...
}

瞧,我们现在可以使用@FSState和绑定了!

image4.gif

下面是最终的@FSState定义:

@propertyWrapper
struct FSState<V>: DynamicProperty {
  @StateObject private var box: Box<V>

  var wrappedValue: V {
    get {
      box.value
    }
    nonmutating set {
      box.value = newValue
    }
  }

  var projectedValue: Binding<V> {
    Binding(
      get: {
        wrappedValue
      },
      set: {
        wrappedValue = $0
      }
    )
  }

  init(wrappedValue value: V) {
    self._box = StateObject(wrappedValue: Box(value))
  }
}
final class Box<T>: ObservableObject {
  var value: T {
    willSet {
      objectWillChange.send()
    }
  }

  init(_ value: T) {
    self.value = value
  }
}

总结

我们对SwiftUI研究得越多,它就越能说明在一个简单、优雅的API中隐藏着多少复杂性。@FSState不像真正的@State那样完整和强大!也许我们还有很多没考虑到的地方。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,012评论 4 359
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,589评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 106,819评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,652评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,954评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,381评论 1 210
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,687评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,404评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,082评论 1 238
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,355评论 2 241
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,880评论 1 255
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,249评论 2 250
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,864评论 3 232
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,007评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,760评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,394评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,281评论 2 259

推荐阅读更多精彩内容