Swift取代OC的10个理由

苹果公司似乎在Swift上还有更大的目标。它的编译器性能和开发语言都被优化了，苹果公司在Swift的文档中暗示Swift被设计成小能（显示）“hello,world”，大能（完成）整个操作系统。苹果公司还没把这门语言的目标说全，Xcode6，Playgrounds和Swift的推出就一起揭露苹果的意图：更简单的应用开发，更易用的开发工具链。

这是从现在起使用Swift工作，并走在比赛前列的10个原因。

1. Swift 容易阅读

如你所能预计到的一门基于 C 构建的语言，Objective-C 身上所有的毒疣子都有。为了将关键词和类型同C的类型作区分，Objective-C 使用@符号引入了新的关键词。因为 Swift 不是基于C构建的，它同意了所有的关键词，并将 Objective-C 类型和对象相关的关键词前面大量的@符号移除了.

Swift 丢弃了遗留下来的约定。因而你不再需要行尾的分号，以及 if/else 语句中围绕条件表达式的括弧。另外一个大变化就是方法的调用不再互相嵌套成中括号的深坑 -- 再见吧，[[[ ]]]。Swift 中的方法和函数的调用使用行业内标准的在一对括弧内使用逗号分隔的参数列表。这样做的结果就是一种带有简化了句法和语法的更加干净有表现力的语言。

除了其它当代流行的编程语言之外，Swift 更像是自然的英语了。这种可读性是的其很容易能被其它来自 JavaScript，Java，Python，C#，以及 C++ 的开发者纳入到他们的工具链之中 -- 一点也不像 Objective-C 这只笨笨的黄小鸭。

2. Swift 更易于维护

历史遗留问题会让 Objective-C 越来越倒退 -- C 没有演进的话，这个语言也就跟着无法进行演进。C 需要程序员维护两套代码文件，以优化构建的时间以及创建可执行 app 的效率, 这种需要延续到了 Objective-C 上。

Swift 丢掉了对着俩文件的要求。Swift1.2 中 Xcode 和 LLVM 编译器可以自动计算出以来并执行增量构建。如此，将内容清单 (头文件) 同内容主体（实现文件）相分离。Swift 将 Objective-C 头文件(.h) 和实现文件 (.m) 合并成了一个代码文件 (.swift）。

3. Swift 更加安全

Objective-C 有意思的一个方面是指针 -- 特别是 nil (null) 指针 -- 它们被处理的方式. 在Objective中-C, 如果你调用方法的是一个值为 nil (未初始化)的指针变量，什么事情都会不发生. 表达式或者一行操作变成了一项空操作（no-operation (no-op)）, 而这就使得其看起来会有不会奔溃的好处, 但其实它已经变成了一个巨大的bug来源. no-op 会导致不可预测的行为, 这是程序员在尝试找出并修复某种随机的奔溃，或者要停止反常的行为时所要面对的敌人.

在Swift代码中的可选类型使得一个nil可选值的可能性变得非常的明确, 这意味它能在你写下一段糟糕的代码时会生成一个编译器错误. 这就建立了一种短程反馈的循环，可以让程序员带着目标去写代码. 问题在代码被写就时就可以被修复, 这大大节省了你要在修复有关来自 Objective-C 指针逻辑的bug时需要耗费的时间和金钱.

在 Objective-C 的传统中, 如果某个值返回自一个方法, （使用注释以及方法的命名约定来）说明指针变量被返回的行为是程序员的责任.在 Swift 中, 可选类型和值类型使得方法定义中值是否存在，或者其有可能是可选的（即值可能存在也可能为nil），这些问题都是很明确清楚的.

为了提供对行为的预测，Swift会在nil可选值被使用时触发一次运行时崩溃。 崩溃提供的就是一种一致的行为，它能减轻修复bug过程的压力，因为它会直白地强制让程序员修复好这个问题. Swift 运行时崩溃的时候会停在nil可选值被使用到的那行代码处。这就意味着bug能更早的被修复，并能在Swift代码中被完全的规避掉.

4. Swift 的内存管理是统一化的

Swift 以一种 Objective-C 从未有过的方式进行了统一。对自动引用计数 (ARC) 的支持是在整个过程化的和面向对象的代码路径上完成的。在。Objective-C。中, ARC 在 Cocoa API 和面向对象代码中获得支持；然而它并不支持过程式的 C 语言代码和像 Core Graphics 这样的 API。这意味着在使用 Core Graphics API 以及其它 iOS 上的底层 API 时，内存管控的处理都是程序员的责任。程序员在 Objective-C 上会遇到的大量内存溢出问题在 Swift 上是不可能的。

程序员不应该为他或她创建的数字对象去考虑内存的问题。因为 ARC 在编译时就处理了所有的内存管理事务, 内存管理所有消耗的脑力现在可以被用来专注于核心的应用逻辑以及新的功能特性。因为 Swift 中的 ARC 在过程式的和面向对象的代码中都能起作用，它也就不再需要程序员进行心理上的上下文切换了, 即使是他们在编写要触及底层API的代码时也不需要 -- 这在目前版本的 Objective-C 中就是一个实实在在的问题。

自动和高性能的内存管理是一个已经被解决的问题，而苹果公司已经证明了这个问题的解决可以提高生产力. 另外一个副作用就是 Objective-C 和 Swift 不会像 Java，Go 或者 C# 那样遇到垃圾收集器针对没有被使用的内存运行清理作业的情况. 这对于那些将会被用于相应图形和用户输入的编程语言而言就是一个非常重要的要素, 特别是在诸如 iPhone、Apple Watch 以及 iPad 这样的(如果响应滞后就会让用户感知上以为应用是坏的)触摸屏设备上。

5. Swift 代码更少

Swift 减少了重复性语句和字符串操作所需要的代码量。在 Objective-C 中, 使用文本字符串将两块信息组合起来的操作非常繁琐。Swift 采用当代编程语言的特性，比如使用“+”操作符将两个字符串加到一起，这在 Objective-C 中是没有。像这样支持对字符和字串的组合对于任何要在屏幕上向用户展示文本的编程语言的基础设施。

6. Swift 更快

删除遗留下来的C语言约定大大提升了引擎盖之下Swift的性能. Swift代码性能的基准测试一直都瞄向苹果公司所致力于的Swift运行app逻辑的速度提升.

根据灵长类动物研究所（Primate Lab）——时下流行的 GeekBench 性能工具的创造者——的调查, 2014年12月中使用曼德尔布罗算法（Mandelbrot algorithm）进行计算密集型任务的性能上，Swift已经逼近C++的表现了.

在2015年2月，灵长类动物研究所发现 Xcode 6.3 测试版提升了Swift在GEMM算法上的性能 -- 这是一种受制于内存限制的算法，需要对大型数组进行顺序访问 -- 有1.4倍. 初始的FFT实现 -- 这是一种会对大型数组进行随机访问的受限于内存的算法 -- 拥有2.6倍的性能提升.

7. 开源项目中更少的名称冲突

Objective-C 代码中一直令人很困扰的问题就是缺乏对命名空间的正式支持, 它是 C++ 处理文件名冲突的解决方案。当名称冲突发生在 Objective-C 中时，就会是一个连接器错误，会导致 app 无法运行。解决的办法倒是有，可它们都有潜在的隐患。一般的约定是使用两到三个字母前缀来区分编写的 Objective-C 代码, 比方说，通过 Facebook 来展现出你自己的代码。

Swift 提供了隐含的命名空间，允许相同的代码文件存在于多个项目，而不会造成构建失败，或者需要向 NSString (Next Step -- Steve Jobs 被 Apple 炒鱿鱼之后创建的公司) 或者 CGPoint (Core Graphics)这样的名称。最终，Swift 中的这一特性使得开发者更加的有生产力，并且也意味着他们没必要再做 Objective-C 需要的备忘式记忆工作。在简单如 Array，Dictionary 以及 String 这样的名字中你可以看到 Swift 的影响力，而不是脱胎于缺少命名空间的 Objective-C 中的 NSArray、NSDictionary 以及 NSString。

8. Swift 支持动态库

Swift 中没有受到足够重视的一个最大的问题是静态库向动态库的切换，其在主要发布版（iOS8，iOS7等等）会被更新。动态库是可以被链接到 app 的可执行代码块。这一特性可以让现有的 Swift 应用可以链接到随着时间推移所产生的更新版本的 Swift 语言。

开发者将 app 连同库文件一并提交，它们都用开发者证书打上了数字签名，以确保完整性 (你好, NSA)。这就意味着 Swift 可以比 iOS 更快地进化，对于一种现代编程语言而言这是必要的。对库文件的修改可以被全部引入 AppStore 上某个 app 的最新更新中，一起运行起来都如此简单.

动态库在 iOS 上从未受到支持，直到 Swift 和 iOS 8 的发布，尽管已经在 Mac 获得支持很久了。动态库处在应用可执行文件之外，不过会被包含在从 AppStore 上下载的应用包中。它减小了 app 被加载到内存中的初始大小，因为外部代码只在被用到时才会被链接进来。

9. Swift Playgrounds 鼓励交互式编码

Swift 新引入的 Playgrounds 是有经验的开发者的福音。Playgrounds 的灵感来自于苹果公司前雇员 Brett Victor 的工作。Playgrounds 可以让程序员用比如说5到20行代码来测试一种新的算法或者图形程序，不用去创建一个完整的 iPhone 应用。

苹果公司已经将内联代码执行操作加入到了 Playgrounds 中，以帮助程序员创建代码块或者编写某种算法时获得反馈。这样的反馈循环可以提升代码编写的速度，因为传统程序员所需要的心智模型已经为 Playground 的数据可视化形式所替代。编程是一个反复的过程，任何可能压力上的减轻或者创造的补充都会使得开发者更具生产力，并能释放出他们的精力来解决更大的问题，而不是死盯着传统编译器来增加程序员的繁琐细节。

10. Swift 是一个你可以影响的未来

Objective-C 没有任何出路，你将不会看到它发生改变，我们要感谢 Swift 的引入. 一些 Swift 特性可能会集成到 Objective-C, 但 Objective-C 的 C 语言遗留物还是注定了它只能吸收那么点 Swift 的好东西。