Swift内存管理（ARC）

概述原文出自：Swift ARC总结 引言 Swift使用自动引用计数（ARC）机制来处理内存。通常情况下，Swift内存管理机制会自动管理内存，无须我们考虑内存的管理。ARC会在类的实例不再被使用（也就是没有引用）时，会自动释放其占用的内存。 可是，在少数情况下，ARC需要更多地了解我们代码之间的联系，才能正确管理内存。本篇文章就这少数情况而讨论和分析其应用场景及如何更好地解决循环引用的问题。 注意

原文出自：Swift ARC总结 @H_301_4@ 引言

Swift使用自动引用计数（ARC）机制来处理内存。通常情况下，Swift内存管理机制会自动管理内存，无须我们考虑内存的管理。ARC会在类的实例不再被使用（也就是没有引用）时，会自动释放其占用的内存。

可是，在少数情况下，ARC需要更多地了解我们代码之间的联系，才能正确管理内存。本篇文章就这少数情况而讨论和分析其应用场景及如何更好地解决循环引用的问题。

注意:ARC仅应用于类的实例。结构体和枚举类型是值类型，不是引用类型，也不是通过引用的方式存储和传递。

@H_301_4@ ARC的工作机制

创建类实例时，该实例就拥有了一块内存，存储相关信息，且会使该实例的引用计数+1，如下面的person实例当前的引用计数就为1，当前person对象只有一个引用。

class Person: NSObject {  deinit {    print("deinit")  }}var person: Person? = Person()

如果有多个引用，则该实例就不会被释放，看下面的@H_502_34@mary和@H_502_34@lili都引用了@H_502_34@person,使其所指向的内存引用计数+2：

var mary = personvar lili = person

现在我们将@H_502_34@mary,@H_502_34@lili设为@H_502_34@nil，则person所指向的内存块引用计数-2，但是并不为0，因此还不会释放。

mary = nillili = nil

现在我们再将@H_502_34@person设为@H_502_34@nil，会如何呢？自然会得到释放了，因此就打印@H_502_34@deinit出来了。

person = nil

为了确保使用中的实例不会被销毁，ARC会跟踪和计算每一个实例正在被多少属性，常量和变量所引用。哪怕实例的引用数为1，ARC都不会销毁这个实例。

无论将实例赋值给属性、常量或变量，它们都会创建此实例的强引用。之所以称之为“强”引用，是因为它会将实例牢牢的保持住，只要强引用还在，实例是不允许被销毁的。

场景一：类实例间的循环强引用

下面看一种这么一种情形：人可以有公寓，公寓可以属于某个人。

class Person: NSObject {   var name: String  // 不一定人人都有公寓，因此设置为可选类型更合适  var apartment: Apartment?  init(name: String) {    self.name = name  }  deinit {    print("deinit person: \(self.name)")  }}class Apartment: NSObject {   var unit: String  // 公寓也可能还没有拥有者，设置为可选类型  // 注意，弱引用只能声明为变量，不能声明为常量  weak var owner: Person?  init(unit: String) {    self.unit = unit  }  deinit {    print("deinit apartment: \(self.unit)")  }}var mary: Person? = Person(name: "Mary")var yaya: Apartment? = Apartment(unit: "yaya")// 下面是建立两者之间的关联关系mary?.apartment = yayayaya?.owner = mary

现在将这两个对象的指向都修改为nil:

// 现在释放，然后就会得到打印结果：// deinit person: Mary// deinit apartment: yayamary = nilyaya = nil

说明这两个对象都得到正确的释放了。这与我们预期的是一致的。

下面换一种写法：如果我们将@H_502_34@var apartment: Apartment?也声明为@H_502_34@weak呢？也就是改成@H_502_34@weak var apartment: Apartment?，现在我们只将@H_502_34@yaya改为@H_502_34@nil会如何呢？

yaya = nilprint(mary?.apartment?.unit)

当@H_502_34@apartment声明为@H_502_34@var apartment: Apartment?，其打印结果为@H_502_34@Optional("yaya") 当@H_502_34@apartment声明为@H_502_34@weak var apartment: Apartment?，其打印结果为@H_502_34@nil。

虽然这么做两者都得到释放，但是这跟我们预期的结果不一致。这是因为双方都是弱引用，当@H_502_34@yaya =nil时，其引用计数值为0，因此会被释放。这时候再去访问，就不存在了。如果其类型不是可选类型，释放后再访问，会导致@H_502_34@crash的。

如果两个类实例之间都是可选类型，使用@H_502_34@weak关键字来处理弱引用更好，但应该是一强一弱引用。

场景二：类实例与属性的循环强引用

下面的例子定义了两个类，Customer和CreditCard，模拟了银行客户和客户的xyk。这两个类中，每一个都将另外一个类的实例作为自身的属性。这种关系可能会造成循环强引用

class Customer {  let name: String  var card: CreditCard?  init(name: String) {    self.name = name  }  deinit {    print("\(name) is being deinitialized")  }}class CreditCard {  let number: UInt64  // 使用uNowned关键字声明为无主引用，可以声明为变量或者常量，但是不能声明为可选类型  // 对于无主引用，永远都是有值的，因此不可声明为可选类型。  uNowned let customer: Customer  init(number: UInt64,customer: Customer) {    self.number = number    self.customer = customer  }  deinit {    print("Card #\(number) is being deinitialized")  }}var john: Customer? = Customer(name: "John")john!.card = CreditCard(number: 1234_5678_9012_3456,customer: john!)

现在我们将john置为nil，其结果如何呢？

// 打印结果：// John is being deinitialized// Card #1234567890123456 is being deinitializedjohn = nil

根据打印结果，我们可以看到这两个实例都得到正确的释放了。使用uNowned关键字声明为无主引用，可以声明为变量或者常量，但是不能声明为可选类型。对于无主引用，永远都是有值的，因此不可声明为可选类型。

注意:
如果试图在实例被销毁后，访问该实例的无主引用，会触发运行时错误。使用无主引用，你必须确保引用始终指向一个未销毁的实例。还需要注意的是,如果试图访问实例已经被销毁的无主引用，Swift确保程序会直接崩溃，而不会发生无法预期的行为。

@H_301_4@ 场景三：闭包引起的循环强引用

下面我们定义@H_502_34@DemoVIEw和@H_502_34@DemoController类，前者有一个闭包作为属性，用于反向传值到后者。

typealias DemoClosure = (isSelected: Bool) ->VoIDclass DemoVIEw: UIVIEw {  var closure: DemoClosure?  func callback(selected: Bool) {    if let callback = closure {      callback(isSelected: selected)    }  }  deinit {    print("demo vIEw deinit")  }}class DemoController: UIVIEwController {  var demoVIEw: DemoVIEw?  var name: String = "DemoControllername"  overrIDe func vIEwDIDLoad() {    super.vIEwDIDLoad()    demoVIEw = DemoVIEw()    self.vIEw.addSubvIEw(demoVIEw!)    // 注意，这里使用了[uNowned self]无主引用    demoVIEw?.closure = { [uNowned self](isSelcted: Bool) in      // 闭包内，强引用了self，也就是DemoController      print("\(self.name)")    }    // 测试调用    self.passtoDmeoVIEw(true)  }  func passtoDmeoVIEw(selected: Bool) {    demoVIEw?.callback(selected)  }  deinit {    print("DemoController deinit")  }}

对比一下添加了@H_502_34@[uNowned self]与未添加的打印结果：

不添加@H_502_34@[uNowned self]，直接使用@H_502_34@self.name时，当返回上一个界面时，由于循环强引用，DemoController对象和DemoVIEw者得不到释放。 添加了@H_502_34@[uNowned self]后，打印结果说明可以得到释放，如下：

DemoController deinitdemo vIEw deinit

我们在使用闭包时，一定要注意循环强引用的问题，否则很容易千万内存泄露。除了使用无主引用之外，还有@H_502_34@weak关键字来声明使用弱使用，比如：

lazy var closure: (Int,String) -> String = {    [uNowned self,weak delegate = self.delegate] (index: Int,Title: String) -> String in    // closure body goes here    print("\(self.name)")    delegate.callBack(Title)}

为了防止循环强引用，对于@H_502_34@weak delegate = self.delegate!也需要使用弱引用。

对于闭包内的引用，何时使用弱引用，何时使用无主引用呢？

在闭包和捕获的实例总是互相引用时并且总是同时销毁时，将闭包内的捕获定义为无主引用，如上面的@H_502_34@closure闭包中的@H_502_34@self与@H_502_34@closure问题互相引用且同时销毁。 在被捕获的引用可能会变为nil时，将闭包内的捕获定义为弱引用。弱引用总是可选类型，并且当引用的实例被销毁后，弱引用的值会自动置为nil。 注意：如果被捕获的引用绝对不会变为nil，应该用无主引用，而不是弱引用。如果上面的@H_502_34@self.delegate不是可选类型，那么其值会一直存在，我们就不应该使用@H_502_34@weak引用，而是使用@H_502_34@uNowned引用。 @H_301_4@ 总结

解决循环强引用的类型有两种：

此处省略…要完整阅读，请移步：Swift ARC总结 @H_301_4@ 关注我

公众号搜索「iOS开发技术分享」快速关注，微信号：iOSDevShares

QQ群：324400294

@H_301_4@ 总结

以上是内存溢出为你收集整理的Swift内存管理（ARC）全部内容，希望文章能够帮你解决Swift内存管理（ARC）所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。

欢迎分享，转载请注明来源：内存溢出

原文地址: http://outofmemory.cn/web/1083566.html