文章转自：http://www.cnblogs.com/theswiftworld/p/swift2.html
随着刚刚结束的WWDC 2015苹果发布了一系列更新，这其中就包括了令人振奋的Swift 2.0。 这是对之前语言特性的一次大幅的更新，加入了很多实用和方便的元素，下面我们就一起来看看这次更新都包括了什么。
将 println 函数统一为 print
现在我们在代码中输入println("xxx")这样的调用时，编译器就会报错：
都已经变成通用的print方式了：
print@H_403_23@("xxx"@H_403_23@)
语言的结构性更强
比如在Swift 1.2中，我们要判断某元素是否在数组中，我们会用到contains函数：
var@H_403_23@ apps = ["Youtube"@H_403_23@,"Google"@H_403_23@,21)">"Facebook"@H_403_23@]
if@H_403_23@ contains@H_403_23@(apps,21)">"Google"@H_403_23@) {
println@H_403_23@("ok"@H_403_23@)
}
而在Swift 2.0中，变成了直接调用数组对象apps的contains方法进行这个操作，这种调用方式更加的结构化，和面向对象化：
if@H_403_23@ apps.contains@H_403_23@( 对于字符串操作，也是一样，如果在Swift 1.2中，我们要获得字符串的长度，我们会这样：
let@H_403_23@ str = "Swift App"@H_403_23@
let@H_403_23@ c@H_403_23@ = count@H_403_23@(str)
Swift 2.0中，我们只需调用str对象的count方法，即可完成字符串数量的统计：
c@H_403_23@ = str.characters.count@H_403_23@
do-while 循环语法关键词的改动
do-while循环语句在Swift 2.0中也发生了变化。以往，我们代码中用到do-while循环，会这样处理：
var@H_403_23@ counter = 5@H_403_23@
do@H_403_23@ {
print@H_403_23@(counter)
counter--
} while@H_403_23@ counter > 0@H_403_23@
swift 2.0中，do-while循环中的do关键字被替换成了repeat，如果我们在Swift 2.0还使用do关键字的话，就会导致编译错误：
Swift 2.0中我们使用repeat-while循环：
repeat {
在Swift 2.0中，之所以将do-while循环变成了repeat-while循环，是因为do关键字另有他用，这个在后面我们会讲到。
新增了 #available 标注来进行多版本兼容性支持
在以往的开发经历中，最让我们头疼的一个问题就是API的版本兼容。比如我们用了一个iOS 8引入的方法，但我们的App运行在了iOS 7的设备上，如果这时不手动进行系统版本检测的话， 我们的App就会直接的崩溃掉。而对于这种API编译器不会给我们任何的提示，只能靠着人工去逐个处理，不仅麻烦，而且很容易造成遗漏，导致严重的崩溃问题。
Swift 2.0新引入的#available机制，就解决了这一问题。 新的Swift编译器，会在编译的时候就进行检测，举个例子，比如UIAlertController这个类是iOS 8.0引入，但我们的项目设置的Deployment Target是iOS 7.0,这时候我们在编译代码的时候，编译器就会给出我们这样的警告：
看到了吧，在Swift 2.0中，编译器会自动帮我们检测哪些API需要进行版本兼容判断，非常的强大吧。这样就减去了我们很多麻烦，并且大大减少了App出错的概率。
编译器帮我们检测到问题之后，接下来我们就要处理这个问题，也就是进行系统版本的条件判断，也就是通过#available来判断：
if@H_403_23@ #available(iOS 8.0@H_403_23@,*) {
let@H_403_23@ alert = UIAlertController@H_403_23@(title: "test"@H_403_23@,message: "app"@H_403_23@,preferredStyle: .Alert@H_403_23@)
UIApplication@H_403_23@.sharedApplication().keyWindow?.rootViewController?.presentViewController(alert,animated: true@H_403_23@,completion: nil@H_403_23@)
} else@H_403_23@ {
let@H_403_23@ alert = UIAlertView@H_403_23@(title: nil@H_403_23@,cancelButtonTitle: "ok"@H_403_23@)
alert.show()
}
我们看上面的代码if #available(iOS 8.0,*)用于检测当前的系统版本是否在iOS 8或以上。如果是的话，那么我们就使用UIAlertController。 否则，我们还继续使用UIAlertView。
现在编译我们的代码，即可编译通过。#available这个特性的提供，算是对我们现有的开发方式的一个改进。也体现了Swift的安全性为本的核心理念。
感觉脑洞小开哦～
错误处理 try,catch 语句的增加
Swift 2.0中提供了对错误处理更好的支持，增加了try-catch语句。现在我们可以这样进行异常处理操作了：
do@H_403_23@ {
let@H_403_23@ content = try NSString@H_403_23@(contentsOfFile: "/file/path/str.txt"@H_403_23@,encoding: NSUTF8StringEncoding@H_403_23@)
} catch {
"read content fail"@H_403_23@)
}
是不是发现了do关键字了呢，Swift 2.0中将do关键字用到了异常处理块中。还有一点和其他语言不同的是，这里的try关键字是写在具体调用代码行上面的。也就是说，那个语句会有可能抛出异常，我们才在哪个语句前面加上try关键字。这种方式有一个好处。就是我们可以一目了然的看到那些代码会抛出异常。而不是将所有代码都混在 try-catch 语句块中。
throws 和 throw 关键字，以及自定义异常类型
我们还可以对我们自己定义的函数声明异常抛出，使用throws关键字：
func@H_403_23@ requestImage@H_403_23@(urlString:String)@H_403_23@@H_403_23@ throws -> UIImage@H_403_23@? {
if@H_403_23@ let@H_403_23@ url = NSURL@H_403_23@(string: urlString) {
let@H_403_23@ data = NSData@H_403_23@(contentsOfURL: url) {
return@H_403_23@ UIImage@H_403_23@(data: data)
}
}
return@H_403_23@ nil@H_403_23@
}
在返回值类型声明前面加上throws关键字,即可将我们的函数声明为抛出异常类型：
requestImage@H_403_23@(urlString:String)@H_403_23@@H_403_23@ throws -> UIImage@H_403_23@?
接下来我们还需要定义我们要抛出的异常类型。我们可以通过ErrorType类型的枚举声明来定义我们自己的异常类型：
enum@H_403_23@ RequestImageError@H_403_23@ : ErrorType@H_403_23@ @H_403_23@{
case@H_403_23@ NetworkError@H_403_23@
case@H_403_23@ URLError@H_403_23@
}
我们定义了两个异常类型，NetworkError表示网络错误，URLError表示 url 错误。 我们还需要在我们的方法中抛出这些异常：
return@H_403_23@ UIImage@H_403_23@(data: data)
} else@H_403_23@ {
throw RequestImageError@H_403_23@.NetworkError@H_403_23@
}
} else@H_403_23@ {
throw RequestImageError@H_403_23@.URLError@H_403_23@
}
}
现在调用这个方法的时候，就可以通过 try,catch 来处理异常情况了：
do@H_403_23@ {
try requestImage("http://swiftcafe.io/images/qrcode.jpg"@H_403_23@)
} catch RequestImageError@H_403_23@.NetworkError@H_403_23@ {
"network error"@H_403_23@)
} catch RequestImageError@H_403_23@.URLError@H_403_23@ {
"url error"@H_403_23@)
}
guard 关键字
Swift 2.0中新引入了一个叫做guard的关键字用于条件判断处理。举个例子来说，我们以前在代码中对函数的参数进行验证的时候，可能会用到这种方法：
printName@H_403_23@(firstName:String?,_@H_403_23@ lastName:String?)@H_403_23@@H_403_23@ {
if@H_403_23@ firstName != nil@H_403_23@ {
if@H_403_23@ lastName != nil@H_403_23@ {
"@H_103_403@\(lastName!)@H_403_23@ @H_103_403@\(firstName!)@H_403_23@"@H_403_23@)
}
}
}
我们对每一个参数都用一个if语句来判断，这样的代码结构读起来结构不是很清晰，并且如果参数的数量比较多的话，if语句的嵌套层数就会很深，导致可读性的降低。那么为了减少嵌套层数，我们还可以这样：
printNameByIf@H_403_23@(firstName:String?,255)">if@H_403_23@ firstName == nil@H_403_23@ {
return@H_403_23@
}
if@H_403_23@ lastName == return@H_403_23@
}
"@H_103_403@\(lastName!)@H_403_23@ @H_103_403@\(firstName!)@H_403_23@"@H_403_23@)
}
我们在函数的开始，用 if 语句来判断各个参数。当这些判断失败的时候，会直接return。只有当所有的判断都通过，才会执行函数中真正的代码。这样做，解决了之前if嵌套的可读性的问题，好了很多。
但这样依然有它的问题。比如，这样的可读性依然不是很好，不能充分显示这个if语句的意图。并且，对于Optional类型的值，也没有进行很好的处理。
基于这些情况，Swift 2.0中引入了guard关键字，我看来看一下如何用guard来实现这个方法：
printNameByGuard@H_403_23@(firstName:String?,_@H_403_23@ lastName:String?)@H_403_23@@H_403_23@ {
guard let@H_403_23@ first = firstName else@H_403_23@ {
return@H_403_23@
}
guard let@H_403_23@ last = lastName return@H_403_23@
}
"@H_103_403@\(first)@H_403_23@ @H_103_403@\(last)@H_403_23@"@H_403_23@)
}
我们这里用到了guard关键字，来进行参数条件的判断。比起之前的if判断，代码的可读性更强，并且意图更加明确。guard还有一个好处就是对于Optional的解包的作用域是在函数内完全可见的。 比如上例中，我们解包出的first和last，可以在guard执行完后，继续使用。
gurad关键字，除了用在参数判断返回的场景下，还能用在很多别的地方：
guard app.characters.count@H_403_23@ > 0@H_403_23@ else@H_403_23@ {
throw InputError@H_403_23@.NameIsEmpty@H_403_23@
}
guard #available(iOS 8@H_403_23@,*) else@H_403_23@ {
return@H_403_23@
}
defer 关键字
在了解defer关键字之前，让我们先了解一个比较常见的例子：
getFileContent@H_403_23@(path:String)@H_403_23@@H_403_23@ -> NSString@H_403_23@ {
guard path.characters.else@H_403_23@ {
showGetFinished()
return@H_403_23@ ""@H_403_23@
}
if@H_403_23@ NSFileManager@H_403_23@.defaultManager().fileExistsAtPath(path) {
do@H_403_23@ {
let@H_403_23@ content = try NSString@H_403_23@(contentsOfFile: path,encoding: NSUTF8StringEncoding@H_403_23@)
showGetFinished()
return@H_403_23@ content
} catch {
showGetFinished()
""@H_403_23@
}
} ""@H_403_23@
}
}
上面的函数就是一个简单的读取文件内容的方法，我们注意看一下里面的showGetFinished()方法，在多个分支都被调用了。实际上它的逻辑只是干一件事，就是在函数结束的时候显示一下读取完成消息。显然我们这里的代码在每个if调用return返回之前，都调用了showGetFinished()方法。在语法上，这样的调用是没问题的。但从业务逻辑角度考虑，其实这样做是比较笨拙的。但我们又受制于语法限制，只能写出很多这样形态的代码。
这就是Swift 2.0中引入defer关键字的作用了。我们来看看Swift 2.0中是怎么处理这个问题的：
getFileContentDefer@H_403_23@(path:String)@H_403_23@@H_403_23@ -> NSString@H_403_23@ {
defer { showGetFinished() }
guard path.characters.else@H_403_23@ {
if@H_403_23@ NSFileManager@H_403_23@.defaultManager().fileExistsAtPath(path) {
NSUTF8StringEncoding@H_403_23@)
return@H_403_23@ content
} catch {
我们看一下上面的代码，所有分支中的showGetFinished()调用都不见了，我们只在函数的第一行看到一句defer { showGetFinished() }。 如果我们执行这个函数，就会发现无论代码走到哪个分支，defer语句块中的showGetFinished()都会被调用。
defer语句就相当于在它的作用域中执行一个收尾工作，又叫做稍后执行，比如我们例子中的函数，showGetFinished()方法就符合这个逻辑，在函数执行完成后，做一些收尾的操作(比如这个例子里面要显示一下状态信息)。
defer从程序语法结构上，做了一个改进，以往我们为了达到类似的目的需要不断的通过if-else分支来实现的逻辑，可以能够更加清晰和简洁的表达出来。
恩，不错不错。喜笑颜开~
defer语句块不仅能够在函数中使用，它几乎可以在任何{..}语句块中使用：
branch@H_403_23@()@H_403_23@@H_403_23@ -> String@H_403_23@ {
var@H_403_23@ str = ""@H_403_23@
str += "1"@H_403_23@
defer { str += "2"@H_403_23@ }
let@H_403_23@ counter = 3@H_403_23@;
if@H_403_23@ counter > 0@H_403_23@ {
str += "3"@H_403_23@
defer { str += "4"@H_403_23@ }
str += "5"@H_403_23@
}
str += "6"@H_403_23@
return@H_403_23@ str
}
我们这次，在branch函数和它里面的if语句块中都用到了defer语句块。我们函数最终返回的 str 中的内容是：
13546
这个结果和各位想到的结果是否一样呢？
Swift 2.0是一个重大的改进，包括了很多的优化与改动，这里面只介绍了其中一些比较显著的优化与更新。更多的更新内容在后期还会为大家继续整理的哦。从这次更新中我们不难看到Swift依然秉持着它基于类型安全已经更现代化的开发方式的理念。在现在产品都注重用户体验的同时，相信Swift也会给我们这些开发者更好的开发体验。
原文链接：https://www.f2er.com/swift/325881.html
