Swtift语言的未来发展.docVIP

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 以及其