厨子今年的演讲很不给力。不过既然是软件开发者大会嘛，焦点自然应该放在软件功能上。
所以我看了下今年的Session401，也就是Swift4.2新特性介绍，做了下笔记，希望能对你有用。
多说一句，Swift越来越好用了，希望开发者能尽快拥抱Swfit。
Source Compatibility 代码兼容性
本次版本发布的XCode里，用户可以选择按照Swift3，Swift4或者Swift4.2来进行编译。也就是说本次的版本将同时支持Swift的三种版本。
另外值得一提的是，Swift5官方release时间定在了2019年，所以本次更新是支持Swift3的最后一次更新了，各位开发者注意做好代码升级工作。
Faster Swift Debug Builds 更快的Swift调试构建
自古以来，对于Swift编译慢的吐槽一直没有停止过。Apple显然知道这一点，因此在最近的更新里总会提到编译速度的优化。在我看来，反正开始速度足够慢，因此之后会有很大的提升空间（围笑）。
官方对于这次的速度提升给出的数据是大约3倍，但是这是基于i7架构的MacbookPro上的，而且编译速度和项目文件组织有很大关系。大家体会一下就好。
不过据说这次提速是由于对pipeline的优化减少了很多无用功，这点还是很值得肯定的。
另外，苹果建议在Debug的时候，使用Incremental build，也就是增量模式，来取代之前的whole module，也就是全量模式，以提高速度。下图中是默认设置，请开发者在Debug时该用Incremental选项。
Runtime Optimization 运行时优化
在Swift4.2中，在变量调用的会话过程中，会采用一种Guranteed-Release的标注方式，取代之前Retain-Release的方式，减少中间无谓的Retain-Release，来提高会话整体的内存运算效率，并且降低了代码量。
Small String
在64位系统上，对于small string放弃了24byte编码，改用16byte编码，提高了利用率。这时候，系统会将最后一子节作为标识符，表示这个string是small string。因此这种改动既可以达到性能的优化，也可以实现整体体积的减小。这里借鉴了TaggedNSString技术来实现。
Reduce Code Size 减少代码体积
有时候，开发者会介意代码量，这关系到app是否可以在蜂窝网络下下载（蜂窝网络下有100MB的文件大小限制）。例如很多国民级App都曾经为了减少包大小而绞尽脑汁，例如支付宝。为了解决这个问题，本版本的XCode中提供了一个选项：
如果勾选，系统会在打包时自动进行优化，经测试，包大小会降低10%-30%不等（已经很给力了）。
Collection of Enum Cases
在Swift4时代，如果你想遍历一个枚举，你需要定义一个变量，在变量里列出所有枚举。如下所示：
但是这种方式蛋疼的是，如果你添加了一个枚举值，你需要同步更新那个变量。
在Swift4.2时代，可以用CaseIterable标签来解决这个问题：自动生成对应的变量，并允许你用.allCases来实现对所有枚举的遍历。是不是很方便？（围笑）
Conditional Conformance 条件化顺应
这个简单说吧。
意思就是如果集合元素是Equatable的，那集合本是也是Equatable。这个我目前体会不深。
Synthesized Equatable and Hashable Equatable和Hashable合成
在Swift4以及之前的版本，想比较两个结构体是否完全相等，要怎么做呢？你猜对了，写个方法把里面每一元素都拿出来比较一次，如果都相等则整体返回相等。更郁闷的是，如果要在Struct中增加一个变量，还需要同步维护这个判等函数，就像下图一样，再次表示蛋疼。。。
这一次，Swift4.2支持Equatable标签，会自动生成上述代码，大家再也不用自己手敲了，是不是很方便。
同理，Hashable也是一样的道理，大大提高了生产力。
这个进化我非常喜欢。
Hashable Enhancements Hashable增强
对于一个结构体的Hashable判断，以及获取结构体整体的Hash值，是一个历来比较混乱的部分。这里面大家的实现方法都很诡异，有用magic number做运算的，有直接用成员的hash值的，很多都是大家从网上找来的方法。这些方法且不论性能（性能也不好），从安全性角度上考虑也实现的很不好。如果一个黑客掌握了这个随机数，理论上对于他的hack是非常有利的。
因此，苹果对于本次的Swift4.2版本给出了全新的针对结构体的hash方法：
protocol Hashable {
func hash(into hasher: inout Hasher)
}
其中hasher是inout类型，可以将所有成员的hash值对整体的hasher进行叠加，由系统根据环境生成随机数来进行hash加密，提高了安全性。
这里，随机数的生成会平衡性能和效率，并且在打开app的时候就会生成。
多说一句，讲到这里的时候，现场气氛有点儿冷，大家可能对于这个地方的痛点并不多。。。
Random Number Generation 随机数生成
一般来说，我们会用C API来实现。但是这个API的名字会因平台不同而有所区别。（当然，如果你是纯iOS开发，这个问题不明显。但是别忘了我们伟大的Swift是跨平台语言，人家考虑的事Linux级别的问题）
例如：
这种情况下需要做平台检查，并对应进行区分。
而且，我们熟知做随机数的方法其实是有些Tricky的，例如，我们调用
arc4random() % 6
方法，我们想的是能平均分布0-5。但是现实情况是，4和5的分布远远小于其它，所以并不是真的随机。
因此在Swift4.2，苹果终于出手了，对于数值类型，直接可以通过radom方法来进行随机，例如
let randomIntFrom0To10 = Int.random(in: 0 ..< 10)
let randomFloat = Float.random(in: 0 ..< 1)
直接实现数字的随机化。这个应该是真.随机。
另外，还提供了集合的随机方法，例如你定义了一个字符串数组，通过randomElement方法可以随机访问某一个元素。这个很赞呀。
let greetings = ["hey", "hi", "hello", "hola"]
print(greetings.randomElement()!)
没完，苹果还提供了随机打乱顺序的方法，名字也很有意思，叫shuffled，类似于重新洗牌，将元素打乱。
let randomlyOrderedGreetings = greetings.shuffled()
print(randomlyOrderedGreetings)
讲到这里，全场掌声雷动啊，看来这几个方法大家都觉得赞。
Checking Platform Conditions 平台监测
在我们开发的过程中，会用到很多条件编译，尤其在iOS和MacOS共存的App中，经常会出现这种代码
说到底还是因为两个平台的UI库不一样。
现在，有了更优雅的方式来进行条件编译：利用canImport（xxLib）来替代原有的一串对于平台的检察。之后的代码可以如下：
怎么说呢，看起来确实是优雅了那么。。。一丢丢。。。
Enforce Exclusive Access to Memory 强制独占内存访问
这一节说的大概意思是Swift对于编译期间的检察更加严格了，并且静态和动态检查进行了合并。当然这部分作为选项让开发者自由选择，不过他还是推荐大部分开发者选第一项，更加严格和保险一些。
我觉得苹果是吸收了很多第三方代码check的框架集成到自己的体系里了吧，总的来说还是让开发者感觉到越来越方便的。
