<h2>悬挂指针及内存泄漏</h2>    <p>如果对象a指向对象b，若对象b被释放了，则此时对象a指向一个未知地址，这种情况叫做悬挂指针。</p>    <p>如果对象a指向对象b，若对象a被释放了，则此时没有任何对象能够指向对象b，对象b无法被释放，这种情况叫做内存泄漏。</p>    <h2>手动内存管理</h2>    <p>在ARC出现之前，ios的内存管理是基于手动内存管理，也叫做MRC。</p>    <p>为了防止悬挂指针及内存泄漏，手动内存管理基于一个引用计数（retain count）的概念，所有对象都可以增加或减少一个对象的引用计数，当对象的引用计数大于0，则该对象继续存在；当该对象的引用计数减少到0，则该对象自动销毁。NSObject实现了 <em>retain</em> 和 <em>release</em> 方法，用于增加或减少引用计数。</p>    <p>具体的规则如下：</p>    <ul>     <li>如果对象a通过调用初始化函数初始化了对象b，则初始化函数增加b的引用计数。</li>     <li>如果对象a通过 <em>copy</em> ， <em>mutableCopy</em> 或任何带有 <em>copy</em> 字样的方法获得一个对象b的拷贝，则这些copy方法负责增加这个新的b的拷贝的引用计数。</li>     <li>如果对象a直接获取一个对象b的引用（不是通过初始化或拷贝的方法），则对象a自己负责增加对象b的引用计数。</li>     <li>如果对象a之前直接或间接的增加了对象b的引用计数，当对象a不再需要对象b的引用之后，对象a要负责减少对象b的引用计数。如果对象b的引用计数减少到0，则对象b被释放。</li>    </ul>    <h2>ARC</h2>    <p>ARC（以及Swift）出现之后，我们不能再调用 <em>retain</em> 和 <em>release</em> 方法了。对引用计数的工作都由ARC自动完成。ARC被实现为编辑器的一部分，它将在幕后为我们自动加入 <em>retain</em> 和 <em>release</em> 方法。</p>    <p>但即使是在ARC的环境下，仍然有一些内存管理问题需要我们注意或进行手动处理。</p>    <h2>循环引用</h2>    <p>在这里我直接使用官方文档的例子：</p>    <pre>  <code class="language-objectivec">class Person {    let name: String    init(name: String) { self.name = name }    var apartment: Apartment?    deinit { print("\(name) is being deinitialized") }  }    class Apartment {    let unit: String    init(unit: String) { self.unit = unit }    var tenant: Person?    deinit { print("Apartment \(unit) is being deinitialized") }  }    var john: Person?  var unit4A: Apartment?    john = Person(name: "John Appleseed")  unit4A = Apartment(unit: "4A")    john!.apartment = unit4A  unit4A!.tenant = john</code></pre>    <p style="text-align:center"><img src="https://simg.open-open.com/show/8a14d4bf1851127d061a9b2f0254a2db.png"></p>    <p style="text-align:center">Paste_Image.png</p>    <p>这是最典型的强引用循环，当john和unit4A释放各自的对象之后，Person和Apartment的实例不会销毁，因为它们在互相引用对方。具体的解决办法有weak和unowned。</p>    <h2>Weak</h2>    <p>将上例的tenant属性声明为weak即可解决循环引用的问题。</p>    <pre>  <code class="language-objectivec">class Person {    let name: String    init(name: String) { self.name = name }    var apartment: Apartment?    deinit { print("\(name) is being deinitialized") }  }    class Apartment {    let unit: String    init(unit: String) { self.unit = unit }    weak var tenant: Person?    deinit { print("Apartment \(unit) is being deinitialized") }  }</code></pre>    <p>此时如图：</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/b831f1e529c3f1da0b07ef6eb4445215.png"></p>    <p style="text-align:center">Paste_Image.png</p>    <p>当john释放时，Person实例因为没有strong引用，所以也被销毁了，tenant属性是weak引用，所以被ARC自动设置为nil。循环引用的问题就此解决。</p>    <p>Weak引用利用了ARC的功能，当一个引用被声明为weak的时候，ARC并不会retain这个对象。ARC会记录所有的weak引用以及它们所指向的对象，当某个对象的引用计数降到0并被销毁之后，ARC会自动将nil赋予这个引用，这也是swift中必须将weak引用声明为optional var的原因。</p>    <h2>Unowned</h2>    <p>与weak引用相类似，unowned引用也不会保存一个strong引用至它所指向的对象。</p>    <p>将一个引用声明为Unowned，意味着ARC对这个引用将不再起任何作用。如果引用的对象被销毁了，我们将真正面临悬挂指针的问题。所以，官方的说法是使用unowned引用必须确保unowned引用所指向的对象拥有与unowned引用相同的或更长的生命期限，因为这样是最安全的。</p>    <p>还是使用官方的例子：</p>    <pre>  <code class="language-objectivec">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 let customer: Customer    init(number: UInt64, customer: Customer) {    self.number = number    self.customer = customer    }    deinit { print("Card #\(number) is being deinitialized") }  }    var john: Customer?  john = Customer(name: "John Appleseed")  john!.card = CreditCard(number: 1234_5678_9012_3456, customer: john!)</code></pre>    <p style="text-align:center"><img src="https://simg.open-open.com/show/d6b92a58a5eab20ad59dfaaf1e347014.png"></p>    <p style="text-align:center">Paste_Image.png</p>    <p>这个例子是使用unowned引用最安全的方法，因为unowned引用所指向的对象拥有与unowned引用相同的或更长的生命期限，我们可以理解为两个对象一损俱损的情况下，使用unowned最安全。</p>    <p>但是，如果此时CreditCard实例有另外一个对象指向它，那么当john被释放了，Customer实例也被销毁了，但是CreditCard实例仍然存在，CreditCard类中的customer属性将指向一个悬挂指针，我们需要手动的将nil赋予customer属性。这种情况也是非常常见的。</p>    <h2>一些特殊例子</h2>    <h2>ARC不支持的delegate</h2>    <p>使用weak引用最常见的情况就是在delegate中，如下：</p>    <pre>  <code class="language-objectivec">class ColorPickerController : UIViewController {     weak var delegate: ColorPickerDelegate? // ...  }</code></pre>    <p>但是，一些内置的Cocoa类使用了ARC不支持的引用（因为它们是非常老旧的代码或有向后兼容的需求），这种属性使用了 <em>assign</em> 关键字，例如， <em>AVSpeechSynthesizer</em> 的delegate属性声明如下：</p>    <pre>  <code class="language-objectivec">@property(nonatomic, assign, nullable) id<AVSpeechSynthesizerDelegate> delegate;</code></pre>    <p>在Swift中，对应的声明如下：</p>    <pre>  <code class="language-objectivec">unowned(unsafe) var delegate: AVSpeechSynthesizerDelegate?</code></pre>    <p>在Swift中， <em>unowned</em> 和Objective-C的 <em>assign</em> 意义相同，都意味着ARC的内存管理机制在这里不起作用。 <em>unsafe</em> 关键字是Swift自己加上去的，作为更进一步的警告吧。</p>    <p>即使我们自己的代码使用了ARC，但是Cocoa的内部代码没有使用ARC，这种情况依然能造成内存错误。例如，我们将某个对象赋予 <em>AVSpeechSynthesizer</em> 的delegate属性，如果我们的对象被销毁了，而这个delegate引用仍然存在，我们就需要手动将nil赋予这个delegate引用。这种情况与我在上一节中最后说的情况一样。</p>    <h2>Notification</h2>    <p>如果使用 <em>addObserver(_:selector:name:object:)</em> 方法注册notification，你其实是在该函数的第一个参数作为一个引用传递给notification center，通常是self。notification center对这个对象的引用是non-ARC的unsafe的引用，当我们的对象被销毁后，notification center将面临悬挂指针的问题。这就是为什么我们必须要在对象销毁前进行unregister。这种情况与前面讲的delegate例子相类似。</p>    <p>如果使用 <em>addObserver(forName:object:queue:using:)</em> 方法注册notification，内存管理的问题将更加复杂。</p>    <ul>     <li><em>addObserver(forName:object:queue:using:)</em> 方法返回的对象将被notification center retain，直到我们unregister它。</li>     <li><em>addObserver(forName:object:queue:using:)</em> 方法的最后一个参数using是一个closure，它可能会引用self，这就意味着在unregister这个notification之前，notification center还会对self进行retain。这同样意味着我们不可能在 <em>deinit</em> 中进行unregister操作，因为在注册之后，unregister之前， <em>deinit</em> 不可能被调用。</li>     <li>如果我们自己又引用了 <em>addObserver(forName:object:queue:using:)</em> 方法返回的对象，该方法的using参数又引用了self，则形成了一个循环引用。</li>    </ul>    <p>我们看下面的例子：</p>    <pre>  <code class="language-objectivec">var observer : Any!   override func viewWillAppear(_ animated: Bool) {    super.viewWillAppear(animated)     self.observer = NotificationCenter.default.addObserver(forName: .woohoo, object:nil, queue:nil) { _ in    print(self.description)    }  }</code></pre>    <p>因为unregister的操作不能在 <em>deinit</em> 中进行。</p>    <pre>  <code class="language-objectivec">override func viewDidDisappear(_ animated: Bool) {     super.viewDidDisappear(animated)     NotificationCenter.default.removeObserver(self.observer)  }</code></pre>    <p>现在完成了register和unregister的操作，但是view controller本身因为有循环引用的问题而出现了内存泄漏的情况，可以发现 <em>deinit</em> 函数不会被调用。</p>    <pre>  <code class="language-objectivec">deinit {   print("deinit")   }</code></pre>    <p>最简单的解决方法是在closure中定义捕捉列表，将self声明为unowned。</p>    <pre>  <code class="language-objectivec">self.observer = NotificationCenter.default.addObserver( forName: .woohoo, object:nil, queue:nil) {     [unowned self] _ in     print(self.description)  }</code></pre>    <h2>Timer</h2>    <p>Timer类文档中有说明如下：“run loops maintain strong references to their timers”。</p>    <p><em>scheduled-Timer(timeInterval:target:selector:userInfo:repeats:)</em> 函数的文档说明如下：“The timer main‐tains a strong reference to target until it (the timer) is invalidated.”</p>    <p>上面的文档已经说明当repeat timer没有被invalidate之前，target参数（通常是self）是被run loops retain的，这意味着在invalidate之前，target参数（通常是self）是无法释放的，这同样意味着我们不可能在 <em>deinit</em> 中进行invalidate操作，因为在invalidate之前， <em>deinit</em> 不可能被调用。与上例相似，我们可以在 <em>viewWillAppear</em> 和 <em>viewDidDisappear</em> 进行相关的操作:</p>    <pre>  <code class="language-objectivec">var timer : Timer!   override func viewWillAppear(_ animated: Bool) {    super.viewWillAppear(animated)     self.timer = Timer.scheduledTimer(timeInterval: 1, target: self, selector: #selector(fired), userInfo: nil, repeats: true)    self.timer.tolerance = 0.1  }   func fired(_ t:Timer) {    print("timer fired")   }  override func viewDidDisappear(_ animated: Bool) {     super.viewDidDisappear(animated)     self.timer.invalidate()  }</code></pre>    <p>在ios 10中，我们可以使用 <em>scheduledTimer(withTimeInterval:repeats:block:)</em> 方法，该方法可以 <em>deinit</em> 函数中进行invalida。但是要注意，如果在block参数（closure）中引用了self，同样要解决循环引用的问题。</p>    <pre>  <code class="language-objectivec">var timer : Timer!   override func viewWillAppear(_ animated: Bool) {    super.viewWillAppear(animated)     self.timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) {      [unowned self] // *       t in       self.fired(t)      }    self.timer.tolerance = 0.1   }  func fired(_ t:Timer) {     print("timer fired")  }  deinit {    self.timer.invalidate()   }</code></pre>    <h2>Objective-C 属性</h2>    <p>在Objective-C中，一个 <em>@property</em> 的声明包含一些关于内存管理的描述，例如在 <em>UIViewController</em> 中，view的属性描述如下：</p>    <pre>  <code class="language-objectivec">@property(null_resettable, nonatomic, strong) UIView *view;</code></pre>    <p>strong表示setter方法将会retain传递进来的UIView对象，Swift将上述声明翻译如下：</p>    <pre>  <code class="language-objectivec">var view: UIView!</code></pre>    <p>Swift默认的声明就是strong。</p>    <p>下面列出几种Cocoa属性的内存管理描述：</p>    <p><em>strong, retain (no Swift equivalent)</em> ：</p>    <p>这两个描述是一个意思，retain来自于在ARC出现之前的时代。</p>    <p><em>weak (Swift weak)</em> ：</p>    <p>该属性将会利用ARC功能，传递进来的对象不会被retain，当该对象被销毁后，ARC将会自动赋予nil给该属性，所以该属性必须声明为optional var。</p>    <p><em>assign (Swift unowned(unsafe))</em> ：</p>    <p>ARC的内存管理机制在对属性不起作用，如果该属性所引用的对象被销毁，该属性将变成一个悬挂指针。需要我们自己手动赋值为nil。</p>    <p><em>copy (no Swift equivalent, or @NSCopying)</em> ：</p>    <p>与strong和retain相似，不同点在于setter方法会通过发送 <em>copy</em> 方法拷贝传递进来的对象。该对象必须遵循NSCopy。</p>    <p><em>copy</em> 属性的应用场合是如果一个immutable类有一个mutable子类，（如 <em>NSString</em> 和 <em>NSMutableString</em> , 或者 <em>NSArray</em> 和 <em>NSMutableArray</em> ），如果setter期望传进来的是一个immutable类对象，结果传进来的是一个mutable子类对象（根据多态性）。为防止这种情况发生， <em>copy</em> 属性会使setter方法对传进来的对象调用copy方法并创建一个新的属于immutable类实例。</p>    <p>在Swift中，这种情况不会发生在string或array上，因为string和array在Swift中实现为struct，本身就是值类型，并且通过拷贝的方式进行传递。所以 <em>NSString</em> 和 <em>NSArray</em> 在Swift中对于的 <em>String</em> 和 <em>Array</em> 没有任何特殊的标记。但那些没有桥接到Swift中的Cocoa类型则需要用到 <em>@NSCopying</em> 标记。例如UILabel中的 <em>attributedText</em> 属性，在Swift中声明如下：</p>    <pre>  <code class="language-objectivec">@NSCopying var attributedText: NSAttributedString?</code></pre>    <p>因为 <em>NSAttributedString</em> 有一个mutable子类 <em>NSMutableAttributedString</em> 。</p>    <p>我们同样可以在我们自己的代码中使用 <em>@NSCopying</em> 标记，Swift会负责管理具体的拷贝操作。如下：</p>    <pre>  <code class="language-objectivec">class StringDrawer {     @NSCopying var attributedString : NSAttributedString!     // ...  }</code></pre>    <p>有时我们会遇到这种情况，我们的类，在类内部可以使用mutable，但是类外部传进来的必须是immutable的，具体方法就是创建一个private的计算型属性即可。</p>    <pre>  <code class="language-objectivec">class StringDrawer {     @NSCopying var attributedString : NSAttributedString!     private var mutableAttributedString : NSMutableAttributedString! {    get {       if self.attributedString == nil {return nil}       return NSMutableAttributedString(attributedString:self.attributedString)      }    set {      self.attributedString = newValue       }    }  // ...  }</code></pre>    <p> </p>    <p>来自：http://www.jianshu.com/p/09a0b5ce35f8</p>    <p> </p>