swift指针&内存管理-引用
无主引用
和弱引用类似，无主引用不会牢牢保持引用的实例。但是不像弱应用，无主引用假定是永远有值的
当我们去访问一个无主引用的时候，总是假定有值的，所以就可能会发生程序的崩溃
如果两个对象的生命周期并不相关，使用weak
如果非强引用对象 拥有与强引用对象相同或更长的声明周期的话，则应使用 无主引用 unowned (也就是说 两个对象拥有关联 — unowned)
结果
IFLObj1 deinit
IFLObj2 deinit
obj1 先销毁，obj2后销毁, obj2与obj1有关联，IFLObj2的成员obj1 与 IFLObj1关联在一起，不是可选值
obj1的成员 obj2 是可选值，也就是说 obj1销毁，成员obj2也一定不存在了
因此，IFLObj2的成员 obj1可以用 无主引用 unowned
闭包循环引用
首先我们的闭包一般默认会捕获我们的外部变量
var mVar = 10
let closure1 = {
mVar += 1
}
closure1()
print("mVar = \(mVar)")
结果
mVar = 11
从打印结果可以看出来
闭包内部对变量的修改将会改变外部原始变量的值
那同样就会有一个问题，如果我们在class内部定义一个闭包，当前闭包访问属性的过程中，就会对我们当前的实例对象进行捕获
class IFLObj1 {
var a: Int = 21
var b: String = "joewong"
var mClosure: (() -> ())?
deinit {
print("IFLObj1 deinit")
}
}
func testClosure() {
let mObj1 = IFLObj1()
mObj1.mClosure = {
mObj1.a += 2
}
}
testClosure()
IFLObj1 deinit 并未执行
控制台查看 mObj1 引用计数
2 = (1 << 33 == 2)
mObj1 的强引用计数 为 1
注意：lldb调试的时候，不能使用 po mObj1,
因为那会增加 mObj1的引用计数，对分析造成干扰，而应该采用 api Unmanaged.passUnretained， passUnretained意思就是不对 mObj1造成引用计数+1
我们对比下不给 IFLObj1 成员 mClosure 赋值的情况
没有对 IFLObj1 成员 mClosure 赋值的情况下
强引用计数为0， 无主引用为1
通过对比，闭包的初始化 就会对 所在类 实例对象进行捕获，而并不需要等到闭包执行时，才捕获
如果用po 直接查看的话，会看到 闭包初始化之后，引用计数为2，未初始化闭包前，引用计数为1
这样就可以解释，testClosure函数作用域内，引用计数为2，作用域结束之后，引用计数 - 1， 变为1，并未变成0，所以无法执行 deinit
而能这样去理解吗？？？
从逻辑上就可以推翻这种假设了，
那如果 直接po mObj1, po多次，就会增加多次引用，作用域结束的时候，引用计数-1，并没有减到0，deinit并没有执行，假设就是错的，不能这样简单取巧的方式去理解
为了更严谨，我们就需要知道 deinit 是如何被调用执行
分析deinit调用时机
我们先通过汇编查看以下 testClosure 作用域结束前的 汇编流程，然后再找线索切入源码查看
swift_bridgeObjectRelease 是 OC 与 swift之间的转换部分，我们现在的代码是swift，忽略掉这几个影响，直接跳转到 swift_release
进入swift_release 指令
这个时候指令跳转进入到 swift_release
关键线索出现, 可是试图通过这种方式去源码搜索关键字，分析源码逻辑，纯粹从逻辑理性角度去分析，结果就是 nothiing，什么也得不出来，除了得到一些自己想当然的垃圾逻辑，基本上都是错的，有主观臆想在里边
这个时候，需要借助于符号断点 + 推断流程 + 部分源码，当然了，要摒弃掉po mObj1 带来的引用计数的影响
单步符号调试+引用计数监测
为了更方便查看引用计数的变化，testClosure 作用域里，我们追加一个 mObj2的引用
deinit 敲上断点
下载这两个符号 重新调试 ， testClosure 作用域结束前打开 下载的两个符号
testClosure作用域内，
mObj1 无主引用计数为1
强引用计数 为 1， [ 1 << 33, 在高32位显示为2]
arrayDestroy, 与目前我们关注的对象不符，忽略
此时，引用计数没有变化，因为还为执行 回收
引用计数没有变化
引用计数发生变化， 32位显示为1，为标识位，标识当前正在进行deinit
deinit 执行
再看下 swift_deallocObjectImpl 源码
至于 deinit 基于什么样的源码逻辑 调用执行，暂时可以放弃这个念头，太繁琐，没有直给的逻辑，但是从前面的调试流程，可以知道
deallocClassInstance 引用计数清零，deinit标识位设置为1， 然后调用deinit
回到之前的闭包循环引用问题
通过符号进入 swift_deallocObjectImpl
引用计数依然为2
此时 引用计数 显示的是 0
但是 deinit 标识位 并没有设置为1， deinit未执行
分析下来，所以关键是这个 第32位标识位 ，为1，才会调用deinit去执行
在以上 闭包初始化前提下的分析过程中，swift_deallocObject 并未执行，反而执行的是swift_slowDealloc
源码中有这样的逻辑
deinit 标识位 不为1，就没有机会执行 deinit
闭包捕获列表
默认情况下，闭包表达式从其周围的范围捕获常量和变量，并强引用这些值，我们可以使用捕获列表来显式控制如何在闭包中捕获值
在参数列表之前，捕获列表被写为用逗号括起来的表达式列表，并用方括号括起来。如果使用捕获列表，则即使省略参数名称，参数类型和返回类型，也必须使用关键字in
var a1 = 0
var h1 = 13.1
let closure1 = { [a1] in
print("closure1, a1 = \(a1), h1 = \(h1)")
}
a1 = 10
h1 = 18.9
closure1()
结果
closure1, a1 = 0, h1 = 18.9
闭包在初始化时，就直接对 捕获列表中的参数进行了初始化，而并不是在闭包执行时才初始化参数列表
也就是说，closure1 在初始化时， 捕获列表中的 参数 a1就已经完成了初始化，这里的逻辑是
[let a1 = 0], 是个常量， 即使closure1执行时， 这个参数也不会再变了
而 非捕获列表中的变量，比如 h1的捕获 则发生在 closure1执行时，这时候就是实际h1的值了
如果改变一下
var a1 = 0
var h1 = 13.1
let closure1 = { [a1] in
print("closure1, a1 = \(a1), h1 = \(h1)")
}
a1 = 10
h1 = 18.9
closure1()
结果
closure1, a1 = 10, h1 = 18.9
闭包-延长生命周期
class IFLObj1 {
var a: Int = 21
var b: String = "joewong"
var mClosure: (() -> ())?
deinit {
print("IFLObj1 deinit")
}
}
func testClosure() {
let mObj1 = IFLObj1()
mObj1.mClosure = { [weak mObj1] in
mObj1!.a += 2
}
mObj1.mClosure!()
print("------mObj1.a = \(mObj1.a)")
}
testClosure()
结果
------mObj1.a = 23
IFLObj1 deinit
类似于OC 的方式，在block 内部 声明强引用，延长生命周期
mObj1.mClosure = { [weak mObj1] in
if let mObj1 = mObj1 {
mObj1.a += 2
}
}
api - withExtendedLifetime 延长生命周期
withExtendedLifetime(mObj1) {
if let mObj1 = mObj1 {
mObj1.a += 2
}
}
