从2014年WWDC发布Swift至今已经有两年的时间了,Swift的发展可谓是十分迅速,能不能替代Objective-C我不敢说,但是由于Swift相对于Objective-C存在的多方面优势,逐渐成为iOS和Mac开发的主要语言是毋庸置疑的。
Swift团队在博客中宣布Swift 3.0语言首个开发者预览版将于5月12日发布,正式版将在4-6周之后推出。开发者预览阶段并无确定的更新周期和计划,不过Swift团队称努力将其控制在4-6周内。按此计划,Swift 3.0将错过WWDC发布窗口,团队计划于年底随新版本Xcode升级版一起发布。
虽然编程语言不会那么容易消逝,但坚持衰落范例的开发小组正在这么做。如果你正为移动设备开发应用程序,并且你还没有研究Swift,那么注意:当Swift涉及到Mac、iPhone、ipad、Apple Watch和未来设备的应用开发时,它不仅会排挤掉Objective-C,而且还会取代在Apple平台中做嵌入式开发的C语言。
由于几个关键特性,在未来几年,Swift有很大潜力成为创造身临其境的、响应迅速的、面向用户的应用程序的实际编程语言。
Swift 丢弃了遗留下来的约定。因而你不再需要行尾的分号,以及 if/else 语句中围绕条件表达式的括弧。另外一个大变化就是方法的调用不再互相嵌套成中括号的深坑 – 再见吧,[[[ ]]]。Swift 中的方法和函数的调用使用行业内标准的在一对括弧内使用逗号分隔的参数列表。这样做的结果就是一种带有简化了句法和语法的更加干净有表现力的语言。
除了其它当代流行的编程语言之外,Swift 更像是自然的英语了。这种可读性是的其很容易能被其它来自 JavaScript,Java,Python,C#,以及 C++ 的开发者纳入到他们的工具链之中。
Swift 丢掉了对着俩文件的要求。Swift1.2 中 Xcode 和 LLVM 编译器可以自动计算出以来并执行增量构建。如此,将内容清单 (头文件) 同内容主体(实现文件)相分离。Swift 将 Objective-C 头文件(.h) 和实现文件 (.m) 合并成了一个代码文件 (.swift)。
Xcode 和 LLVM 编译器可以在幕后做一些工作来减轻程序员的工作负担. 使用 Swift, 程序员可以少做些费脑力的记忆性工作,从而能在创建app逻辑的工作上面赢得更多的时间. Swift 为我们程序员裁掉了那些样板式的工作,同时对代码、注释以及所要支持的特性的质量都有所提升.
首先是类型安全,尽管Swift中要生命的类型比Objective-C少了很多,但是Swift的类型推断机制不得不说很强大。以及增加确定类型和可选类型来保证类型安全。
Objective-C 有意思的一个方面是如果你调用方法的是一个值为 nil (未初始化)的指针变量,什么事情都会不发生. 表达式或者一行操作变成了一项空操作(no-operation (no-op)), 而这就使得其看起来会有不会奔溃的好处, 但其实它已经变成了一个巨大的bug来源. no-op 会导致不可预测的行为, 这是程序员在尝试找出并修复某种随机的奔溃,或者要停止反常的行为时所要面对的敌人。
在Swift代码中的可选类型使得一个nil可选值的可能性变得非常的明确, 这意味它能在你写下一段糟糕的代码时会生成一个编译器错误. 这就建立了一种短程反馈的循环,可以让程序员带着目标去写代码. 问题在代码被写就时就可以被修复, 这大大节省了你要在修复有关来自 Objective-C 指针逻辑的bug时需要耗费的时间和金钱。
虽然Objective-C下ARC机制解决了在MRC时代下的手动引用计数这个令人头疼的问题,然而它并不支持过程式的 C 语言代码和像 Core Graphics 这样的 API。这意味着在使用 Core Graphics API 以及其它 iOS 上的底层 API 时,内存管控的处理都是程序员的责任。但是到了Swift中这一机制显得更加强大和统一。因为 Swift 中的 ARC 在过程式的和面向对象的代码中都能起作用,它也就不再需要程序员进行心理上的上下文切换了, 即使是他们在编写要触及底层API的代码时也不需要 – 这在目前版本的 Objective-C 中就是一个实实在在的问题。
Swift 减少了重复性语句和字符串操作所需要的代码量。在 Objective-C 中, 使用文本字符串将两块信息组合起来的操作非常繁琐。Swift 采用当代编程语言的特性,比如使用“+”操作符将两个字符串加到一起,这在 Objective-C 中是没有。
Swift中的类型系统减少了代码语句的复杂性–作为编译器可以理解的类型。比如,Objective-C要求程序员记住特殊字符标记(%s,%d,%@)并且提供了一个用逗号分隔的变量来代替每个标记。Swift支持字符串插入,这就消除了需要记住的标记和允许程序员直接插入变量到面向用户的字符串中。
删除遗留下来的C语言约定大大提升了引擎盖之下Swift的性能. Swift代码性能的基准测试一直都瞄向苹果公司所致力于的Swift运行app逻辑的速度提升.
根据Primate Lab——时下流行的 GeekBench 性能工具的创造者——的调查, 2014年12月中使用曼德尔布罗算法(Mandelbrot algorithm)进行计算密集型任务的性能上,Swift已经逼近C++的表现了.
Objective-C 代码中一直令人很困扰的问题就是缺乏对命名空间的正式支持, 它是 C++ 处理文件名冲突的解决方案。当名称冲突发生在 Objective-C 中时,就会是一个连接器错误,会导致 app 无法运行。解决的办法倒是有,可它们都有潜在的隐患。一般的约定是使用两到三个字母前缀来区分编写的 Objective-C 代码。
在简单如 Array,Dictionary 以及 String 这样的名字中你可以看到 Swift 的影响力,而不是脱胎于缺少命名空间的 Objective-C 中的 NSArray、NSDictionary 以及 NSString。
Swift 的命名空间是基于一份代码文件所属的目标位置。这就意味可以使用命名空间标识来区分出不同的类和值。Swift 中的这个改变很大,它极大的方便了将开发员项目、框架以及库集成到你代码中来的操作。命名空间使得在集成开源项目时,不用担心来自不同软件公司的同名代码文件会发生冲突。现在 Facebook 和苹果公司可以同时使用一个叫做 FlyingCar.swift 的对象代码文件,不会有任何错误或者失败。
Swift 中没有受到足够重视的一个最大的问题是静态库向动态库的切换,其在主要发布版(iOS8,iOS7等等)会被更新。动态库是可以被链接到 app 的可执行代码块。这一特性可以让现有的 Swift 应用可以链接到随着时间推移所产生的更新版本的 Swift 语言。
动态库处在应用可执行文件之外,不过会被包含在从 AppStore 上下载的应用包中。它减小了 app 被加载到内存中的初始大小,因为外部代码只在被用到时才会被链接进来。
Swift 新引入的 Playgrounds 是有经验的开发者的福音。Playgrounds 的灵感来自于苹果公司前雇员 Brett Victor 的工作。Playgrounds 可以让程序员用比如说5到20行代码来测试一种新的算法或者图形程序,不用去创建一个完整的 iPhone 应用。
Swift 向开发者社区提供了一个直接的方式,去影响一门语言,它将会被用于应用的创建,嵌入式系统(如果苹果公司向第三方的嵌入式框架和芯片进行了授权)以及像 Apple Watch 这样的设备.
使用 Swift,程序员只要维护原来一半量的代码文件,手动的代码同步工作为零,标点输入出错的概率也远远低于以前 – 这样就能腾出更多的时间写高质量的代码。通过使用可选类型 —— 一种针对返回或不返回值的编译时安全机制,而返回值是同步操作、网络失效时无效的用户输入以及数据验证错误发生时普遍会遇到的问题。ARC 在 Swift 中对过程式 C 风格的代码,还有苹果公司 CObjective-Coa 框架使用的面向对象代码都进行了统一。
作为Objective-C开发者其实真不用担心如何转向Swift。Swift和Objective-C其实骨子里还是一样的,变的只是语法形式。比如说方法的调用,大部分你只需要将Objective-C的中括号去掉,换成点语法就OK了。写过两个Swift方法之后就可以依照这样的形式调出其他的方法,完全没有学习难度。
我从一开始学习Swift的时候是通过官方文档来学习的,当然我英文不那么好,所以就看的中文翻译的。
看起来好多,其实不需要都看完,反正我看的时候基本都是跳着看的,有Objective-C作为基础,看起来根本不会吃力。并且看着看着就会发现越来越多的根本都不需要看了,猜都能猜出来是讲Objective-C转成Swift是怎么写的了。如果时间充足,可能这些用两三天都差不多可以过一遍了,至少用来写项目是没有问题的,剩下的就是慢慢调整写法习惯。那些不常用的地方,用到时的时候再来查就可以了。
文档不得不说写的很好,不建议有Objective-C基础的再去看Swift视频来学习,我觉得纯粹是在浪费时间。
可能会有很多人认为我通篇在扯废话,实际上你在看了本篇文章后再去学习Swift就会带有目的性的去学,可以深刻理解到Objective-C与Swift本质上有那些不同,而不是填鸭式的学习了。