ddddxxx's Blog

封装 NSRegularExpression

Sun, 28 Feb 2021 00:00:00 +0000

本文是关于 Regex 库的设计心得。

在 Swift 中使用 NSRegularExpression 非常繁琐。实际使用中，我们通常都会对其进行扩展（例如去除匹配时必须传入的 NSRange 参数），或是另起炉灶，重新设计一套 API。

出于个人使用需求，我早在 Swift 3 时期就制作了一个 Regex 库。当时我找遍了 GitHub 上类似的项目，无一能满足我的要求，只好自己造轮子。如今两年过去了，这样的项目在数量上多了不少，但逐一看来，质量竟还不如我两年前的设计。遂决定翻修项目，增加文档说明，发布 1.0.0 版本，并在此记录一些设计思路。

整体设计

从正则表达式本身的属性出发，很容易得出基本的设计：

每个正则表达式匹配结果都是一个 Match 实例
可以直接从 Match 中获取范围和匹配的字符串，不需要像 NSTextCheckingResult 一样再截取一次
可以从 Match 中取得 capture group，并从 capture group 中获取范围和匹配的字符串
可以获取到 0 号 capture group，即整个匹配

从第 4 点出发，我们很容易得出 Match 就是 capture group 的集合。Match 本身不必携带额外的信息，只需从 $0 中获取即可。那么 capture group 就不能是简单的 String, 内部要有自己的结构才行，即 Capture 的实例。

此时 Match 的设计大概是这样的：

struct Match {
    let captures: [Capture?]
}

有两个要注意的点

Match 和 Capture 必须是 struct 而不是 class。二者的实例可能非常小且数量多。值类型可以避免申请内存和引用计数的开销
Capture 可空，因为正则表达式允许 capture group 不参与匹配

Capture 的内部是什么样的呢？显然它应该包含范围和字符串。为了避免不必要的字符串复制，这里应该使用 Substring 而非 String。由于 Substring 自带范围，我们不需要额外储存范围：

struct Capture {
    let content: Substring
    var range: Range<String.Index> {
        return content.startIndex..<content.endIndex
    }
}

看起来不错。但是不行，我们踩进了第一个坑里。

Unicode

这是正则表达式和 Swift 间不可调和的矛盾。正则表达式（ICU标准，即 NSRegularExpression 采用的标准）匹配的单位是 Unicode Scalar，可以大致看成码点(Code Point)，而 Swift 中字符（Character）的标准是 Extended Grapheme Cluster。所以 Swift 中一个字符可能被拆成多个码点分别匹配。例如 é(U+0065 U+0301) 在 Swift 中是一个字符，但可以从中单独匹配出一个e。匹配到的范围无法用 Range<String.Index> 表达。

这并非是罕见情况，CRLF就是一个组合字符（"\r\n".count == 1），Emoji 中也有大量组合字符。GitHub 上大量项目遇到不可表达的范围时就返回空字符串，这是不可容忍的。

但完全退回 Foundation的世界，只使用 NSString 和 NSRange 也不可取。NSString 毕竟是二等公民，比不上精心调优的 String，特别是对于小字符串，String 值类型的优势是 NSString 无论如何都赶不上的。

我的做法是对于有效的范围使用 Substring，无效的范围则回退到 NSString。在保证正确的前提确保性能。

桥接

由于 Objective-C 头文件的导入规则，NSRegularExpression 相关的函数签名使用的是 Swift 原生字符串。这给了很多人一个幻觉，认为 NSRegularExpression 可以直接操作 String。但事实上这个字符串是被桥接过去的。虽然桥接没有开销，但由于底层编码不同，对字符串的操作需要支付转换编码的代价。最糟糕的是，你可能需要反复支付这个代价。GitHub 上一些类似的项目在不经意间造成了 O(n^2) 的额外开销。

事实上，在匹配前转换成 NSString 并一次性支付转换开销对性能更有帮助。在测试中，仅这一项就导致了10倍的性能差异。即使你使用裸 NSRegularExpression，也要小心这一点。

构造器

这是一个语法糖，我没见过其它项目用过，但是我认为它很甜。

Regex 的构造器显然是可以抛出错误的。但是如果我们使用编译期已知的常量字符串，这样的错误就没必要处理。这是程序编写有误，直接崩溃就好了。利用 StaticString，我们可以重载一个不会抛出错误的构造器。除此之外，这里还需要一个非公开的标签 @_disfavoredOverload 来调整优先级

init(_ staticPattern: StaticString, options: Options = [])
@_disfavoredOverload
init(_ pattern: String, options: Options = []) throws

这样用常量字符串来初始化的时候就不需要处理错误了：

let regex = Regex("(foo|bar)") // 不会抛出错误，出错直接崩溃

let pattern = "(foo|bar)"
let regex = try! Regex(pattern) // 强制要求错误处理

跨平台

不知为何，Linux 平台下 NSRegularExpression.enumerateMatches 要求传入逃逸闭包，这和 macOS 下的函数签名不一致。如果要支持 Linux，这里必须用 withoutActuallyEscaping 转换一下。

其它

还有一些小技巧。例如模式匹配运算符 ~=，实现之后可以用 switch 来匹配正则。还有ReferenceConvertible，实现之后 Regex 和 NSRegularExpression 可以用 as 来互相转换。查找替换的函数叫 replacingMatches(of:with:options:range)，命名参考了 String.replacingOccurrences(of:with:)。

其实整个 NSRegularExpression 的 API 非常小，全部封装一遍也就一两百行代码，工作量很少。但是由于涉及到 Objective-C 和 Swift 的桥接，以及正则表达式和 Unicode 本身的复杂性，封装过程有很多小坑。事实上，如果你直接使用 NSRegularExpression，很容易踩进这些坑里。而好的封装有助于你避开这些坑。

Swift 中 String 和 Index 的奇妙行为

Thu, 02 May 2019 00:00:00 +0000

在 Playground 中运行这段代码，猜猜最后一行的结果是什么：

var s = String(format: "你好 %@", "world!")
let i = s.firstIndex(of: "w")!
s.reserveCapacity(100)
s[i]

答案是 Xcode (10.2.1, 10E1001) 会崩溃。如果把最后一行换成 print(s[i])，你会得到 \345。

无论如何，这都不是我们预期的结果。在第二行，我们获取了 w 这个字符的索引。然后我们改变了字符串容器的大小。这显然没有改变字符串的内容，所以上一行的索引仍然有效。最后我们使用这个索引寻找对应的字符，发现 w 不在那了。

如果你使用的 Swift 版本低于 Swift 5（即 Xcode 低于 10.2.0），则不会有这个问题。如果把第一行换成 “你好 world!”，同样不会有问题。可能有些人已经猜到了问题所在，不过还是让我们从头说起。

String 和 Index

要解开这个问题，我们首先要知道 String.Index 是怎么工作的。从外部来看，这是一个不透明结构体。而根据源代码我们可以看到，其中只包含了一个 UInt64 的 _rawBits。抛开其中缓存和转码相关内容，和索引相关的是其中的高 48 位。“An offset into the string’s code units”，这一偏移量是基于码元（Code Unit）的。我们可以通过 encodedOffset 直接访问这一值。

注意，String.Index 是基于码元的偏移量。而同一个码点，使用不同的编码方式，得到的码元数量也不同。所以同一个字符串的同一个位置，在不同编码下，偏移量是不同的。

这时候原因就很明显了，reserveCapacity 这个操作，改变了字符串的编码方式，同时作废了相关的所有 Index。使用无效的 Index 当然不能得到正确结果。

编码

但我们还要问，为什么编码会变？

继续看源码，一个字符串对象可能以三种方式存储。忽略静态不可变字符串，一个 String 对象的底层还可能是原生 Swift String，或是桥接来的 NSString。我们已经知道 NSString 是用 UTF-16 编码，那 Swift String 呢？

好吧，正如你猜到的，从 Swift 5.0 起，native Swift string 的编码方式由 UTF-16 切换到 UTF-8。

回到原来的问题，字符串和 index 由执行 reserveCapacity 之前的

你    好    ␣     w     o     r     l     d     !
\4F60 \597D \0020 \0077 \006F \0072 \006C \0064 \0021
                  ^ index

变成了

你          好          ␣   w   o   r   l   d   !
\E4 \BD \A0 \E5 \A5 \BD \20 \77 \6F \72 \6C \64 \21
            ^ index

好像哪里不对。虽然指向了不同的字符，但还在正确的字符边界上。为什么还是会崩溃呢？

Cache

我们先尝试使用同一个偏移来制作下标：

"你好 world!"[String.Index(encodedOffset: 3)]
// 好

确定不是因为偏移导致的崩溃。由于 Index 是简单结构体，我们可以直接强转成其中的 _rawBits

String(format: "%X", unsafeBitCast(i, to: UInt64.self))
// 30100
String(format: "%X", unsafeBitCast(String.Index(encodedOffset: 3), to: UInt64.self))
// 30000

找到区别了，b8 开始多了个 1。我们可以直接查源码：

b13:b8: grapheme cache: A 6-bit value remembering the distance to the next grapheme

这几位缓存了到下一个字符的距离。可以加速下标访问。回到我们的字符串，使用 UTF-16 时，这个距离是 1，使用 UTF-8 时，这个距离是3。我们可以尝试构造出这个下标

let i = unsafeBitCast(0x30300, to: String.Index.self)
"你好 world!"[i]
// 好

当我们使用 30100 这个下标时，只有一个码元被取出，得到 0xE5，即为文章开头打印出的 0o345。Xcode 试图使用这个非法的 Character 构造 String。导致了崩溃。

迷思

事实上这个问题在 Swift 5 之前就存在了，如果你在一个静态 c 字符串上计算 index，然后拷贝一份，稍作修改再索引，也可能得到未定义行为。但是 Swift String 和 NSString 的分裂加重了问题的影响范围。现在对一个 String 做出最轻微的修改，甚至不必修改其内容，就会作废之前的所有的 index （而非修改处之后的 index）。这在使用 NSRegularExpression 时尤其恼人。

要避免这一问题，你可以：

使用 String.UTF16View.Index
- 缺点：某些情况下性能糟糕
使用 NSString
- 缺点：需要不断类型转换，对性能也有影响
使用 [Character].Index
- 缺点：需要将待处理字符串转为 [Character]，无法使用字符串相关方法

现有的设计并不理想。很难想象 String.Index 居然不能兼顾到性能，安全性和易用性的任何一方。我们需要使用冗长的语法构建出 Index，并且承担了大量的性能代价。然而这些脆弱的 Index 不能承受最轻微的修改。如果这是 Unicode Correctness 的代价，未免也太重了些。

Method Swizzling 与 NSProxy

Tue, 14 Aug 2018 00:00:00 +0000

本文假设读者有关于 Method Swizzling，和 objc 消息处理流程的基本知识。

Hook delegate 方法

使用 Method Swizzling 可以轻松 hook 一个类中的已知方法，但是对于 delegate 方法，其实际调用的类是不确定的, 如何针对未知调用类来 hook 呢？

这是一个很经典的问题，网上已经有很成熟的方案了。这里只大概讲一下思路。

由于 delegate 的调用对象是一个遵循 delegate 协议的类的实例，我们首先需要 hook setDelegate 这个方法。找到实际的 delegate 对象，然后动态进行 Hook。这也分两种情况：

delegate 对象实现了目标方法。则交换实现。
delegate 对象未实现目标方法。则动态添加该方法。

我们是如何判断 delegate 对象是否实现了目标方法的呢？是通过 class_getInstanceMethod 来查找 class 中的实例方法，如果查到了，则认为该 class 实现了该方法。

停！这里有一个很隐蔽的漏洞。我们并不是要判断 delegate 对象是否实现了某个方法，而是要判断 delegate 对象能否响应某条消息。这两个命题一般是相等的，但在某些特殊情况下有着细微的差别。

坑

如果你用 Method Swizzling 实现了 hook UIScrollView 的 delegate 方法，你会遇到一个很诡异的的 Bug。具体来说，UIWebView 对点击事件的响应会相当奇怪。你可能无法和页面中的某些元素交互。

你可能想看一下动态 hook 的过程发生了什么。在 UIWebView 的例子中，scroll view 是 _UIWebViewScrollView，而设置的 delegate 是 _UIWebViewScrollViewDelegateForwarder 的实例。试图 hook 时，我们发现 delegate 并没有实现 UIScrollViewDelegate 中的方法，于是我们添加了这些方法。但是如果我们不添加这些方法，而是打上符号断点的话，会发现 _UIWebViewScrollViewDelegateForwarder 确实处理了这些消息。

如果你熟悉 proxy 设计模式的话，这个类名已经提示你发生什么事了。

Proxy 与消息转发

上面例子中的 _UIWebViewScrollViewDelegateForwarder 是一个 proxy 对象。它本身不处理任何消息，也没有实现 UIScrollViewDelegate 中的方法。当它收到一条消息时，会通过消息转发流程，将消息转发给真正的接收者。

所以，当你通过 class_getInstanceMethod 查询时，会发现 proxy 并没有这些实例方法。于是你动态添加了这些方法。然而，一旦 proxy 对象实现了某个方法，对应的消息就不会走转发流程，而是直接被 proxy 处理掉了。也就是说，动态添加的方法“吃掉”了本应被转发的消息。

我们可以通过 dump 出来的头文件看到 _UIWebViewScrollViewDelegateForwarder 到底做了什么。它在内部保存了一个真实的 delegate，然后通过 forwardInvocation: 和 methodSignatureForSelector: 将消息转发给这个 delegate。

解决方案

任何动态添加的方法都可能“吃掉”本应被转发的消息。不过我们可以选择不要 Hook 可能转发消息的类。改进后的 Method Swizzling 流程是这样的：

通过 class_getInstanceMethod 查找实例方法。
如果没有实例方法，检查 delegate 是否是 NSProxy 的子类，或者实现了 forwardingTargetForSelector:，forwardInvocation: 这一类的转发方法
若是，则说明可能是 proxy 对象，终止 hook 流程

更好的方法是通过 Proxy 对象拦截发送的消息。我会再写一篇文章描述这一方案。

Swift 中基于闭包的 KVO 的隐患

Sun, 29 Apr 2018 00:00:00 +0000

KVO (Key-Value Observing) 是 Foundation 提供的极其强大的特性，但是使用起来十分啰嗦。好在 Swift 4 提供了一个简洁的包装。我们可以轻松写出以下的代码：

class A: NSObject {
    @objc dynamic var v: Int = 0
}

class B: NSObject {

    let a = A()
    var token: NSKeyValueObservation?

    override init() {
        super.init()
        token = a.observe(\.v, options: [.new]) { _, change in
            print("new value: \(change.newValue!)")
        }
    }
}

根据文档，我们甚至不用在销毁 B 时手动移除观察者，因为 NSKeyValueObservation 在生命周期结束后就会自动停止观察：

when the returned NSKeyValueObservation is deinited or invalidated, it will stop observing.

真的是这样吗？我们来加两个符号断点：

-[NSObject addObserver:forKeyPath:options:context:]
-[NSObject removeObserver:forKeyPath:context:]

然后测试一下：

var b: B? = B()
b = nil

运行到第一行时，我们可以看到确实调用了addObserver，然而，removeObserver 却没有如预期调用。这可不是我们想要的结果，带着观察者被销毁可能会导致一些难以调试的崩溃。

如果我们在第一行和第二行之间插入 b.token = nil，手动释放 KVO，可以发现此时又会调用 removeObserver，而靠 B 来自动释放就会出问题。可以说是非常玄学了。

更加玄学的是，只要调换一下成员声明的顺序，整个问题就消失了：

-     let a = A()
      var token: NSKeyValueObservation?
+     let a = A()

有些同学可能已经猜到问题在哪了。NSKeyValueObservation 内保存了一个观察对象的弱引用，以便在合适的时机注销观察者。第一个例子中，B.a 先销毁，等到 B.token 销毁时，已经找不到目标来注销观察者了。

这里有个非常令人迷惑的逻辑漏洞，token只被 self 引用，保证了token的生命周期不长于 self。而 self 引用了观察对象，保证了观察对象生命周期不短于self。那么观察对象被销毁前，token也会被销毁。如此就保证了观察对象就不会带着观察者被销毁。而事实上，这还取决于成员变量销毁的顺序。

为了避免这种时机问题，最保险的办法是，在 B.deinit 中手动销毁 KVO。

+     deinit {
+         token?.invalidate()
+     }

事实上，第一个例子中的代码并不完全符合苹果官方的示例。如果按照示例来改写的话，应该是这样的：

...
-     let a = A()
+     @objc let a = A()
...
-         token = a.observe(\.v, options: [.new]) { _, change in
+         token = observe(\.a.v, options: [.new]) { _, change in
...

由于观察对象变成了 self，就不会出现上述的问题了。不过需要把对象标注为 @objc，我并不喜欢这种方式。

TL;DR

如果直接对观察对象调用 observe(_:options:changeHandler:) 并保存 token，可能导致观察对象早于 token 被释放。需要在 deinie 中手动调用 token 的 invalidate 方法以注销观察者。

在 Swift 中捕获 Objc 抛出的异常

Fri, 29 Dec 2017 00:00:00 +0000

错误还是异常

一般来说错误分为两种情况。一种是可以预见，可恢复的错误。称为错误（error）。另一种则是不能预见，通常也是不可恢复的致命错误。称为异常（exception）。例如，文件无法打开是错误，数组访问越界则是异常。

在 Objective-C 中，这两种错误分别以 NSError 和 NSException 表示。Apple 有两篇关于此的文档，Dealing with Errors 和 Handling Exceptions。

Swift 从 2.0 开始有了内建错误处理。虽然形式上是我们熟悉的 try-catch(do-catch) 但实际上做的是错误处理，而不是异常。Objc 中原有使用 NSError 的代码被标记为 throws。而原本会抛出异常的代码则使用 fatalError 直接崩溃。

接不住的异常

我个人喜欢 Swift 的设计。它要求开发者显示处理可能的错误，并且其抛出错误的效率远高于 C++ （相比兼任错误处理的异常处理），而对于异常部分，其被设计为尽早退出，避免程序进入未定义区域。但是，这样的设计也造成了一些尴尬的情况，完全排除异常处理的 Swift 无法处理 Objc 中抛出的异常。

例如，反序列化方法 NSKeyedUnarchiver.unarchiveObject(with:) 在失败时会抛出 invalidArchiveOperationException，这个错误无法通过 Swift 的 do-catch 接住。事实上，当你试图用纯 Swift 反序列化一段来源不明的数据时，没有任何办法能避免程序崩溃。

我认为这是一个设计上的失误，这个异常明显是开发阶段可以预见的，但却没有按照错误来处理。iOS 9 / macOS 10.11 引入了另一个不会抛异常的方法 unarchiveTopLevelObjectWithData(:) throws。可惜对于大多数应用来说，系统版本要求太高了。

封装异常处理

我们可以在 Objc 做一层封装，以便在纯 Swift 中处理异常：

void catchException(void (NS_NOESCAPE ^ _Nonnull tryBlock)(), void(NS_NOESCAPE ^ _Nullable catchBlock)(NSException * _Nonnull e)) {
    @try {
        tryBlock();
    }
    @catch (NSException *exception) {
        if (catchBlock) {
            catchBlock(exception);
        }
    }
}

这个方法导入到 Swift 中是这样的：catchException(_: () -> Void, _: ((NSException) -> Void)?)。于是我们可以这样做：

var result: Any?
catchException({
    do {
        let data = try Data(contentsOf: url)
        let obj = NSKeyedUnarchiver.unarchiveObject(with: data)
        result = obj
    } catch {
        // error handling
    }
}, { e in
    // exception handling
})
// use `result`

还是很不方便，这样做有几个问题：

无法在 block 中返回值到外部
不保证控制流
和 Swift 原生 error 嵌套时难以处理

我们再用 Swift 包一层：

extension NSException: Error {
    public class func `catch`<T>(_ block: () throws -> T) throws -> T {
        var _result: T?
        var _error: Error?
        catchException({
            do {
                _result = try block()
            } catch {
                _error = error
            }
        }, { error in
            _error = error
        })
        if let _error = _error {
            throw _error
        } else {
            return _result!
        }
    }
}

这里作为 NSException 的类方法以避免污染命名空间。注意我们让 NSException 遵循 Error，这样允许我们直接抛出把 exception 作为错误抛出。

于是我们可以这样：

let obj = try NSException.catch { () -> Any? in
    let data = try Data(contentsOf: url)
    return NSKeyedUnarchiver.unarchiveObject(with: data)
}
// use `obj`

错误处理则是这样：

do {
    // try NSException.catch
} catch let error as NSException {
    // exception handling
} catch {
    // error handling
}

无论如何，捕获 NSException 并允许程序继续运行是极不推荐的。Objc 被假定不能从异常中恢复，所以 ARC 默认不保证异常安全，抛出异常可能导致内存泄漏。务必只在必要时这样做。

【译】Swift 4 中的弱引用

Wed, 27 Sep 2017 00:00:00 +0000

本文译自 Friday Q&A 2017-09-22: Swift 4 Weak References，作者 Mike Ash。

译者 ddddxxx，自由转载，请注明出处。

Swift 刚开源不久，我写了一篇关于弱引用如何实现的文章。时过境迁，这一实现已经发生了改变。我将谈谈当前的实现方法，以及和旧版本的对比。

原有的实现

鉴于有些人已经忘了原有的实现，且不想读之前的文章，让我们快速回顾一下它是怎么实现的

在原来的实现中，Swift 对象有两个引用计数：强引用计数和弱引用计数。当强引用计数归零，而弱引用计数仍不为零时，这个对象将被销毁（destroy），但内存不会被释放（deallocate）。这导致被弱引用指向的对象成为某种僵尸对象驻留在内存中。

加载弱引用时，runtime 将会检查对象是否为僵尸对象。若是，则清零弱引用，并将弱引用计数减 1。当弱引用计数归零时则释放内存。这意味着一旦访问了对它们的弱引用，僵尸对象就会被清除。

我喜欢这个简洁的实现，但是它也有缺陷。一个缺陷是，僵尸对象可能在内存中停留很长时间。对于那些有大型实例的类（因为它包含很多成员变量，或使用 ManagedBuffer 这样的方法来分配额外内存），可能是极大的浪费。

编写之前的文章后我还发现了另一个问题，它在并发访问时不是线程安全的。这个问题随后修复了，但是对其的讨论表明，它的实现者需要更好的方法来实现弱引用，为了能更好的适应类似的状况。

对象数据

Swift 中的“一个对象”是由多个部分构成的。

首先，最明显的是，源代码中声明的的存储属性。它们可以由程序员直接访问。

第二部分，是对象的类。它被用于动态派发，以及内建的 type(of:) 函数。大多数情况下，它是隐藏的，尽管动态派发和 type(of:) 暗示了它的存在。

第三部分，是各种引用计数。它们完全不可见，除非你做一些骚操作，例如读对象的原始内存，或者说服编译器让你调用 CFGetRetainCount。

第四部分，通过 Objective-C runtime 添加的辅助信息，例如 Objective-C 弱引用表（Objective-C 会单独追踪每个弱指针）和关联对象（associated object）。

你要把这些信息储存在哪？

在 Objective-C 中，类型信息和存储属性（即实例变量）都内联存储在对象的内存中。类型占用了第一个指针大小的块，实例变量尾随其后。辅助信息存储在额外的表中。当你使用关联对象（associated object）时，runtime 会查找一个大哈希表，它的键是对象的指针。这有些慢，并且这一操作必须加锁以避免多线程操作失败。引用计数有时保存在对象的内存中，有时保存在外部表中，这取决于系统版本和 CPU 架构。

在 Swift 原有的实现中，类，引用计数和存储属性都内联存储。而辅助信息仍然存储在单独的表中。

让我们把这些语言的实现放在一边，先问一个问题：它们应该怎样存储？

每个位置各有优劣。存储在对象的内存中的数据访问起来很快，但始终占用空间。存储在额外表中的数据访问起来稍慢，但是若是对象没有这些数据，它们就不占用空间。

Objective-C 传统上不在对象内部保存引用计数，至少有一部分原因就是为此。Objective-C 加入引用计数时，电脑性能远不如现在，并且内存极为有限。典型的 Objective-C 程序中的大多数对象只有一个所有者，即引用计数为 1。在对象内存中留出 4 字节的空间用于存储 1 是很浪费的。通过使用外部表，1 这样的常见值可以由表项不存在来表示，从而减少内存消耗。

每一个对象都有一个类，并且会经常访问。每次调用动态方法都需要它。它应该直接保存在对象内存中。存储在外部也不会有任何好处。

存储属性预计可以快速访问，对象是否拥有它们是在编译期决定的。如果一个对象没有没有存储属性，就可以不分配空间。所以它们应该直接保存在对象内部。

每一个对象都有引用计数。虽然不是所有对象的引用计数都不为 1，但这仍然是很常见的情况，而且现在内存已经很大了。它或许应该直接保存在对象内存里。

大多数对象都没有弱引用计数或是关联对象。为它们在对象内存中分配空间是很浪费的。它们应该保存在外部。

这是合理的权衡，但也很讨厌。对于那些有弱引用计数和关联对象的对象来说，这实在有些慢。我们怎样能解决这个问题呢？

Side Tables

Swift 新的弱引用的实现引入了一个名为 side table 的概念。

Side table 是一个单独的内存块，用于保存一个对象的额外信息。它是可选的，这意味着一个对象可能有 side tables，也可能没有。那些需要 side table 功能的对象会造成额外开销，而那些不需要的对象则不必付出任何开销。

每个对象都有一个指向其 side table 的指针，而 side table 中也有一个指向原始对象的指针。side table 还可以存储其它信息，例如关联对象。

为了避免 side table 带来的 8 字节空间开销，Swift做了一个漂亮的优化。对象的第一个字是它的类，下一个字是引用计数。当一个对象需要 side table 时，第二个字将被重新用作 side table 指针。因为对象仍需引用计数，所以引用计数将保存在 side table 中。这两种情况将由其中的一个位来区分，从而决定保存的是引用计数还是 side table。

side table 允许 Swift 保持原有引用计数的基本形式，并修复其缺陷。弱引用不再指向对象本身，而是直接指向 side table。

因为 side table 已知很小，这样就不会有弱引用指向大对象导致的内存浪费，所以问题自然就消失了。这也指明了线程安全问题的简单解决方案：不用提前清零弱引用。既然已知 side table 比较小，指向它的弱引用可以持续保留，直到这些引用自身被覆盖或销毁。

我要提醒一下，当前的 side table 实现只保存引用计数和指向原始对象的指针。其它用途，例如关联对象，只是一个假设。Swift 没有内建关联对象功能，而 Objective-C API 仍在使用全局表。

该技术有很大的潜力，我们或许能在不久的将来看到其它用法，例如关联对象。我希望这将打开在类扩展中声明存储属性等其它漂亮功能的大门。

代码

由于 Swift 已经开源，关于这些的代码都能直接访问。

大多数关于 side table 的代码都在 stdlib/public/SwiftShims/RefCount.h

更高层次的弱引用 API，以及丰富的注释，都在 swift/stdlib/public/runtime/WeakReference.h

更多关于堆对象的实现和注释在 stdlib/public/runtime/HeapObject.cpp

我链接到了这些文件的特定版本，以便以后的读者也能看到我在说什么。如果你想看最新，最好的代码，请在点击链接后切换到 master 分支，或任何你感兴趣的内容。

结论

弱引用是一个重要的语言特性。Swift 的初始实现非常聪明，有很多优势，但也有一些问题。通过添加 side table，Swift 的工程师能够在解决问题的同时保留这些优势。side table 也为未来的新功能铺平了道路。

macOS 10.13 SDK 的一个错误，以及解决方案

Sat, 23 Sep 2017 00:00:00 +0000

最近升级了 Xcode 9 GM，并把几个主要项目迁移到了 Swift 4。过程中发现了一个小坑，记下来以供参考。

0

Xcode 9 附带的 macOS 10.13 SDK 中有这样一个改动：

- func validModesForFontPanel(_ fontPanel: NSFontPanel) -> Int
+ func validModesForFontPanel(_ fontPanel: NSFontPanel) -> NSFontPanel.ModeMask

这是一个很 Swift 的改动，其中 NSFontPanel.ModeMask 是一个 OptionSet，这样我们就可以使用数组字面量来生成一个选项集合：

- return Int(NSFontPanelSizeModeMask | NSFontPanelCollectionModeMask | NSFontPanelFaceModeMask)
+ return [.size, .collection, .face]

看起来似乎很美好，然而我们看一下它的定义:

@available(OSX 10.13, *)
public struct ModeMask : OptionSet

这就很尴尬了，这个类要求 macOS 10.13 或更高的系统版本。我们显然不能接受这个条件。

1

看来我们只能使用旧版 API 了。来看一下原有的代码能否工作：

override func validModesForFontPanel(_ fontPanel: NSFontPanel) -> Int
// error: method does not override any method from its superclass

因为方法签名改了，原有的方法自然没有覆盖新的 API。所以我们删掉 override。

func validModesForFontPanel(_ fontPanel: NSFontPanel) -> Int

再次运行程序，发现 FontPanel 并没有遵循我们的设置。这是因为 Swift 4 新的特性，根据 SE-0160，NSObject 子类的方法不会自动生成 Objective-C 入口。所以这个方法在 Objective-C 运行时是不可见的。

根据要求，我们添加 @objc 标签：

@objc func validModesForFontPanel(_ fontPanel: NSFontPanel) -> Int
// error: Overriding method with selector 'validModesForFontPanel:' has incompatible type '(NSFontPanel) -> Int'

方法签名不一致，编译器拒绝生成 Objective-C 入口。

既然有版本限制，给整个方法加上版本限制如何？

@available(OSX 10.13, *)
override func validModesForFontPanel(_ fontPanel: NSFontPanel) -> NSFontPanel.ModeMask
// error: Overriding 'validModesForFontPanel' must be as available as declaration it overrides

到这里似乎所有的路都堵死了，难道只能退回到 Objective-C 来实现吗？

2

其实纯 Swift 的方法也是有的，不过有些复杂。有请 Method Swizzling：

class MyClass: NSObject {

    static let swizzler: () = {
        let cls = MyClass.self
        let sel = #selector(NSObject.validModesForFontPanel)
        let dummySel = #selector(MyClass.dummyValidModesForFontPanel)
        guard let dummyIMP = class_getMethodImplementation(cls, dummySel),
            let dummyImpl = class_getInstanceMethod(cls, dummySel),
            let typeEncoding = method_getTypeEncoding(dummyImpl) else {
                fatalError("failed to replace method \(sel) from \(cls)")
        }
        class_replaceMethod(cls, sel, dummyIMP, typeEncoding)
    }()

    @objc func dummyValidModesForFontPanel(_ fontPanel: NSFontPanel) -> UInt32 {
        // Do what you want
        return NSFontPanelStandardModesMask
    }

}

这里我们动态修改了 NSObject.validModesForFontPanel 的实现。为了使其生效，我们需要在合适的时机调用 _ = MyClass.swizzler。由于不需要原来的实现，这里使用了 class_replaceMethod 而不是 method_exchangeImplementations，事实上，这里的 MyClass 原本并没有 validModesForFontPanel 的实现。

这里的 swizzler 是一个小技巧，由于 Swift 3 废弃了 dispatch_once，这样写可以保证 swizzler 仅构造一次，即 Method Swizzling 仅执行一次。我会再写一篇文章详细解释这一方法。

如何优雅地在 Jekyll 博客中插入高清图片

Mon, 21 Aug 2017 00:00:00 +0000

用 Markdown 插入图片是一件很简单的事，只需要这样写：

![AltText](/path/to/img.jpg)

然而，如果你需要进行更多的控制，情况立刻变得复杂了起来。由于 Markdown 秉持结构和样式分离的原则，你无法在插入图片时控制其大小。要达到这样的目的，你需要使用普通的 <img> 标签：

<img src="/path/to/img.jpg" width="100" height="100" alt="AltText" />

相对前一种语法，后者明显麻烦许多。所幸这种情况一般都是极少数。一般来说，我们只需要使用前一种语法。然而，有一种状况会让你需要大量使用后一种语法 —— Retina 屏幕的截图。一张 100pt * 100pt 的截图事实上是 200px * 200px。贴到文章里之后，电脑又会以 200pt * 200pt 的大小来渲染。你的截图立刻变得大而模糊。为了避免这种状况，你需要手动计算图片的实际大小，然后使用 HTML 语法插入图片。当你需要插入大量图片时，这一工作很快变得枯燥而难以忍受。

当然，你可以通过指定比例从而避免手工计算大小：

<img src="/path/to/img.jpg" width="50%" alt="AltText" />

虽然免去了计算大小，你依然需要使用冗长的 HTML 语法。能不能用 Markdown 语法来做这件事呢？

我们知道有些 Markdown 方言支持调整图片大小，例如：

Mou:
![AltText](/path/to/img.jpg =100x)

MWeb:
![AltText-w100](/path/to/img.jpg)

...

显然，这些在 Jekyll 中都是不支持的。不过，我们有更好的方法：

![AltText @2x]()

只需添加 @2x 后缀，图片就会自动缩放为50%大小

这显然不是 Markdown 或 Jekyll 的功能，在你的博客中使用不会有任何效果。真正的魔法在 CSS 样式表中：

.post-container img[alt~="@2x"] {
    zoom: 50%;
}

我们用到了 CSS 中的属性选择器，它可以对拥有指定属性的 HTML 元素设置样式。在这里，我们对 alt 中包含 @2x 的所有图片添加了 zoom: 50% 属性。

同理，你也可以为 iPhone * Plus 的截图设置三倍缩放：

.post-container img[alt~="@3x"] {
    zoom: 33%;
}

制作跨  平台的动态链接库

Sat, 05 Aug 2017 00:00:00 +0000

注意：这篇文章旨在解决多平台项目中 target 过多的问题，而不会教你制作 Framework 的基础知识。

引言

如果你制作过跨  平台的 framework，你一定遇到过这种情况：

Alamofire 支持 iOS/macOS/tvOS/watchOS，加上测试，总共有 7 个 target。

再看 SnapKit 的：

同样是支持多平台，然而只有两个 Target。它要怎么编译到不同的平台呢？于是我们来看看它的 scheme：

只需要一个 scheme！其中包含了所有的目标平台。每一个都能运行单元测试并通过。

这样的好处是显而易见的。通常多平台的项目都会在不同的 target 间使用相同的编译规则。而多个 target 意味着你需要手动逐个修改编译选项，极其容易出错。我在 SwiftyJSON 的工程中就发现了这样的错误。

多个 target 本身也导致了更多 target，一个 test target 只能运行在一个 scheme 上。所以如果你的项目中有多个 target，你还需要创建等量的 test target 以运行单元测试。

解决方案

其实要做到单 target 非常简单，但是有很多细节需要注意。

单 target 的核心在于，Xcode 使用 Supported Platforms¹ 来标记一个 target 支持的设备，你可以手动添加需要支持的平台。我创建一个新项目作为例子：

这是 Supported Platforms 的默认设置：

添加我们需要支持的平台：

此时在右上角 scheme 中选择平台，发现已经可以选择 My Mac 作为目标，但是看不到 tvOS 和 watchOS 的模拟器。这是因为除了支持的平台以外，我们还要标记支持的设备。这个选项叫做 Target Device Family²，可选的值有 1，2，3，4。

不幸的是，Xcode并不允许我们选择全部的组合：

你需要手动修改工程文件。文件的位置在 PATH/TO/YOUR/PROJECT/YourProjectName.xcodeproj/project.pbxproj。搜索 TARGETED_DEVICE_FAMILY，将对应行的值改为 1,2,3,4。

如果文件中没有对应字段，请在 Xcode 中修改 Target Device Family 的值，并确认该行变为加粗字体。（细字体意味着 pbxproj 中没有对应字段，自动取默认值）

现在你应该可以在 scheme 中选择所有的设备和模拟器了，你还可以在任一平台上编译。不过还有一些事要处理，是关于动态链接库的。

iOS 和 macOS 的程序包中，动态链接库的位置是相同的，都在 (Contents/)Frameworks／。然而二者的可执行文件位置却不同。iOS 的可执行文件直接位于最外层，而 macOS 的可执行文件位于 Contents/MacOS/。所以 iOS 中 framework 的相对位置是 Frameworks/，而 macOS 中则是 ../Frameworks/。我们需要设置不同的加载地址。

这个选项叫做 Runpath Search Path，我们需要额外设置针对 macOS 的选项。

展开该项目，点击 + 符号以添加一个针对 macOS 的设置。

将 macOS 的值改为 @loader_path/../Frameworks 和 @executable_path/../Frameworks。并在 Release 中进行相同的设置。

迁移现有的项目

你可能已经有包含数个 target 的 framework。你可以遵循下列步骤将其合并为单个 target：

选定一个平台的 target 作为目标结果。
遵照上一节的步骤使其支持多个平台。
检查其他 target 的编译选项。对于在 Xcode 中显示为加粗的项目，将其选项合并到目标 target 中。
你的源文件中可能有一些仅用于特定平台的代码。你需要将其添加到目标 target 中，并使用 #if TARGET_OS_XXX(Objc), #if os(XXX)(Swift) 等方法使其仅在特定平台编译。
如果你为每个 target 指定了不同的 Info.plist，我强烈建议你只保留一份。通常来说它们的内容都是相同的。
为目标 target 选择不同的平台编译并测试。通常来说这不会有任何问题。
删除剩余的 target。

开始新的跨平台项目

你可能已经看过一些文章教你如何制作多平台 framework。通常办法是新建一个空的 Xcode 工程，然后依次添加每个平台的 target。整理文件夹以使用同一份源代码。这些都完成后，你就可以遵照上一节的步骤合并这些 target。

不过还有更好的方法。如果你使用 Swift Package Manager 的话，这一切都会简单到难以置信。

To be continued…

引用 Carthage 包

To be continued…

注

Supported Platforms 可选值集合
- macosx
- iphoneos
- iphonesimulator
- appletvos
- appletvsimulator
- watchos
- watchsimulator
↩
Target Device Family 数字对应关系
- 1 = iPhone and iPod touch
- 2 = iPad
- 3 = Apple TV
- 4 = Apple Watch
↩

ddddxxx's Blog

封装 NSRegularExpression

整体设计

Unicode

桥接

构造器

跨平台

其它

Swift 中 String 和 Index 的奇妙行为

String 和 Index

编码

Cache

迷思

Method Swizzling 与 NSProxy

Hook delegate 方法

坑

Proxy 与 消息转发

解决方案

Swift 中基于闭包的 KVO 的隐患

TL;DR

在 Swift 中捕获 Objc 抛出的异常

错误还是异常

接不住的异常

封装异常处理

【译】Swift 4 中的弱引用

原有的实现

对象数据

Side Tables

代码

结论

macOS 10.13 SDK 的一个错误，以及解决方案

0

1

2

如何优雅地在 Jekyll 博客中插入高清图片

制作跨  平台的动态链接库

引言

解决方案

迁移现有的项目

开始新的跨平台项目

引用 Carthage 包

注

Proxy 与消息转发