Swift vs. Objective-C：未来看好 Swift 的十个理由 已翻译 100%

是时候使用易入手又全面的Swif语言为iOS和mac OS X做应用开发了。

虽然编程语言不会那么容易消逝,但坚持衰落范例的开发小组正在这么做。如果你正为移动设备开发应用程序,并且你还没有研究Swift，那么注意:当Swift涉及到Mac、iPhone、ipad、Apple Watch和未来设备的应用开发时，它不仅会排挤掉Objective-C，而且还会取代在Apple平台中做嵌入式开发的C语言。

由于几个关键特性,在未来几年，Swift有很大潜力成为创造身临其境的、响应迅速的、面向用户的应用程序的实际编程语言。

苹果公司似乎在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）。

Objective-C 的两份文件系统存在强加给程序员的额外工作 -- 而这些工作会让程序员难免分心而不能顾全大局. 在 Objective-C 中你不得不手动去同步文件之间的方法名称和注释, 有时候要寄希望于一个约定好的标准，不过除非团队的规矩和代码审查制度到位，否则这是不会为你提供什么保障的.   

Xcode 和 LLVM 编译器可以在幕后做一些工作来减轻程序员的工作负担. 使用 Swift, 程序员可以少做些费脑力的记忆性工作，从而能在创建app逻辑的工作上面赢得更多的时间. 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 中是没有。像这样支持对字符和字串的组合对于任何要在屏幕上向用户展示文本的编程语言的基础设施。

Swift中的类型系统减少了代码语句的复杂性--作为编译器可以理解的类型。比如，Objective-C要求程序员记住特殊字符标记（%s，%d，%@）并且提供了一个用逗号分隔的变量来代替每个标记。Swift支持字符串插入，这就消除了需要记住的标记和允许程序员直接插入变量到面向用户的字符串中，比如标签或者按钮的标题。这类推理系统和字符串插入减少错误来源在Objective-C中都是很常见的。

在Objective—C中，搞乱了顺序或者使用了错误字符串标记会造成app崩溃。这里，Swift再次将你从反锁的工作中解放出来，翻译成更少要编写的代码（代码现在已经不容易出错）因为它的对处理文本字符串和数据的内嵌支持。