swift中weak和unowned的区别

weak和unowned都是解决循环引用的关键字
区别:
如果您是一直写 Objective-C 过来的,那么从表面的行为上来说 unowned 更像以前的 unsafe_unretained,而 weak 就是以前的 weak。
用通俗的话说,就是 unowned 设置以后即使它原来引用的内容已经被释放了,它仍然会保持对被已经释放了的对象的一个 “无效的” 引用,它不能是 Optional 值,也不会被指向 nil。如果你尝试调用这个引用的方法或者访问成员属性的话,程序就会崩溃。
而 weak 则友好一些,在引用的内容被释放后,标记为 weak 的成员将会自动地变成 nil (因此被标记为 @weak 的变量一定需要是 Optional 值)。
关于两者使用的选择,Apple 给我们的建议是如果能够确定在访问时不会已被释放的话,尽量使用 unowned,如果存在被释放的可能,那就选择用 weak。

swift 关键字篇

@noescape:no escape(没有逃脱)
用来修饰闭包,含义为非逃逸闭包。
当闭包作为参数传递进函数时,如果这个闭包只在函数中被使用,则开发者可以将这个闭包声明成非逃逸的,即告诉系统当此函数结束后,这个闭包的生命周期也将结束,这样做的好处是可以提高代码性能,将闭包声明成非逃逸的类型使用@noescape关键字。
(1) 默认,swift 3.0 弃用,函数结束后,这个闭包的生命周期也将结束。
(2) 在其内部如果需要使用self这个关键字,self可以被省略。

@escaping 逃逸闭包
逃逸的闭包常用于异步的操作,这类函数会在异步操作开始之后立刻返回,但是闭包直到异步操作结束后才会被调用。例如这个闭包是异步处理一个网络请求,只有当请求结束后,闭包的生命周期才结束。当闭包作为函数的参数传入时,很有可能这个闭包在函数返回之后才会被执行。

@autoclosure 自动闭包
(1)默认非逃逸
(2)闭包也可以被自动的生成,这种闭包被称为自动闭包,自动闭包自动将表达式封装成闭包。
(3)自动闭包不接收任何参数,被调用时会返回被包装在其中的表达式的值。
(4)当闭包作为函数参数时,可以将参数标记 @autoclosure 来接收自动闭包。
(5)自动闭包能够延迟求值,因为代码段不会被执行直到你调用这个闭包。
(6)自动闭包默认是非逃逸的,如果要使用逃逸的闭包,需要手动声明: @autoclosure @escaping 旧版本:@autoclosure(escaping)

//(a)自动闭包演示
var students = [“A”,”B”,”C”]
let studentsProvider = { students.remove(at: 0) } //自动闭包自动将表达式封装成闭包
studentsProvider()//(b)自动闭包演示
var list = [1,2,3,4,5,6]

//创建一个显式闭包
let closures = {
list.append(7)
}

print(list)//将打印[1,2,3,4,5,6]

closures()
print(list)//引用传递,将打印[1,2,3,4,5,6,7]

func func1(closure: ()->Void) -> Void {
//执行显式的闭包
closures()
}

func func2(auto: @autoclosure ()->Void) -> Void {
//执行自动闭包
auto()
}

//显式闭包
func1(closure: closures)
print(list) //将打印[1,2,3,4,5,6,7,7]

//将表达式自动生成闭包
func2(auto: list.append(8))
print(list)//将打印[1,2,3,4,5,6,7,7,8]

struct 和class的区别

  1. struct是值类型,值类型在传递和赋值时将进行复制。
    class是引用类型,引用类型只会使用引用对象的一个『指向』

  2. class有这几个功能struct没有的:

class可以继承,这样子类可以使用父类的特性和方法
类型转换可以在runtime的时候检查和解释一个实例的类型
可以用deinit来释放资源
一个类可以被多次引用

struct也有这样几个优势:

结构较小,适用于复制操作,相比于一个class的实例被多次引用更加安全
无须担心内存memory leak或者多线程冲突问题

顺便提一下,array在swift中是用struct实现的。Apple重写过一次array,然后复制就是深度拷贝了。猜测复制是类似参照那样,通过栈上指向堆上位置的指针来实现的。而对于它的复制操作,也是在相对空间较为宽裕的堆上来完成的,所以性能上还是不错的。

函数式编程

避免使用程序状态和可变对象,是降低程序复杂度的有效方式之一,而这也正是函数式编程的精髓。 函数式编程强调执行的结果,而非执行的过程。

我们先构建一系列简单却具有一定功能的小函数,然后再将这些函数进行组装以实现完整的逻辑和复杂的运算,这是函数式编程的基本思想。

Swift与Objective-C的兼容方法:@objc和Dynamic

Swift必须考虑与Objective-C的兼容。

首先通过添加{product-module-name}-Bridging-Header.h文件,并在其中填写想要使用的头文件名称,我们就可以很容易地在Swift中使用Objective-C代码了。Xcode为了简化这个设定,甚至在Swift项目中第一次导入Objective-C文件时会主动弹框进行询问是否要自动创建这个文件,可以说是非常方便。

但是如果想要在Objective-C中使用Swift的类型的时候,事情就复杂一些。如果是来自外部的框架,那么这个框架与Objective-C项目肯定不是处在同一个target中的,我们需要对外部的Swift module进行导入。这个其实和使用Objective-C的原来的Framework是一样的,对于一个项目来说,外界框架是由Swift写的还是Objective-C写的,两者并没有太大区别。我们通过使用2013年新引入的@import来引入module:

[cpp] view plaincopy在CODE上查看代码片派生到我的代码片
@import MySwiftKit;
之后就可以正常使用这个Swift写的框架了。

如果想要在Objective-C里使用的是同一个项目中的Swift的源文件的话,可以直接导入自动生成的头文件{product-module-name}-Swift.h来完成。比如项目的target叫做MyApp的话,我们就需要在Objective-C文件中写:

[cpp] view plaincopy在CODE上查看代码片派生到我的代码片
#import “MyApp-Swift.h”
但这只是故事的开始。Objective-C和Swift在底层使用的是两套完全不同的机制,Cocoa中的Objective-C对象是基于运行时的,它从骨子里遵循了KVC(Key-Value Coding,通过类似字典的方式存储对象信息)以及动态派发(Dynamic Dispatch,在运行调用时再决定实际调用的具体实现)。而Swift为了追求性能,如果没有特殊需要的话,是不会在运行时再来决定这些的。也就是说,Swift类型的成员或者方法在编译时就已经决定,而运行时便不再需要经过一次查找,而可以直接使用。

显而易见,这带来的问题是如果我们要使用Objective-C的代码或者特性来调用纯Swift的类型时候,我们会因为找不到所需要的这些运行时信息,而导致失败。解决起来也很简单,在Swift类型文件中,我们可以将需要暴露给Objective-C使用的任何地方(包括类,属性和方法等)的声明前面加上@objc修饰符。注意这个步骤只需要对那些不是继承自NSObject的类型进行,如果你用Swift写的class是继承自NSObject的话,Swift会默认自动为所有的非private的类和成员加上@objc。这就是说,对一个NSObject的子类,你只需要导入相应的头文件就可以在Objective-C里使用这个类了。

@objc修饰符的另一个作用是为Objective-C侧重新声明方法或者变量的名字。虽然绝大部分时候自动转换的方法名已经足够好用(比如会将Swift中类似init(name: String) 的方法转换成-initWithName:(NSString *)name这样),但是有时候我们还是期望Objective-C里使用和Swift中不一样的方法名或者类的名字,比如Swift里这样的一个类:

[cpp] view plaincopy在CODE上查看代码片派生到我的代码片
class 我的类 {
func 打招呼(名字: String) {
println(“哈喽,(名字)”)
}
}

我的类().打招呼(“小明”)
Objective-C的话是无法使用中文来进行调用的,因此我们必须使用@objc将其转为ASCII才能在Objective-C里访问:

[cpp] view plaincopy在CODE上查看代码片派生到我的代码片
@objc(MyClass)
class 我的类 {
@objc(greeting:)
func 打招呼(名字: String) {
println(“哈喽,(名字)”)
}
}
这样,我们在Objective-C里就能调用 [[MyClass new] greeting:@”XiaoMing”] 这样的代码了(虽然比起原来一点都不好玩了)。另外,正如上面所说的以及在Selector一节中所提到的,即使是NSObject的子类,Swift也不会在被标记为private的方法或成员上自动加@objc。如果我们需要使用这些内容的动态特性的话,我们需要手动给它们加上@objc修饰。

添加@objc修饰符并不意味着这个方法或者属性会变成动态派发,Swift依然可能会将其优化为静态调用。如果你需要和Objective-C里动态调用时相同的运行时特性的话,你需要使用的修饰符是dynamic。一般情况下在做App开发时应该用不上,但是在施展一些像动态替换方法或者运行时再决定实现这样的 “黑魔法” 的时候,我们就需要用到dynamic修饰符了。在之后的KVO一节中,我们还会提到一个关于使用dynamic的实例。