转载

外文解析：现在放弃Objective-C使用Swift的最好时机

各位亲爱的iOS与OS X应用程序开发人员，如今正是将编程阵地转移至更为亲民、功能更为全面的Swift的最佳时机。

一般而言，编程语言往往不会轻易消亡，不过由相关厂商大力推动的更新换代举措则不在此列。如果大家从事移动设备应用程序开发工作，但却还没体验过Swift，那请注意啦：Swift不仅仅是一种希望在Mac、iPhone、iPad、Apple Watch以及其它未来设备上取代Objective-C的新型编程语言，它同时也将在苹果平台上一举取代C语言对嵌入式编程的统治。

得益于自身的多项关键性特色，Swift正迅速成为我们在未来几年中创建沉浸式、响应式、面向消费者的应用程序时不容忽视的优先性编程语言选项。

苹果公司似乎为Swift制定了一项宏伟的发展目标。该语言针对编译器性能以及语言开发需求作出了诸多优化，而且苹果公司在Swift的说明文档中暗示称该语言“在设计思路上充分考虑到规模化需要，从‘你好，世界’到完整的操作系统皆可轻松应对”。尽管苹果方面目前还没有明确指出该语言的设计目标，但Xcode 6、Playgrounds再加上Swift的陆续出台标志着苹果公司希望让应用程序开发工作变得更加轻松，同时这套体系与任意其它开发工具链的对接也将变得简单便捷。

在今天的文章中，我们将立足于十大理由，了解选择Swift作为首选编程方案所带来的具体收益。

1. Swift代码更易于阅读

Objective-C几乎让大家对于一款以C为基础建立起的编程语言所抱有的一切预期及希望都落了空。为了能够将自身关键字与类型设置与C语言作出区分，Objective-C引入了@符号作为新的关键字标记。由于Swift并非以C语言为建立基础，因此其能够将所有关键字加以统一，同时取消了原本在每种Objective-C类型或者与对象相关的关键字中的@符号。

Swift彻底丢弃了其前身的大量遗留设定。因此，大家已经没必要再保证每一行代码以分号结尾，或者在if/else语句当中利用括号将条件表达式给括起来。另一大重要变更在于，Swift中的方法调用不再相互嵌套，这就让我们从可怕的中括号地狱中解脱了出来——再也不见了，[[[ ]]]。Swift中的方法与函数调用采用了业界标准化的，在圆括号内以逗号分隔参数列表的作法。结果就是，我们如今拥有了一套更为简洁、更富于表现力的编程语言，并能够享受其中更为简单的语法表达方式。

Swift的代码内容与英语这一自然语言非常接近，或者说比目前其它主流现代编程语言相比更为接近。这种可读性使原本使用JavaScript、Java、Python、C#以及C++等语言的程序员能够更轻松地将Swift纳入其工具链当中——而不像当初的丑小鸭Objective-C那么难对付。

2. Swift代码易于维护

这种继承属性正是Objective-C在发展中遭遇拖累的主要原因——如果C语言没有进化，那么Objective-C也将无法进化。C语言要求程序员同时维护两个代码文件，从而改善构建时间并提高应用程序创始的执行效果，而这一要求也被Objective-C原原本本地继承了过来。

Swift语言则消除了这种双文件要求。在Swift 1.2版本中，Xcode与LLVM编译器已经能够自动判断出关联性并执行增量构建。如此一来，将内容表（也就是头文件）从主体（也就是执行文件）中剥离出来的任务已经彻底不复存在。Swift将Objective-C的头文件（即.h文件）与执行文件（即.m文件）整合成了单一代码文件（即.swift文件）。

Objective-C的双文件系统无疑给程序员带来了额外的工作负担——而这让程序员们更难从大局角度出发完成开发任务。在Objective-C中，我们必须以手动方式在两个文件之间进行方法名及注释的同步工作，从而让二者使用同一套标准表达，但除非开发团队已经拥有现成的规则及代码审查机制、否则这一目标根本得不到保障。

Xcode以及LLVM编译器能够在幕后起效以减少程序员的实际工作量。而在Swift当中，程序员几乎用不着再为上述任务所烦恼，从而把更多精力及时间用于创建应用程序逻辑。Swift简化了样板工作、提升了代码及注释内容的质量，同时带来更多功能支持能力。

3. Swift安全性更高

Objective-C语言的一大有趣之处在于对指针——特别是nil（也就是null）指针——的处理方式。在Objective-C当中，如果大家尝试利用某个为nil（即未初始化）的指针变量调用一项方法，则不会起到任何效果。该表达式或者代码行将因此变成无操作（no-op）内容，尽管其不至于导致意外崩溃状况的出现，但却一直是应用程序中各类bug的主要根源。一条no-op往往会导致不可预知的行为，而这正是程序员们在努力寻找并修正随机崩溃或者中止意外状况时所面临的头号大敌。

可靠类型的出现让无操作值在Swift代码中的可能后果变得非常明确，这意味着一旦大家编写出糟糕的代码、其将直接引发编译器错误。Swift借此创建出一套简短的反馈循环，并允许程序员根据自己的意图进行编码。在代码编写的过程中、相关问题就能够同时得到解决，而这显然会大大降低我们在bug修复工作中所投入的时间及精力——特别是与Objective-C指针逻辑相关的bug。

从传统角度看，在Objective-C当中，如果某个值返回自某个方法，那么程序员就需要负责在文件中记录下该指针返回变量的行为（利用注释以及方法命名规则）。而在Swift中，可选类型及值类型的存在使我们能够很轻松地通过方法定义了解到该值是否存在或者其是否属于潜在的可选项（即该值可能存在或者可能为nil）。

为了提供具备可预测性的行为，如果某个nil可选变量被使用、Swift会触发一项运行时崩溃。这一崩溃会带来一致性行为，从而简化了整个bug修复过程——因为这迫使程序员需要立即对该问题进行修复。此类Swift运行时崩溃将阻止对应代码行在出现nil可选变量被使用后继续运行的状况。这意味着该bug必须尽快得到修复，或者被彻底被排除出Swift代码。

4. Swift在内存管理方面拥有统一化特性

Swift能够以Objective-C所无法达到的方式实现自身语言的高度统一。Swift对自动引用计数（即Automatic Reference Counting，简称ARC）的支持能力可以完全涵盖面向过程与面向对象的代码路径。在Objective-C当中，ARC只能够在Cocoa API以及面向对象代码内部得到支持; 除此之外，其无法作用于C代码过程以及Core Graphics等API当中。这意味着程序员在使用由iOS所提供的Core Graphics API以及其它低级API时，必须自行负责内存管理工作。有鉴于此，Swift彻底杜绝了程序员经常在Objective-C中所面临的内存大规模泄漏问题。

程序员不应该从自己所创建的每个数字化对象角度考虑内存管理工作。由于ARC能够在编译的过程中处理所有内存管理事务，因此大家的脑力应该专注于应用程序的核心逻辑以及各类新功能。由于Swift中的ARC能够跨越面向过程与面向对象的代码起效，因此其不再要求程序员把太多精力浪费在上下文切换方面——我们甚至能够直接编写出触及底层API的代码，从而一举解决Objective-C目前版本所面临的最大难题。

通过解决自动化与高性能内存管理这一难题，苹果公司用事实证明了Swift能够切实帮助程序员提高生产效率。另一项附加作用在于，Objective-C与Swift都不会受到用于清理未使用内存的垃圾收集机制（即Garbage Collector）的影响，正如Java、Go或者C#一样。这一点对于任何一种会被用于响应图形及用户输入内容的编程语言都非常重要，特别是在像iPhone、Apple Watch或者iPad这样的触控设备之上（在这些平台中，操作滞后会带来令人难以忍受的糟糕体验，并导致用户认为应用程序的运行出现了问题）。

5. Swift所需要的代码较少

Swift对于需要重复的语句以及字符串操作，Swift能够大大降低所需代码量。在Objective-C当中，处理文本字符串的过程非常繁琐，而且需要采取一系列步骤来将两组信息结合在一起。相比之下，Swift则具备多种现代编程语言特性，例如通过“+”运算符将两条字符串直接合并在一起，这种能力是Objective-C所不具备的。对于此类字符与字符串结合方式的支持能力已经成为任何一种需要在屏幕上向用户显示文本内容的编程语言的必备要素。

Swift中的类型系统能够降低代码语句的复杂程度——因为编译器能够直接识别出这些类型。举例来说，Objective-C要求程序员雇特殊的字符串标记（例如%s、%d以及%@），并提供一份由逗号分隔的变量列表来替代这些标记。Swift支持字符串插值，这就使程序员不必再死记硬背这些标记、而能够直接将变量插入到面向用户的字符串之内，例如标签或者按钮标题。相比之下，Objective-C中的类型推理系统与字符串插值则往往成为导致应用崩溃的诱因。

在Objective-C当中，弄乱字符串标记的顺序或者使用了错误的字符串标记都有可能令应用程序发生崩溃。但现在，Swift能够把程序员从这些繁琐的规定当中解放出来，并凭借着其对文本字符串及数据操作的内联支持能力保证翻译得出的代码成果更为精练（从而降低了代码出现错误的机率）。

正文到此结束